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?