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: <ba611f52-9817-46ff-b16b-a9ef7404a51d@linux.intel.com>
Date: Wed, 11 Jun 2025 23:33:19 +0800
From: Binbin Wu <binbin.wu@...ux.intel.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Rick P Edgecombe <rick.p.edgecombe@...el.com>,
 "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
 "pbonzini@...hat.com" <pbonzini@...hat.com>,
 "mikko.ylinen@...ux.intel.com" <mikko.ylinen@...ux.intel.com>,
 Kai Huang <kai.huang@...el.com>, Jiewen Yao <jiewen.yao@...el.com>,
 Xiaoyao Li <xiaoyao.li@...el.com>, Tony Lindgren <tony.lindgren@...el.com>,
 Adrian Hunter <adrian.hunter@...el.com>,
 Reinette Chatre <reinette.chatre@...el.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 Yan Y Zhao <yan.y.zhao@...el.com>, Isaku Yamahata
 <isaku.yamahata@...el.com>, Kirill Shutemov <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 9:36 PM, Sean Christopherson wrote:
> On Wed, Jun 11, 2025, Binbin Wu wrote:
>> On 6/11/2025 3:58 AM, Sean Christopherson wrote:
>>> On Tue, Jun 10, 2025, Rick P Edgecombe wrote:
>>>> It seems like the reasoning could be just to shrink the possible configurations
>>>> KVM has to think about, and that we only have the option to do this now before
>>>> the ABI becomes harder to change.
>>>>
>>>> Did you need any QEMU changes as a result of this patch?
>>>>
>>>> Wait, actually I think the patch is wrong, because KVM_CAP_EXIT_HYPERCALL could
>>>> be called again after KVM_TDX_FINALIZE_VM. In which case userspace could get an
>>>> exit unexpectedly. So should we drop this patch?
>>> Yes, drop it.
>>>
>> 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?
>
> 	if (!user_exit_on_hypercall(vcpu->kvm, KVM_HC_MAP_GPA_RANGE)) {
> 		ret = TDVMCALL_STATUS_INVALID_OPERAND;
> 		goto error;
> 	}
>
My previous thought was MapGpa is in base GHIC API.
Userspace is required to opt-in KVM_HC_MAP_GPA_RANGE.
If not, it's userspace's responsibility, so I thought exit to userspace with
error may be better.

If return an error code is preferred, now it has a new status code
TDVMCALL_STATUS_SUBFUNC_UNSUPPORTED to use.

Basically, if the MapGpa is not support, either choice will stop VM from
execution. But had a second thought, returning an error code to guest allows
guest to choose to continue or not if MapGpa failed, though I can't
imagine what case it is.