This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to design simple memory protection using MMU attributes & modes ?

Hello,

Can anyone give some points as to how to design simple memory protection model, of standalone OS application composed tasks, each has its own region/section with attributes such as read only, write only, shared memory etc.

I mean, when a region has some access limitation, than this access limitation is for everyone including himself. 

I want to make a simple process-like application, so that each process has its own memory where the process can read/write, yet other process cannot.

I tried to find a similar work/wiki with google's assistance, but surprisingly, I did not find anything !

Thank you!

Ran

Parents
  • Hi Ran,

    The translation tables don't restrict access based on any kind of process ID, the only access permission granularity is unprivileged (i.e. user space) and privileged (i.e. kernel space-ish.)

    The way to do per-process access restrictions is to take advantage of the fact that, on any CPU, only one thread is active at any one time.  You can then have different translation table, with different mappings, one for each process.  As the scheduler changes the active process it also changes which translation table is in use.

    A nice feature of the Arm architecture is that EL0/1 has two translation table registers (TTBR0 and TTBR1) so one can be used for kernel mapping that don't change and one can be used to point to the table for the current process and therefore be easily updated.

    Pete.

Reply
  • Hi Ran,

    The translation tables don't restrict access based on any kind of process ID, the only access permission granularity is unprivileged (i.e. user space) and privileged (i.e. kernel space-ish.)

    The way to do per-process access restrictions is to take advantage of the fact that, on any CPU, only one thread is active at any one time.  You can then have different translation table, with different mappings, one for each process.  As the scheduler changes the active process it also changes which translation table is in use.

    A nice feature of the Arm architecture is that EL0/1 has two translation table registers (TTBR0 and TTBR1) so one can be used for kernel mapping that don't change and one can be used to point to the table for the current process and therefore be easily updated.

    Pete.

Children
No data