On 10/29/18 9:48 AM, Jann Horn wrote: > On Mon, Oct 29, 2018 at 5:37 PM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: >> 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. PKRU gives information about rights to various bits of application data. From that, a seccomp filter can infer the context, and thus the ability for the code to call a given syscall at a certain point in time. This makes PKRU an opt-in part of the syscall ABI, which is pretty interesting. We _could_ do the same kind of thing with any callee-saved general purpose register, but PKRU is particularly attractive because there is only one instruction that writes to it (well, outside of XSAVE*), and random library code is very unlikely at this point to be using it. PKRU getting reset on signals, and the requirement now that it *can't* be changed if you make syscalls probably needs to get thought about very carefully before we do this, though.
