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 for Android: free password hash cracker in your pocket

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

Message-ID: <E69330D6-1302-4BA1-BADD-8C91A096A1FD@oracle.com>
Date: Thu, 21 Aug 2025 19:14:31 +0000
From: Qing Zhao <qing.zhao@...cle.com>
To: Kees Cook <kees@...nel.org>
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 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.

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. 

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? 

> 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? 

Qing
> 
>>> +      tree parm = DECL_ARGUMENTS (fndecl);