In message <zwxzya3ngc3oe...@neutralgood.org>, "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.schub...@cschubert.com>
FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org
NTP: <c...@nwtime.org> Web: https://nwtime.org
e^(i*pi)+1=0
