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.
