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 :) > > There might be other use cases for this patch like disabling unneeded > system calls for a library (e.g. network i/o for a crypto library) while > the library runs without disabling the system calls for the whole > program (by changing the PKRU before and after the library executes). > Using this one could ensure that the library behaves a expected (e.g. > the crypto library not sending private keys to a malicious server). But > I am mainly interested in the first use case. Fair enough. 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 :) --Andy
