On Wed, Oct 22, 2025 at 12:27:53PM -0700, Andrew Pinski wrote: > 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.
Okay, so for aarch64 KCFI, I should drop the -ffixed-reg conflict checking logic? -- Kees Cook
