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

[David Laight]

On Fri, 26 Jun 2026 16:38:02 +0100
Russell King <linux@xxxxxxxxxxxxxxx> wrote:

> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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@xxxxxxxxxx/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).
> 

I'd probably forgotten a bit in the middle of that.
(Possibly backing up the pc.)
I guess it would need a flag in an elf header/section to set the behaviour
on a per program basis (horrid).

	David