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: <202510221253.D6B51F950@keescook>
Date: Wed, 22 Oct 2025 13:05: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>,
	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:33:18PM -0700, Andrew Pinski wrote:
> On Wed, Oct 22, 2025 at 11:27 AM Kees Cook <kees@...nel.org> wrote:
> [...]
> > @@ -11847,6 +11848,16 @@ aarch64_expand_call (rtx result, rtx mem, rtx cookie, bool sibcall)
> >
> >    call = gen_rtx_CALL (VOIDmode, mem, const0_rtx);
> >
> > +  /* Only indirect calls need KCFI instrumentation.  */
> > +  bool is_direct_call = SYMBOL_REF_P (XEXP (mem, 0));
> > +  rtx kcfi_type_rtx = is_direct_call ? NULL_RTX
> > +    : kcfi_get_type_id_for_expanding_gimple_call ();
> 
> I don't like kcfi_get_type_id_for_expanding_gimple_call call.
> Does it make better sense to create a few new optabs for the kfci call
> instead and pass this down instead of having this call?

Unless I'm misunderstanding how optabs work, I don't want to use
that here. To use an optab, I think I'd need to create a separate
"define_expand" RTL pattern for kcfi calls. I found this to be infeasible
(I tried it somewhere back in around v2), as the calling conventions
for most architectures are extraordinarily complex, and I'd have to
duplicate all of that logic for kcfi expansion. Instead, I have KCFI
just happen in late expansion, which seems the best fit.

Just so I can understand better, why don't you like it? I assume it's
the fact that we're basically in RTL and that function ends up reaching
back up to GIMPLE? This seemed like a layering violation to me too, but
I noticed that it's not uncommon for expansion code to use
currently_expanding_gimple_stmt, so as a result it didn't end up seeming
unreasonable to also use it for KCFI (it is, as it turns out, exactly
what's needed at that moment in the expansion: "give me the kcfi
typeid").

Obviously, I could be missing something here, so if you see a way to do
this better, I am happy to do so. :)

-Kees

-- 
Kees Cook