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: <aEmYqH_2MLSwloBX@google.com>
Date: Wed, 11 Jun 2025 07:54:32 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Xiaoyao Li <xiaoyao.li@...el.com>
Cc: Binbin Wu <binbin.wu@...ux.intel.com>, rick.p.edgecombe@...el.com, 
	pbonzini@...hat.com, kvm@...r.kernel.org, kai.huang@...el.com, 
	adrian.hunter@...el.com, reinette.chatre@...el.com, tony.lindgren@...el.com, 
	isaku.yamahata@...el.com, yan.y.zhao@...el.com, mikko.ylinen@...ux.intel.com, 
	linux-kernel@...r.kernel.org, kirill.shutemov@...el.com, jiewen.yao@...el.com
Subject: Re: [RFC PATCH 3/4] KVM: TDX: Exit to userspace for GetTdVmCallInfo

On Wed, Jun 11, 2025, Xiaoyao Li wrote:
> On 6/11/2025 9:37 AM, Binbin Wu wrote:
> > On 6/10/2025 5:16 PM, Xiaoyao Li wrote:
> > > On 6/10/2025 10:14 AM, Binbin Wu wrote:
> > > > Exit to userspace for TDG.VP.VMCALL<GetTdVmCallInfo> via a new KVM exit
> > > > reason to allow userspace to provide information about the support of
> > > > TDVMCALLs when r12 is 1 for the TDVMCALLs beyond the GHCI base API.
> > > > 
> > > > GHCI spec defines the GHCI base TDVMCALLs: <GetTdVmCallInfo>, <MapGPA>,
> > > > <ReportFatalError>, <Instruction.CPUID>, <#VE.RequestMMIO>,
> > > > <Instruction.HLT>, <Instruction.IO>, <Instruction.RDMSR> and
> > > > <Instruction.WRMSR>. They must be supported by VMM to support
> > > > TDX guests.
> > > > 
> > > > For GetTdVmCallInfo
> > > > - When leaf (r12) to enumerate TDVMCALL functionality is set to 0,
> > > >    successful execution indicates all GHCI base TDVMCALLs listed
> > > > above are
> > > >    supported.
> > > > 
> > > >    Update the KVM TDX document with the set of the GHCI base APIs.
> > > > 
> > > > - When leaf (r12) to enumerate TDVMCALL functionality is set to 1, it
> > > >    indicates the TDX guest is querying the supported TDVMCALLs beyond
> > > >    the GHCI base TDVMCALLs.
> > > >    Exit to userspace to let userspace set the TDVMCALL
> > > > sub-function bit(s)
> > > >    accordingly to the leaf outputs.  KVM could set the TDVMCALL bit(s)
> > > >    supported by itself when the TDVMCALLs don't need support
> > > > from userspace
> > > >    after returning from userspace and before entering guest.
> > > > Currently, no
> > > >    such TDVMCALLs implemented, KVM just sets the values returned from
> > > >    userspace.
> > > > 
> > > >    A new KVM exit reason KVM_EXIT_TDX_GET_TDVMCALL_INFO and its
> > > > structure
> > > >    are added. Userspace is required to handle the exit reason as
> > > > the initial
> > > >    support for TDX.
> > > 
> > > It doesn't look like a good and correct design.
> > > 
> > > Consider the case that userspace supports SetupEventNotifyInterrupt
> > > and returns bit 1 of leaf_output[0] as 1 to KVM, and KVM returns it
> > > to TD guest for TDVMCALL_GET_TD_VM_CALL_INFO. So TD guest treats it
> > > as SetupEventNotifyInterrupt is support. But when TD guest issues
> > > this TDVMCALL, KVM doesn't support the exit to userspace for this
> > > specific leaf and userspace doesn't have chance to handle it.
> > Previously, I also had the idea of setting the information based on
> > userspace's opt-ins.
> > 
> > But for simplicity, this patch set doesn't adopt the opt-in mechanism for
> > KVM exit reasons due to TDVMCALLs.
> > 
> > To resolve the issue you mentions that userspace could set a bit that KVM
> > doesn't support the exit to userspace, KVM could mask off the bit(s) not
> > supported by KVM before returning back to guest.
> 
> silently mask off the value provided from userspace is not a stable ABI from
> userspace perspective. A kvm cap to report what value is allowed/supported
> is still helpful.
> 
> > If we agree that it's the right time to have the opt-in, we could go the
> > opt-in way and KVM could set the information based on userspace's opt-ins
> > without exit to userspace for GetTdVmCallInfo.
> 
> Let's see what Paolo and Sean will say.

Kicking this to userspace seems premature.  AIUI, no "optional" VMCALL features
are defined at this time, i.e. there's nothing to enumerate.  And there's no
guarantee that there will ever be capabilties that require enumeration from 
*userspace*.  E.g. if fancy feature XYZ requires enumeration, but that feature
requires explicit KVM support, then forcing userspace will be messy.

So I don't see why KVM should anything other than return '0' to the guest (or
whatever value says "there's nothing here").