linux-kernel - Re: [RFC PATCH 31/56] x86/alternative: Prepend nops with retpolines

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: <20251022104043.GY3419281@noisy.programming.kicks-ass.net>
Date: Wed, 22 Oct 2025 12:40:43 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: David Laight <david.laight.linux@...il.com>
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 31/56] x86/alternative: Prepend nops with retpolines

On Wed, Oct 22, 2025 at 09:41:05AM +0100, David Laight wrote:

> > > Ah, I found it, you freeze everything, which puts it at safe points.  
> > 
> > Yes.  In fact, I think you were the one who pointed me in that direction :)
> 
> Does that help?
> It'll stop the cpu prefetch queue containing garbage and let you flush the I-cache,
> but I don't see how it can stop the return address after the NOP3 being on the
> stack from an earlier interrupt, or even the nmi entry itself.
> 
> I'm not sure, but if the kernel is pre-emptable could a sleeping thread have
> a stack that includes the address after the NOP3 - eg if an interrupt at
> that point is what caused the reschedule.

The thing is that freezing is only done at known safe points;
specifically schedule() calls that have TASK_FREEZABLE set.

Typically this is the return to userspace point and for kernel threads
somewhere in their main event loop.

This ensures tasks are not preempted at random points like in the middle
of an alternative.