Re: [PATCH v6 3/4] KVM: TDX: Report only KVM-allowed CPUID bits in KVM_TDX_CAPABILITIES

[Nikolay Borisov]

On 28.10.26 г. 10:16 ч., Binbin Wu wrote:
> Filter the directly configurable CPUID bits reported through
> KVM_TDX_CAPABILITIES against KVM's TDX allowlist, and drop the hardcoded
> denylist-based filtering.
>
> The TDX module reports the CPUID bits that the VMM can directly configure
> for a TD, but KVM must not advertise bits that it doesn't support, as
> blindly exposing a feature that clobbers host state can corrupt the host.
> The existing denylist, which clears only TSX and WAITPKG, can't account
> for such features introduced by future TDX modules.
>
> Add tdx_get_cpuid_cfg_mask() to compute the mask of directly configurable
> bits that KVM allows for a given CPUID register, and apply it to every
> CPUID entry reported through KVM_TDX_CAPABILITIES.  The mask combines
> feature bits, taken from tdx_cpu_cfg_caps[], with non-feature bits, which
> are identified by function, index, and register.
>
> Treat CPUID.0x1.{EAX,EBX}, CPUID.{0x4,0x18,0x1F}, and CPUID.0x80000008.EAX
> as fully allowed, as these registers enumerate non-feature information,
> e.g. family/model/stepping, brand index, CLFLUSH line size, APIC ID,
> cache/TLB/topology properties, and address sizes.  Allow the reserved bits
> in them as well.  Though there's no architectural guarantee, given what
> these registers enumerate, the reserved bits are expected to be used to
> extend the existing information rather than to enumerate new features.
>
> Also allow CPUID.0x24.0.EBX[7:0] (AVX10 version), which the TDX module
> reports as directly configurable when AVX10 is supported, even though the
> CPUID virtualization table in the "Intel TDX Module ABI Definitions"
> currently lists it as not configurable.  The table is expected to be
> corrected.
>
> As a result, directly configurable bits that aren't in the allowlist,
> including bits introduced by future TDX modules, aren't advertised to
> userspace until KVM explicitly opts in.
>
> Note, this is an ABI change, as some bits that were previously reported as
> configurable no longer are.  However, the semantics of
> KVM_TDX_CAPABILITIES are unchanged: KVM already filtered unsupported bits
> out of KVM_TDX_CAPABILITIES, albeit via a denylist, and the set of
> reported bits already varies with the TDX module and KVM versions, i.e.
> userspace can't assume a fixed set.
>
> The change isn't expected to break userspace or guests:
>   - Userspace that honors KVM_TDX_CAPABILITIES simply stops setting the
>     dropped bits, and KVM_TDX_INIT_VM still succeeds.
>   - 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@xxxxxxxxxxxxxxx>
> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
> Reviewed-by: Chao Gao <chao.gao@xxxxxxxxx>
> Reviewed-by: Xiaoyao Li <xiaoyao.li@xxxxxxxxx>

Reviewed-by: Nikolay Borisov <nik.borisov@xxxxxxxx>