Re: [PATCH v5 bpf-next 3/9] bpf: Add bpf_rbtree_{add,remove,first} kfuncs

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Feb 14, 2023 at 03:59:57PM -0800, Alexei Starovoitov wrote:
> How is 'kcfi' 32-bit hash computed?
> Some kind of hash of type id-s?

Yes. Specifically I think a hash of the C++ name mangled function
signature. (which is giving pain with eg. Rust because then the C++
mangling isn't specific enough or somesuch, I'm sure Sami can easily
find it if you want to know more)

> Here we'll be dealing with bpf side callbacks with its own types
> that are called from the kernel side with its own types.

As long as there's a kernel side function declaration (definition not
required) the compiler will generate you a usable __kcfi_typeid_##name
symbol that contains the hash.

If it is a pure BPF internal (C never sees either the declaration of
definition) then it doesn't matter and you can make up your own scheme
as long as caller and callee agree on the magic number.

> Also what to do with the situation when kernel is compiled with GCC
> while bpf progs are with clang? and the other way around ?
> gcc-bpf can compile all of selftests/bpf, but not yet run them.

As of yet GCC doesn't support kCFI, so mixing is not possible at
present. kCFI fundamentally changes the C ABI in incompatible ways.

Ideally the GCC implementation of kCFI (when it happens) will use the
same hashing scheme as LLVM so that mutual compatibility is possible.

> kcfi is addressing the case when endbr/ibt is not supported by cpu
> or some other reason?

kCFI/FineIBT are supplementary to regular IBT. kCFI works regardless of
hardware support, but the same infrastructure is employed with FineIBT
to provide more fine-gained target control.

Specifically, with bare IBT all that is required is the indirect target
be an ENDBR instruction, *any* ENDBR instruction.

The kCFI/FineIBT improvement over that is that caller and callee need to
agree on the hash, thereby further limiting which functions can be
called.