linux-kernel - Re: [RFC] x86/alternatives: Merge first and second step in text_poke_bp

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: <Z4f91RUP8sDniss7@krava>
Date: Wed, 15 Jan 2025 19:26:29 +0100
From: Jiri Olsa <olsajiri@...il.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Jiri Olsa <olsajiri@...il.com>, Peter Zijlstra <peterz@...radead.org>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	David Laight <David.Laight@...lab.com>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-trace-kernel@...r.kernel.org, bpf@...r.kernel.org,
	x86@...nel.org
Subject: Re: [RFC] x86/alternatives: Merge first and second step in
 text_poke_bp_batch

On Tue, Jan 14, 2025 at 10:36:04AM -0500, Steven Rostedt wrote:
> On Tue, 14 Jan 2025 15:31:14 +0100
> Jiri Olsa <olsajiri@...il.com> wrote:
> 
> > > IIRC this is the magic recipe blessed by both Intel and AMD, and
> > > if we're going to be changing this I would want both vendors to sign off
> > > on that.  
> > 
> > ok
> 
> Right. In fact Intel wouldn't sign off on this recipe for a few years. We
> actually added to the kernel before they gave their full blessing. I got a
> "wink, it should work" from them but they wouldn't officially say so ;-)
> 
> But a lot of it has to do with all the magic of the CPU. They have always
> allowed writing the one byte int3. I figured, if I could write that one
> byte int3 then run a sync on all CPUs where all CPUs see that change, then
> nothing should ever care about the other 4 bytes after that int3 (a sync
> was already done). Then change the 4 bytes and sync again.
> 
> I doubt the int3 plus the 4 byte change would work, as was mentioned if the
> other 4 bytes were on another cache line, another CPU could read the first
> set of bytes without the int3 and the second set of bytes with the update
> and go boom!
> 
> This dance was to make sure everything sees everything properly. I gave a
> talk about this at Kernel-Recipes in 2019:
> 
>   https://www.slideshare.net/slideshow/kernel-recipes-2019-ftrace-where-modifying-a-running-kernel-all-started/177509633#44

nice! thanks for all the details,
jirka