linux-hardening - Re: [PATCH v5 5/7] aarch64: Add AArch64 Kernel Control Flow Integrity implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <202510221216.EA5EBB1@keescook>
Date: Wed, 22 Oct 2025 12:21:43 -0700
From: Kees Cook <kees@...nel.org>
To: Andrew Pinski <andrew.pinski@....qualcomm.com>
Cc: Qing Zhao <qing.zhao@...cle.com>, Andrew Pinski <pinskia@...il.com>,
	Jakub Jelinek <jakub@...hat.com>, Martin Uecker <uecker@...raz.at>,
	Richard Biener <rguenther@...e.de>,
	Joseph Myers <josmyers@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ard Biesheuvel <ardb@...nel.org>, Jeff Law <jeffreyalaw@...il.com>,
	Jan Hubicka <hubicka@....cz>,
	Richard Earnshaw <richard.earnshaw@....com>,
	Richard Sandiford <richard.sandiford@....com>,
	Marcus Shawcroft <marcus.shawcroft@....com>,
	Kyrylo Tkachov <kyrylo.tkachov@....com>,
	Kito Cheng <kito.cheng@...il.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Andrew Waterman <andrew@...ive.com>,
	Jim Wilson <jim.wilson.gcc@...il.com>,
	Dan Li <ashimida.1990@...il.com>,
	Sami Tolvanen <samitolvanen@...gle.com>,
	Ramon de C Valle <rcvalle@...gle.com>,
	Joao Moreira <joao@...rdrivepizza.com>,
	Nathan Chancellor <nathan@...nel.org>,
	Bill Wendling <morbo@...gle.com>,
	"Osterlund, Sebastian" <sebastian.osterlund@...el.com>,
	"Constable, Scott D" <scott.d.constable@...el.com>,
	gcc-patches@....gnu.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH v5 5/7] aarch64: Add AArch64 Kernel Control Flow
 Integrity implementation

On Wed, Oct 22, 2025 at 12:14:32PM -0700, Andrew Pinski wrote:
> On Wed, Oct 22, 2025 at 11:27 AM Kees Cook <kees@...nel.org> 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/dbf9a593-e19d-4f53-96d0-d067868f40b5@gmail.com/

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