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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