On Wed, Aug 3, 2022 at 10:25 AM Ingo Molnar <mingo@xxxxxxxxxx> wrote: > > > * Kyle Huey <me@xxxxxxxxxxxx> 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
