From: Kees Cook <kees@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Pinski <pinskia@gmail.com>,
Andrew Pinski <andrew.pinski@oss.qualcomm.com>,
Qing Zhao <qing.zhao@oracle.com>,
GCC Patches <gcc-patches@gcc.gnu.org>,
Joseph Myers <josmyers@redhat.com>,
Richard Biener <rguenther@suse.de>, 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>,
linux-hardening@vger.kernel.org
Subject: Re: [RFC PATCH 3/7] kcfi: Add core Kernel Control Flow Integrity infrastructure
Date: Fri, 22 Aug 2025 01:47:07 -0700 [thread overview]
Message-ID: <202508220139.49831A70FF@keescook> (raw)
In-Reply-To: <20250822082420.GB1386988@noisy.programming.kicks-ass.net>
On Fri, Aug 22, 2025 at 10:24:20AM +0200, Peter Zijlstra wrote:
> On Fri, Aug 22, 2025 at 09:51:15AM +0200, Peter Zijlstra wrote:
> > On Thu, Aug 21, 2025 at 02:22:30AM -0700, Andrew Pinski wrote:
> > > On Thu, Aug 21, 2025, 2:13 AM Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > > On Thu, Aug 21, 2025 at 01:16:56AM -0700, Andrew Pinski wrote:
> > > >
> > > > > > +/* Compute KCFI type ID for a function declaration or function type
> > > > > > (internal) */
> > > > > > +static uint32_t
> > > > > > +compute_kcfi_type_id (tree fntype_or_fndecl)
> > > > > > +{
> > > > > > + if (!fntype_or_fndecl)
> > > > > > + return 0;
> > > > > > +
> > > > > > + const char *canonical_name = mangle_function_type
> > > > (fntype_or_fndecl);
> > > > > > + uint32_t base_type_id = kcfi_hash_string (canonical_name);
> > > > > >
> > > > >
> > > > > Now I am curious why this needs to be a mangled function name? Since the
> > > > > function in C the symbol is just its name.
> > > > > Is there documentation that says the hash needs to be based on all of the
> > > > > function arguments types?
> > > >
> > > > The whole point of kCFI is to limit the targets of indirect calls to
> > > > functions of the same signature. The actual function name is immaterial.
> > > >
> > >
> > >
> > > So then just hash the function argument types. It only needs to be
> > > consistent for the objects that are compiled together right?
> >
> > Function argument and return; but yes that could be done. Ideally the
> > kCFI implementation would be compatible between compilers. Specifically
> > rust is based on llvm and therefore generates kCFI that is compatible
> > with clang. Being able to mix GCC and rust code (as the kernel does)
> > would be nice.
>
> FWIW, Kees, for this to actually work, we need this
> CFI_ICALL_NORMALIZE_INTEGERS thing supported. Rust gets really upset
> about LP64's whole 'long' vs 'long long' trainwreck :/
>
> That is the -fsanitize-cfi-icall-experimental-normalize-integers
> argument for clang (omg so long).
Yup! I forgot to include my "TODO" list in the RFC. It is:
* -fsanitize-cfi-icall-experimental-normalize-integers (but this option
needs a better name if it's going to be supported in GCC too for Rust
compat)
* -fsanitize-kcfi-arity
https://clang.llvm.org/docs/ControlFlowIntegrity.html#fsanitize-kcfi-arity
* cfi_salt function attribute
https://clang.llvm.org/docs/AttributeReference.html#cfi-salt
https://github.com/llvm/llvm-project/commit/aa4805a09052c1b6298718eeb6d30c33dd0d695f
-Kees
--
Kees Cook
next prev parent reply other threads:[~2025-08-22 8:47 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-21 7:26 [RFC PATCH 0/7] Introduce Kernel Control Flow Integrity ABI [PR107048] Kees Cook
2025-08-21 7:26 ` [RFC PATCH 1/7] sanitizer: Expand sanitizer flag from 32-bit to 64-bit Kees Cook
2025-08-21 7:26 ` [RFC PATCH 2/7] mangle: Introduce C typeinfo mangling API Kees Cook
[not found] ` <CALvbMcAPV1eB6nocPAS=qR8SCiQyU43v911R8S7Ah_=G7yK-+g@mail.gmail.com>
2025-08-21 8:29 ` Andrew Pinski
2025-08-21 16:16 ` Kees Cook
2025-08-21 16:24 ` Andrew Pinski
2025-08-21 19:14 ` Qing Zhao
2025-08-21 21:29 ` Kees Cook
2025-08-22 15:11 ` Qing Zhao
2025-08-22 19:02 ` Kees Cook
2025-08-22 20:29 ` Qing Zhao
2025-08-22 22:29 ` Kees Cook
2025-08-25 8:13 ` Peter Zijlstra
2025-08-25 13:56 ` Qing Zhao
2025-08-21 7:26 ` [RFC PATCH 3/7] kcfi: Add core Kernel Control Flow Integrity infrastructure Kees Cook
[not found] ` <CALvbMcA+8iHo+zCCvs4UdAg9PVQVtgOno-rtMS4i5YajrjkyGw@mail.gmail.com>
2025-08-21 9:12 ` Peter Zijlstra
2025-08-21 11:01 ` Richard Biener
2025-08-21 14:25 ` Peter Zijlstra
2025-08-21 18:09 ` Qing Zhao
2025-08-22 5:15 ` Kees Cook
2025-08-22 10:03 ` Peter Zijlstra
2025-08-21 19:57 ` Kees Cook
2025-08-22 6:53 ` Richard Biener
2025-08-22 19:23 ` Kees Cook
[not found] ` <CA+=Sn1koTTQaXDnAVWtVU6ACWwhD08NR5nDJO236Pmcoi2X9qA@mail.gmail.com>
2025-08-22 7:51 ` Peter Zijlstra
2025-08-22 8:24 ` Peter Zijlstra
2025-08-22 8:47 ` Kees Cook [this message]
2025-08-22 5:10 ` Kees Cook
2025-08-22 5:27 ` Andrew Pinski
2025-08-28 14:57 ` Qing Zhao
2025-09-04 4:24 ` Kees Cook
2025-09-04 7:16 ` Peter Zijlstra
2025-09-04 14:41 ` Qing Zhao
2025-08-21 7:26 ` [RFC PATCH 4/7] x86: Add x86_64 Kernel Control Flow Integrity implementation Kees Cook
2025-08-21 9:29 ` Peter Zijlstra
2025-08-21 18:46 ` Kees Cook
2025-08-21 19:03 ` Kees Cook
2025-08-22 8:19 ` Peter Zijlstra
2025-08-22 8:36 ` Kees Cook
2025-08-22 8:55 ` Peter Zijlstra
2025-08-21 7:26 ` [RFC PATCH 5/7] aarch64: Add AArch64 " Kees Cook
2025-08-21 7:26 ` [RFC PATCH 6/7] riscv: Add RISC-V " Kees Cook
2025-08-21 7:26 ` [RFC PATCH 7/7] kcfi: Add regression test suite 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=202508220139.49831A70FF@keescook \
--to=kees@kernel.org \
--cc=andrew.pinski@oss.qualcomm.com \
--cc=andrew@sifive.com \
--cc=ashimida.1990@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hubicka@ucw.cz \
--cc=jim.wilson.gcc@gmail.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=palmer@dabbelt.com \
--cc=peterz@infradead.org \
--cc=pinskia@gmail.com \
--cc=qing.zhao@oracle.com \
--cc=rguenther@suse.de \
--cc=richard.earnshaw@arm.com \
--cc=richard.sandiford@arm.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 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.