linux-hardening - Re: [RFC PATCH 3/7] kcfi: Add core Kernel Control Flow Integrity infrastructure

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] [day] [month] [year] [list]

Message-ID: <2D8786B0-EB76-456F-B0AE-0FF9D8862C55@oracle.com>
Date: Thu, 4 Sep 2025 14:41:40 +0000
From: Qing Zhao <qing.zhao@...cle.com>
To: Kees Cook <kees@...nel.org>
CC: "gcc-patches@....gnu.org" <gcc-patches@....gnu.org>,
        Joseph Myers
	<josmyers@...hat.com>,
        Richard Biener <rguenther@...e.de>, 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>,
        Peter
 Zijlstra <peterz@...radead.org>,
        Dan Li <ashimida.1990@...il.com>,
        "linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>
Subject: Re: [RFC PATCH 3/7] kcfi: Add core Kernel Control Flow Integrity
 infrastructure



> On Sep 4, 2025, at 00:24, Kees Cook <kees@...nel.org> wrote:
> 
>> At the same time, A wrapper type is created for the original function type, whose typename is 
>> “__kcfi_wrapper_type_id”.
>> 
>> I am confused:
>> 
>> 1. Why the additional wrapper type is needed?  why the original function type + “kcfi_type_id” not enough?
> 
> This was created to keep calls some being combined during optimization.
> e.g.:
> 
> if (func1) {
> func1();
> return;
> }
> if (func2) {
> func2();
> return;
> }
> 
> this was getting constructed as:
> 
> if (func1) {
> ptr = func1;
> do_call:
> call ptr;
> return;
> }
> if (func2) {
> ptr = func2;
> goto do_call;
> }
> 
> The above is normally totally fine because only address "matters", but
> in the CFI world, the typeid is a part of the call. If func1 and
> func2 don't share the same typeid, suddenly the "goto do_call" call path
> will fail because the call (that checks the func1 typeid) will trigger a
> mismatch wne func2 tries to be called through the func1-typeid-call.

If the new “wrapper type” is only used to avoid the above transformation, then 
original function type + kcfi_type_id should be enough to avoid such merging, 
No need to create a new wrapper type with the exactly same information embedded.

Do I still miss anything obvious? 
>> 
>>> 
>>> For indirect call targets:
>>> 
>>> - kcfi_emit_preamble_if_needed() uses function_needs_kcfi_preamble(),
>>> and counter helpers, to emit the preablem, with patchable function
>>> entry NOPs. This gets used both in default_print_patchable_function_entry()
>>> and the per-arch path.
>> 
>> I saw that “kcfi_emit_preamble_if_needed” is called by “default_print_patchable_function_entry”,
>> But I didn’t see where it is called when the function is not patchable?
> 
> These were in the per-arch function label emission, but for v2 I've
> moved them out after refactoring how the patchable function entry
> integration works.
> 
Yeah, I saw them when I read the patches for the backends. -:)
>>> 
>>> - get_function_kcfi_type_id() generates the 32-bit hash value, using
>>> compute_kcfi_type_id() and kcfi_hash_string() to hook to the mangling
>>> API. The hash is FNV-1a right now: it doesn't need secrecy. It could be
>>> replaced with any hash, though the hash will need to be coordinated
>>> with Rust, which implements the KCFI ABI as well.
>> 
>> One question here, the final type_id will be computed by the following 2 steps:
>> 
>> 1. Itanium C++ mangling based on return type + parameter types of the function. 
>> 2. FNV-1a hash on the mangled string
>> 
>> If the hacker knows these, it should be quite easy for them to come up with a
>> matched typeid, is it? 
> 
> The hashes aren't considered secret -- they need to be known/match between
> compilation units, and even across languages (Rust). The KCFI mitigation
> is fundamentally an "exploit surface reduction" measure in the sense
> that it limits an attacker's set of callable functions to only matching
> typeids (instead of all functions or all executable memory). I discuss
> this a big more here:
> https://gcc.gnu.org/pipermail/gcc-patches/2025-August/693059.html

Thanks for the info.

Qing.