On Wed, Oct 22, 2025 at 12:21 PM Kees Cook <[email protected]> wrote: > > 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?
I cannot comment on other targets; they might still want it. For aarch64, it does not make sense to check x16/x17 being fixed when using KFCI. For aarch64, I suspect the check will be a generic check that is not connected to KFCI for the reasons why I mentioned about. Thanks, Andrew > > -Kees > > -- > Kees Cook
