From: Michael Sammler <msammler@mpi-sws.org>
To: Jann Horn <jannh@google.com>, Dave Hansen <dave.hansen@intel.com>
Cc: wad@chromium.org, Kees Cook <keescook@chromium.org>,
Linux API <linux-api@vger.kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
linuxram@us.ibm.com, Andy Lutomirski <luto@amacapital.net>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC PATCH] seccomp: Add protection keys into seccomp_data
Date: Mon, 29 Oct 2018 18:02:08 +0100 [thread overview]
Message-ID: <24afa443-92e8-8202-845a-c1e1df1a3226@mpi-sws.org> (raw)
In-Reply-To: <CAG48ez1mY7Osdsc4iJ1JKq=C60wb9bQF=aHbi1fb=pb_V2XMJA@mail.gmail.com>
On 10/29/2018 05:48 PM, Jann Horn wrote:
> On Mon, Oct 29, 2018 at 5:37 PM Dave Hansen <dave.hansen@intel.com> wrote:
>> On 10/29/18 9:25 AM, Kees Cook wrote:
>>> On Mon, Oct 29, 2018 at 4:23 AM, Michael Sammler <msammler@mpi-sws.org> wrote:
>>>> 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?
>
Yes, but I agree that it should probably be documented, that the filter
should only look at the parts of the PKRU, which belong to pkeys the
user space program allocated (if the kernel wants to use some parts of
the PKRU for its own purposes).
>> 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.
Yes, https://arxiv.org/pdf/1801.06822.pdf is indeed the context and what
you say is correct.
>> 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.
I don't know, which guarantees about the PKRU are provided at the
moment, but the only guarantee needed for this patch is, that the kernel
does not change the bits of the PKRU register, which belong to pkeys
allocated by the user program, between the syscall entry and the call to
secure_computing(). Is there are use case where the kernel would like to
modify these bits of the PKRU?
-- MIchael
next prev parent reply other threads:[~2018-10-29 17:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-29 11:23 [RFC PATCH] seccomp: Add protection keys into seccomp_data Michael Sammler
2018-10-29 16:25 ` Kees Cook
2018-10-29 16:37 ` Dave Hansen
2018-10-29 16:48 ` Jann Horn
2018-10-29 17:02 ` Michael Sammler [this message]
2018-10-29 17:07 ` Dave Hansen
2018-10-29 17:29 ` Dave Hansen
2018-10-29 21:55 ` Michael Sammler
2018-10-29 22:33 ` Dave Hansen
2018-10-30 10:55 ` Michael Sammler
2018-10-29 16:42 ` Jann Horn
2018-10-29 16:48 ` Ram Pai
2018-10-29 17:05 ` Michael Sammler
2022-11-14 10:09 Stephen Röttger
2022-11-15 4:16 ` Michael Sammler
2022-11-16 12:20 ` Stephen Röttger
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=24afa443-92e8-8202-845a-c1e1df1a3226@mpi-sws.org \
--to=msammler@mpi-sws.org \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=jannh@google.com \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=linuxram@us.ibm.com \
--cc=luto@amacapital.net \
--cc=wad@chromium.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).