From: Peter Zijlstra <peterz@infradead.org>
To: David Laight <david.laight.linux@gmail.com>
Cc: Marcos Del Sol Vives <marcos@orca.pet>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Brian Gerst <brgerst@gmail.com>, Uros Bizjak <ubizjak@gmail.com>,
Ard Biesheuvel <ardb@kernel.org>,
David Kaplan <david.kaplan@amd.com>,
"Ahmed S. Darwish" <darwi@linutronix.de>,
Kees Cook <kees@kernel.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Oleg Nesterov <oleg@redhat.com>, "Xin Li (Intel)" <xin@zytor.com>,
Sabyrzhan Tasbolatov <snovitoll@gmail.com>
Subject: Re: [PATCH] x86: add hintable NOPs emulation
Date: Thu, 21 Aug 2025 14:46:59 +0200 [thread overview]
Message-ID: <20250821124659.GO3289052@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20250821132807.0a898dfa@pumpkin>
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.
next prev parent reply other threads:[~2025-08-21 12:47 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-20 1:34 [PATCH] x86: add hintable NOPs emulation Marcos Del Sol Vives
2025-08-20 9:07 ` Peter Zijlstra
2025-08-21 12:28 ` David Laight
2025-08-21 12:46 ` Peter Zijlstra [this message]
2025-08-21 18:40 ` David Laight
2025-08-21 19:46 ` Marcos Del Sol Vives
2025-08-21 15:11 ` Marcos Del Sol Vives
2025-08-20 9:14 ` Ahmed S. Darwish
2025-08-20 9:33 ` Marcos Del Sol Vives
2025-08-20 9:43 ` Borislav Petkov
2025-08-20 9:51 ` Marcos Del Sol Vives
2025-08-20 9:55 ` Borislav Petkov
2025-08-20 10:01 ` Marcos Del Sol Vives
2025-08-20 10:08 ` Borislav Petkov
2025-08-20 10:21 ` Marcos Del Sol Vives
2025-08-20 10:30 ` Borislav Petkov
2025-08-21 2:00 ` Kees Cook
2025-08-20 10:11 ` Ahmed S. Darwish
2025-08-20 10:30 ` Ahmed S. Darwish
2025-08-21 1:43 ` H. Peter Anvin
2025-08-21 9:35 ` Marcos Del Sol Vives
2025-08-21 5:02 ` H. Peter Anvin
2025-08-21 12:26 ` David Laight
2025-08-21 12:48 ` Marcos Del Sol Vives
2025-08-21 12:48 ` Peter Zijlstra
2025-08-21 13:45 ` Marcos Del Sol Vives
2025-08-21 13:59 ` Peter Zijlstra
2025-08-22 22:12 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250821124659.GO3289052@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=andrew.cooper3@citrix.com \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=darwi@linutronix.de \
--cc=dave.hansen@linux.intel.com \
--cc=david.kaplan@amd.com \
--cc=david.laight.linux@gmail.com \
--cc=hpa@zytor.com \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcos@orca.pet \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=snovitoll@gmail.com \
--cc=tglx@linutronix.de \
--cc=ubizjak@gmail.com \
--cc=x86@kernel.org \
--cc=xin@zytor.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.