Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Cy Schubert <[email protected]>
| Newsgroups | gmane.os.freebsd.architechture,gmane.os.freebsd.devel.hackers,gmane.os.freebsd.devel.net,gmane.network.tcpdump.devel,gmane.os.netbsd.devel.network |
|---|---|
| Message-ID | <[email protected]> |
In message <[email protected]>, "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 <[email protected]> FreeBSD UNIX: <[email protected]> Web: https://FreeBSD.org NTP: <[email protected]> Web: https://nwtime.org e^(i*pi)+1=0