Re: [PATCH] x86/fpu: Fix the os panic issue caused by the XGETBV instruction

["Chang S. Bae" <chang.seok.bae@intel.com>]

On 1/17/2025 2:10 PM, Sean Christopherson wrote:
> 
> I don't see anything in the SDM that suggests this is a misconfigured CPU.  Intel
> might not have plans to ship such CPUs, but AFAICT it's not a violation of the
> architecture as defined in the SDM.
> 
> The SDM even explicitly says that protection keys can exist and be used without
> PKU state being supported in XSAVE at all, at which point assuming the existence
> of XGETBV1 is rather nonsensical.
> 
>    XCR0[9] is associated with PKRU state (see Section 13.5.7). Software can use
>    the XSAVE feature set to manage PKRU state only if XCR0[9] = 1. The value of
>    XCR0[9] in no way determines whether software can use protection keys or execute
>    other instructions that access PKRU state (these instructions can be executed even
>    if XCR0[9] = 0).
> 
>    XCR0[9] is 0 coming out of RESET. As noted in Section 13.2, a processor allows
>    software to set XCR0[9] if and only if CPUID.(EAX=0DH,ECX=0):EAX[9] = 1.

Yeah, right.

Furthermore, looking further at the update_pkru_in_sigframe() change, I 
doubt the xfeatures_in_use() invocation is really necessary.

The change seems to always write the PKRU state in the signal frame and 
set the PKRU bit. Since XSAVE has already been performed, the latter 
could be something like this:

	__get_user(xstate_bv, &buf->header.xfeatures);
	xstate_bv |= XFEATURE_MASK_PKRU;
	__put_user(xstate_bv, &buf->header.xfeatures);

A similar code is already there for FP/SSE bits in the 
save_xstate_epilog() function:
	https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/fpu/signal.c#n139

Thanks,
Chang