Clang/LLVM as code generator for uBPF

[Alan-Jowett]

Clang/LLVM as code generator for uBPF

Overview

Clang/LLVM has a much richer tool chain for generating optimal ISA-specific instruction sequences. Proposal is to use LLVM to convert eBPF byte code to optimal native instruction sequences.

Background

Clang/LLVM has a language neutral internal representation (IR). Various front-ends produce IR that is then handed off to back-ends to produce optimal and secure ISA-specific machine code. LLVM code generation is platform aware and can take advantage of advanced processor features like vectored / SIMD instructions (via auto-vectorization) as well as having support for speculative load hardening and other security features.

Proposal

1. Write a Clang/LLVM front-end that translates BPF byte code to LLVM IR.
2. Detect CPU features at runtime and configure LLVM.
3. Use LLVM back-end to generate optimal native instruction sequence.
4. Optionally provide LLVM IR versions of map helper functions (to permit
   inlining of helper functions).

Expected benefits

1. LLVM already supports x86, ARM and ARM64, so uBPF will be able
   to JIT correctly on all these platforms.
2. LLVM can optimize the generated machine code as it has the entire control
   flow graph as IR.
3. LLVM mitigations for branch prediction side-channel attacks will be applied
   to the generated code.
4. As the BPF ISA grows (adding support of atomic instructions etc), the Clang/LLVM gets updated and the uBPF can benefit from it.

Challenges

1. It looks like LLVM doesn't currently support constant blinding (to mitigate JIT spray attacks).
2. Clang/LLVM is fairly large dependency, making it less than ideal for uBPF's goal of being a small light weight jitter/interpreter.

[jpsamaroo]

The simpler version of this: add a function to load native machine code from an object file and execute that. The compiler invocations and Clang/LLVM APIs are far too complicated, flexible, and version dependent to be worth accessing from ubpf; let the user deal with that instead, we only care about the native code anyway.

[rlane]

Agreed with @jpsamaroo, LLVM would be a very heavy dependency. It'd be interesting to see how much performance could be gained from an optimizing compiler vs ubpf's straightforward instruction translation but it would be better as a separate project. If there are portions of ubpf that would be useful for this I wouldn't mind adding new public APIs for them.

[Alan-Jowett]

Thanks, that makes a lot of sense. Can't really say how much gain there would be until we try it though. Folks on the Ebpf-For-Windows project suggested posting it here as it isn't a Windows specific proposal, but a separate project also makes sense.