lkml.org 
[lkml]   [2016]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [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

    \
     
     \ /
      Last update: 2016-01-08 00:01    [W:3.663 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site