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

On Tue, 2024-10-15 at 12:03 +1300, Huang, Kai wrote:
> > "Is going to", as in "will be changed to"? Or "does today"?
> 
> Will be changed to (today's behaviour is to go back to guest to let the 
> fault happen again to retry).
> 
> AFAICT this is what Sean suggested:
> 
> https://lore.kernel.org/all/ZuR09EqzU1WbQYGd@google.com/
> 
> The whole point is to let KVM loop internally but not go back to guest 
> when the fault handler sees a frozen PTE.  And in this proposal this 
> applies to both leaf and non-leaf PTEs IIUC, so it should handle the 
> case where try_cmpxchg64() fails as mentioned by Yan.
> 
> > 
> > > retry internally for
> > > step 4 (retries N times) because it sees the frozen PTE, but will never go
> > > back
> > > to guest after the fault is resolved?  How can step 4 triggers zero-step?
> > 
> > Step 3-4 is saying it will go back to the guest and fault again.
> 
> As said above, the whole point is to make KVM loop internally when it 
> sees a frozen PTE, but not go back to guest.

Yea, I was saying on that idea that I thought looping forever without checking
for a signal would be problematic. Then userspace could re-enter the TD. I don't
know if it's a show stopper.

In any case the discussion between these threads and LPC/KVM forum hallway
chatter has gotten a bit fragmented. I don't think there is any concrete
consensus solution at this point.