On 08/26/2010 12:04 PM, Mike Frysinger wrote:
On Thursday, August 26, 2010 14:19:41 Steve Longerbeam wrote:
The ARM MPU can do something similar. MPU regions can overlap, and a
simple priority scheme is used to decide which region's permissions
apply to a memory access that overlaps (higher numbered regions have
higher priority). So on ARM we can "lock" a PTE/region, by defining
region 0 to cover the entire address space, and give kernel read/write
access, user no access. And region 0 is never overwritten or disabled.
So if an access is made to an address not described by any other region,
region 0 permissions are applied to the access (and a protection fault
is generated if the access was made in user mode).
Note that, with region 0 locked, that only leaves 7 PTEs/regions that
can be swapped in and out for user processes. So with the ARM MPU, we
can't create a region for every mmap(), we would run out of available
entries. So we have to use a trade-off, only create an MPU region for
XIP file mappings (text). All other mappings (non-XIP file mappings and
anonymous mappings) allocate from a common user memory pool (which is
another patch I plan to submit).
i dont understand why running out of entries is a problem. we run out of
entries too as you cant cover 512MiB of SDRAM with 16 entries. we simply take
an exception when this occurs and in the exception handler, we use a basic
round-robin replacement scheme to install a valid PTE (assuming of course the
user has a valid mapping for the excepting address). then we return to the
user process and it continues on.
why wont this scheme work for you too ?
no, you're right, that would work. Of course, it would have a bigger
memory usage for the page tables, and a performance hit (with my
implementation when a process is running there are no faults). But it is
more inline with how MMU kernels work, and it adds process-to-process
protection too.
Steve
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
