Re: [PATCH] x86: add hintable NOPs emulation

[David Laight <david.laight.linux@gmail.com>]

On Thu, 21 Aug 2025 14:46:59 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Thu, Aug 21, 2025 at 01:28:07PM +0100, David Laight wrote:
> > On Wed, 20 Aug 2025 11:07:33 +0200
> > Peter Zijlstra <peterz@infradead.org> wrote:
> >   
> > > On Wed, Aug 20, 2025 at 03:34:46AM +0200, Marcos Del Sol Vives wrote:  
> > > > Hintable NOPs are a series of instructions introduced by Intel with the
> > > > Pentium Pro (i686), and described in US patent US5701442A.
> > > > 
> > > > These instructions were reserved to allow backwards-compatible changes
> > > > in the instruction set possible, by having old processors treat them as
> > > > variable-length NOPs, while having other semantics in modern processors.
> > > > 
> > > > Some modern uses are:
> > > >  - Multi-byte/long NOPs
> > > >  - Indirect Branch Tracking (ENDBR32)
> > > >  - Shadow Stack (part of CET)
> > > > 
> > > > Some processors advertising i686 compatibility lack full support for
> > > > them, which may cause #UD to be incorrectly triggered, crashing software
> > > > that uses then with an unexpected SIGILL.
> > > > 
> > > > One such software is sudo in Debian bookworm, which is compiled with
> > > > GCC -fcf-protection=branch and contains ENDBR32 instructions. It crashes
> > > > on my Vortex86DX3 processor and VIA C3 Nehalem processors [1].
> > > > 
> > > > This patch is a much simplified version of my previous patch for x86
> > > > instruction emulation [2], that only emulates hintable NOPs.
> > > > 
> > > > When #UD is raised, it checks if the opcode corresponds to a hintable NOP
> > > > in user space. If true, it warns the user via the dmesg and advances the
> > > > instruction pointer, thus emulating its expected NOP behaviour.
> > > > 
> > > > [1]: https://lists.debian.org/debian-devel/2023/10/msg00118.html
> > > > [2]: https://lore.kernel.org/all/20210626130313.1283485-1-marcos@orca.pet/
> > > > 
> > > > Signed-off-by: Marcos Del Sol Vives <marcos@orca.pet>    
> > > 
> > > This is going to be terribly slow if there's a significant number of
> > > traps (like with endbr32), but yeah, this ought to work.  
> > 
> > Could you patch the memory resident page to contain a supported nop?
> > (without marking it 'dirty')
> > Then the same function wouldn't trap until the code page was reloaded
> > from the source file.  
> 
> It would mean cloning the page as private. Yes you can do it, uprobes
> has all the code for this. But it has non-trivial memory overhead.

I was thinking it would be safe to do this change without cloning the page.
After all the change is needed for all processes executing the code.
That might only be easy on UP systems - but I doubt the affected CPU are SMP.

	David