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

[Cy Schubert <Cy.Schubert%cschubert.com@localhost>]

In message <ZwxzYa3ngC3oeZsZ%neutralgood.org@localhost>, "Kevin P. Neal" writes:
> 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.

An interpreter in the kernel. What could possibly go wrong with that?


-- 
Cheers,
Cy Schubert <Cy.Schubert%cschubert.com@localhost>
FreeBSD UNIX:  <cy%FreeBSD.org@localhost>   Web:  https://FreeBSD.org
NTP:           <cy%nwtime.org@localhost>    Web:  https://nwtime.org

			e^(i*pi)+1=0