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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <331a04dc-60df-47ad-8ba6-53a605d9f472@intel.com>
Date: Fri, 17 Jan 2025 15:24:25 -0800
From: "Chang S. Bae" <chang.seok.bae@...el.com>
To: Sean Christopherson <seanjc@...gle.com>
CC: Tony W Wang-oc <TonyWWang-oc@...oxin.com>, <tglx@...utronix.de>,
	<mingo@...hat.com>, <bp@...en8.de>, <dave.hansen@...ux.intel.com>,
	<x86@...nel.org>, <hpa@...or.com>, <aruna.ramakrishna@...cle.com>,
	<pbonzini@...hat.com>, <levymitchell0@...il.com>, <attofari@...zon.de>,
	<linux-kernel@...r.kernel.org>, <CobeChen@...oxin.com>, <TimGuo@...oxin.com>,
	<LeoLiu-oc@...oxin.com>, Lyle Li <LyleLi@...oxin.com>
Subject: Re: [PATCH] x86/fpu: Fix the os panic issue caused by the XGETBV
 instruction

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