Re: x86/fpu/xsave: protection key test failures

[Dave Kleikamp]

On 5/25/21 5:18 PM, Dave Hansen wrote:
> On 5/25/21 2:37 PM, Babu Moger wrote:
> > My suspicion at this point is towards the selftest tool protection_keys.c.
> > I will keep looking. Any feedback would be much appreciated to debug further.
>
> The pkey selftest code that pokes at the signal stack is rather hackish.
>   If I had to guess, I'd suspect that PKRU ends up in there in a slightly
> different place than on Intel CPUs.
>
> One oddity is that xfeatures seems to lose its pkey bit somewhere:
>
> >   protection_keys-17350 [035] 59275.834197: x86_fpu_copy_src:     	x86/fpu: 0xffff93d7595e2dc0 load: 0 xfeatures: 202 xcomp_bv: 8000000000000207
> >   protection_keys-17350 [035] 59275.834197: x86_fpu_copy_dst:     	x86/fpu: 0xffff93d722877800 load: 0 xfeatures: 2 xcomp_bv: 8000000000000207
>
> The only legitimate way that can happen (on Intel at least) is an XRSTOR
> that brings PKRU back to the init state.  That would destroy all
> meaningful PKRU state, unless PKRU=0, which it almost never does on Linux.
>
> What values do PKRU and the shadow have when the test fails?  Is PKRU 0?
>   Any idea how xfeatures&0x200 got clear?

I did observe that PKRU is 0 right before the failure.

Shouldn't this still be a valid value?