ARM: traps: Implement KCFI trap handler for ARM32

ARM32 GCC KCFI[1] violations currently show as generic "Oops - undefined instruction" errors, making debugging CFI failures difficult. Add a proper KCFI trap handler similar to the aarch64 implementation to provide clear CFI error messages, including the call target and the expected type.

Clang and GCC trap CFI failures differently on ARM32. Clang lowers its checks to a BKPT, handled via the breakpoint/prefetch-abort path in hw_breakpoint.c, which cannot recover the target or expected type and so must report via report_cfi_failure_noaddr(). GCC instead lowers KCFI checks to a UDF (undefined instruction) whose immediate encodes the registers involved, so the handler can decode it and call the full report_cfi_failure() with the target and expected type.

The GCC ARM32 KCFI implementation uses UDF instructions with a specific encoding pattern:
- UDF instruction format: cccc 0111 1111 imm12 1111 imm4
- 16-bit immediate reconstructed from bits 19-8 and 3-0
- KCFI encoding: 0x8000 | (type_reg_num << 5) | (target_reg_num & 31)
- Bit 15: KCFI trap identifier (0x8000)
- Bits 9-5: Type ID register field (0x1F when unavailable)
- Bits 4-0: Target address register number

When the type register field is 0x1F (the type was spilled rather than kept in a register), the handler walks back up to 6 preceding instructions to recover the 32-bit type ID from the four EOR-immediate instructions the compiler emits, similar to x86 CFI trap reconstruction.

The handler is dispatched directly from do_undefinstr() rather than through register_undef_hook(). A registered hook is only installed once initcalls run, so any KCFI violation that fires earlier in boot would be reported as a generic "undefined instruction"; calling the decoder from the exception handler itself catches failures from the very first instruction. Dispatching directly also lets the handler ignore non-kernel-mode UDFs, preventing a user process from spoofing the KCFI encoding.

Both the UDF handler and the Clang breakpoint handler in hw_breakpoint.c act on the report_cfi_failure*() result identically (oops on a fatal violation, or skip the trapping instruction under CFI permissive mode) so factor that shared tail into arm_cfi_handle_failure(), declared in asm/traps.h.

Link https://inbox.sourceware.org/gcc-patches/[email protected]/ [1]

Signed-off-by Kees Cook <[email protected]>

ARM32 GCC KCFI[1] violations currently show as generic "Oops - undefined instruction" errors, making debugging CFI failures difficult. Add a proper KCFI trap handler similar to the aarch64 implementation to provide clear CFI error messages, including the call target and the expected type.

Clang and GCC trap CFI failures differently on ARM32. Clang lowers its checks to a BKPT, handled via the breakpoint/prefetch-abort path in hw_breakpoint.c, which cannot recover the target or expected type and so must report via report_cfi_failure_noaddr(). GCC instead lowers KCFI checks to a UDF (undefined instruction) whose immediate encodes the registers involved, so the handler can decode it and call the full report_cfi_failure() with the target and expected type.

Quoted 4 lines · Kees Cook

ARM32 GCC KCFI[1] violations currently show as generic "Oops - undefined instruction" errors, making debugging CFI failures difficult. Add a proper KCFI trap handler similar to the aarch64 implementation to provide clear CFI error messages, including the call target and the expected type.

Reviewed-by Linus Walleij <[email protected]>

Quoted 7 lines

Clang and GCC trap CFI failures differently on ARM32. Clang lowers its checks to a BKPT, handled via the breakpoint/prefetch-abort path in hw_breakpoint.c, which cannot recover the target or expected type and so must report via report_cfi_failure_noaddr(). GCC instead lowers KCFI checks to a UDF (undefined instruction) whose immediate encodes the registers involved, so the handler can decode it and call the full report_cfi_failure() with the target and expected type.

Aha, that explains a few things.

The UDF is a better approach for ARM I think (Russell will know best).

As noted from earlier conversation the breakpoint usecase overloading on ARM is a mess, and we would certainly like to avoid it if possible, albeit I have a patch in Russell's patch tracker to paper it over.

Do you think that long term we could switch Clang to do what GCC does?