On Fri, Dec 18, 2015 at 1:45 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Fri, Dec 18, 2015 at 1:12 PM, Dave Hansen > <dave.han...@linux.intel.com> wrote: >> >> But, if we are picking out an execute-only pkey more dynamically, we've >> got to keep the default value for the entire process somewhere. > > How dynamic do we want to make this, though? > > I haven't looked at the details, and perhaps more importantly, I don't > know what exactly are the requirements you've gotten from the people > who are expected to actually use this. > > I think we might want to hardcode a couple of keys as "kernel > reserved". And I'd rather reserve them up-front than have some user > program be unhappy later when we want to use them. > > I guess we want to leave key #0 for "normal page", so my suggesting to > use that for the execute-only was probably misguided. > > But I do think we might want to have that "no read access" as a real > fixed key too, because I think the kernel itself would want to use it: > > (a) to make sure that it gets the right fault when user space passes > in a execute-only address to a system call. > > (b) for much more efficient PAGEALLOC_DEBUG for kernel mappings. > > so I do think that we'd want to reserve two of the 16 keys up front. > > Would it be ok for the expected users to have those keys simply be > fixed? With key 0 being used for all default pages, and key 1 being > used for all execute-only pages? And then defaulting PKRU to 4, > disallowing access to that key #1? > > I could imagine that some kernel person would want to use even more > keys, but I think two fixed keys are kind of the minimal we'd want to > use.
I imagine we'd reserve key 0 for normal page and key 1 for deny-read. Let me be a bit more concrete about what I'm suggesting: We'd have thread_struct.baseline_pkru. It would start with key 0 allowing all access and key 1 denying reads. We'd have a syscall like set_protection_key that could allocate unused keys and change the values of keys that have been allocated. Those changes would be reflected in baseline_pkru. Changes to keys 0 and 1 in baseline_pkru would not be allowed. Signal delivery would load baseline_pkru into the PKRU register. Signal restore would restore PKRU to its previous value. WRPKRU would, of course, override baseline_pkru, but it wouldn't change baseline_pkru. The set_protection_key syscall would modify *both* real PKRU and baseline_pkru. Apps that don't want to use the baseline_pkru mechanism could use syscalls to claim ownership of protection keys but then manage them purely with WRPKRU directly. We could optionally disallow mprotect_key on keys that weren't allocated in advance. Does that seem sane? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
