All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave@sr71.net>
To: Ingo Molnar <mingo@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>,
	linux-arch <linux-arch@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Mel Gorman <mgorman@techsingularity.net>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux API <linux-api@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Hugh Dickins <hughd@google.com>, "H. Peter Anvin" <hpa@zytor.com>,
	X86 ML <x86@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>
Subject: Re: [PATCH 6/9] x86, pkeys: add pkey set/get syscalls
Date: Tue, 12 Jul 2016 08:39:07 -0700	[thread overview]
Message-ID: <57850F1B.4080306@sr71.net> (raw)
In-Reply-To: <20160712071305.GA13444@gmail.com>

On 07/12/2016 12:13 AM, Ingo Molnar wrote:
>> > Remember, PKRU is just a *bitmap*.  The only place keys are stored is in the 
>> > page tables.
> A pkey is an index *and* a protection mask. So by representing it as a bitmask we 
> lose per thread information. This is what I meant by 'incomplete shadowing' - for 
> example the debug code couldn't work: if we cleared a pkey in a task we wouldn't 
> know what to restore it to with the current data structures, right?

Right.  I actually have some code to do the shadowing that I wrote to
explore how to do different PKRU values in signal handlers.  The code
only shadowed the keys that were currently allocated, and used the
(mm-wide) allocation map to figure that out.  It did not have a separate
per-thread concept of which parts of PKRU need to be shadowed.

It essentially populated the shadow value on all pkru_set() calls.

WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave@sr71.net>
To: Ingo Molnar <mingo@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>,
	linux-arch <linux-arch@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Mel Gorman <mgorman@techsingularity.net>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux API <linux-api@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Hugh Dickins <hughd@google.com>, "H. Peter Anvin" <hpa@zytor.com>,
	X86 ML <x86@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>
Subject: Re: [PATCH 6/9] x86, pkeys: add pkey set/get syscalls
Date: Tue, 12 Jul 2016 08:39:07 -0700	[thread overview]
Message-ID: <57850F1B.4080306@sr71.net> (raw)
In-Reply-To: <20160712071305.GA13444@gmail.com>

On 07/12/2016 12:13 AM, Ingo Molnar wrote:
>> > Remember, PKRU is just a *bitmap*.  The only place keys are stored is in the 
>> > page tables.
> A pkey is an index *and* a protection mask. So by representing it as a bitmask we 
> lose per thread information. This is what I meant by 'incomplete shadowing' - for 
> example the debug code couldn't work: if we cleared a pkey in a task we wouldn't 
> know what to restore it to with the current data structures, right?

Right.  I actually have some code to do the shadowing that I wrote to
explore how to do different PKRU values in signal handlers.  The code
only shadowed the keys that were currently allocated, and used the
(mm-wide) allocation map to figure that out.  It did not have a separate
per-thread concept of which parts of PKRU need to be shadowed.

It essentially populated the shadow value on all pkru_set() calls.

--
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>

  reply	other threads:[~2016-07-12 15:39 UTC|newest]

Thread overview: 103+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-07 12:47 [PATCH 0/9] [REVIEW-REQUEST] [v4] System Calls for Memory Protection Keys Dave Hansen
2016-07-07 12:47 ` Dave Hansen
2016-07-07 12:47 ` [PATCH 1/9] x86, pkeys: add fault handling for PF_PK page fault bit Dave Hansen
2016-07-07 12:47   ` Dave Hansen
2016-07-07 14:40   ` Mel Gorman
2016-07-07 14:40     ` Mel Gorman
2016-07-07 15:42     ` Dave Hansen
2016-07-07 15:42       ` Dave Hansen
2016-07-07 12:47 ` [PATCH 2/9] mm: implement new pkey_mprotect() system call Dave Hansen
2016-07-07 12:47   ` Dave Hansen
2016-07-07 14:40   ` Mel Gorman
2016-07-07 14:40     ` Mel Gorman
2016-07-07 16:51     ` Dave Hansen
2016-07-07 16:51       ` Dave Hansen
2016-07-08 10:15       ` Mel Gorman
2016-07-08 10:15         ` Mel Gorman
2016-07-07 12:47 ` [PATCH 3/9] x86, pkeys: make mprotect_key() mask off additional vm_flags Dave Hansen
2016-07-07 12:47   ` Dave Hansen
2016-07-07 12:47 ` [PATCH 4/9] x86: wire up mprotect_key() system call Dave Hansen
2016-07-07 12:47   ` Dave Hansen
2016-07-07 12:47 ` [PATCH 5/9] x86, pkeys: allocation/free syscalls Dave Hansen
2016-07-07 12:47   ` Dave Hansen
2016-07-07 14:40   ` Mel Gorman
2016-07-07 14:40     ` Mel Gorman
2016-07-07 15:38     ` Dave Hansen
2016-07-07 15:38       ` Dave Hansen
2016-07-07 12:47 ` [PATCH 6/9] x86, pkeys: add pkey set/get syscalls Dave Hansen
2016-07-07 12:47   ` Dave Hansen
2016-07-07 14:45   ` Mel Gorman
2016-07-07 14:45     ` Mel Gorman
2016-07-07 17:33     ` Dave Hansen
2016-07-07 17:33       ` Dave Hansen
2016-07-08  7:18       ` Ingo Molnar
2016-07-08  7:18         ` Ingo Molnar
     [not found]         ` <20160708071810.GA27457-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-07-08 16:32           ` Dave Hansen
2016-07-08 16:32             ` Dave Hansen
2016-07-08 16:32             ` Dave Hansen
2016-07-09  8:37             ` Ingo Molnar
2016-07-09  8:37               ` Ingo Molnar
2016-07-09  8:37               ` Ingo Molnar
2016-07-11  4:25               ` Andy Lutomirski
2016-07-11  4:25                 ` Andy Lutomirski
     [not found]                 ` <CALCETrXJhVz6Za4=oidiM2Vfbb+XdggFBYiVyvOCcia+w064aQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-07-11  7:35                   ` Ingo Molnar
