On 10/24/2018 08:43 PM, Andy Lutomirski wrote:
On Wed, Oct 24, 2018 at 11:25 AM Michael Sammler <msammler@xxxxxxxxxxx> wrote:
Am 24.10.2018 um 18:01 schrieb Andy Lutomirski:
On Oct 24, 2018, at 8:35 AM, Michael Sammler <msammler@xxxxxxxxxxx> wrote:
Add the current value of the PKRU register to data available for
seccomp-bpf programs to work on. This allows filters based on the
currently enabled protection keys.
This sounds conceptually reasonable, but can you give an example of how you would use it?
The main reason for this patch is to enable lightweight sandboxing
untrusted code using memory protection keys: It is possible to check,
that the untrusted code does not contain WRPKRU instructions and it
cannot exploit existing WRPKRU instructions (for details see this paper:
https://arxiv.org/abs/1801.06822), but without this patch the untrusted
code can simply map a new executable page containing WRPKRU
instructions. This patch enables preventing system calls while the
untrusted code executes but allowing them when the control goes back to
trusted code by writing a simple seccomp filter, which allows system
calls based on the PKRU.
That's very cute, although it seems that much wider CPU support could
be achieved using techniques like NaCl :)
CPU support is indeed a problem of protection keys, but a sandbox based
on them would also have advantages over techniques like NaCl or
WebAssembly. For a comparison of a sandbox based on protection keys vs.
a sandbox based on WebAssembly see Table 6 in the paper liked above
(https://arxiv.org/abs/1801.06822): In this benchmark the overhead (over
executing without isolation) is 80%-190% for WebAssembly and 2%-15% for
protection keys.
I would argue that the field in seccomp_data should be at least a u64,
not a u32 with padding, though. After all, more than 32 protection
keys could easily happen :)
This is a good point and it allow to remove the awkward reserved field.
I think this will also depend on the platform support (the current
implementation is focused on x86).
