linux-kernel - Re: [PATCH 09/21] KVM: TDX: Retry seamcall when TDX_OPERAND

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: <5f7ee34ca34bdfcc9bf8644b66d05b10cc2d42af.camel@intel.com>
Date: Wed, 11 Sep 2024 02:48:52 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "seanjc@...gle.com" <seanjc@...gle.com>, "Huang, Kai"
	<kai.huang@...el.com>
CC: "Yao, Yuan" <yuan.yao@...el.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "isaku.yamahata@...il.com"
	<isaku.yamahata@...il.com>, "Zhao, Yan Y" <yan.y.zhao@...el.com>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>, "nik.borisov@...e.com" <nik.borisov@...e.com>,
	"dmatlack@...gle.com" <dmatlack@...gle.com>
Subject: Re: [PATCH 09/21] KVM: TDX: Retry seamcall when TDX_OPERAND_BUSY with
 operand SEPT

On Wed, 2024-09-11 at 13:17 +1200, Huang, Kai wrote:
> > is the VM-Enter
> > error uniquely identifiable, 
> 
> When zero-step mitigation is active in the module, TDH.VP.ENTER tries to 
> grab the SEPT lock thus it can fail with SEPT BUSY error.  But if it 
> does grab the lock successfully, it exits to VMM with EPT violation on 
> that GPA immediately.
> 
> In other words, TDH.VP.ENTER returning SEPT BUSY means "zero-step 
> mitigation" must have been active.  

I think this isn't true. A sept locking related busy, maybe. But there are other
things going on that return BUSY.

> A normal EPT violation _COULD_ mean 
> mitigation is already active, but AFAICT we don't have a way to tell 
> that in the EPT violation.
> 
> > and can KVM rely on HOST_PRIORITY to be set if KVM
> > runs afoul of the zero-step mitigation?
> 
> I think HOST_PRIORITY is always set if SEPT SEAMCALLs fails with BUSY.

What led you to think this? It seemed more limited to me.