linux-kernel - Re: [PATCH v2 14/16] KVM: x86: Expose APX foundational feature bit to guests

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] [day] [month] [year] [list]

Message-ID: <48bc5534-05f0-4d5f-ae21-4ee7f7a15cad@intel.com>
Date: Tue, 20 Jan 2026 12:50:49 -0800
From: "Chang S. Bae" <chang.seok.bae@...el.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>, "Li, Xiaoyao"
	<xiaoyao.li@...el.com>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
	"seanjc@...gle.com" <seanjc@...gle.com>
CC: "binbin.wu@...ux.intel.com" <binbin.wu@...ux.intel.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "Gao, Chao" <chao.gao@...el.com>, "Fang,
 Peter" <peter.fang@...el.com>
Subject: Re: [PATCH v2 14/16] KVM: x86: Expose APX foundational feature bit to
 guests

On 1/20/2026 10:07 AM, Edgecombe, Rick P wrote:
> On Mon, 2026-01-19 at 13:55 +0800, Xiaoyao Li wrote:   
>>
>> Not any intention of this patch, but this change eventually allows the
>> userspace to expose APX to TDX guests.
>>
>> Without any mentioning of TDX APX tests and validation like the one for
>> CET[1], I think it's unsafe to allow it for TDX guests.

My original assumption was like what I just mentioned in the RFC cover:

   The specification deliberately scopes out some areas. For example,
   Sections 3.1.4.4.2–7 note that initialization and reset behaviors
   follow existing XSTATE conventions.

With there in 3.1.4.4.2 Intel® TDX,

   Intel® TDX has an XCR0-derived interface called TDCS.XFAM. Bits in
   XFAM act as an opt-in for state and ISA controls. Therefore,
   XFAM[APX_F] acts as a control for enabling Intel® APX within Trust
   Domains (or TDs), and the XFAM settings are established at TD INIT
   (TDH.TD.INIT).

Conceptually, APX enablement for TDX could be explicitly gated, which 
helps to narrow the scope of the KVM changes (perhaps, at least for the 
early review).

*However*, once the APX bit is set in supported_xcr0, it can flow into 
XFAM through the code path as:

tdx_get_supported_xfam(...)
{
	u64 val = kvm_caps.supported_xcr0 | kvm_caps.supported_xss;

	if ((val & td_conf->xfam_fixed1) != td_conf->xfam_fixed1)
		return 0;

	val &= td_conf->xfam_fixed0;

	return val;
}

So I agree that, in the current codebase, whoever updates the KVM-side 
bitmask should ensure that TDX guests are okay with it. I also now 
understand the idea that TDX guests are yet another guest type, which is 
under the impact of whatever kvm_cap changes.

>>
> 
> That was an especially odd one.
> 
>>   E.g., the worst
>> case would be KVM might need extra handling to keep host's
>> states/functionalities correct once TD guest is able to manage APX.
>>
>> I'm thinking maybe we need introduce a supported mask,
>> KVM_SUPPORTED_TD_XFAM, like KVM_SUPPORTED_TD_ATTRS. So that any new XFAM
>> related feature for TD needs the explicit enabling in KVM, and people
>> work on the new XSAVE related feature enabling for normal VMs don't need
>> to worry about the potential TDX impact.
> 
> We might need it. But in general, I agree KVM enabling for new features needs to
> consider the TDX impact now. For APX, it looks like we don't need to add a new
> type of supported feature tracking because the TDX APX arch is public.
> 
> Chang, let's circle back internally and figure out who owns what.

I'd come back here with positive TDX test results once available. For 
now, I would leave additional guarding or geting outside of this 
enabling scope.

Thanks,
Chang