linux-kernel - Re: [PATCH 10/26] x86, pkeys: notify userspace about protection key faults

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]

Message-ID: <20150924093026.GA29699@gmail.com>
Date:	Thu, 24 Sep 2015 11:30:26 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Dave Hansen <dave@...1.net>
Cc:	x86@...nel.org, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 10/26] x86, pkeys: notify userspace about protection key
 faults


* Ingo Molnar <mingo@...nel.org> wrote:

> > --- a/include/uapi/asm-generic/siginfo.h~pkeys-09-siginfo	2015-09-16 10:48:15.584161859 -0700
> > +++ b/include/uapi/asm-generic/siginfo.h	2015-09-16 10:48:15.592162222 -0700
> > @@ -95,6 +95,13 @@ typedef struct siginfo {
> >  				void __user *_lower;
> >  				void __user *_upper;
> >  			} _addr_bnd;
> > +			int _pkey; /* FIXME: protection key value??
> > +				    * Do we really need this in here?
> > +				    * userspace can get the PKRU value in
> > +				    * the signal handler, but they do not
> > +				    * easily have access to the PKEY value
> > +				    * from the PTE.
> > +				    */
> >  		} _sigfault;
> 
> A couple of comments:
> 
> 1)
> 
> Please use our ABI types - this one should be 'u32' I think.
> 
> We could use 'u8' as well here, and mark another 3 bytes next to it as reserved 
> for future flags. Right now protection keys use 4 bits, but do you really think 
> they'll ever grow beyond 8 bits? PTE bits are a scarce resource in general.
> 
> 2)
> 
> To answer your question in the comment: it looks useful to have some sort of 
> 'extended page fault error code' information here, which shows why the page fault 
> happened. With the regular error_code it's easy - with protection keys there's 16 
> separate keys possible and user-space might not know the actual key value in the 
> pte.

Btw., alternatively we could also say that user-space should know what protection 
key it used when it created the mapping - there's no need to recover it for every 
page fault.

OTOH, as long as we don't do a separate find_vma(), it looks cheap enough to look 
up the pkey value of that address and give it to user-space in the signal frame.

Btw., how does pkey support interact with hugepages?

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/