[lkml]   [2016]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 08/10] x86, pkeys: default to a restrictive init PKRU
On Fri, Jul 29, 2016 at 9:30 AM, Dave Hansen <> wrote:
> From: Dave Hansen <>
> 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.

 \ /
  Last update: 2016-07-29 20:21    [W:0.190 / U:24.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site