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] [day] [month] [year] [list]

Message-ID: <20250114103604.7388352c@gandalf.local.home>
Date: Tue, 14 Jan 2025 10:36:04 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Jiri Olsa <olsajiri@...il.com>
Cc: 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, 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

-- Steve