linux-kernel - Re: [PATCH 08/10] x86, pkeys: default to a restrictive init PKRU

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: <cd74ae8b-36e4-a397-e36f-fe3d4281d400@suse.cz>
Date:	Mon, 1 Aug 2016 16:42:51 +0200
From:	Vlastimil Babka <vbabka@...e.cz>
To:	Dave Hansen <dave@...1.net>, linux-kernel@...r.kernel.org
Cc:	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,
	luto@...nel.org, mgorman@...hsingularity.net,
	dave.hansen@...ux.intel.com, arnd@...db.de
Subject: Re: [PATCH 08/10] x86, pkeys: default to a restrictive init PKRU

On 07/29/2016 06:30 PM, Dave Hansen wrote:
> From: Dave Hansen <dave.hansen@...ux.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@...ux.intel.com>