linux-hardening - Re: [PATCH v3 4/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: <202509171251.BA32F4B@keescook>
Date: Wed, 17 Sep 2025 13:01:49 -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>, 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>, gcc-patches@....gnu.org,
	linux-hardening@...r.kernel.org
Subject: Re: [PATCH v3 4/7] aarch64: Add AArch64 Kernel Control Flow
 Integrity implementation

On Sat, Sep 13, 2025 at 04:43:29PM -0700, Andrew Pinski wrote:
> On Sat, Sep 13, 2025 at 4:28 PM 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.
> 
> How does this interact with BTI and sibcalls?

BTI and KCFI are complementary. BTI uses passes to insert insns at entry
points and at call-return sites. Like x86's CET "endbr" stuff, KCFI is
providing finer granularity checking for forward-edge.

Sibcalls are handled normally and there's no change to their
construction beyond the KCFI sequence using jmp instead of call.

> Since for indirect
> calls, x17 is already used for the address.
> Why do you need/want to use a fixed register here for the load/compare
> anyways? Why can't you use any free register?

I spent a bunch of time trying to understand the register allocator,
and the bottom line is that the register allocator won't give me a
scratch register if we hit register pressure because it (correctly) sees
that while it can do a spill, it can't do a reload since the insn is a
"CALL". As such, I have to do register lifetime management internally
to the KCFI insn sequence.

For aarch32, I've done this by using ip (r12) by default, but if it's
used as the target register, I switch to r3, and do a spill/reload only
if r3 is used as a call argument. Since r3 is already in the clobber list
due to the call, the register allocator is already doing a spill/reload
of r3 when it is live.

For aarch64 w16 and w17 are universally on the clobber list (even for
sibcalls), so I'm free to use them internally. But "proving" this to
answer your question led me to find where that clobber is happening,
which means I can drop the redundant clobber I was adding in this patch.

> > +  /* Add KCFI clobbers for indirect calls.  */
> > +  if (kcfi_type_rtx)
> > +    {
> > +      rtx usage = CALL_INSN_FUNCTION_USAGE (call_insn);
> > +      /* Add X16 and X17 clobbers for AArch64 KCFI scratch registers.  */
> > +      clobber_reg (&usage, gen_rtx_REG (DImode, 16));
> > +      clobber_reg (&usage, gen_rtx_REG (DImode, 17));
> > +      CALL_INSN_FUNCTION_USAGE (call_insn) = usage;
> > +    }

i.e. I've dropped the above.

> > +
> >    /* Check whether the call requires a change to PSTATE.SM.  We can't
> >       emit the instructions to change PSTATE.SM yet, since they involve
> >       a change in vector length and a change in instruction set, which
> 
> Also how does this interact with SME calls?

Based on what I've been able to find, there's no conflict: the KCFI
typeid is tied strictly to the function type and doesn't take the SME
attributes into account. So this appears to be fine.

-Kees

-- 
Kees Cook