HenryCase wrote:
bloodline wrote:
The answer is: Not very. i.e. Impossible. While the exec design team clearly envisiaged memory protection at some future time... none of the rest of the OS design team did (I think intuition alone is a very bad boy!), and public/private memory flags were never enforced.
Tasks and libraries happily pass memory pointers around without a care in the world.
That is useful information to me bloodline, so thank you for that. None of what you describe makes retrofitting memory protection impossible though.
It does if you want all your old software and large parts of the OS to keep working... :-D
Let me explain...
:nervous:
The memory doesn't have to flag whether it is public or private as long as the API functions asking for memory space are not allowed direct access to the memory.
When you request memory from exec you are supposed to flag the memory if it is to shared or private. Although in AmigaOS this actually does nothing (due to the early machines not having an MMU), this tells the OS that the memory should be allocated in either the task's private address space or if it should be allocated in some public memory pool (where anyone can mess around).
Due to the lack of MMU, these flags were never enforced so no amiga software actually bothers to set them properly... Enforcing them nnow after 20 years would break a lot of apps.
You put an OS layer inbetween memory allocation functions and the real memory. This MMU gives the memory allocation functions the impression that it is writing directly to the memory, when in reality it is controlling memory allocation/deallocation and protecting unwanted memory access.
I don't understand... The way memory protection would work is that each task gets it's own address space... in effect each task gets up to 4gig of address space to itself. I shall expalin the reprocussions of this later...
A good book on how MMU's work should give you a better understanding... The intel developer docs are a great place to start!
For those memory functions called without a flag, the memory status is set to private by default.
Well that would break EVERY app, since it is the exact opposite of the current situation... for there to be any hope of this working at all... the default behaviour needs to be the same as current behaviour.
You then have the issue of inter-program communication. For this, you want to allow the programs to attempt communication, but you want to prevent incorrect values being entered into the program space and potentially crashing the OS. You allow the value to be passed by the first program, but the MMU checks to see if the value is valid before it passing it on to the second program.
One of the great things about AmigaOS is that is places no restrictons on what is passed in an exec message... In effect the OS has no idea what the programs are sending to each other. (it's the same problem as the parasite emulator we discussed before).
Now here is where the problems begin... You have two tasks, both have their own address spaces... one task sends a pointer to a data block to another task in a message... that pointer is meaningless to the receiving task, since the pointer is either not vaild in its address space or pointer for somthing completely different!
The only way around this is to have a public pool of memory mapped to the same address window in all task address spaces... but since the public/private flags were ignored this can't work.
For the few programs where this method is not suitable (where you need as much speed as possible for example) the MMU can either be switched off or the program can be patched. The MMU will only be known to the new kernel and the user, the API functions will not be aware of its existence, so they will not mind using non memory protected mode.
You can't just switch off the MMU once it is on... the whole integrity of the memory structure is maintained by this device... Switching it off would leave the memory in effectly a random jumble of 4k blocks that used to mean something...
Those are my ideas as they stand at the moment. As I said I am still conducting research into the feasibility of a memory protected AROS.
Do you think my ideas are sound in principal?
Not really :-)
MMU's are hard to get your head around at first but some solid study and a lot of running it out on paper with a pencil will give you a good idea of the issues here...
