Thread (13 messages) 13 messages, 5 authors, 2018-10-30

Re: [RFC PATCH] seccomp: Add protection keys into seccomp_data

From: Jann Horn <jannh@google.com>
Date: 2018-10-29 16:53:09
Also in: linux-api

On Mon, Oct 29, 2018 at 5:37 PM Dave Hansen [off-list ref] wrote:
On 10/29/18 9:25 AM, Kees Cook wrote:
quoted
On Mon, Oct 29, 2018 at 4:23 AM, Michael Sammler [off-list ref] wrote:
quoted
Add the current value of an architecture specific protection keys
register (currently PKRU on x86) to data available for seccomp-bpf
programs to work on. This allows filters based on the currently
enabled protection keys.
How does the current "assignment" of protection keys to the various uses
get communicated to the filter?
I assume that you first allocate your protection keys, then install the filter?
I'm not sure this is a great use for PKRU.  I *think* the basic problem
is that you want to communicate some rights information down into a
filter, and you want to communicate it with PKRU.  While it's handy to
have an extra register that nobody (generally) mucks with, I'm not quite
convinced that we want to repurpose it this way.
That's not how I understand it; I believe that the context is probably
https://arxiv.org/pdf/1801.06822.pdf ?
My understanding is that PKRU is used for lightweight in-process
sandboxing, and to extend this sandbox protection to the syscall
interface, it is necessary to expose PKRU state to seccomp filters.
In other words, this isn't using PKRU exclusively for passing rights
into a filter, but it has to use PKRU anyway.
Also, I'm not sure the kernel provides the PKRU guarantees you want at
the moment.  Our implementation *probably* works, but it's mostly by
accident.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help