linux-kernel - Re: [RFC PATCH v2 14/23] KVM: TDX: Split and inhibit huge mappings if a VMExit carries level info

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: <aRvdewUMeaPZoCEU@yzhao56-desk.sh.intel.com>
Date: Tue, 18 Nov 2025 10:44:11 +0800
From: Yan Zhao <yan.y.zhao@...el.com>
To: "Huang, Kai" <kai.huang@...el.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "Li, Xiaoyao"
	<xiaoyao.li@...el.com>, "quic_eberman@...cinc.com"
	<quic_eberman@...cinc.com>, "Hansen, Dave" <dave.hansen@...el.com>,
	"david@...hat.com" <david@...hat.com>, "thomas.lendacky@....com"
	<thomas.lendacky@....com>, "vbabka@...e.cz" <vbabka@...e.cz>,
	"tabba@...gle.com" <tabba@...gle.com>, "Du, Fan" <fan.du@...el.com>,
	"michael.roth@....com" <michael.roth@....com>, "seanjc@...gle.com"
	<seanjc@...gle.com>, "binbin.wu@...ux.intel.com" <binbin.wu@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>, "Weiny, Ira"
	<ira.weiny@...el.com>, "kas@...nel.org" <kas@...nel.org>,
	"ackerleytng@...gle.com" <ackerleytng@...gle.com>, "Peng, Chao P"
	<chao.p.peng@...el.com>, "zhiquan1.li@...el.com" <zhiquan1.li@...el.com>,
	"Yamahata, Isaku" <isaku.yamahata@...el.com>, "Annapurve, Vishal"
	<vannapurve@...gle.com>, "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
	"Miao, Jun" <jun.miao@...el.com>, "x86@...nel.org" <x86@...nel.org>,
	"pgonda@...gle.com" <pgonda@...gle.com>
Subject: Re: [RFC PATCH v2 14/23] KVM: TDX: Split and inhibit huge mappings
 if a VMExit carries level info

On Tue, Nov 18, 2025 at 08:26:42AM +0800, Huang, Kai wrote:
> On Fri, 2025-11-14 at 09:42 +0800, Yan Zhao wrote:
> > On Tue, Nov 11, 2025 at 06:55:45PM +0800, Huang, Kai wrote:
> > > On Thu, 2025-08-07 at 17:44 +0800, Yan Zhao wrote:
> > > > @@ -2044,6 +2091,9 @@ static int tdx_handle_ept_violation(struct kvm_vcpu *vcpu)
> > > >  		 */
> > > >  		exit_qual = EPT_VIOLATION_ACC_WRITE;
> > > >  
> > > > +		if (tdx_check_accept_level(vcpu, gpa_to_gfn(gpa)))
> > > > +			return RET_PF_RETRY;
> > > > +
> > > 
> > > I don't think you should return RET_PF_RETRY here.
> > > 
> > > This is still at very early stage of EPT violation.  The caller of
> > > tdx_handle_ept_violation() is expecting either 0, 1, or negative error code.
> > Hmm, strictly speaking, the caller of the EPT violation handler is expecting
> > 0, >0, or negative error code.
> > 
> > vcpu_run
> >   |->r = vcpu_enter_guest(vcpu);
> >   |        |->r = kvm_x86_call(handle_exit)(vcpu, exit_fastpath);
> >   |        |  return r;
> >   |  if (r <= 0)
> >   |     break;
> > 
> > handle_ept_violation
> >   |->return __vmx_handle_ept_violation(vcpu, gpa, exit_qualification);
> > 
> > tdx_handle_ept_violation
> >  |->ret = __vmx_handle_ept_violation(vcpu, gpa, exit_qual); 
> >  |  return ret;
> > 
> > The current VMX/TDX's EPT violation handlers returns RET_PF_* to the caller
> > since commit 7c5480386300 ("KVM: x86/mmu: Return RET_PF* instead of 1 in
> > kvm_mmu_page_fault") for the sake of zero-step mitigation.
> > 
> > This is no problem, because
> > 
> > enum {
> >         RET_PF_CONTINUE = 0,
> >         RET_PF_RETRY,
> >         RET_PF_EMULATE,
> >         RET_PF_WRITE_PROTECTED,
> >         RET_PF_INVALID,
> >         RET_PF_FIXED,
> >         RET_PF_SPURIOUS,
> > };
> > 
> > /*
> >  * Define RET_PF_CONTINUE as 0 to allow for
> >  * - efficient machine code when checking for CONTINUE, e.g.
> >  *   "TEST %rax, %rax, JNZ", as all "stop!" values are non-zero,
> >  * - kvm_mmu_do_page_fault() to return other RET_PF_* as a positive value.
> >  */
> > static_assert(RET_PF_CONTINUE == 0);
> 
> Ah, OK.
> 
> But this makes KVM retry fault, when kvm_split_cross_boundary_leafs() fails, due
> to -ENOMEM, presumably.  While in the normal page fault handler path, -ENOMEM
> will just return to userspace AFAICT.
>
> This is not consistent, but I guess nobody cares, or noticed.
Oh, I got your point now.

Though retrying on -ENOMEM is also OK, returning ret to userspace for
consistency is a good point, given mmu_topup_memory_caches() returns -ENOMEM to
userspace.

I'll update it accordingly. Thanks!