Re: [PATCH v5 5/5] KVM: TDX: Validate userspace CPUID input for KVM_TDX_INIT_VM

[Chao Gao <chao.gao@intel.com>]

On Fri, Oct 16, 2026 at 05:14:22PM +0800, Binbin Wu wrote:
>Validate the CPUID configuration provided by userspace through
>KVM_TDX_INIT_VM against KVM's TDX allowlist, and drop the hardcoded
>denylist-based check.
>
>The TDX module lets the VMM directly configure certain CPUID bits for a TD
>at initialization time, but KVM must strictly govern which of those bits
>userspace can set, otherwise a feature that clobbers host state could be
>enabled behind KVM's back.  The existing denylist rejects only TSX and
>WAITPKG, and thus would accept any bit that a future TDX module makes
>configurable, even if KVM knows nothing about the associated feature.
>
>Add tdx_has_unsupported_cpuid_cfg_bit() and reject KVM_TDX_INIT_VM if
>userspace sets any bit outside of the mask returned by
>tdx_get_cpuid_cfg_mask(), i.e. the same mask used to filter
>KVM_TDX_CAPABILITIES.  Don't bother intersecting the userspace input with
>the bits that the TDX module reports as directly configurable, as the TDX
>module itself rejects any bit outside that set.
>
>As with the existing check, use the subleaf reported by the TDX module to
>look up the allowed mask.  For leaves without subleaves, the TDX module's
>"no subleaf" index is normalized to 0, which matches how such leaves are
>tracked in reverse_cpuid[].
>
>Note, the change is user-visible, as KVM_TDX_INIT_VM now rejects some
>input that was previously accepted.  The ABI itself is unchanged: KVM
>already rejected unsupported CPUID bits, albeit via a denylist, and
>userspace has always been required to consult KVM_TDX_CAPABILITIES and set
>only the bits reported as configurable.
>
>The change isn't expected to break userspace or guests:
> - The newly rejected bits are no longer reported as configurable by
>   KVM_TDX_CAPABILITIES, so userspace that honors KVM_TDX_CAPABILITIES
>   won't set them.
> - CORE_CAPABILITIES, which older TDX module specs defined as fixed-1, is
>   still allowed.
> - The dropped features are either obsolete or unsupported by KVM, and in
>   the latter case, a guest relying on them would already have run into
>   problems.
>
>Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com>
>Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>

Reviewed-by: Chao Gao <chao.gao@intel.com>