2016-07-11  7:35                     ` Ingo Molnar
2016-07-11  7:35                     ` Ingo Molnar
2016-07-11 14:28                     ` Dave Hansen
2016-07-11 14:28                       ` Dave Hansen
2016-07-12  7:13                       ` Ingo Molnar
2016-07-12  7:13                         ` Ingo Molnar
2016-07-12 15:39                         ` Dave Hansen [this message]
2016-07-12 15:39                           ` Dave Hansen
2016-07-11 14:50                     ` Andy Lutomirski
2016-07-11 14:50                       ` Andy Lutomirski
2016-07-11 14:34                   ` Dave Hansen
2016-07-11 14:34                     ` Dave Hansen
2016-07-11 14:34                     ` Dave Hansen
2016-07-11 14:45                     ` Andy Lutomirski
2016-07-11 14:45                       ` Andy Lutomirski
2016-07-11 15:48                       ` Dave Hansen
2016-07-11 15:48                         ` Dave Hansen
2016-07-12 16:32                         ` Andy Lutomirski
2016-07-12 16:32                           ` Andy Lutomirski
2016-07-12 17:12                           ` Dave Hansen
2016-07-12 17:12                             ` Dave Hansen
2016-07-12 22:55                             ` Andy Lutomirski
2016-07-12 22:55                               ` Andy Lutomirski
2016-07-13  7:56                           ` Ingo Molnar
2016-07-13  7:56                             ` Ingo Molnar
2016-07-13 18:43                             ` Andy Lutomirski
2016-07-13 18:43                               ` Andy Lutomirski
2016-07-14  8:07                               ` Ingo Molnar
2016-07-14  8:07                                 ` Ingo Molnar
2016-07-18  4:43                                 ` Andy Lutomirski
2016-07-18  4:43                                   ` Andy Lutomirski
2016-07-18  9:56                                   ` Ingo Molnar
2016-07-18  9:56                                     ` Ingo Molnar
     [not found]               ` <20160709083715.GA29939-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-07-18 18:02                 ` Dave Hansen
2016-07-18 18:02                   ` Dave Hansen
2016-07-18 18:02                   ` Dave Hansen
2016-07-18 20:12                 ` Dave Hansen
2016-07-18 20:12                   ` Dave Hansen
2016-07-18 20:12                   ` Dave Hansen
2016-07-08 19:26         ` Dave Hansen
2016-07-08 19:26           ` Dave Hansen
     [not found]       ` <577E924C.6010406-gkUM19QKKo4@public.gmane.org>
2016-07-08 10:22         ` Mel Gorman
2016-07-08 10:22           ` Mel Gorman
2016-07-08 10:22           ` Mel Gorman
2016-07-07 12:47 ` [PATCH 7/9] generic syscalls: wire up memory protection keys syscalls Dave Hansen
2016-07-07 12:47   ` Dave Hansen
2016-07-07 12:47 ` [PATCH 8/9] pkeys: add details of system call use to Documentation/ Dave Hansen
2016-07-07 12:47   ` Dave Hansen
2016-07-07 12:47 ` [PATCH 9/9] x86, pkeys: add self-tests Dave Hansen
2016-07-07 12:47   ` Dave Hansen
     [not found] ` <20160707124719.3F04C882-LXbPSdftPKxrdx17CPfAsdBPR1lH4CV8@public.gmane.org>
2016-07-07 14:47   ` [PATCH 0/9] [REVIEW-REQUEST] [v4] System Calls for Memory Protection Keys Mel Gorman
2016-07-07 14:47     ` Mel Gorman
2016-07-07 14:47     ` Mel Gorman
2016-07-08 18:38   ` Hugh Dickins
2016-07-08 18:38     ` Hugh Dickins
2016-07-08 18:38     ` Hugh Dickins
  -- strict thread matches above, loose matches on Subject: below --
2016-06-09  0:01 [PATCH 0/9] [v3] " Dave Hansen
2016-06-09  0:01 ` [PATCH 6/9] x86, pkeys: add pkey set/get syscalls Dave Hansen
2016-06-09  0:01   ` Dave Hansen
2016-06-07 20:47 [PATCH 0/9] [v2] System Calls for Memory Protection Keys Dave Hansen
2016-06-07 20:47 ` [PATCH 6/9] x86, pkeys: add pkey set/get syscalls Dave Hansen
2016-06-07 20:47   ` 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=57850F1B.4080306@sr71.net \
    --to=dave@sr71.net \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=hughd@google.com \
    --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@amacapital.net \
    --cc=mgorman@techsingularity.net \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --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.