On Fri, Jul 29, 2016 at 9:30 AM, Dave Hansen <dave@xxxxxxxx> wrote: > > From: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx> > > 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. > > 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. I think you missed the fpu__clear() caller in kernel/fpu/signal.c. ISTM it might be more comprehensible to change fpu__clear in general and then special case things you want to behave differently. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
