On Wed, May 19, 2021, at 3:44 PM, Dave Hansen wrote: > On 5/17/21 12:46 AM, Paolo Bonzini wrote: > > On 14/05/21 07:11, Andy Lutomirski wrote: > >> That's nice, but it fails to restore XINUSE[PKRU]. As far as I know, > >> that bit is live, and the only way to restore it to 0 is with > >> XRSTOR(S). > > > > The manual says "It is possible for XINUSE[i] to be 1 even when state > > component i is in its initial configuration" so this is architecturally > > valid. Does the XINUSE optimization matter for PKRU which is a single > > word? > > In Linux with normal userspace, virtually never. > > The hardware defaults PKRU to 0x0 which means "no restrictions on any > keys". Linux defaults PKRU via 'init_pkru_value' to the most > restrictive value. This ensures that new non-zero-pkey-assigned memory > is protected by default. > > But, that also means PKRU is virtually never in its init state in Linux. > An app would probably need to manipulate PKRU with XRSTOR to get > XINUSE[PKRU]=0. > > It would only even *possibly* be useful if running a KVM guest that had > PKRU=0x0 (sorry I don't consider things using KVM "normal userspace" :P ). > There was at least one report from the rr camp of glibc behaving differently depending on the result of XGETBV(1). It's at least impolite to change the XINUSE register for a guest behind its back. Admittedly that particular report wasn't about PKRU, and *Linux* guests won't run with XINUSE[PKRU]=0 under normal circumstances, but non-Linux guests could certainly do so.
