[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Cookie Jar problem



Hello!

>> As I said on the IRC, I'll see :) For now, if someone _needs_ to use
>> such programs, please compile the kernel -DJAR_PRIVATE. This will
>> bring the previous behaviour back.
>>
>> Generally, the Cookie Jar isn't a place for pointers. Also no
>> application programs should store any cookies in it.
>
> I aggree with you but the situation is not so easy. The protocols like
> XHDI, SCSIDRV, STIK and so on are widely used now.
>
> We need at least a method to get the current gateways and established
> protocols working (it should be enough if Ssystem cookie install will
> install the cookie jar globally for all applications).

As for XHDI, I think there is no big problem, since while the cookie jar is
being copied to the user space, the XHDI cookie value is changed so that it
points to routine in user_things.S, and that routine calls the Sysemu(). So,
unless I miss something, using old XHDI calling method should be safe now
(although I'd prefer programs to directly call the Sysemu(), without looking
up the jar).

I hope this can be also done for SCSIDRV.

As for Ssystem(S_SETCOOKIE), it would have to be able to setup the cookie in
every cookie jar in the system, as if you compile with -DJAR_PRIVATE, there
is no global cookie jar anymore. Despite that, the value of the cookie must
point to a reasonable address. In case of STIK we either make it point to a
global area established by gluestik, and make it unsafe by definition this
way, or integrate STIK emulation into kernel (I'd strongly dislike that).

BTW. the reason why the STiK protocol is used instead of MiNTNET, as I many
times heard on the IRC, is: "because MiNT-Net has gluestik". So the protocol
is so widespread (?) partly "thanks" to the existence of the gluestik. Usual
self-growing paranoia.

There is yet the DHST protocol. It is used by very few programs, and one of
them we have in the CVS, so it can be updated easily. The other is CAB.
Others I don't know. I also don't know about any other protocols like that.

The point of making -DJAR_PRIVATE is such, that the user should be able to
make a 100% safe MiNT/MiNT-Net setup, if he wants to. 100% safety means 100%
of memory protection, without any holes. This is not possible with global
cookie jar, and some other holes which are yet to be fixed.

Obviously, if someone doesn't need such safety, can give up the private
cookie jar and use STiK programs ad libitum.

CVV

--
Konrad M.Kokoszkiewicz
http://draco.atari.org

** Ea natura multitudinis est,
** aut seruit humiliter, aut superbe dominatur (Liv. XXIV,25)
*************************************************************
** Taka to juz natura pospólstwa, albo sluzalczo sie plaszczy,
** albo bezczelnie sie panoszy.