RE: [MiNT] Proposal for SLB extension

["Julian Reschke" <reschke@medicaldataservice.de>]

> From: owner-mint@fishpool.com [mailto:owner-mint@fishpool.com]On Behalf
> Of Thomas Binder
> Sent: Monday, April 17, 2000 12:01 PM
> To: mint@fishpool.com
> Subject: Re: [MiNT] Proposal for SLB extension
>
>
> Hi!
>
> On Mon, Apr 17, 2000 at 10:22:12AM +0200, Julian Reschke wrote:
> > The only environment in question would be MiNT with MP enabled.
>
> It seems you haven't read my mails carefully enough. Memory not
> Malloc()ed by MiNT at startup (and that includes the GEMDOS variables of
> TOS, of course) is _not_ at all protected. Why should it help to run
> problematic TSRs before MiNT, if that weren't the case? I already
> pointed that out ...

And I know that.

However this does not necessarily mean that act_pd under MiNT still points
to the same place as in the underlying GEMDOS. And even if it does right
now, that doesn't mean that this will be the case in all future MiNT
releases.

> Of course, using a variable which is also _writeable_ by a user
> application isn't actually a good idea, as it may impose security risks
> (consider an SLB using the basepage address for some access checks).

So that would already be a reason to move the variable-pointed-to by act_pd
into a memory region where processes can't overwrite it.

> > Could you elaborate where you want to put that variable? I would guess
> > it needs to be in the process' memory space, otherwise  you'll
> > probably get a nasty comment from Frank :-)
>
> Why? It just needs to be a variable in memory writeable by the kernel
> and readable by user processes. Unfortunately, the current memory
> protection model doesn't allow for memory of this kind (supervisor
> writeable, user readable), as the MMU trees for supervisor and user mode
> are identical.
>
> Thus, a temporary solution would be global memory, with the security
> risks noted above. Currently, the kernel's BSS segment is global, thus
> using a variable there will do for the moment.

Please confirm with Frank and Konrad :-)