For the ARM v7M microcontrollers we currently treat their memory protection unit like a funny kind of MMU that only has a 1:1 address mapping. This basically works but it means that we can only support protection regions which are a multiple of 1K in size and on a 1K address boundary (because that's what we define as the "page size" for it). The real hardware lets you define protection regions on a granularity down to 64 bytes (both size and address).
So far we've got away with this, but I think only because the payloads we've tested haven't really used the MPU much or at all. With v8M I expect the MPU (and its secure/non-secure cousin the Security Attribution Unit) to be much more heavily used, so it would be nice if we could lift this limitation somehow. Does anybody have any good ideas for how this ought to be done? We could wind down the "page size" for these CPUs (since we now have runtime-configurable-page-size for ARM CPUs this shouldn't compromise the A profile cores which can stick to 1K or 4K pages) but I don't think we can get down as low as 64 bytes due to all the things we keep in the low bits of TLB entries. I'm guessing we'd need to have "this page has fine grained protection regions" imply "take the slow path" and then do the protection check in the slow path. Alex Graf pointed out to me a while back that we already have a data structure for handling sub-page-sized things in the slow path (the subpage handling in the memory system), but can we easily (or otherwise) use it, or would it be simpler just to have a separate thing? There are probably some awkward corner cases too, for instance translate.c code would have to cope with the fact that it would now be possible for the first address in a page to be executable but later addresses in the same page not be executable... Any thoughts/ideas/suggestions? thanks -- PMM