Messages in this thread | | | Subject | Re: [PATCH 08/10] x86, pkeys: default to a restrictive init PKRU | From | Vlastimil Babka <> | Date | Mon, 1 Aug 2016 16:42:51 +0200 |
| |
On 07/29/2016 06:30 PM, Dave Hansen wrote: > From: Dave Hansen <dave.hansen@linux.intel.com> > > PKRU is the register that lets you disallow writes or all access > to a given protection key. > > The XSAVE hardware defines an "init state" of 0 for PKRU: its > most permissive state, allowing access/writes to everything. > Since we start off all new processes with the init state, we > start all processes off with the most permissive possible PKRU. > > This is unfortunate. If a thread is clone()'d [1] before a > program has time to set PKRU to a restrictive value, that thread > will be able to write to all data, no matter what pkey is set on > it. This weakens any integrity guarantees that we want pkeys to > provide. > > To fix this, we define a very restrictive PKRU to override the > XSAVE-provided value when we create a new FPU context. We choose > a value that only allows access to pkey 0, which is as > restrictive as we can practically make it. > > This does not cause any practical problems with applications > using protection keys because we require them to specify initial > permissions for each key when it is allocated, which override the > restrictive default.
Here you mean the init_access_rights parameter of pkey_alloc()? So will children of fork() after that pkey_alloc() inherit the new value or go default?
> In the end, this ensures that threads which do not know how to > manage their own pkey rights can not do damage to data which is > pkey-protected. > > 1. I would have thought this was a pretty contrived scenario, > except that I heard a bug report from an MPX user who was > creating threads in some very early code before main(). It > may be crazy, but folks evidently _do_ it. > > Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
| |