Re: [PATCH v3 0/4] KVM: TDX: Validate directly configurable CPUID bits

[Binbin Wu]

On 8/29/2026 12:58 AM, Edgecombe, Rick P wrote:
> On Fri, 2026-08-28 at 11:19 +0800, Binbin Wu wrote:
>>>
>>> But it isn't a kernel bug, so I'd think to punt on this and let TDX module
>>> figure out a solution if/when the time comes. Probably various opt-in knobs
>>> to allow for working around it.
>>
>> Do you mean on the old platforms, the according TDX module versions add opt-in
>> knobs to allow the "effective 1 -> directly configurable" change?
> 
> Yea. Or the other way. Forcing the old fixed-1 bits to 1 automatically. Could be
> like a quirk like config thing. User/admin can decide if they want migration
> flexible design, or backwards compatibility for existing TDs.

It's all about the new created TDs on the old platforms. For existing TDs, the
runtime TDX module update should not change the shape of the TDs.

> BUT, we could work
> out the details later if we think we have options.
> 
> I think I've convinced myself we have options and can close this one. Agreed?

Agree.

> 
> <snip>
>>
>>
>> If FRED support lands in KVM for non-TDX VMs before this
>> filtering/invalidation is in place, adding FRED to the hardcoded denylist
>> would work as a temporary solution.
> 
> This could easily happen.
> 
>>
>> But that only holds for a well-behaved userspace VMM. QEMU, for example, only
>> enables features supported by both KVM and TDX, so if FRED isn't supported in
>> KVM for non-TDX VMs, QEMU won't enable it for TDX either.
>>
>> A malicious userspace VMM, however, can set a feature regardless of KVM's
>> reported CPU capabilities, and could still cause trouble.
> 
> Right. It the problem I thought we would need an opt-in to avoid.
> 
>>
>>> Do we want it? Where would it get plugged in?
>>
>> So if the approach in this series is taken, I think we still need such an opt-
>> in interface to tell the TDX module that the VMM is now filtering the CPUID
>> bits so that the TDX module knows that it's safe to report new host state
>> clobbering features.
> 
> Yep. Can we think about what it would look like? Easiest would be a bit passed
> in TDH_SYS_CONFIG. But then arch/x86 is saying how KVM will behave. Ok to me,
> for the simplicity. Could come with a nice comment.

The TDX module is initialized before KVM is loaded. I guess the upstream kernel
doesn't support out of tree KVM code, so we can assume if the kernel has the code to
opt-in the new host state clobbering features, KVM must have implemented the TDX
CPUID filtering and validation?

Also, do you think it's reasonable to backport this patch series to stable/LTS
kernels as an alternative?