On Tue, Feb 14, 2023 at 2:00 PM Sami Tolvanen <samitolvanen@xxxxxxxxxx> wrote: > > On Tue, Feb 14, 2023 at 7:36 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > > > The other case, which you allude to I think, is control transfer to the > > JIT'ed code which is currently __nocfi annotated. I've only briefly > > thought about how to change this, but basically it would entail the JIT > > emitting the correct prefix bytes and setting the entry point at +16. > > > > Given the JIT will only run after we've selected kCFI/FineIBT it knows > > which form to pick from and can emit the right prefix. Then if we remove > > the __nocfi annotation from the call into JIT'ed code, everything should > > work. > > > > None of this should be exceptionally hard, but I've not had time to > > actually do much about it yet. > > The dispatcher path shouldn't be terribly hard to fix, but when I > looked into this briefly half a year ago and ran BPF self-tests with > CFI enabled, I found a few more places that indirectly call jitted > code (or trampolines) using a different function pointer type: > > https://github.com/ClangBuiltLinux/linux/issues/1727 > > For some of these, determining the correct type didn't look all that > simple, but then again, I'm not super familiar with BPF internals. How is 'kcfi' 32-bit hash computed? Some kind of hash of type id-s? Here we'll be dealing with bpf side callbacks with its own types that are called from the kernel side with its own types. I don't quite see how clang can come up with the same hashing algorithm for both. 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. kcfi is addressing the case when endbr/ibt is not supported by cpu or some other reason? btw even for bpf_tail_call we're using direct call most of the time. Even when bpf progs look like a callback through an indirect call we are using direct call whenever possible.
