From: Nikolay Borisov <nik.borisov@suse.com>
To: Binbin Wu <binbin.wu@linux.intel.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: seanjc@google.com, pbonzini@redhat.com,
dave.hansen@linux.intel.com, andrew.cooper3@citrix.com,
kas@kernel.org, rick.p.edgecombe@intel.com, xiaoyao.li@intel.com,
chao.gao@intel.com, tony.lindgren@linux.intel.com,
kishen.maloor@intel.com, dedekind1@gmail.com
Subject: Re: [PATCH v6 4/4] KVM: TDX: Validate userspace CPUID input for KVM_TDX_INIT_VM
Date: Wed, 28 Oct 2026 14:49:51 +0200 [thread overview]
Message-ID: <567ad0ec-378a-4f65-833b-e40c07ab56d2@suse.com> (raw)
In-Reply-To: <20261028081658.1228484-5-binbin.wu@linux.intel.com>
On 28.10.26 г. 10:16 ч., 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.
>
> Rewrite tdx_is_unsupported_cpuid_entry() to 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.
>
> Ignore the index for non-indexed functions when walking reverse_cpuid[],
> as userspace isn't required to zero it.
>
> Note, this is an ABI change, as KVM_TDX_INIT_VM now rejects some input
> that was previously accepted. However, the semantics of KVM_TDX_INIT_VM
> are 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 newly rejected 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: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Reviewed-by: Chao Gao <chao.gao@intel.com>
> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
prev parent reply other threads:[~2026-10-28 12:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-28 8:16 [PATCH v6 0/4] KVM: TDX: Validate directly configurable CPUID bits Binbin Wu
2026-10-28 8:16 ` [PATCH v6 1/4] KVM: TDX: Track configurable CPUID bits allowed by KVM Binbin Wu
2026-10-28 8:16 ` [PATCH v6 2/4] KVM: TDX: Add CORE_CAPABILITIES to the allowlist Binbin Wu
2026-10-28 8:16 ` [PATCH v6 3/4] KVM: TDX: Report only KVM-allowed CPUID bits in KVM_TDX_CAPABILITIES Binbin Wu
2026-10-28 12:49 ` Nikolay Borisov
2026-10-28 8:16 ` [PATCH v6 4/4] KVM: TDX: Validate userspace CPUID input for KVM_TDX_INIT_VM Binbin Wu
2026-10-28 12:49 ` Nikolay Borisov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=567ad0ec-378a-4f65-833b-e40c07ab56d2@suse.com \
--to=nik.borisov@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=binbin.wu@linux.intel.com \
--cc=chao.gao@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=dedekind1@gmail.com \
--cc=kas@kernel.org \
--cc=kishen.maloor@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=tony.lindgren@linux.intel.com \
--cc=xiaoyao.li@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.