From: Martin Uecker <uecker@tugraz.at>
To: Kees Cook <kees@kernel.org>, Qing Zhao <qing.zhao@oracle.com>
Cc: Andrew Pinski <pinskia@gmail.com>,
Jakub Jelinek <jakub@redhat.com>,
Richard Biener <rguenther@suse.de>,
Joseph Myers <josmyers@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Ard Biesheuvel <ardb@kernel.org>,
Jeff Law <jeffreyalaw@gmail.com>, Jan Hubicka <hubicka@ucw.cz>,
Richard Earnshaw <richard.earnshaw@arm.com>,
Richard Sandiford <richard.sandiford@arm.com>,
Marcus Shawcroft <marcus.shawcroft@arm.com>,
Kyrylo Tkachov <kyrylo.tkachov@arm.com>,
Kito Cheng <kito.cheng@gmail.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Andrew Waterman <andrew@sifive.com>,
Jim Wilson <jim.wilson.gcc@gmail.com>,
Dan Li <ashimida.1990@gmail.com>,
Sami Tolvanen <samitolvanen@google.com>,
Ramon de C Valle <rcvalle@google.com>,
Joao Moreira <joao@overdrivepizza.com>,
Nathan Chancellor <nathan@kernel.org>,
Bill Wendling <morbo@google.com>,
gcc-patches@gcc.gnu.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH v4 1/7] typeinfo: Introduce KCFI typeinfo mangling API
Date: Mon, 29 Sep 2025 12:34:02 +0200 [thread overview]
Message-ID: <def69866c55cfb9ae3b32cecec0ca667b6fc627d.camel@tugraz.at> (raw)
In-Reply-To: <20250926030252.2387681-1-kees@kernel.org>
Am Donnerstag, dem 25.09.2025 um 20:02 -0700 schrieb Kees Cook:
>
> An important aspect of the C++ typeinfo behavior that is retained here
> is that typedefs are treated as pass-through except when the underlying
> type lacks a tag (i.e. anonymous struct, union, or enum). This provides a
> distinction between those typedefs and typedefs used to provide _aliases_
> (u8, uint16_t).
>
> In the future, an additional "strict mode" builtin helper pair could
> also be added to follow strict ISO C type equivalency instead of the
> existing typeinfo used here, but that is out of scope for this patch.
The ISO C mode would be *less* strict. Or in other words,
the current version would reject valid C programs at run-time.
I try to point out the differences below.
> +
> + /* Test pointer types */
> + TEST_STRING(char*, "Pc");
> + TEST_STRING(int*, "Pi");
> + TEST_STRING(void*, "Pv");
> + TEST_STRING(const char*, "PKc");
> +
> + /* Test array types */
> + TEST_STRING(int[10], "A10_i");
> + TEST_STRING(char[20], "A20_c");
> + TEST_STRING(short[], "A_s");
> +
> + /* Test basic function types */
> + extern void func_void(void);
> + extern void func_char(char x);
> + extern void func_short(short x);
> + extern void func_int(int x);
> + extern void func_long(long x);
> + TEST_STRING(func_void, "FvvE");
> + TEST_STRING(func_char, "FvcE");
> + TEST_STRING(func_short, "FvsE");
> + TEST_STRING(func_int, "FviE");
> + TEST_STRING(func_long, "FvlE");
> +
> + /* Test functions with unsigned types */
> + extern void func_unsigned_char(unsigned char x);
> + extern void func_unsigned_short(unsigned short x);
> + extern void func_unsigned_int(unsigned int x);
> + TEST_STRING(func_unsigned_char, "FvhE");
> + TEST_STRING(func_unsigned_short, "FvtE");
> + TEST_STRING(func_unsigned_int, "FvjE");
> +
> + /* Test functions with signed types */
> + extern void func_signed_char(signed char x);
> + extern void func_signed_short(signed short x);
> + extern void func_signed_int(signed int x);
> + TEST_STRING(func_signed_char, "FvaE");
> + TEST_STRING(func_signed_short, "FvsE");
> + TEST_STRING(func_signed_int, "FviE");
> +
> + /* Test functions with pointer types */
> + extern void func_void_ptr(void *x);
> + extern void func_char_ptr(char *x);
> + extern void func_short_ptr(short *x);
> + extern void func_int_ptr(int *x);
> + extern void func_int_array(int arr[]); /* Decays to "int *". */
> + extern void func_long_ptr(long *x);
> + TEST_STRING(func_void_ptr, "FvPvE");
> + TEST_STRING(func_char_ptr, "FvPcE");
> + TEST_STRING(func_short_ptr, "FvPsE");
> + TEST_STRING(func_int_ptr, "FvPiE");
> + TEST_STRING(func_int_array, "FvPiE");
> + TEST_STRING(func_long_ptr, "FvPlE");
> +
> + /* Test functions with const qualifiers */
> + extern void func_const_void_ptr(const void *x);
> + extern void func_const_char_ptr(const char *x);
> + extern void func_const_short_ptr(const short *x);
> + extern void func_const_int_ptr(const int *x);
> + extern void func_const_long_ptr(const long *x);
> + TEST_STRING(func_const_void_ptr, "FvPKvE");
> + TEST_STRING(func_const_char_ptr, "FvPKcE");
> + TEST_STRING(func_const_short_ptr, "FvPKsE");
> + TEST_STRING(func_const_int_ptr, "FvPKiE");
> + TEST_STRING(func_const_long_ptr, "FvPKlE");
This ok, but there is a proposal to relax the rules for
qualifiers, so in the future preserving all qualifiers
might be too strict for C.
> + /* Test 2D VLA with fixed dimension: should be all the same. */
> + extern void func_vla_2d_first(int n, int arr[n][10]);
> + extern void func_vla_2d_empty(int n, int arr[][10]);
> + extern void func_vla_2d_ptr(int n, int (*arr)[10]);
> + TEST_STRING(func_vla_2d_first, "FviPA10_iE");
> + TEST_STRING(func_vla_2d_empty, "FviPA10_iE");
> + TEST_STRING(func_vla_2d_ptr, "FviPA10_iE");
> +
> + /* Test 2D VLA with both dimensions variable: should be all the same. */
> + extern void func_vla_2d_both(int rows, int cols, int arr[rows][cols]);
> + extern void func_vla_2d_second(int rows, int cols, int arr[][cols]);
> + extern void func_vla_2d_star(int rows, int cols, int arr[*][cols]);
> + TEST_STRING(func_vla_2d_both, "FviiPA_iE");
> + TEST_STRING(func_vla_2d_second, "FviiPA_iE");
> + TEST_STRING(func_vla_2d_star, "FviiPA_iE");
While the top-most decays to a pointer, the deeper arrays are stay but
are compatible between the fixed and variable case. So according to
C rules, they would all need to be canonicalized to the same.
Martin
next prev parent reply other threads:[~2025-09-29 10:42 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-26 3:02 [PATCH v4 0/7] Introduce Kernel Control Flow Integrity ABI [PR107048] Kees Cook
2025-09-26 3:02 ` [PATCH v4 1/7] typeinfo: Introduce KCFI typeinfo mangling API Kees Cook
2025-09-29 10:34 ` Martin Uecker [this message]
2025-09-30 6:21 ` Kees Cook
2025-10-03 19:21 ` Qing Zhao
2025-10-14 23:32 ` Kees Cook
2025-09-26 3:02 ` [PATCH v4 2/7] kcfi: Add core Kernel Control Flow Integrity infrastructure Kees Cook
2025-10-02 14:56 ` Qing Zhao
2025-10-14 23:28 ` Kees Cook
2025-10-15 18:05 ` Qing Zhao
2025-09-26 3:02 ` [PATCH v4 3/7] kcfi: Add regression test suite Kees Cook
2025-09-26 3:02 ` [PATCH v4 4/7] x86: Add x86_64 Kernel Control Flow Integrity implementation Kees Cook
2025-09-26 3:02 ` [PATCH v4 5/7] aarch64: Add AArch64 " Kees Cook
2025-09-26 3:02 ` [PATCH v4 6/7] arm: Add ARM 32-bit " Kees Cook
2025-09-26 4:06 ` Kees Cook
2025-09-29 9:59 ` Ard Biesheuvel
2025-09-30 6:18 ` Kees Cook
2025-09-26 3:02 ` [PATCH v4 7/7] riscv: Add RISC-V " Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=def69866c55cfb9ae3b32cecec0ca667b6fc627d.camel@tugraz.at \
--to=uecker@tugraz.at \
--cc=andrew@sifive.com \
--cc=ardb@kernel.org \
--cc=ashimida.1990@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hubicka@ucw.cz \
--cc=jakub@redhat.com \
--cc=jeffreyalaw@gmail.com \
--cc=jim.wilson.gcc@gmail.com \
--cc=joao@overdrivepizza.com \
--cc=josmyers@redhat.com \
--cc=kees@kernel.org \
--cc=kito.cheng@gmail.com \
--cc=kyrylo.tkachov@arm.com \
--cc=linux-hardening@vger.kernel.org \
--cc=marcus.shawcroft@arm.com \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=palmer@dabbelt.com \
--cc=peterz@infradead.org \
--cc=pinskia@gmail.com \
--cc=qing.zhao@oracle.com \
--cc=rcvalle@google.com \
--cc=rguenther@suse.de \
--cc=richard.earnshaw@arm.com \
--cc=richard.sandiford@arm.com \
--cc=samitolvanen@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).