linux-kernel - Re: [PATCH v7 7/7] KVM: TDX: Explicitly do WBINVD when no more TDX SEAMCALLs

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] [day] [month] [year] [list]

Message-ID: <95f75d0e10a78537b82d97c1b372a3d6d8d4faa4.camel@intel.com>
Date: Tue, 26 Aug 2025 23:31:47 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Hansen, Dave" <dave.hansen@...el.com>, "seanjc@...gle.com"
	<seanjc@...gle.com>, "Huang, Kai" <kai.huang@...el.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "ashish.kalra@....com"
	<ashish.kalra@....com>, "thomas.lendacky@....com" <thomas.lendacky@....com>,
	"kas@...nel.org" <kas@...nel.org>, "mingo@...hat.com" <mingo@...hat.com>,
	"dwmw@...zon.co.uk" <dwmw@...zon.co.uk>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "Chatre, Reinette" <reinette.chatre@...el.com>,
	"Yamahata, Isaku" <isaku.yamahata@...el.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "tglx@...utronix.de" <tglx@...utronix.de>,
	"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>, "bp@...en8.de" <bp@...en8.de>, "Gao, Chao"
	<chao.gao@...el.com>, "binbin.wu@...ux.intel.com"
	<binbin.wu@...ux.intel.com>, "Williams, Dan J" <dan.j.williams@...el.com>,
	"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH v7 7/7] KVM: TDX: Explicitly do WBINVD when no more TDX
 SEAMCALLs

On Tue, 2025-08-26 at 10:18 -0700, Dave Hansen wrote:
> > Can you add a comment here to explain why this is done even if the kernel
> > doesn't support kexec?  I've no objection to the superfluous flushing, but
> > I've spent far too much time deciphering old commits where the changelog
> > says one thing and the code does something else with no explanation.  I
> > don't want to be party to such crimes 🙂
> 
> You mean as opposed to #ifdef'ing it out?
> 
> Looking at the code again, I completely agree in concept. The connection
> between TDX, kexec and 'cache_state_incoherent' is totally opaque.

So what do we want to do here? Everyone agrees something must be done. We have
two votes for compile out from the KVM maintainer side. Dave, not clear if this
is ok with you or you prefer just a comment.

My 2 cents. Let's just compile it out with a stub (not an IS_ENABLED() check)
because it also means we won't have a "kexec" symbol when kexec is not
configured. For the comment, I think the one in the sole caller is enough. But
if we want some, here is a suggestion to take or leave:

void tdx_cpu_flush_cache_for_kexec(void)
{
	lockdep_assert_preemption_disabled();

	/* Only flush if a SEAMCALL might have dirtied the cache */
	if (!this_cpu_read(cache_state_incoherent))
		return;

	wbinvd();

	/*
         * Clear the tracking so racy shutdown logic doesn't
         * need to flush later during kexec.
         */
	this_cpu_write(cache_state_incoherent, false);
}
EXPORT_SYMBOL_GPL(tdx_cpu_flush_cache_for_kexec);


Paolo, Kai and I are glad to take you up on your offer to take this over.
Hopefully it only needs one more revision. The plan was to take it through tip
with acks for the KVM patch. Do you want to reverse that and get acks for the
arch/x86 parts?