[PATCH v3] ARM: breakpoint: CFI breakpoints only on demand
Sami Tolvanen
samitolvanen at google.com
Wed Jul 1 08:30:38 PDT 2026
On Wed, Jul 1, 2026 at 5:50 AM Linus Walleij <linusw at kernel.org> wrote:
>
> On Wed, Jul 1, 2026 at 1:10 PM Russell King <linux at armlinux.org.uk> wrote:
>
> > Have the LLVM compiler people responded to this bug yet? What is their
> > plan with the silly choice of BKPT usage for CFI failure?
>
> Haven't heard anything.
LLVM's generic KCFI pass uses a debug trap as an architecture-agnostic
way to trap on failure. It shouldn't be a problem to switch to
something else now that we have an ARM back-end implementation thanks
to Kees.
> My tentative plan is to follow this up with a patch to LLVM (and I guess
> then later also GCC...) to enable handling CFI faults with a read
> to the guard region at 0xffc00000 instead of using BKPT so we get a
> good old predictable segfault instead. I was thinking something like
>
> -fsanitize-kcfi-guard-region-address=0xffc00000
>
> My idea is that the unwinder can then see that this is caused by KCFI
> and act accordingly, but already the existing stack trace should make
> it pretty obvious what happened.
>
> It's the best I can think of at least, haven't seen any other ideas.
Note that for X86 and RISC-V the compiler emits a list of CFI trap
locations in the .kcfi_traps section (see CONFIG_ARCH_USES_CFI_TRAPS),
which the kernel uses to figure out if an exception was caused by a
CFI failure. I'm not sure if this is useful in your case, but the
plumbing is already in the compiler and could also be enabled in the
ARM implementation if needed.
Sami
More information about the linux-arm-kernel
mailing list