Re: [PATCH 31/31] x86, pkeys: execute-only support

From: Dave Hansen
Date: Thu Jan 07 2016 - 17:13:17 EST


On 01/07/2016 01:10 PM, Andy Lutomirski wrote:
> On Wed, Jan 6, 2016 at 4:01 PM, Dave Hansen <dave@xxxxxxxx> wrote:
>> From: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
>> Protection keys provide new page-based protection in hardware.
>> But, they have an interesting attribute: they only affect data
>> accesses and never affect instruction fetches. That means that
>> if we set up some memory which is set as "access-disabled" via
>> protection keys, we can still execute from it.
>> could lose the bits in PKRU that enforce execute-only
>> permissions. To avoid this, we suggest avoiding ever calling
>> mmap() or mprotect() when the PKRU value is expected to be
>> stable.
>
> This may be a bit unfortunate for people who call mmap from signal
> handlers. Admittedly, the failure mode isn't that bad.

mmap() isn't in the list of async-signal-safe functions, so it's bad
already.

> Out of curiosity, do you have timing information for WRPKRU and
> RDPKRU? If they're fast and if anyone ever implements my deferred
> xstate restore idea, then the performance issue goes away and we can
> stop caring about whether PKRU is in the init state.

I don't have timing information that I can share. From my perspective,
they're pretty fast, *not* like an MSR write or something. I think
they're fast enough to use in the context switch path. I'd say PKRU is
in XSAVE for consistency more than for performance.