From: Sean Christopherson <seanjc@google.com>
To: Xiaoyao Li <xiaoyao.li@intel.com>
Cc: Rick P Edgecombe <rick.p.edgecombe@intel.com>,
Chao Gao <chao.gao@intel.com>, Kai Huang <kai.huang@intel.com>,
"binbin.wu@linux.intel.com" <binbin.wu@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
Reinette Chatre <reinette.chatre@intel.com>,
Isaku Yamahata <isaku.yamahata@intel.com>,
Yan Y Zhao <yan.y.zhao@intel.com>,
"tony.lindgren@linux.intel.com" <tony.lindgren@linux.intel.com>
Subject: Re: [PATCH V4 0/1] KVM: TDX: Decrease TDX VM shutdown time
Date: Mon, 14 Jul 2025 06:56:01 -0700 [thread overview]
Message-ID: <aHUMcdJ9Khh2Yeox@google.com> (raw)
In-Reply-To: <3ef581f1-1ff1-4b99-b216-b316f6415318@intel.com>
On Mon, Jul 14, 2025, Xiaoyao Li wrote:
> On 7/12/2025 7:17 AM, Edgecombe, Rick P wrote:
> > On Fri, 2025-07-11 at 16:05 -0700, Sean Christopherson wrote:
> > > > Zero the reserved area in struct kvm_tdx_capabilities so that fields added
> > > > in
> > > > the reserved area won't disturb any userspace that previously had garbage
> > > > there.
> > >
> > > It's not only about disturbing userspace, it's also about actually being able
> > > to repurpose the reserved fields in the future without needing *another* flag
> > > to tell userspace that it's ok to read the previously-reserved fields. I care
> > > about this much more than I care about userspace using reserved fields as
> > > scratch space.
> >
> > If, before calling KVM_TDX_CAPABILITIES, userspace zeros the new field that it
> > knows about, but isn't sure if the kernel does, it's the same no?
Heh, yeah, this crossed my mind about 5 minutes after I logged off :-)
> > Did you see that the way KVM_TDX_CAPABILITIES is implemented today is a little
> > weird? It actually copies the whole struct kvm_tdx_capabilities from userspace
> > and then sets some fields (not reserved) and then copies it back. So userspace
> > can zero any fields it wants to know about before calling KVM_TDX_CAPABILITIES.
> > Then it could know the same things as if the kernel zeroed it.
> >
> > I was actually wondering if we want to change the kernel to zero reserved, if it
> > might make more sense to just copy caps->cpuid.nent field from userspace, and
> > then populate the whole thing starting from a zero'd buffer in the kernel.
>
> +1 to zero the whole buffer of *caps in the kernel.
Ya, I almost suggested that, but assumed there was a reason for copying the entire
structure.
> current code seems to have issue on the caps->kernel_tdvmcallinfo_1_r11/kernel_tdvmcallinfo_1_r12/user_tdvmcallinfo_1_r12,
> as KVM cannot guarantee zero'ed value are returned to userspace.
This? (untested)
diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index f4d4fd5cc6e8..42cb328d8a7d 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -2270,25 +2270,26 @@ static int tdx_get_capabilities(struct kvm_tdx_cmd *cmd)
const struct tdx_sys_info_td_conf *td_conf = &tdx_sysinfo->td_conf;
struct kvm_tdx_capabilities __user *user_caps;
struct kvm_tdx_capabilities *caps = NULL;
+ u32 nr_user_entries;
int ret = 0;
/* flags is reserved for future use */
if (cmd->flags)
return -EINVAL;
- caps = kmalloc(sizeof(*caps) +
+ caps = kzalloc(sizeof(*caps) +
sizeof(struct kvm_cpuid_entry2) * td_conf->num_cpuid_config,
GFP_KERNEL);
if (!caps)
return -ENOMEM;
user_caps = u64_to_user_ptr(cmd->data);
- if (copy_from_user(caps, user_caps, sizeof(*caps))) {
+ if (get_user(nr_user_entries, &user_caps->cpuid.nent)) {
ret = -EFAULT;
goto out;
}
- if (caps->cpuid.nent < td_conf->num_cpuid_config) {
+ if (nr_user_entries < td_conf->num_cpuid_config) {
ret = -E2BIG;
goto out;
}
next prev parent reply other threads:[~2025-07-14 13:56 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-11 9:51 [PATCH V4 0/1] KVM: TDX: Decrease TDX VM shutdown time Adrian Hunter
2025-06-11 9:51 ` [PATCH V4 1/1] KVM: TDX: Add sub-ioctl KVM_TDX_TERMINATE_VM Adrian Hunter
2025-06-16 3:40 ` Vishal Annapurve
2025-06-18 5:50 ` Adrian Hunter
2025-06-18 6:00 ` Vishal Annapurve
2025-06-18 8:33 ` Adrian Hunter
2025-06-19 0:33 ` Sean Christopherson
2025-06-19 11:12 ` Adrian Hunter
2025-06-20 14:24 ` Sean Christopherson
2025-06-20 16:14 ` Vishal Annapurve
2025-06-20 16:26 ` Sean Christopherson
2025-06-23 20:36 ` Vishal Annapurve
2025-06-23 21:39 ` Sean Christopherson
2025-06-23 23:35 ` Vishal Annapurve
2025-06-20 18:59 ` Edgecombe, Rick P
2025-06-20 21:21 ` Vishal Annapurve
2025-06-20 23:34 ` Edgecombe, Rick P
2025-06-21 3:00 ` Vishal Annapurve
2025-06-23 16:23 ` Edgecombe, Rick P
2025-06-23 20:22 ` Vishal Annapurve
2025-06-23 22:51 ` Edgecombe, Rick P
2025-06-18 22:07 ` Edgecombe, Rick P
2025-06-23 20:40 ` Vishal Annapurve
2025-06-25 22:25 ` [PATCH V4 0/1] KVM: TDX: Decrease TDX VM shutdown time Sean Christopherson
2025-06-26 15:58 ` Sean Christopherson
2025-06-26 19:52 ` Adrian Hunter
2025-07-11 8:55 ` Xiaoyao Li
2025-07-11 13:05 ` Sean Christopherson
2025-07-11 13:40 ` Xiaoyao Li
2025-07-11 14:19 ` Sean Christopherson
2025-07-11 22:31 ` Edgecombe, Rick P
2025-07-11 22:54 ` Sean Christopherson
2025-07-11 23:04 ` Edgecombe, Rick P
2025-07-11 23:00 ` Edgecombe, Rick P
2025-07-11 23:05 ` Sean Christopherson
2025-07-11 23:17 ` Edgecombe, Rick P
2025-07-14 3:20 ` Xiaoyao Li
2025-07-14 13:56 ` Sean Christopherson [this message]
2025-07-14 15:06 ` Xiaoyao Li
2025-07-16 9:22 ` Xiaoyao Li
2025-07-18 15:35 ` Sean Christopherson
2025-07-17 9:14 ` Nikolay Borisov
2025-07-18 14:36 ` Sean Christopherson
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=aHUMcdJ9Khh2Yeox@google.com \
--to=seanjc@google.com \
--cc=adrian.hunter@intel.com \
--cc=binbin.wu@linux.intel.com \
--cc=chao.gao@intel.com \
--cc=isaku.yamahata@intel.com \
--cc=kai.huang@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=reinette.chatre@intel.com \
--cc=rick.p.edgecombe@intel.com \
--cc=tony.lindgren@linux.intel.com \
--cc=xiaoyao.li@intel.com \
--cc=yan.y.zhao@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.