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.
