Re: Ada's Slide To Oblivion ...

[Ole-Hjalmar Kristensen <oleh@vlinux.voxelvision.no>]

Ian Wild <ian@cfmu.eurocontrol.be> writes:

> Ole-Hjalmar Kristensen wrote:
> >  
> > ??? This is pure fantasy. How do you think the code got into the code
> > space in the first place?
> 
> (sigh)
> 
> Let's take the example of a 68000 'cos I've got the data sheet
> readily available.  There are three lines coming out of the
> processor which distinguish various spaces.  Of interest are:
> 
>   supervisor code
>   supervisor data
>   user code
>   user data
> 
> If the OS is clever, and many of them were, it's set up the MMU
> tables such that 'user code' exists at some point in 'supervisor
> data', at least long enough to load the executable from disc.  At
> some later point it may re-map things so that 'user data' exists
> at that same address in 'supervisor data', letting it initialise
> the bss.  At some late stage it initialises the MMU so that
> 'user code' starts at address 0, 'user data' starts at address 0
> (but with the first page unmapped to catch NULL pointers), and
> does a mode switch.  There is then NO WAY from user mode to write
> to the 'user code' space, and only limited (ie PC relative) access
> for reading.
> 
> Oh - before anyone suggest it, no, the MMU is not visible from
> user mode either.
> 
> Is this really rocket science?  I would've though the above
> sufficiently obvious that I could have got a patent on it.


What you are saying now is correct, but that's not what you said in your 
previous post. Of course these processors have mecahnisms which can be
used to protect code from being overwritten, but that's very different 
your statement that:

>There
> are wires that come out of the processor to say which space to use.  On
> such a system there's NO WAY to write to code space,
                       ********