linux-kernel - Re: [RFC PATCH 1/5] x86/kexec: Do unconditional WBINVD for bare-metal in stop_this

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: <gbxpvgmmzf354g3gccflrv5shtaque4rd3uklrgltlbnedip7y@hhwvyhxh46nk>
Date: Mon, 17 Mar 2025 14:52:49 +0200
From: "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc: "tglx@...utronix.de" <tglx@...utronix.de>, 
	"peterz@...radead.org" <peterz@...radead.org>, "mingo@...hat.com" <mingo@...hat.com>, 
	"Hansen, Dave" <dave.hansen@...el.com>, "Huang, Kai" <kai.huang@...el.com>, 
	"bp@...en8.de" <bp@...en8.de>, "nik.borisov@...e.com" <nik.borisov@...e.com>, 
	"bhe@...hat.com" <bhe@...hat.com>, "seanjc@...gle.com" <seanjc@...gle.com>, 
	"x86@...nel.org" <x86@...nel.org>, "dyoung@...hat.com" <dyoung@...hat.com>, 
	"sagis@...gle.com" <sagis@...gle.com>, "hpa@...or.com" <hpa@...or.com>, 
	"Chatre, Reinette" <reinette.chatre@...el.com>, "Williams, Dan J" <dan.j.williams@...el.com>, 
	"thomas.lendacky@....com" <thomas.lendacky@....com>, "pbonzini@...hat.com" <pbonzini@...hat.com>, 
	"ashish.kalra@....com" <ashish.kalra@....com>, "Yamahata, Isaku" <isaku.yamahata@...el.com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "dwmw@...zon.co.uk" <dwmw@...zon.co.uk>
Subject: Re: [RFC PATCH 1/5] x86/kexec: Do unconditional WBINVD for
 bare-metal in stop_this_cpu()

On Thu, Mar 13, 2025 at 06:40:09PM +0000, Edgecombe, Rick P wrote:
> > Currently, the kernel only performs WBINVD in stop_this_cpu() when SME
> > is supported by hardware.  Perform unconditional WBINVD to support TDX
> > instead of adding one more vendor-specific check.  Kexec is a slow path,
> > and the additional WBINVD is acceptable for the sake of simplicity and
> > maintainability.
> 
> Out of curiosity, do you know why this was not already needed for non-self snoop
> CPUs? Why can't there be other cache modes that get written back after the new
> kernel starts using the memory for something else?

KeyID is a hack. Memory controller is aware about KeyID, but not cache.
Cache considers KeyID as part of physical address. Two cache lines for the
same physical address with different KeyID are considered unrelated from
cache coherency PoV.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov