I can only really think of two ways to keep tasks from writing in each other's memory. The first is to change the segment and limits whenever you switch tasks (so if a task tries to go out of its area, it will seg fault). This seems a pretty reasonable thing to do on the x86, but apparently most systems don't support segments.
The second is to only have the page tables for the current task marked as present. However, this would mean that during task switching you would have to mark all the old task's memory as not present and all the new task's memory as present. So I'm wondering if it is reasonable to do all this during the task switch or if it would take up too much time (task switching is supposed to be as fast as possible after all).
Also, are there any other ways of doing this?
Protecting Task Memory
Re:Protecting Task Memory
somebody more experienced should probably expand on or refute this, but until that happens, i believe that you can simply switch the CR3 register (Page Directory Base Register) to point to a completely new page directory on each task switch. that way, all page directories stay in memory so you dont have to switch present bits on and off on a task switch, just change what page directory the current process is using.
Re:Protecting Task Memory
Yes, that's pretty much it.
Every good solution is obvious once you've found it.
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Protecting Task Memory
alternatively, you can have several threads in the same address space that would still be protected from each other by Local Descriptor Tables. The scheduler would switch from task A's LDT to task B's LDT, which would result in a new set of segment, and thus a new set of memory access rights.
In the case of shell tools, for instance, it could be rather handy to have them all in one address space, sharing memory for pipes rather than using kernel-level sharing (files), and allowing faster switch than between independent process (due to the absence of TLB flushing)
In the case of shell tools, for instance, it could be rather handy to have them all in one address space, sharing memory for pipes rather than using kernel-level sharing (files), and allowing faster switch than between independent process (due to the absence of TLB flushing)