On Wed, Aug 3, 2022 at 10:25 AM Ingo Molnar mingo@kernel.org wrote:
- Kyle Huey me@kylehuey.com wrote:
Also, what's the security model for this register, do we trust all input values user-space provides for the PKRU field in the XSTATE? I realize that WRPKRU already gives user-space write access to the register - but does the CPU write it all into the XSTATE, with no restrictions on content whatsoever?
There is no security model for this register. The CPU does write whatever is given to WRPKRU (or XRSTOR) into the PKRU register. The pkeys(7) man page notes:
Protection keys have the potential to add a layer of security and reliability to applications. But they have not been primarily designed as a security feature. For instance, WRPKRU is a completely unprivileged instruction, so pkeys are useless in any case that an attacker controls the PKRU register or can execute arbitrary instructions.
Ok - allowing ptrace to set the full 32 bits of the PKRU register seems OK then, and is 100% equivalent to using WRPKRU, right? So there's no implicit masking/clearing of bits depending on how many keys are available, or other details where WRPKRU might differ from a pure 32-bit per thread write, correct?
Right. The hardware doesn't have any concept of what keys are available or not, that exists entirely in the kernel.
- Kyle
Thanks,
Ingo