Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1348874

Re: [RFC][PATCH 0/7] System Calls for Memory Protection Keys

From "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Newsgroups linux.kernel
Subject Re: [RFC][PATCH 0/7] System Calls for Memory Protection Keys
Date 2016-03-03 09:20 +0100
Message-ID <r8wEi-4cL-9@gated-at.bofh.it> (permalink)
References <r59NU-6nf-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Hi Dave,

On 23 February 2016 at 02:11, Dave Hansen <dave@sr71.net> wrote:
> As promised, here are the proposed new Memory Protection Keys
> interfaces.  These interfaces make it possible to do something
> with pkeys other than execute-only support.
>
> There are 5 syscalls here.  I'm hoping for reviews of this set
> which can help nail down what the final interfaces will be.
>
> You can find a high-level overview of the feature and the new
> syscalls here:
>
>         https://www.sr71.net/~dave/intel/pkeys.txt

(That's pretty thin...)

> ===============================================================
>
> To use memory protection keys (pkeys), an application absolutely
> needs to be able to set the pkey field in the PTE (obviously has
> to be done in-kernel) and make changes to the "rights" register
> (using unprivileged instructions).
>
> An application also needs to have an an allocator for the keys
> themselves.  If two different parts of an application both want
> to protect their data with pkeys, they first need to know which
> key to use for their individual purposes.
>
> This set introduces 5 system calls, in 3 logical groups:
>
> 1. PTE pkey setting (sys_pkey_mprotect(), patches #1-3)
> 2. Key allocation (sys_pkey_alloc() / sys_pkey_free(), patch #4)
> 3. Rights register manipulation (sys_pkey_set/get(), patch #5)
>
> These patches build on top of "core" support already in the tip tree,
> specifically 62b5f7d013, which can currently be found at:
>
>         http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=mm/pkeys
>
> I have manpages written for some of these syscalls, and I will
> submit a full set of manpages once we've reached some consensus
> on what the interfaces should be.

Please don't do things in this order. Providing man pages up front
make it easier for people to understand, review, and critique the API.
Submitting man pages should be a foundational part of submitting a new
set of interfaces and discussing their design.

Thanks,

Michael

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC][PATCH 0/7] System Calls for Memory Protection Keys Dave Hansen <dave@sr71.net> - 2016-02-23 02:20 +0100
  [RFC][PATCH 3/7] x86, pkeys: make mprotect_key() mask off additional vm_flags Dave Hansen <dave@sr71.net> - 2016-02-23 02:20 +0100
  [RFC][PATCH 1/7] x86, pkeys: Documentation Dave Hansen <dave@sr71.net> - 2016-02-23 02:20 +0100
  [RFC][PATCH 6/7] x86, pkeys: add pkey set/get syscalls Dave Hansen <dave@sr71.net> - 2016-02-23 02:20 +0100
    Re: [RFC][PATCH 6/7] x86, pkeys: add pkey set/get syscalls Ingo Molnar <mingo@kernel.org> - 2016-02-23 07:50 +0100
  [RFC][PATCH 4/7] x86: wire up mprotect_key() system call Dave Hansen <dave@sr71.net> - 2016-02-23 02:20 +0100
  [RFC][PATCH 7/7] pkeys: add details of system call use to Documentation/ Dave Hansen <dave@sr71.net> - 2016-02-23 02:20 +0100
    Re: [RFC][PATCH 7/7] pkeys: add details of system call use to  Documentation/ Ingo Molnar <mingo@kernel.org> - 2016-02-23 07:40 +0100
  [RFC][PATCH 2/7] mm: implement new pkey_mprotect() system call Dave Hansen <dave@sr71.net> - 2016-02-23 02:20 +0100
  [RFC][PATCH 5/7] x86, pkeys: allocation/free syscalls Dave Hansen <dave@sr71.net> - 2016-02-23 02:20 +0100
  Re: [RFC][PATCH 0/7] System Calls for Memory Protection Keys "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-03-03 09:20 +0100
    Re: [RFC][PATCH 0/7] System Calls for Memory Protection Keys Dave Hansen <dave@sr71.net> - 2016-03-04 00:50 +0100

csiph-web