linux-kernel - Re: [PATCH 4/7] 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: <9d86698d-525e-4d8c-b3d9-b6a0e7634649@intel.com>
Date: Wed, 8 Oct 2025 08:40:28 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Jürgen Groß <jgross@...e.com>,
 "Reshetova, Elena" <elena.reshetova@...el.com>,
 "Annapurve, Vishal" <vannapurve@...gle.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "bp@...en8.de" <bp@...en8.de>,
 "tglx@...utronix.de" <tglx@...utronix.de>,
 "peterz@...radead.org" <peterz@...radead.org>,
 "mingo@...hat.com" <mingo@...hat.com>, "hpa@...or.com" <hpa@...or.com>,
 "thomas.lendacky@....com" <thomas.lendacky@....com>,
 "x86@...nel.org" <x86@...nel.org>, "kas@...nel.org" <kas@...nel.org>,
 "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
 "dwmw@...zon.co.uk" <dwmw@...zon.co.uk>, "Huang, Kai" <kai.huang@...el.com>,
 "seanjc@...gle.com" <seanjc@...gle.com>,
 "Chatre, Reinette" <reinette.chatre@...el.com>,
 "Yamahata, Isaku" <isaku.yamahata@...el.com>,
 "Williams, Dan J" <dan.j.williams@...el.com>,
 "ashish.kalra@....com" <ashish.kalra@....com>,
 "nik.borisov@...e.com" <nik.borisov@...e.com>, "Gao, Chao"
 <chao.gao@...el.com>, "sagis@...gle.com" <sagis@...gle.com>,
 "Chen, Farrah" <farrah.chen@...el.com>, Binbin Wu <binbin.wu@...ux.intel.com>
Subject: Re: [PATCH 4/7] x86/kexec: Disable kexec/kdump on platforms with TDX
 partial write erratum

On 10/7/25 06:31, Jürgen Groß wrote:>
> If we can't come to an agreement that kdump should be allowed in
> spite of a potential #MC, maybe we could disable kdump only if TDX
> guests have been active on the machine before?

How would we determine that?

We can't just call the TDX module to see because it might have been
running before but got shut down.