linux-kernel - Re: [PATCH v3 24/25] KVM: TDX: Guard VM state transitions with "all" the locks

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: <aP-1qlTkmFUgTld-@google.com>
Date: Mon, 27 Oct 2025 11:10:50 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Rick P Edgecombe <rick.p.edgecombe@...el.com>
Cc: Yan Y Zhao <yan.y.zhao@...el.com>, 
	"borntraeger@...ux.ibm.com" <borntraeger@...ux.ibm.com>, 
	"kvm-riscv@...ts.infradead.org" <kvm-riscv@...ts.infradead.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>, 
	"pbonzini@...hat.com" <pbonzini@...hat.com>, 
	"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>, 
	"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>, 
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>, 
	"michael.roth@....com" <michael.roth@....com>, "kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"oliver.upton@...ux.dev" <oliver.upton@...ux.dev>, "palmer@...belt.com" <palmer@...belt.com>, 
	"x86@...nel.org" <x86@...nel.org>, "chenhuacai@...nel.org" <chenhuacai@...nel.org>, 
	"aou@...s.berkeley.edu" <aou@...s.berkeley.edu>, Vishal Annapurve <vannapurve@...gle.com>, 
	"binbin.wu@...ux.intel.com" <binbin.wu@...ux.intel.com>, "maddy@...ux.ibm.com" <maddy@...ux.ibm.com>, 
	"maobibo@...ngson.cn" <maobibo@...ngson.cn>, "maz@...nel.org" <maz@...nel.org>, 
	"linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>, "anup@...infault.org" <anup@...infault.org>, 
	Kai Huang <kai.huang@...el.com>, "frankja@...ux.ibm.com" <frankja@...ux.ibm.com>, 
	"pjw@...nel.org" <pjw@...nel.org>, "zhaotianrui@...ngson.cn" <zhaotianrui@...ngson.cn>, 
	"ackerleytng@...gle.com" <ackerleytng@...gle.com>, 
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, Ira Weiny <ira.weiny@...el.com>, 
	"loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>, 
	"imbrenda@...ux.ibm.com" <imbrenda@...ux.ibm.com>, "kas@...nel.org" <kas@...nel.org>
Subject: Re: [PATCH v3 24/25] KVM: TDX: Guard VM state transitions with "all"
 the locks

On Mon, Oct 27, 2025, Rick P Edgecombe wrote:
> On Mon, 2025-10-27 at 17:26 +0800, Yan Zhao wrote:
> > > Ugh, I'd rather not?  Refresh me, what's the story with "v1"?  Are we now on
> > > v2?
> > No... We are now on v1.
> > As in [1], I found that TDX module changed SEAMCALL TDH_VP_INIT behavior to
> > require exclusive lock on resource TDR when leaf_opcode.version > 0.
> > 
> > Therefore, we moved KVM_TDX_INIT_VCPU to tdx_vcpu_unlocked_ioctl() in patch
> > 22.
> > 
> > [1] https://lore.kernel.org/all/aLa34QCJCXGLk%2Ffl@yzhao56-desk.sh.intel.com/
> 
> Looking at the PDF docs, TDR exclusive locking in version == 1 is called out at
> least back to the oldest ABI docs I have (March 2024). Not sure about the
> assertion that the behavior changed, but if indeed this was documented, it's a
> little bit our bad. We might consider being flexible around calling it a TDX ABI
> break?
> 
> Sean, can you elaborate why taking mmu_lock is objectionable here, though?

It's not, I was just hoping we could avoid yet more complexity.

Assuming we do indeed need to take mmu_lock, can you send a patch that applies
on top?  I'm not planning on sending any of this to stable@, so I don't see any
reason to try and juggle patches around.

> Note, myself (and I think Yan?) determined the locking by examining TDX module
> source. For myself, it's possible I misread the locking originally.
> 
> Also, I'm not sure about switching gears at this point, but it makes me wonder
> about the previously discussed option of trying to just duplicate the TDX locks
> on the kernel side.

Please no.  At best that will yield a pile of effectively useless code.  At worst,
it will make us lazy and lead to real bugs because we don't propery guard the *KVM*
flows that need exclusivity relative to what is going on in the TDX-Module.

> Or perhaps make some kind of debug time lockdep type thing to document/check
> the assumptions in the kernel. Something along the lines of this patch, but
> to map the TDX locks to KVM locks or something. As we add more things (DPAMT,
> etc), it doesn't seem like the TDX locking is getting tamer...

Hmm, I like the idea, but actually getting meaningful coverage could be quite
difficult.