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 <pet...@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).
