Messages in this thread | | | From | Andy Lutomirski <> | Date | Thu, 7 Jan 2016 14:44:14 -0800 | Subject | Re: [PATCH 31/31] x86, pkeys: execute-only support |
| |
On Thu, Jan 7, 2016 at 2:13 PM, Dave Hansen <dave@sr71.net> wrote: > On 01/07/2016 01:10 PM, Andy Lutomirski wrote: >> On Wed, Jan 6, 2016 at 4:01 PM, Dave Hansen <dave@sr71.net> wrote: >>> From: Dave Hansen <dave.hansen@linux.intel.com> >>> 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.
mmap the POSIX function may not be, but mmap the syscall is just a syscall. Also, I'm moderately confident that there are synchronous signals, too. If not, there should be (e.g. raise with an unblocked signal).
> >> 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. >
I'll play with this at some point. Probably not until I get the right hardware.
--Andy
| |