Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative

[David Chisnall <theraven%freebsd.org@localhost>]

> On 14 Oct 2024, at 03:49, Cy Schubert <Cy.Schubert%cschubert.com@localhost> wrote:
> 
>>  It
>> can be solved, I think the DirectX LLVM backend ("DXIL") does this, but I
>> still suggest you not do this.

NaCl and SPIR made this mistake first. WebAssembly and SPIR-V learned the lesson.

>> LLVM is huge. Really huge. A codebase that large has no business being in
>> the kernel.

Many years ago, I wrote a proof of concept BPF to LLVM IR compiler. The idea was that a trusted userspace component could do the BPF compilation and load binary code into the kernel. BPF would still be BPF and so have the same guarantees, but compiling it would be faster (on average, each BPF bytecode was slightly more than one x86 instruction after LLVM optimisations had run). LLVM was still in the TCB though, even in userspace. I didn’t peruse it because LLVM is *not* safe in the presence of untrusted inputs.

More generally, the LLVM IR model is similar to C. It allows arbitrary pointer casts and arbitrary pointer arithmetic. It is not a good starting point for anything that you want to analyse for security. LLVM analyses take advantage of undefined behaviour. An in-bounds address calculation instruction is an assertion from the front end that the result will be in bounds. Optimisations are free to rely on this, even when they can’t prove it, because it is undefined behaviour to claim something is in bounds when it is not. The same is true of a lot of other properties on the IR. Many are not computable to recover post facto, they rely on translation from a higher-level language that enforces the properties by construction.

David