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

["Kevin P. Neal" <kpn%neutralgood.org@localhost>]

On Tue, Sep 10, 2024 at 02:41:20PM +0000, Gavin D. Howard wrote:
> But the good thing about this is that FreeBSD could use LLVM IR as the
> BPF64 language, which means any language that compiles to LLVM is a
> possible target.

Please don't do this.

The LLVM IR language is a moving target. IR that works in one version is
not guaranteed to work in prior versions. There is an upgrade step where
it tries to read in older IR, but writing out older IR is a problem. It
can be solved, I think the DirectX LLVM backend ("DXIL") does this, but I
still suggest you not do this.
 
> As for restricting access, I think it would be possible to check the
> instructions in LLVM IR for any unsafe instructions or calls to
> restricted functions.
> 
> The downsides:
> 
> * Someone would need to write an LLVM analyze pass or whatever they're
>   called. Maybe more than one.

Close. "Analysis pass".

> * The kernel would need the ability to compile LLVM IR, making LLVM part
>   of the Ring 0 domain.
> 	* Either that, or someone builds an LLVM-to-bytecode translator.
> 	* But the analysis pass(es) must still live in the kernel.

LLVM is huge. Really huge. A codebase that large has no business being in
the kernel.
-- 
Kevin P. Neal                                http://www.pobox.com/~kpn/
"14. Re-reading No. 13, I realize that it's quite possible I'm losing my
mind. I'm glad that for the most part I'm not aware it's happening."
  -- from "20 things I'm thankful for": Fortune, Nov 29, 2004, page 230