From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"binbin.wu@linux.intel.com" <binbin.wu@linux.intel.com>
Cc: "Gao, Chao" <chao.gao@intel.com>,
"seanjc@google.com" <seanjc@google.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"kas@kernel.org" <kas@kernel.org>,
"Li, Xiaoyao" <xiaoyao.li@intel.com>,
"Maloor, Kishen" <kishen.maloor@intel.com>,
"dedekind1@gmail.com" <dedekind1@gmail.com>,
"tony.lindgren@linux.intel.com" <tony.lindgren@linux.intel.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
"nik.borisov@suse.com" <nik.borisov@suse.com>
Subject: Re: [PATCH v4 4/4] KVM: TDX: Validate userspace CPUID input for KVM_TDX_INIT_VM
Date: Wed, 23 Sep 2026 00:16:25 +0000 [thread overview]
Message-ID: <f4caf60832121805e7784cc8f2c533ae266acdc4.camel@intel.com> (raw)
In-Reply-To: <20260917072548.2314491-5-binbin.wu@linux.intel.com>
On Thu, 2026-09-17 at 15:25 +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 configure certain CPUID features for a TD at
> initialization time, but KVM must strictly govern which of them userspace
> can actually enable, otherwise a host state clobbering feature could be
> enabled behind KVM's back. The existing check only rejects TSX and
> WAITPKG, i.e. it is not fail-safe, as any bit that a future TDX module
> makes configurable would be accepted even if KVM has no idea about the
> feature.
>
> Add tdx_has_unsupported_cpuid_cfg_bit() and reject KVM_TDX_INIT_VM if
> userspace sets any bit outside the mask returned by
> tdx_get_cpuid_cfg_mask(). There is no need to first mask the userspace
> input with the bits the TDX module reports as directly configurable, as
> anything outside that set is rejected by the TDX module itself.
>
> Also reject CPUID entries whose index differs from the value expected by
> the TDX module, as kvm_find_cpuid_entry2() ignores the index when
> KVM_CPUID_FLAG_SIGNIFCANT_INDEX is cleared, i.e. a mismatching entry could
> otherwise be applied to the wrong subleaf.
>
> Update the comments for KVM_TDX_INIT_VM in the uapi header and the TDX
> documentation accordingly.
Same comment on this one as patch 3, this removes some previously configurable
features right? And you checked qemu and reasoned on the rest that this won't
break anything. We don't need the full bit by bit detail here, but if someone
bisects this patch it would be good to have some info about what the ABI change
was.
prev parent reply other threads:[~2026-09-23 0:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 7:25 [PATCH v4 0/4] KVM: TDX: Validate directly configurable CPUID bits Binbin Wu
2026-09-17 7:25 ` [PATCH v4 1/4] KVM: TDX: Track configurable CPUID bits allowed by KVM Binbin Wu
2026-09-23 0:01 ` Edgecombe, Rick P
2026-09-23 0:14 ` Binbin Wu
2026-09-23 0:45 ` Edgecombe, Rick P
2026-09-23 0:57 ` Binbin Wu
2026-09-23 1:09 ` Edgecombe, Rick P
2026-09-23 1:17 ` Binbin Wu
2026-09-17 7:25 ` [PATCH v4 2/4] KVM: TDX: Report CORE_CAPABILITIES as configurable Binbin Wu
2026-09-22 21:11 ` Edgecombe, Rick P
2026-09-23 0:03 ` Binbin Wu
2026-09-17 7:25 ` [PATCH v4 3/4] KVM: TDX: Filter configurable CPUID bits Binbin Wu
2026-09-23 0:16 ` Edgecombe, Rick P
2026-09-23 0:28 ` Binbin Wu
2026-09-23 0:34 ` Edgecombe, Rick P
2026-09-17 7:25 ` [PATCH v4 4/4] KVM: TDX: Validate userspace CPUID input for KVM_TDX_INIT_VM Binbin Wu
2026-09-23 0:16 ` Edgecombe, Rick P [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=f4caf60832121805e7784cc8f2c533ae266acdc4.camel@intel.com \
--to=rick.p.edgecombe@intel.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=nik.borisov@suse.com \
--cc=pbonzini@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®