From: Nathan Chancellor <nathan@kernel.org>
To: Kees Cook <kees@kernel.org>
Cc: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>,
"Linus Walleij" <linusw@kernel.org>,
"Sami Tolvanen" <samitolvanen@google.com>,
"Zhen Lei" <thunder.leizhen@huawei.com>,
"Arnd Bergmann" <arnd@arndb.de>,
"Michał Pecio" <michal.pecio@gmail.com>,
"Sebastian Andrzej Siewior" <bigeasy@linutronix.de>,
linux-arm-kernel@lists.infradead.org,
"Russell King" <linux@armlinux.org.uk>,
"Will Deacon" <will@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"Nick Desaulniers" <ndesaulniers@google.com>,
"Bill Wendling" <morbo@google.com>,
"Justin Stitt" <justinstitt@google.com>,
linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH v3] ARM: traps: Implement KCFI trap handler for ARM32
Date: Mon, 20 Jul 2026 17:11:59 -0700 [thread overview]
Message-ID: <20260721001159.GA3326792@ax162> (raw)
In-Reply-To: <20260715175223.make.153-kees@kernel.org>
On Wed, Jul 15, 2026 at 10:52:27AM -0700, Kees Cook wrote:
> 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/20260618204539.824446-6-kees@kernel.org/ [1]
> Signed-off-by: Kees Cook <kees@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
I tested this in QEMU using LKDTM, which shows lkdtm_increment_int() as
the target of the failed call.
--
Cheers,
Nathan
next prev parent reply other threads:[~2026-07-21 0:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 17:52 [PATCH v3] ARM: traps: Implement KCFI trap handler for ARM32 Kees Cook
2026-07-21 0:11 ` Nathan Chancellor [this message]
2026-07-21 7:54 ` Linus Walleij
2026-07-21 16:15 ` Nick Desaulniers
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=20260721001159.GA3326792@ax162 \
--to=nathan@kernel.org \
--cc=arnd@arndb.de \
--cc=bigeasy@linutronix.de \
--cc=justinstitt@google.com \
--cc=kees@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=llvm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=michal.pecio@gmail.com \
--cc=morbo@google.com \
--cc=ndesaulniers@google.com \
--cc=rmk+kernel@armlinux.org.uk \
--cc=samitolvanen@google.com \
--cc=thunder.leizhen@huawei.com \
--cc=will@kernel.org \
/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.