linux-kernel - Re: [PATCH v2 00/21] Runtime TDX Module update support

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGtprH_1CRxEUoJnU7KVrJK_Sgtq_jngxC0yRX3gVNguocZ9zg@mail.gmail.com>
Date: Fri, 24 Oct 2025 14:09:57 -0700
From: Vishal Annapurve <vannapurve@...gle.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Sean Christopherson <seanjc@...gle.com>, dan.j.williams@...el.com, 
	Chao Gao <chao.gao@...el.com>, Elena Reshetova <elena.reshetova@...el.com>, 
	"linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "x86@...nel.org" <x86@...nel.org>, 
	Reinette Chatre <reinette.chatre@...el.com>, Ira Weiny <ira.weiny@...el.com>, 
	Kai Huang <kai.huang@...el.com>, "yilun.xu@...ux.intel.com" <yilun.xu@...ux.intel.com>, 
	"sagis@...gle.com" <sagis@...gle.com>, "paulmck@...nel.org" <paulmck@...nel.org>, 
	"nik.borisov@...e.com" <nik.borisov@...e.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>, 
	Ingo Molnar <mingo@...hat.com>, "Kirill A. Shutemov" <kas@...nel.org>, Paolo Bonzini <pbonzini@...hat.com>, 
	Rick P Edgecombe <rick.p.edgecombe@...el.com>, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v2 00/21] Runtime TDX Module update support

On Fri, Oct 24, 2025 at 1:14 PM Dave Hansen <dave.hansen@...el.com> wrote:
>
> On 10/24/25 13:00, Sean Christopherson wrote:
> > C'mon people (especially the Google folks), this is the ***exact***
> > same problem as certificate updates for SNP[1].  Y'all suggested
> > holding a lock across a userspace exit back then, and Dan's analysis
> > confirms my reaction from back then that "Holding a lock across an
> > exit to userspace seems wildly unsafe."[2]
> >
> > In the end, it took more time to understand the problem then to
> > sketch out and test a solution[3].
> >
> > Unless this somehow puts the host (kernel) at risk, this is a
> > userspace problem.
>
> If there's an similar SEV-SNP problem and accepted solution punted to
> userspace that TDX can leverage, I'm 100% on board with that. Let's do that.

So IIUC, the current stance is that the kernel can rely on userspace
to ensure forward progress of TDX module update.

I still vote for the "Avoid updates during update sensitive times"
approach to be enabled in the host kernel to ensure userspace can't
mess up the TDX module state.