All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <kees@kernel.org>
To: Martin Uecker <uecker@tugraz.at>
Cc: Qing Zhao <qing.zhao@oracle.com>,
	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 23:21:10 -0700	[thread overview]
Message-ID: <202509292318.D9BC37B@keescook> (raw)
In-Reply-To: <def69866c55cfb9ae3b32cecec0ca667b6fc627d.camel@tugraz.at>

On Mon, Sep 29, 2025 at 12:34:02PM +0200, Martin Uecker wrote:
> 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.

Ah, gotcha.

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

Okay, thanks for the notes! How do you want me to phrase the commit log
for this patch as far as the potential future mode/builtins?

And do you think the existing builtin names are okay? I think "typeinfo"
has a very specific current meaning, so I think the names I have here
are good for this mode.

-- 
Kees Cook

  reply	other threads:[~2025-09-30  6:21 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
2025-09-30  6:21     ` Kees Cook [this message]
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=202509292318.D9BC37B@keescook \
    --to=kees@kernel.org \
    --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=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 \
    --cc=uecker@tugraz.at \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.