linux-kernel - Re: [PATCH v3 3/6] x86/kexec: Disable kexec/kdump on platforms with TDX partial write erratum

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: <CAGtprH-q91ajkgzN3Mki9nRt1cJu2fK7XMiZUeJaAfwZOjLduw@mail.gmail.com>
Date: Wed, 2 Jul 2025 15:16:20 -0700
From: Vishal Annapurve <vannapurve@...gle.com>
To: "Huang, Kai" <kai.huang@...el.com>
Cc: "Gao, Chao" <chao.gao@...el.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>, 
	"ashish.kalra@....com" <ashish.kalra@....com>, "Hansen, Dave" <dave.hansen@...el.com>, 
	"thomas.lendacky@....com" <thomas.lendacky@....com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "mingo@...hat.com" <mingo@...hat.com>, 
	"seanjc@...gle.com" <seanjc@...gle.com>, "pbonzini@...hat.com" <pbonzini@...hat.com>, 
	"tglx@...utronix.de" <tglx@...utronix.de>, "Yamahata, Isaku" <isaku.yamahata@...el.com>, 
	"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>, 
	"Chatre, Reinette" <reinette.chatre@...el.com>, "nik.borisov@...e.com" <nik.borisov@...e.com>, 
	"hpa@...or.com" <hpa@...or.com>, "peterz@...radead.org" <peterz@...radead.org>, 
	"sagis@...gle.com" <sagis@...gle.com>, "Chen, Farrah" <farrah.chen@...el.com>, 
	"Edgecombe, Rick P" <rick.p.edgecombe@...el.com>, "bp@...en8.de" <bp@...en8.de>, 
	"x86@...nel.org" <x86@...nel.org>, "Williams, Dan J" <dan.j.williams@...el.com>
Subject: Re: [PATCH v3 3/6] x86/kexec: Disable kexec/kdump on platforms with
 TDX partial write erratum

On Wed, Jul 2, 2025 at 1:45 AM Huang, Kai <kai.huang@...el.com> wrote:
>
> On Wed, 2025-07-02 at 16:25 +0800, Gao, Chao wrote:
> > On Thu, Jun 26, 2025 at 10:48:49PM +1200, Kai Huang wrote:
> > > Some early TDX-capable platforms have an erratum: A kernel partial
> > > write (a write transaction of less than cacheline lands at memory
> > > controller) to TDX private memory poisons that memory, and a subsequent
> > > read triggers a machine check.
> > >
> > > On those platforms, the old kernel must reset TDX private memory before
> > > jumping to the new kernel, otherwise the new kernel may see unexpected
> > > machine check.  Currently the kernel doesn't track which page is a TDX
> > > private page.  For simplicity just fail kexec/kdump for those platforms.
> >
> > My understanding is that the kdump kernel uses a small amount of memory
> > reserved at boot, which the crashed kernel never accesses. And the kdump
> > kernel reads the memory of the crashed kernel and doesn't overwrite it.
> > So it should be safe to allow kdump (i.e., no partial write to private
> > memory). Anything I missed?
> >
> > (I am not asking to enable kdump in *this* series; I'm just trying to
> > understand the rationale behind disabling kdump)
>
> As you said it *should* be safe.  The kdump kernel should only read TDX
> private memory but not write.  But I cannot say I am 100% sure (there are
> many things involved when generating the kdump file such as memory
> compression) so in internal discussion we thought we should just disable it.

So what's the side-effect of enabling kdump, in the worst case kdump
kernel crashes and in the most likely scenario kdump will generate a
lot of important data to analyze from the host failure.

Allowing kdump seems to be a net positive outcome to me. Am I missing
something? If not, my vote would be to enable/allow kdump for such
platforms in this series itself.