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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 7 Jan 2016 14:44:14 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Dave Hansen <dave@...1.net>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>, X86 ML <x86@...nel.org>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kees Cook <keescook@...gle.com>
Subject: Re: [PATCH 31/31] x86, pkeys: execute-only support

On Thu, Jan 7, 2016 at 2:13 PM, Dave Hansen <dave@...1.net> wrote:
> On 01/07/2016 01:10 PM, Andy Lutomirski wrote:
>> On Wed, Jan 6, 2016 at 4:01 PM, Dave Hansen <dave@...1.net> wrote:
>>> From: Dave Hansen <dave.hansen@...ux.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