On Sat, Jun 27, 2026 at 04:00:04PM -0700, Andrea Pinski wrote:
> On Thu, Jun 18, 2026 at 1:45 PM Kees Cook <[email protected]> wrote:
> >
> > Implement AArch64-specific KCFI backend.
> >
> > - Trap debugging through ESR (Exception Syndrome Register) encoding
> >   in BRK instruction immediate values.
> >
> > - Scratch register allocation using w16/w17 (x16/x17) following
> >   AArch64 procedure call standard for intra-procedure-call registers,
> >   which already makes x16/x17 available through existing clobbers.
> >
> >   Note that BTI uses x16/x17 AT the call site, and KCFI uses w16/w17
> >   BEFORE the call (for the type hash comparison). These don't conflict
> >   because:
> >   - KCFI clobbers w16/w17 with hash values.
> >   - Then the actual call happens via blr %target_reg (whatever
> >     register the target is in).
> >   - If SLS hardening is enabled, aarch64_indirect_call_asm will
> >     create a thunk that moves target into x16 and does br x16.
> >   - By the time the SLS thunk uses x16, KCFI is already done with it.
> >
> > - Complementary with BTI (which uses a separate pass system to inject
> >   landing instructions where needed).
> >
> > - Does not interfere with SME, which uses attributes not function
> >   prototypes for distinguishing functions.
> >
> > Assembly Code Pattern for AArch64:
> >   ldur w16, [target, #-4]       ; Load actual type ID from preamble
> >   mov  w17, #type_id_low        ; Load expected type (lower 16 bits)
> >   movk w17, #type_id_high, lsl #16  ; Load upper 16 bits if needed
> >   cmp  w16, w17                 ; Compare type IDs directly
> >   b.eq .Lpass                   ; Branch if types match
> >   .Ltrap: brk #esr_value        ; Enhanced trap with register info
> >   .Lpass: blr/br target         ; Execute validated indirect transfer
> >
> > ESR (Exception Syndrome Register) Integration:
> > - BRK instruction immediate encoding format:
> >   0x8000 | ((TypeIndex & 31) << 5) | (AddrIndex & 31)
> >   - TypeIndex indicates which W register contains expected type (W17 = 17)
> >   - AddrIndex indicates which X register contains target address (0-30)
> >   - Example: brk #33313 (0x8221) = expected type in W17, target address in 
> > X1
> >
> > Build and run tested with Linux kernel ARCH=arm64.
> >
> > gcc/ChangeLog:
> >
> >         config/aarch64/aarch64-protos.h: Declare 
> > aarch64_indirect_branch_asm,
> >         and KCFI helpers.
> >         config/aarch64/aarch64.cc (aarch64_expand_call): Wrap CALLs in
> >         KCFI, with clobbers.
> >         (aarch64_indirect_branch_asm): New function, extract common
> >         logic for branch asm, like existing call asm helper.
> >         (aarch64_output_kcfi_insn): Emit KCFI assembly.
> >         config/aarch64/aarch64.md: Add KCFI RTL patterns and replace
> >         open-coded branch emission with aarch64_indirect_branch_asm.
> >         doc/invoke.texi: Document aarch64 nuances.
> >
> > gcc/testsuite/ChangeLog:
> >
> >         * gcc.dg/kcfi/kcfi-adjacency.c: Add aarch64 patterns.
> >         * gcc.dg/kcfi/kcfi-basics.c: Add aarch64 patterns.
> >         * gcc.dg/kcfi/kcfi-call-sharing.c: Add aarch64 patterns.
> >         * gcc.dg/kcfi/kcfi-complex-addressing.c: Add aarch64 patterns.
> >         * gcc.dg/kcfi/kcfi-direct-call-shapes.c: Add aarch64 patterns.
> >         * gcc.dg/kcfi/kcfi-move-preservation.c: Add aarch64 patterns.
> >         * gcc.dg/kcfi/kcfi-no-sanitize-inline.c: Add aarch64 patterns.
> >         * gcc.dg/kcfi/kcfi-no-sanitize.c: Add aarch64 patterns.
> >         * gcc.dg/kcfi/kcfi-offset-validation.c: Add aarch64 patterns.
> >         * gcc.dg/kcfi/kcfi-patchable-entry-only.c: Add aarch64 patterns.
> >         * gcc.dg/kcfi/kcfi-patchable-large.c: Add aarch64 patterns.
> >         * gcc.dg/kcfi/kcfi-patchable-medium.c: Add aarch64 patterns.
> >         * gcc.dg/kcfi/kcfi-patchable-prefix-only.c: Add aarch64 patterns.
> >         * gcc.dg/kcfi/kcfi-tail-calls.c: Add aarch64 patterns.
> >         * gcc.dg/kcfi/kcfi-trap-section.c: Add aarch64 patterns.
> >         * gcc.dg/kcfi/kcfi-trap-encoding.c: New test.
> 
> Ok once all other prerequisites have been approved.

Great; thank you for all the review!

-- 
Kees Cook

Reply via email to