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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <IA1PR11MB94955392108F5A662D469134E7E9A@IA1PR11MB9495.namprd11.prod.outlook.com>
Date: Thu, 16 Oct 2025 06:46:07 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: "Hansen, Dave" <dave.hansen@...el.com>, "Annapurve, Vishal"
	<vannapurve@...gle.com>, "Gao, Chao" <chao.gao@...el.com>
CC: "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>, "Chatre, Reinette"
	<reinette.chatre@...el.com>, "Weiny, Ira" <ira.weiny@...el.com>, "Huang, Kai"
	<kai.huang@...el.com>, "Williams, Dan J" <dan.j.williams@...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>, "Edgecombe, Rick P"
	<rick.p.edgecombe@...el.com>, Thomas Gleixner <tglx@...utronix.de>
Subject: RE: [PATCH v2 00/21] Runtime TDX Module update support



> -----Original Message-----
> From: Hansen, Dave <dave.hansen@...el.com>
> Sent: Wednesday, October 15, 2025 6:03 PM
> To: Reshetova, Elena <elena.reshetova@...el.com>; Annapurve, Vishal
> <vannapurve@...gle.com>; Gao, Chao <chao.gao@...el.com>
> Cc: linux-coco@...ts.linux.dev; linux-kernel@...r.kernel.org; x86@...nel.org;
> Chatre, Reinette <reinette.chatre@...el.com>; Weiny, Ira
> <ira.weiny@...el.com>; Huang, Kai <kai.huang@...el.com>; Williams, Dan J
> <dan.j.williams@...el.com>; yilun.xu@...ux.intel.com; sagis@...gle.com;
> paulmck@...nel.org; 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>; Edgecombe, Rick P
> <rick.p.edgecombe@...el.com>; Thomas Gleixner <tglx@...utronix.de>
> Subject: Re: [PATCH v2 00/21] Runtime TDX Module update support
> 
> On 10/15/25 01:54, Reshetova, Elena wrote:
> ...
> >> "Performing TD Preserving during a TD Build operation might result in
> >> a corrupted TD hash in the TD attestation report. Until fixed in a
> >> future Intel TDX module update, a host VMM can avoid the problem by
> >> not conducting a TD Preserving Update while TD Build operation is in
> >> progress."
> >>
> >> Do you know if this issue is fixed already? If so, what version of TDX
> >> module fixes this issue?
> >
> > It is not fixed, because the limitation comes from the internal crypto context
> > maintained by the IPP crypto library.
> 
> Does the TD attestation report contain information about the TDX module?

Yes, of course. 

> Isn't that information in flux during a module update?

If you mean that the attestation after a TD preserving update will show a different
TDX module, it depends if SVN has changed (if yes, then it will be visible).
But I fail to see how this relates to the problem we are discussing. 
Here, the attestation of a TD that was build during the TD preserving update
will fail, because the end crypto hash would not match. 
It would look like a random failure to CSP, because VMM did everything correctly
(build a TD), but TD's attestation will fail.
Not a very good situation to debug. 


> 
> ...
> > But the situation can be avoided fully, if TD preserving update is not
> conducted
> > during the TD build time.
> 
> Sure, and the TDX module itself could guarantee this as well as much as
> the kernel could. It could decline to allow module updates during TD
> builds, or error out the TD build if it collides with an update.

TDX module has a functionality to decline going into SHUTDOWN state
(pre-requisite for TD preserving update) if TD build or any problematic
operation is in progress. It requires VMM to opt-in into this feature.