From: Florian Weimer <fweimer@redhat.com>
To: Michael Sammler <msammler@mpi-sws.org>
Cc: Will Drewry <wad@chromium.org>, Kees Cook <keescook@chromium.org>,
linux-api@vger.kernel.org, Ram Pai <linuxram@us.ibm.com>,
Andy Lutomirski <luto@amacapital.net>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] seccomp: Add pkru into seccomp_data
Date: Thu, 25 Oct 2018 11:12:25 +0200 [thread overview]
Message-ID: <875zxqo0ee.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <11a706bd-060f-41de-118b-bababfd83b3d@mpi-sws.org> (Michael Sammler's message of "Thu, 25 Oct 2018 10:39:17 +0200")
* Michael Sammler:
> Thank you for the pointer about the POWER implementation. I am not
> familiar with POWER in general and its protection key feature at
> all. Would the AMR register be the correct register to expose here?
Yes, according to my notes, the register is called AMR (special purpose
register 13).
> I understand your concern about exposing the number of protection keys
> in the ABI. One idea would be to state, that the pkru field (which
> should probably be renamed) contains an architecture specific value,
> which could then be the PKRU on x86 and AMR (or another register) on
> POWER. This new field should probably be extended to __u64 and the
> reserved field removed.
POWER also has proper read/write bit separation, not PKEY_DISABLE_ACCESS
(disable read and write) and PKEY_DISABLE_WRITE like Intel. It's
currently translated by the kernel, but I really need a
PKEY_DISABLE_READ bit in glibc to implement pkey_get in case the memory
is write-only.
> Another idea would be to not add a field in the seccomp_data
> structure, but instead provide a new BPF instruction, which reads the
> value of a specified protection key.
I would prefer that if it's possible. We should make sure that the bits
are the same as those returned from pkey_get. I have an implementation
on POWER, but have yet to figure out the implications for 32-bit because
I do not know the AMR register size there.
Thanks,
Florian
next prev parent reply other threads:[~2018-10-25 9:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20181024153523.10974-1-msammler@mpi-sws.org>
2018-10-24 18:06 ` [PATCH] seccomp: Add pkru into seccomp_data Florian Weimer
2018-10-25 8:39 ` Michael Sammler
2018-10-25 9:12 ` Florian Weimer [this message]
2018-10-25 16:42 ` Michael Sammler
2018-10-25 23:00 ` Andy Lutomirski
2018-10-26 0:35 ` Kees Cook
2018-10-26 0:49 ` Andy Lutomirski
2018-10-29 22:01 ` Kees Cook
2018-10-26 5:52 ` Ram Pai
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=875zxqo0ee.fsf@oldenburg.str.redhat.com \
--to=fweimer@redhat.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=msammler@mpi-sws.org \
--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 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.