On Wed, Oct 22, 2025 at 12:14:32PM -0700, Andrew Pinski wrote: > On Wed, Oct 22, 2025 at 11:27 AM 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. > > > > - Incompatible with -ffixed-x16 or -ffixed-x17. > > Can you explain why? > The documentation for `-ffixed-` says this: > ``` > -ffixed-reg > Treat the register named reg as a fixed register; generated code > should never refer to it (except perhaps as a stack pointer, frame > pointer or in some other fixed role). > ``` > In this case it is a `in some other fixed role`. Or is the problem you > are using the allocator to figure out which is free? > In the case of indirect tail calls, x17/x16 is always used for the > pointer (since r9-5291-g901e66e03e1cd8). > Which is the register class TAILCALL_ADDR_REGS. > I think it is compatible with doing -ffixed-x17 (or -ffixed-x16) > because it is a "fixed role" at this point. > Though If both are supplied GCC will fall over anyways (will file a > bug about that in a few minutes).
This was done based on feedback from the riscv patch in v2: https://lore.kernel.org/linux-hardening/[email protected]/ Jeff's interpretation of -ffixed-reg seemed to imply "GCC should not touch this register", which seemed sensible to me from the perspective of the "generated code should never refer to it" bit. How that interacts with the "except perhaps as ... some other fixed role" is totally unclear to me. Shall I drop all of the -ffixed-reg logic for all backends? -Kees -- Kees Cook
