linux-kernel - Re: [RFC PATCH 3/4] KVM: TDX: Exit to userspace for GetTdVmCallInfo

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e2e7f3d0-1077-44c6-8a1d-add4e1640d32@linux.intel.com>
Date: Wed, 11 Jun 2025 10:04:56 +0800
From: Binbin Wu <binbin.wu@...ux.intel.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
 "Li, Xiaoyao" <xiaoyao.li@...el.com>,
 "pbonzini@...hat.com" <pbonzini@...hat.com>,
 "seanjc@...gle.com" <seanjc@...gle.com>,
 "kvm@...r.kernel.org" <kvm@...r.kernel.org>
Cc: "mikko.ylinen@...ux.intel.com" <mikko.ylinen@...ux.intel.com>,
 "Huang, Kai" <kai.huang@...el.com>, "Yao, Jiewen" <jiewen.yao@...el.com>,
 "Chatre, Reinette" <reinette.chatre@...el.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "Zhao, Yan Y" <yan.y.zhao@...el.com>,
 "Lindgren, Tony" <tony.lindgren@...el.com>,
 "Shutemov, Kirill" <kirill.shutemov@...el.com>,
 "Hunter, Adrian" <adrian.hunter@...el.com>,
 "Yamahata, Isaku" <isaku.yamahata@...el.com>
Subject: Re: [RFC PATCH 3/4] KVM: TDX: Exit to userspace for GetTdVmCallInfo



On 6/11/2025 12:54 AM, Edgecombe, Rick P wrote:
> On Tue, 2025-06-10 at 09:50 -0700, Rick Edgecombe wrote:
>> Why do we need an opt-in interface instead of a way to expose which exit's are
>> supported by KVM? I would think the need for a TDVMCALL opt-in interface would
>> only come up if there was a bad guest that was making TDVMCALLs that it did not
>> see in GetTdVmCallInfo.

The opt-in interface can eliminate some requirements for userspace.
E.g, for GetQuote, this patch set enforces userspace to handle the exit reason
due to GetQuote as the initial support, because KVM doesn't know if userspace
is able to handle the exit reason or not without userspace's opt-in, unless
it's handled by default in userspace.

>>   So that we would actually require an opt-in is not
>> guaranteed.
>>
>> Another consideration could be how to handle GetQuote for an eventual TDVMCALL
>> opt-in interface, should it be needed. The problem would be GetQuote would be
>> opted in by default and make the interface weird. But we may not want to have a
>> TDVMCall specific opt-in interface. There could be other TDX behaviors that we
>> need to opt-in around. In which case the opt-in interface could be more generic,
>> and by implementing the TDVMCall opt-in interface ahead of time we would end up
>> with two opt-in interfaces instead of one.

Maybe we can use a TDX specific opt-in interface instead of TDVMCALL specific
interface.
But not sure we should add it now or later.

>>
>> So how about just adding a field to struct kvm_tdx_capabilities to describe the
>> KVM TDVMcalls? Or some other place? But don't invent an opt-in interface
>> until/if we need it.
> Oh, and there already is a hypercall exit opt-in interface, so
> KVM_CAP_TDX_USER_EXIT_TDVMCALL would overlap with it, right?
Not sure what does "overlap" mean here.

They have different namespaces, so they don't impact each other.

Or did you mean it's a duplication both having KVM_CAP_EXIT_HYPERCALL and
KVM_CAP_TDX_USER_EXIT_TDVMCALL?