Re: [RFC PATCH v2 2/4] KVM: x86: TDX: Hide unsupported configurable CPUID bits

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The secure-by-default CPUID allowlist is applied to KVM capability reporting but missing from TD initialization validation. This allows a malicious userspace VMM to bypass capability enumeration and supply unsupported configurable CPUID bits directly to the TDX module, potentially causing host state corruption.
--

commit e4dd30c1f72bbeeb74f3ba5a865ab30e0c17bcf6
Author: Binbin Wu <binbin.wu@linux.intel.com>

KVM: x86: TDX: Hide unsupported configurable CPUID bits

This commit introduces get_supported_cfg_cpuid() to filter the CPUID 
capabilities reported by KVM_TDX_CAPABILITIES. It replaces a hardcoded 
denylist with a secure-by-default allowlist approach to prevent exposing 
unsupported features that could lead to host state corruption.

> diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
> index 028d54c76b81e..befda6bc17b1e 100644
> --- a/arch/x86/kvm/vmx/tdx.c
> +++ b/arch/x86/kvm/vmx/tdx.c

[ ... ]

> -static void clear_waitpkg(struct kvm_cpuid_entry2 *entry)
> +static bool tdx_unsupported_cpuid(const struct kvm_cpuid_entry2 *entry)
>  {
> -	entry->ecx &= ~__feature_bit(X86_FEATURE_WAITPKG);
> +	return has_tsx(entry) || has_waitpkg(entry);
>  }

[Severity: High]
This is a pre-existing issue, but by keeping this legacy denylist active, is
there a risk that userspace can bypass the new secure-by-default allowlist
during TD initialization?

While this patch updates capability reporting to explicitly mask unsupported 
features, the configuration path in setup_tdparams_cpuids() still appears to 
use this older denylist function to validate user input:

arch/x86/kvm/vmx/tdx.c:setup_tdparams_cpuids() {
        ...
        if (tdx_unsupported_cpuid(entry))
                return -EINVAL;

        value = &td_params->cpuid_values[i];
        value->eax = entry->eax;
        value->ebx = entry->ebx;
        value->ecx = entry->ecx;
        value->edx = entry->edx;
        ...
}

Because these user-provided CPUID values are copied directly into the hardware 
initialization parameters without being masked against the newly introduced 
get_supported_cfg_cpuid() allowlist, could a VMM explicitly request and pass 
unsupported configurable CPUID bits directly to the TDX module?

Does this still leave the door open to the host state corruption mentioned
in the commit message if the TDX module only enforces hardware-level support
rather than KVM's software constraints?

>  
> -static void tdx_clear_unsupported_cpuid(struct kvm_cpuid_entry2 *entry)
> +static u32 get_supported_cfg_cpuid(u32 function, u32 index, u8 reg)
>  {

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260604023314.3907511-1-binbin.wu@linux.intel.com?part=2