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

On 3/17/25 14:59, Edgecombe, Rick P wrote:
> Sure, but non-selfsnoop CPUs can have trouble when PAT aliases cachetypes, I
> guess. This came up in KVM recently.
> 
> So if new kernel maps the same memory with a different memtype I thought it
> might be a similar problem.
Yeah, both the KeyIDs and memtypes mismatches are places that normal
cache coherency breaks. They break it in different ways for sure, but
it's still broken in a way that software has to work around.

As for kexec vs. PAT memtypes, there are only even theoretical issues on
old hardware.  They _theoretically_ need a WBINVD at kexec. But there
might be enough other things happening during kexec (including other
WBINVD's) to keep us from getting bitten in practice.

I'm not going to lose any sleep over it though.