Re: [REGRESSION] 32-bit ARM's BKPT instruction no longer works

[Russell King <linux@armlinux.org.uk>]

On Fri, Jun 26, 2026 at 02:53:56PM +0100, David Laight wrote:
> On Fri, 26 Jun 2026 14:53:56 +0200
> Linus Walleij <linusw@kernel.org> wrote:
> 
> > [Adding Nathan and Kees so we can figure out how best to deal with this]
> > 
> > On Sun, Jun 21, 2026 at 9:15 PM slipher <slipher@protonmail.com> wrote:
> > 
> > > Consider the C program for 32-bit ARM architectures:
> > >
> > >
> > > int main() {
> > >         __asm__ __volatile__ ("BKPT");
> > >         return 0;
> > > }
> > >
> > > Expected behavior is that this raises SIGTRAP. Since Linux 6.10 this no
> > > longer happens; instead execution perpetually resumes at the same
> > > instruction, using 100% of CPU. It does not matter whether GDB is
> > > attached. I have tested with an armv7l CPU, but I imagine any other
> > > variants with the BKPT instruction would be equally affected.
> > >
> > > I believe the culprit to be commit
> > > c3f89986fde7bb9ccc86a901bf28e1f7d69fc3b3 "ARM: 9391/2: hw_breakpoint:
> > > Handle CFI breakpoints".  The commit defines the method-of-entry code 3
> > > as "ARM_ENTRY_CFI_BREAKPOINT", but this is the code used for any BKPT
> > > instruction - see
> > > https://developer.arm.com/documentation/ddi0379/a/Debug-Register-Reference/Control-and-status-registers/Debug-Status-and-Control-Register--DSCR-?lang=en
> > > "Method of Debug Entry (MOE), bits [5:2]". If the CFI option is disabled
> > > in the kernel config,  hw_breakpoint_pending() returns 0 indicating the
> > > breakpoint was handled, but takes no action. So breakpoints cannot be
> > > used by user-space code, regardless of how CONFIG_CFI is set. The blog
> > > post
> > > https://www.jwhitham.org/2015/04/the-mystery-of-fifteen-millisecond.html
> > > gives a nice overview of the control flow in older, working kernels.  
> > 
> > Does simply reverting the patch solve the issue?
> > 
> > > The following Systemtap script can be used to demonstrate that the
> > > ARM_ENTRY_CFI_BREAKPOINT path is used, when running the above C program.  
> > 
> > Yeah it's definitely that one causing it.
> > 
> > I sent the naive solution to it, and before anyone point it out: no it does
> > not allow custom breakpoints to be mixed with kernel CFI, but it
> > probably makes legacy systems work on newer kernels since they
> > probably don't select CFI.
> > https://lore.kernel.org/linux-arm-kernel/20260626-arm32-cfi-bug-v1-1-a467b5050c0b@kernel.org/T/#u
> > 
> > I understand that this is not solving everything.
> 
> I'm confused.
> Why would building a kernel with CFI (to check kernel indirect calls)
> change the behaviour of executing anything in userspace?
> 
> If userspace is compiled with CFI and gets an equivalent fail then you'd
> (probably) want a fatal signal - but isn't that entirely unrelated to
> the kernel code.
> Do those checks even need kernel support? I know shadow stacks do.

CFI generates instructions that can check the type of the function
against the caller. It appears that on 32-bit ARM, Clang close that,
in the case of a mismatch, it would cause a BKPT instruction to be
executed.

Linus' code in commit c3f89986fde7 ("ARM: 9391/2: hw_breakpoint:
Handle CFI breakpoints") added code to handle this BKPT use.

However, we now have a regression reported as a result of that commit
where there is a userspace program that has explicit BKPT instructions
encoded within it, and the program relies on the kernel behaviour that
was introduced in f81ef4a920c8 ("ARM: 6356/1: hw-breakpoint: add ARM
backend for the hw-breakpoint framework") in 2.6.37 - and this "new"
behaviour is conditional on CONFIG_PERF_EVENTS being enabled - where
it raises a SIGTRAP.

Prior to this commit, or whenever CONFIG_PERF_EVENTS is disabled, the
kernel will raise a SIGBUS instead.

Both SIGTRAP and SIGBUS are "forced" signals - the kernel will force
them to be delivered to the program irrespective of whether the program
has blocked or ignored these signals, since this is the kernel trying
to save the system (because it doesn't know how to handle it.)

Moreover, BKPT was only introduced around the ARMv5TE era, and the
FSR code for it was only added in later architecture reference manuals,
changing an existing FSR code from an implementation defined "Terminal
Exception" to an architecturally defined "Debug Exception".

Support for this "Debug Exception" was only added with patch 6356/1,
but that did not handle the BKPT instruction. Linus' commit above
(9391/1) added support for the CFI case, but meant that userspace
would now spin on a BKPT instruction rather than force a signal,
thereby causing the regression.

We can't fix BKPT handling - this userspace program relies on the fact
that the kernel doesn't handle this instruction (for example, it relies
on the PC not being advanced) and advancing the PC by one instruction
after a SIGTRAP handler returns may not be the correct way to handle
it anyway. Consider BKPT being used as an "assert" type context, where
the compiler doesn't expect execution to continue, and a literal pool
following the instruction.

We are now stuck with the sorry state that BKPT is, and as I have said
many times now, BKPT should be avoided - it's an utter trainwreck. The
only sensible use that BKPT has is with a hardware debugger that traps
the BKPT entry into debug mode (a special hardware debugger mode that
the CPU enters which software can't see).

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!