linux-kernel - Re: [RFC PATCH 40/56] x86/alternative: Use sync_core_nmi

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: <20251023222333.4cac1430@pumpkin>
Date: Thu, 23 Oct 2025 22:23:33 +0100
From: David Laight <david.laight.linux@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: "Kaplan, David" <David.Kaplan@....com>, Thomas Gleixner
 <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>, Josh Poimboeuf
 <jpoimboe@...nel.org>, Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
 Ingo Molnar <mingo@...hat.com>, Dave Hansen <dave.hansen@...ux.intel.com>,
 "x86@...nel.org" <x86@...nel.org>, "H . Peter Anvin" <hpa@...or.com>,
 Alexander Graf <graf@...zon.com>, Boris Ostrovsky
 <boris.ostrovsky@...cle.com>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 40/56] x86/alternative: Use sync_core_nmi_safe()

On Mon, 20 Oct 2025 17:01:33 +0200
Peter Zijlstra <peterz@...radead.org> wrote:

> On Mon, Oct 20, 2025 at 02:49:56PM +0000, Kaplan, David wrote:
> 
> > Coming back to this, are you thinking we should just create something
> > like 'text_poke_sync_core()' inside alternative.c and that can use:
> >    1. SERIALIZE (if available)
> >    2. MOV-CR2 (if re-patching)
> >    3. Else, IRET
> > 
> > And maybe someday we put MFENCE into there too for AMD parts.
> > 
> > Right now, of course this is the only logic that would care about an
> > NMI-safe sync_core().  So maybe this makes sense vs creating a generic
> > version that nobody else is using?  
> 
> I was thinking something fairly straight forward like the below. Yes,
> there are a few more sync_core() callers out there, git tells me:
> 
...
> But none of that seems like it cares about an extra few cycles, and why
> complicate matters with another sync_core variant and all that.
> 
...
> +	 * CPUID is the conventional way, but it's nasty: it doesn't
> +	 * exist on some 486-like CPUs, and it usually exits to a
> +	 * hypervisor.

Hasn't support for those 486 cpu been dropped now?
So the comment probably needs updating?

	David