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: <ff5fd57a-9522-448c-9ab6-e0006cb6b2ee@intel.com>
Date: Tue, 10 Jun 2025 17:16:53 +0800
From: Xiaoyao Li <xiaoyao.li@...el.com>
To: Binbin Wu <binbin.wu@...ux.intel.com>, pbonzini@...hat.com,
 seanjc@...gle.com, kvm@...r.kernel.org
Cc: rick.p.edgecombe@...el.com, 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 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.

I have a proposal:

Implement KVM_CAP_TDX_USER_EXIT_TDVMCALL

- on check of this cap, KVM returns the bitmap of TDVMCALL leafs that
   allows userspace to opt-in the user exit; e.g.,

#define TDX_USER_EXIT_TDVMCALL_GETQUOTE 		 BIT_ULL(0)
#define TDX_USER_EXIT_TDVMCALL_SetupEventNotifyInterrupt BIT_ULL(1)
...

- on enable of this cap, KVM allows userspace to opt-in which leaf will
   exit to usersapce for handling;

- KVM returns the result for leaf(r12)==1 of <GetTdVmCallInfo> based on
   the KVM_CAP_TDX_USER_EXIT_TDVMCALL enabled by userspace and its own
   capability;

If a non-base GHCI TDVMCALL is supported by KVM itself and no need exit 
to userspace, it's not reported in KVM_CAP_TDX_USER_EXIT_TDVMCALL so 
that usersapce cannot enable the user exit of this leaf. But KVM will 
still return the corresponding bit of this leaf as 1 for leaf(r12)==1 of 
<GetTdVmCallInfo> since it's supported by KVM itself.

If a non-base GHCI TDVMCALL is not supported by KVM itself but KVM 
allows/supports userspace to opt-in the user exit. e.g., <Getquote>. 
check of KVM_CAP_TDX_USER_EXIT_TDVMCALL will have the bit of this leaf set.

  - only when usersapce enable the corresponding bit by calling
    enable_cap(KVM_CAP_TDX_USER_EXIT_TDVMCALL), will KVM return the
    corresponding bit of this leaf as 1 for leaf(r12)==1 of
    <GetTdVmCallInfo> and exit to userspace for such leaf.

  - if userspace doesn't enable the corresponding bit with
    enable_cap(KVM_CAP_TDX_USER_EXIT_TDVMCALL). KVM will return 0 for
    the corresponding bit of this leaf for leaf(r12)==1 of
    <GetTdVmCallInfo> and return TDVMCALL_STATUS_SUBFUNC_UNSUPPORTED when
    TDX guest issues such leaf;

If a non-base GHCI TDVMCALL is not supported by KVM and KVM doesn't 
allow/support userspace to opt-in the user exit. e.g., 
<SetupEventNotifyInterrupt>. check of KVM_CAP_TDX_USER_EXIT_TDVMCALL 
will not have the bit of this leaf set, so that userspace cannot opt-in 
the user exit of such leaf. leaf(r12)==1 of <GetTdVmCallInfo> return the 
bit of such leaf as 0 and TDX guest request of such leaf gets 
TDVMCALL_STATUS_SUBFUNC_UNSUPPORTED.