linux-hardening - Re: [RFC PATCH 2/7] mangle: Introduce C typeinfo mangling API

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: <202508211258.8DEE293@keescook>
Date: Thu, 21 Aug 2025 14:29:02 -0700
From: Kees Cook <kees@...nel.org>
To: Qing Zhao <qing.zhao@...cle.com>
Cc: Andrew Pinski <andrew.pinski@....qualcomm.com>,
	"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 2/7] mangle: Introduce C typeinfo mangling API

On Thu, Aug 21, 2025 at 07:14:31PM +0000, Qing Zhao wrote:
> 
> 
> > On Aug 21, 2025, at 12:16, Kees Cook <kees@...nel.org> wrote:
> > 
> > 
> >>> +  else if (TREE_CODE (fntype_or_fndecl) == FUNCTION_DECL)
> >>> +    {
> >>> +      tree fndecl = fntype_or_fndecl;
> >>> +      tree base_fntype = TREE_TYPE (fndecl);
> >>> +
> >>> +      /* For FUNCTION_DECL, build a synthetic function type using
> >>> DECL_ARGUMENTS
> >>> +        if available to preserve typedef information.  */
> >>> 
> >> 
> >> Why do the building? Seems like you could just do that work here. Also
> >> doesn't FUNCTION_DECL's type have exactly what you need?
> > 
> > I need the function prototype in three places:
> > 
> > - address-taken extern functions
> > - function preambles
> > - indirect call sites
> > 
> 
> A little confused with the above:
> 
> From my understanding, 
> 
> 1. At each indirect call sites, we should generate the checking code to 
>      A. load the hashed precomputed typeid from the callee’s preamble 
>      B. compare it with the precomputed typeid for this call site
> 
>     So, we need the function prototype of  the indirect call site to compute the typeid for this call site.

Correct.

> 2. For every “address-taken” function, we should generate the function
>     preamble, in which the precomputed typeid for this function is stored. 
> 
>     So, we need the function prototype of  this function to compute the typeid for this function. 
> 
> The above 2 should cover all the KCFI ABIs. 

For non-static functions, we cannot know if other compilation units may
make indirect calls to a given function, so those functions must always
have their kcfi preamble added. For static functions, if they are
address-taken by the current compilation unit, then they must get a kcfi
preamble added.

> What I was confused is, why “address-taken external function” and “function preambles” are separated items? 
> For the function preambles, shall we generate for all the functions? Or only for address-taken functions in
> the compilation? 

The other case is emitting the __ckfi_typeid_FUNC weak symbols, which is
used for link-time resolution with non-C code (i.e. raw .S assembly)
which doesn't have access to the C type system to calculate the hashes
on its own, and needs to have a way to build its own kcfi preambles. This
is how Linux constructs its assembly function entry points:

#ifndef __CFI_TYPE
#define __CFI_TYPE(name)                                \
        .4byte __kcfi_typeid_##name
#endif

#define SYM_TYPED_ENTRY(name, linkage, align...)        \
        linkage(name) ASM_NL                            \
        align ASM_NL                                    \
        __CFI_TYPE(name) ASM_NL                         \
        name:

That way all the asm functions can be be indirect call targets without
knowing the hash value (which will be filled in at link time).

> > At indirect call sites (during the early GIMPLE pass), I had a
> > FUNCTION_TYPE available that still had the full typedef information,
> > and I could use it fine.
> 
> > For the other two, it's later on and the
> > TREE_TYPE(fndecl)'s FUNCTION_TYPE had lost the typedef information (which
> > I need to be able to examine in cases where the typedef name was needed
> > for the mangling vs looking at the underlying types).
> 
> Then why not also compute the typeid for the function preamble during early GIMPLE phase 
> the same as the indirect call sites when all the typedef information is available? 

I assume I just didn't see how yet. :) I wasn't able to identify nor
store the typeid for function definitions that ultimately end up getting
.s file output. For example, down in ix86_asm_output_function_label(),
I have the decl (but it's way late):

ix86_asm_output_function_label (FILE *out_file, const char *fname,
                                tree decl)

I couldn't figure out how to find these during the GIMPLE pass. Oh,
perhaps I can do this with an IPA pass? That should let me walk all
functions including externs. I'll give it a try...

-- 
Kees Cook