linux-kernel - Re: [RFC PATCH 4/4] KVM: TDX: Check KVM exit on KVM_HC_MAP_GPA

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: <b4d89b67-0c83-42c7-90d1-3a2c1431a933@linux.intel.com>
Date: Thu, 12 Jun 2025 00:00:18 +0800
From: Binbin Wu <binbin.wu@...ux.intel.com>
To: Xiaoyao Li <xiaoyao.li@...el.com>,
 "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
 "seanjc@...gle.com" <seanjc@...gle.com>
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>,
 "Lindgren, Tony" <tony.lindgren@...el.com>,
 "Hunter, Adrian" <adrian.hunter@...el.com>,
 "Zhao, Yan Y" <yan.y.zhao@...el.com>,
 "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
 "pbonzini@...hat.com" <pbonzini@...hat.com>,
 "Yamahata, Isaku" <isaku.yamahata@...el.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "Shutemov, Kirill" <kirill.shutemov@...el.com>
Subject: Re: [RFC PATCH 4/4] KVM: TDX: Check KVM exit on KVM_HC_MAP_GPA_RANGE
 when TD finalize



On 6/11/2025 10:26 PM, Xiaoyao Li wrote:
> On 6/11/2025 10:04 PM, Edgecombe, Rick P wrote:
>> On Wed, 2025-06-11 at 22:01 +0800, Xiaoyao Li wrote:
>>>>> So, when the TDX guest calls MapGPA and KVM finds userspace doesn't opt-in
>>>>> KVM_HC_MAP_GPA_RANGE, just return error to userspace?
>>>>
>>>> Why can't KVM just do what it already does, and return an error to the
>>>> guest?
>>>
>>> Because GHCI requires it must be supported. No matter with the old GHCI
>>> that only allows <GetTdVmCallInfo> to succeed and the success of
>>> <GetTdVmCallInfo> means all the TDVMCALL leafs are support, or the
>>> proposed updated GHCI that defines <MapGpa> as one of the base API/leaf,
>>> and the base API must be supported by VMM.
>>>
>>> Binbin wants to honor it.
>>
>> But KVM doesn't need to support all ways that userspace could meet the GHCI
>> spec. If userspace opts-in to the exit, they will meet the spec. If they
>> configure KVM differently then they wont, but this is their decision.
>
> I agree with you and Sean. And I'm trying to answer Sean's question on behalf of Binbin.
Yes, it was my thought.

>
> Strictly speaking, KVM can be blamed for some reason. Because it is KVM that returns success for <GetTdVmCallInfo> unconditionally when r12 == 0  to report that all the (base) leafs are supported.
>
> But I totally agree with KVM cannot guarantee userspace will behave correctly. Even with this patch that KVM mandates the userspace to enable user exit of KVM_HC_MAP_GPA_RANGE, it's still possible for a misbehaved userspace to error to TD guest on KVM_HC_MAP_GPA_RANGE and breaks the semantics of successful <GetTdVmCallInfo>.
>
> So I'm with you and Sean.
>
Also see my reply
https://lore.kernel.org/kvm/ba611f52-9817-46ff-b16b-a9ef7404a51d@linux.intel.com/

In the next version, how about combining this patch to patch 1 to use
TDVMCALL_STATUS_SUBFUNC_UNSUPPORTED if userspace doesn't opt-in
KVM_HC_MAP_GPA_RANGE?