Date: Sun, 13 Oct 2024 19:49:12 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: "Kevin P. Neal" <kpn@neutralgood.org> Cc: "Gavin D. Howard" <gavin@gavinhoward.com>, freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org, freebsd-net@freebsd.org, tcpdump-workers@lists.tcpdump.org, tech-net@netbsd.org, Alexander Nasonov <alnsn@netbsd.org> Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Message-ID: <20241014024912.B82FD289@slippy.cwsent.com> In-Reply-To: <ZwxzYa3ngC3oeZsZ@neutralgood.org> References: <20240910040544.125245ad@nuclight.lan> <wLzD36W8VSXSlBByVmK745ezszNVGM-hfWOobdrCb1vmx9snihwW_gBgeAlvtKWL55fnAZgr9G5ztIO3UjD3Wou3-YPxmLkMp9AFuGHwXsA=@gavinhoward.com> <ZwxzYa3ngC3oeZsZ@neutralgood.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <ZwxzYa3ngC3oeZsZ@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.Schubert@cschubert.com>
FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org
NTP: <cy@nwtime.org> Web: https://nwtime.org
e^(i*pi)+1=0
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20241014024912.B82FD289>