[Qemu-devel] handling emulation fine-grained memory protection

[Qemu-devel] handling emulation fine-grained memory protection

[Peter Maydell]

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

Re: [Qemu-devel] handling emulation fine-grained memory protection

[Richard Henderson]

On 07/03/2017 03:04 AM, Peter Maydell wrote:
> 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.

It's close..  We need 3 bits that do not overlap any requested alignment.

Does the v7m profile have 8-byte aligned operations?  I see that STREXD is out, 
and I can't think of anything else.  So bits 8, 16, 32 are up for grabs, which 
does fit a 64-byte page minimum.

That said...

> 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?

I think it would be simpler to have a separate thing, since the regular subpage 
handling requires memory allocation.

I would just think about a bit, TLB_PROT_RECHECK or so, that not only takes the 
slow path through the helper, but also the slow path back through tlb_fill.

Since these are defined by system registers, I can imagine there can only be a 
few pages for which this fine grained handling might apply any any one time. 
This would certainly be preferable to reducing the effectiveness of the entire 
TLB by a factor of 16.


r~

Re: [Qemu-devel] handling emulation fine-grained memory protection

[Peter Maydell]

On 3 July 2017 at 17:07, Richard Henderson <rth@twiddle.net> wrote:
> On 07/03/2017 03:04 AM, Peter Maydell wrote:
>> 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.
>
>
> It's close..  We need 3 bits that do not overlap any requested alignment.
>
> Does the v7m profile have 8-byte aligned operations?  I see that STREXD is
> out, and I can't think of anything else.  So bits 8, 16, 32 are up for
> grabs, which does fit a 64-byte page minimum.

Looking at section B5.4 in the v8M ARM ARM, it lists only
alignment faults for non-halfword-aligned halfword accesses
and for non-word-aligned various, so we don't need 8-byte
alignment checks.

> That said...
>
>> 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?
>
>
> I think it would be simpler to have a separate thing, since the regular
> subpage handling requires memory allocation.
>
> I would just think about a bit, TLB_PROT_RECHECK or so, that not only takes
> the slow path through the helper, but also the slow path back through
> tlb_fill.
>
> Since these are defined by system registers, I can imagine there can only be
> a few pages for which this fine grained handling might apply any any one
> time. This would certainly be preferable to reducing the effectiveness of
> the entire TLB by a factor of 16.

Yes, that was somewhat my feeling too -- really tiny TLB pages
are not very nice, and most pages probably won't be finegrained.

thanks
-- PMM

Re: [Qemu-devel] handling emulation fine-grained memory protection

[Richard Henderson]

On 07/03/2017 09:40 AM, Peter Maydell wrote:
>> Since these are defined by system registers, I can imagine there can only be
>> a few pages for which this fine grained handling might apply any any one
>> time. This would certainly be preferable to reducing the effectiveness of
>> the entire TLB by a factor of 16.
> 
> Yes, that was somewhat my feeling too -- really tiny TLB pages
> are not very nice, and most pages probably won't be finegrained.

Coming back to this, might it make sense to choose a *larger* page size for M 
profile?  1K is awfully small.  Any idea how aligned the region start/end tends 
to be for real applications?

If we're only taking this extra trap for the first and last page of a region, 
when the application happens to use a size/alignment that conflicts with the 
page size that we choose, then a much larger page size choice might perform 
well overall.


r~