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: <B838DBF8-DE0B-4CD5-A852-0CB9E188E1A6@oracle.com>
Date: Mon, 25 Aug 2025 13:56:37 +0000
From: Qing Zhao <qing.zhao@...cle.com>
To: Peter Zijlstra <peterz@...radead.org>, 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>,
        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 25, 2025, at 04:13, Peter Zijlstra <peterz@...radead.org> wrote:
> 
> On Fri, Aug 22, 2025 at 03:29:11PM -0700, Kees Cook wrote:
>> On Fri, Aug 22, 2025 at 08:29:16PM +0000, Qing Zhao wrote:
>>>> On Aug 22, 2025, at 15:02, Kees Cook <kees@...nel.org> wrote:
>>>> Right, and sometimes we have to explicitly perform a no-op
>>>> address-taking to make sure a symbol gets generated:
>>>> 
>>>> /*
>>>> * Force the compiler to emit 'sym' as a symbol, so that we can reference
>>>> * it from inline assembler. Necessary in case 'sym' could be inlined
>>>> * otherwise, or eliminated entirely due to lack of references that are
>>>> * visible to the compiler.
>>>> */
>>>> #define ___ADDRESSABLE(sym, __attrs)                                            \
>>>>       static void * __used __attrs                                            \
>>>>       __UNIQUE_ID(__PASTE(__addressable_,sym)) = (void *)(uintptr_t)&sym;
>>>> 
>>>> #define __ADDRESSABLE(sym) \
>>>>       ___ADDRESSABLE(sym, __section(".discard.addressable"))
>>>> 
>>>> $ git grep KCFI_REFERENCE
>>>> include/linux/compiler.h:#define KCFI_REFERENCE(sym) __ADDRESSABLE(sym)
>>>> arch/x86/include/asm/page_64.h:KCFI_REFERENCE(copy_page);
>>>> arch/x86/include/asm/string_64.h:KCFI_REFERENCE(__memset);
>>>> arch/x86/include/asm/string_64.h:KCFI_REFERENCE(__memmove);
>>>> arch/x86/kernel/alternative.c:KCFI_REFERENCE(__bpf_prog_runX);
>>>> arch/x86/kernel/alternative.c:KCFI_REFERENCE(__bpf_callback_fn);
>>> 
>>> I am curious on why the compiler eliminates an external routine completely in the file if it's address-taken in that file. 
>>> Why an additional no-op address-taken is needed here. 
>> 
>> If I am remembering correctly this is needed for rare cases where
>> a function built without a C definition is being used in Linux's
>> self-patching "alternatives" code swaps in one function for another,
>> and is being used indirectly. These cases end up not being visible to
>> compiler (so no address-taken), but the indirect call site is still
>> being instrumented. And the above list is the _entire_ list of such
>> corner cases: all really low-level things.
>> 
>> Peter may remember this better than me...
> 
> The above are all functions from assembly and JITs, the C compiler
> simply never sees the function definition, only the declaration. The
> above is used to force emit the __typeid symbol, such that assembly can
> reference it and it all links correctly.

Okay, I see. Thanks for the information.

Qing