linux-kernel - Re: [PATCH 6/9] x86, pkeys: add pkey set/get syscalls

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] [day] [month] [year] [list]

Message-ID: <578D3821.4050705@intel.com>
Date:	Mon, 18 Jul 2016 13:12:17 -0700
From:	Dave Hansen <dave.hansen@...el.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Mel Gorman <mgorman@...hsingularity.net>,
	linux-kernel@...r.kernel.org, x86@...nel.org,
	linux-api@...r.kernel.org, linux-arch@...r.kernel.org,
	linux-mm@...ck.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, dave.hansen@...ux.intel.com,
	arnd@...db.de, hughd@...gle.com, viro@...iv.linux.org.uk,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH 6/9] x86, pkeys: add pkey set/get syscalls

On 07/09/2016 01:37 AM, Ingo Molnar wrote:
>  - There are 16 pkey indices on x86 currently. We already use index 15 for the 
>    true PROT_EXEC implementation. Let's set aside another pkey index for the 
>    kernel's potential future use (index 14), and clear it explicitly in the 
>    FPU context on every context switch if CONFIG_X86_DEBUG_FPU is enabled to make 
>    sure it remains unallocated.

After mulling over this for a week: I really don't think we want to
pre-reserve any keys.

The one bit of consistent feedback I've heard from the folks that are
going to use this is that they want more keys.  The current code does
not reserve any keys (except 0 of course).

Virtually every feature that we've talked about adding on top of this
_requires_ having this allocation mechanism and kernel knowledge of
which keys are in use.  Even having kernel-reserved keys requires
telling userspace about allocation, whether we use pkey_mprotect() for
it or not.

I'd like to resubmit this set with pkey_get/set() removed, but with
pkey_alloc/free() still in place.

Why are folks so sensitive to the number of keys?  There are a few modes
this will get used in when folks want more pkeys that hardware provides.
 Both of them are harmed in a meaningful way if we take some of their
keys away.  Here's how they will use pkeys:
1. As an accelerator for existing mprotect()-provided guarantees.
   Let's say you want 100 pieces of data, but you only get 15 pkeys in
   hardware.  The app picks the 15 most-frequently accessed pieces, and
   uses pkeys to control access to them, and uses mprotect() for the
   other 85.  Each pkey you remove means a smaller "working set"
   covered by pkeys, more mprotect()s and lower performance.
2. To provide stronger access guarantees.  Let's say you have 100
   pieces of data.  To access a given piece of data, you hash its key
   in to a pkey: hash(92)%NR_PKEYS.  Accessing a random bit of data,
   you have a 1/NR_PKEYS chance of a hash collision and access to data
   you should not have access to.  Fewer keys means more data
   corruption.  Losing 2/16 keys means a 15% greater chance of a
   collision on a given access.