All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Dave Hansen <dave@sr71.net>, linux-kernel@vger.kernel.org
Cc: x86@kernel.org, linux-api@vger.kernel.org,
	linux-arch@vger.kernel.org, linux-mm@kvack.org,
	torvalds@linux-foundation.org, akpm@linux-foundation.org,
	luto@kernel.org, mgorman@techsingularity.net,
	dave.hansen@linux.intel.com, arnd@arndb.de
Subject: Re: [PATCH 08/10] x86, pkeys: default to a restrictive init PKRU
Date: Mon, 1 Aug 2016 16:42:51 +0200	[thread overview]
Message-ID: <cd74ae8b-36e4-a397-e36f-fe3d4281d400@suse.cz> (raw)
In-Reply-To: <20160729163021.F3C25D4A@viggo.jf.intel.com>

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>

WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz>
To: Dave Hansen <dave@sr71.net>, linux-kernel@vger.kernel.org
Cc: x86@kernel.org, linux-api@vger.kernel.org,
	linux-arch@vger.kernel.org, linux-mm@kvack.org,
	torvalds@linux-foundation.org, akpm@linux-foundation.org,
	luto@kernel.org, mgorman@techsingularity.net,
	dave.hansen@linux.intel.com, arnd@arndb.de
Subject: Re: [PATCH 08/10] x86, pkeys: default to a restrictive init PKRU
Date: Mon, 1 Aug 2016 16:42:51 +0200	[thread overview]
Message-ID: <cd74ae8b-36e4-a397-e36f-fe3d4281d400@suse.cz> (raw)
In-Reply-To: <20160729163021.F3C25D4A@viggo.jf.intel.com>

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>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2016-08-01 14:43 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-29 16:30 [PATCH 00/10] [v6] System Calls for Memory Protection Keys Dave Hansen
2016-07-29 16:30 ` Dave Hansen
2016-07-29 16:30 ` [PATCH 01/10] x86, pkeys: add fault handling for PF_PK page fault bit Dave Hansen
2016-07-29 16:30   ` Dave Hansen
2016-09-09 11:10   ` [tip:mm/pkeys] x86/pkeys: Add " tip-bot for Dave Hansen
2016-07-29 16:30 ` [PATCH 02/10] mm: implement new pkey_mprotect() system call Dave Hansen
2016-07-29 16:30   ` Dave Hansen
2016-09-09 11:11   ` [tip:mm/pkeys] mm: Implement " tip-bot for Dave Hansen
2016-07-29 16:30 ` [PATCH 03/10] x86, pkeys: make mprotect_key() mask off additional vm_flags Dave Hansen
2016-07-29 16:30   ` Dave Hansen
2016-09-09 11:11   ` [tip:mm/pkeys] x86/pkeys: Make " tip-bot for Dave Hansen
2016-07-29 16:30 ` [PATCH 04/10] x86, pkeys: allocation/free syscalls Dave Hansen
2016-07-29 16:30   ` Dave Hansen
2016-09-09 11:12   ` [tip:mm/pkeys] x86/pkeys: Allocation/free syscalls tip-bot for Dave Hansen
2016-07-29 16:30 ` [PATCH 05/10] x86: wire up protection keys system calls Dave Hansen
2016-07-29 16:30   ` Dave Hansen
2016-07-29 16:30   ` Dave Hansen
2016-09-09 11:12   ` [tip:mm/pkeys] x86: Wire " tip-bot for Dave Hansen
2016-07-29 16:30 ` [PATCH 06/10] generic syscalls: wire up memory protection keys syscalls Dave Hansen
2016-07-29 16:30   ` Dave Hansen
2016-09-09 11:12   ` [tip:mm/pkeys] generic syscalls: Wire " tip-bot for Dave Hansen
2016-07-29 16:30 ` [PATCH 07/10] pkeys: add details of system call use to Documentation/ Dave Hansen
2016-07-29 16:30   ` Dave Hansen
2016-09-09 11:13   ` [tip:mm/pkeys] pkeys: Add " tip-bot for Dave Hansen
2016-07-29 16:30 ` [PATCH 08/10] x86, pkeys: default to a restrictive init PKRU Dave Hansen
2016-07-29 16:30   ` Dave Hansen
2016-07-29 17:29   ` Andy Lutomirski
2016-07-29 17:29     ` Andy Lutomirski
2016-07-29 17:50     ` Dave Hansen
2016-07-29 17:50       ` Dave Hansen
2016-07-29 19:44       ` Andy Lutomirski
2016-07-29 19:44         ` Andy Lutomirski
2016-08-01 14:42   ` Vlastimil Babka [this message]
2016-08-01 14:42     ` Vlastimil Babka
2016-08-01 14:58     ` Dave Hansen
2016-08-01 14:58       ` Dave Hansen
2016-08-02  8:20       ` Vlastimil Babka
2016-08-02  8:20         ` Vlastimil Babka
2016-09-09 11:13   ` [tip:mm/pkeys] x86/pkeys: Default " tip-bot for Dave Hansen
2016-07-29 16:30 ` [PATCH 09/10] x86, pkeys: allow configuration of init_pkru Dave Hansen
2016-07-29 16:30   ` Dave Hansen
2016-08-02  8:28   ` Vlastimil Babka
2016-08-02  8:28     ` Vlastimil Babka
2016-08-02 14:37     ` Dave Hansen
2016-08-02 14:37       ` Dave Hansen
2016-09-09 11:14   ` [tip:mm/pkeys] x86/pkeys: Allow " tip-bot for Dave Hansen
2016-07-29 16:30 ` [PATCH 10/10] x86, pkeys: add self-tests Dave Hansen
2016-07-29 16:30   ` Dave Hansen
2016-09-09 11:14   ` [tip:mm/pkeys] x86/pkeys: Add self-tests tip-bot for Dave Hansen
2016-08-08 23:18 [PATCH 00/10] [v6] System Calls for Memory Protection Keys Dave Hansen
2016-08-08 23:18 ` [PATCH 08/10] x86, pkeys: default to a restrictive init PKRU Dave Hansen
2016-08-08 23:18   ` Dave Hansen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cd74ae8b-36e4-a397-e36f-fe3d4281d400@suse.cz \
    --to=vbabka@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=dave@sr71.net \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mgorman@techsingularity.net \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.