BPF: A New Type of Software • Hacker News Board

Re: BPF: A New Type of Software

#121

Post by sigjuice » Tue, Dec 03, 2019, 6:29 PM UTC

monocasa wrote: post #94

manyworlds wrote: post #67

Earlier quoted context omitted.

You can maintain production safety by using a BPF->kernel module compiler. This additionally removes the need to have the bpf compiler in the kernel, reducing both core size and vulnerability surface area. No reason BPF must imply JIT

The end goal with bpf is to allow arbitrary untrusted programs to load bpf programs. If you were just loading kernel modules you wouldn't be able to maintain kernel integrity and let arbitrary programs load code.

I can't find the LKML thread, but there is some fundamental problem with unloading modules safely. BPF programs might not have such limitations.

Re: BPF: A New Type of Software

#122

Post by jacquesm » Tue, Dec 03, 2019, 6:30 PM UTC

rhencke wrote: post #74

sho_hn wrote: post #61

Earlier quoted context omitted.

webassembly "runs in kernel space"?

Yes, though it's early days yet. See: https://github.com/wasmerio/kernel-wasm

Please no.

Re: BPF: A New Type of Software

#123

Post by sigstoat » Tue, Dec 03, 2019, 6:35 PM UTC

base0x10 wrote: post #106

sigstoat wrote: post #102

if i like the guarantees that BPF gives the kernel, and want to embed it into my user-space software so that it can execute BPF programs received from other untrusted processes, are there any hints on where to start? the "BPF beginners" material i come across doesn't seem to discuss this use case.

This is currently not easy to do. First of all, the kernel BPF implementation is GPLv2, which means you cannot rip out the runtime and embed it in your userspace code unless you are able to distribute your userspace software as GPLv2 (This is AFAIK and IANAL). For software engineering and license compatibility reasons, you probably want to use a clean implementation of eBPF. Two such implementations exist. uBPF has a…

> First of all, the kernel BPF implementation is GPLv2, which means you cannot rip out the runtime and embed it in your userspace code unless you are able to distribute your userspace software as GPLv2

mmm right, should've thought of that.

> What you are looking for is a really interesting possibility but would require a significant software engineering effort.

thanks for the info, i appreciate it, and it gives me a bit to chew on.

Re: BPF: A New Type of Software

#124

Post by muricula » Tue, Dec 03, 2019, 6:35 PM UTC

meithecatte wrote: post #90

nikanj wrote: post #86

Earlier quoted context omitted.

Bytecode + compiler was also how both Flash and Java Applets worked. Have we forgotten how secure those were?

It's also how wasm works, and in some sense -- JavaScript. Somehow, these introduce much less security problems.

https://github.com/tunz/js-vuln-db

I'm not sure Javascript has fewer security problems at all. Sandboxes help a lot, but not all sandboxes are equally strong and Javascript engines routinely get popped.

Re: BPF: A New Type of Software

#125

Post by ttctciyf » Tue, Dec 03, 2019, 6:37 PM UTC

throwaway894345 wrote: post #116

hackworks wrote: post #79

eBPF can be viewed as a mechanism to safely run user code in kernel since it uses a DSL and a compiler before the byte code is executed in kernel. This opens up doors for running performance critical functionality in kernel without having to bundle it with the kernel or very tightly coupled with the kernel version. Optimizing FUSE is an example: https://extfuse.github.io/ I expect custom security auditing software, r…

According to https://news.ycombinator.com/item?id=18496054 , these programs have to halt? How does this system guarantee that the programs halt? Does this mean eBPF is not Turing complete?

From the accompanying video (17:11)[1] it's not Turing complete "because the verifier rejects unbounded loops and so there is some things that are not possible. We do have bounded loops in BPF now."

1: https://youtu.be/7pmXdG8-7WU?t=1031

Re: BPF: A New Type of Software

#126

Post by SahAssar » Tue, Dec 03, 2019, 6:41 PM UTC

kizer wrote: post #112

I've wondered why operating systems, aside from hypervisors, are overwhelmingly the first abstraction - I know the obvious benefits, or rather necessities (processor sharing, security, file system, etc etc) - but in ultra-specialized perf-critical applications I'd have thought economic pressures would have materialized a greater variety of ad-hoc bare-metal software. I guess we're headed that way w/ the twilight of M…

Isn't that sorta what a unikernel is?

Re: BPF: A New Type of Software

#127

Post by fizwhiz » Tue, Dec 03, 2019, 6:47 PM UTC

leetrout wrote: post #65

HIP_HOP wrote: post #46

Can someone write an ELI5 of BPF, please?

Take a look through https://qmonnet.github.io/whirl-offload/2016/09/01/dive-into...

Good god those linked articles ought to keep anyone busy for months

Re: BPF: A New Type of Software

#128

Post by nwallin » Tue, Dec 03, 2019, 6:49 PM UTC

throwaway894345 wrote: post #116

hackworks wrote: post #79

eBPF can be viewed as a mechanism to safely run user code in kernel since it uses a DSL and a compiler before the byte code is executed in kernel. This opens up doors for running performance critical functionality in kernel without having to bundle it with the kernel or very tightly coupled with the kernel version. Optimizing FUSE is an example: https://extfuse.github.io/ I expect custom security auditing software, r…

According to https://news.ycombinator.com/item?id=18496054 , these programs have to halt? How does this system guarantee that the programs halt? Does this mean eBPF is not Turing complete?

The language itself is Turing complete, but the kernel will refuse to run a program that it cannot prove will halt.

There are three categories of programs; programs you can trivially prove will halt, programs you can trivially prove won't halt, and programs where it's difficult or impossible to prove whether or not will halt. The third category is what we call the halting problem. Only the first category will be run by the kernel.

The nitty gritty is that the only jumps which are allowed to go backwards are the end of a loop with a fixed number of iterations. All other jumps must jump forward.

This sounds like it's really limiting, but in practice there's not a whole lot of useful stuff you're unable to do.

Re: BPF: A New Type of Software

#129

Post by staticassertion » Tue, Dec 03, 2019, 6:55 PM UTC

iainmerrick wrote: post #110

meithecatte wrote: post #90

Earlier quoted context omitted.

It's also how wasm works, and in some sense -- JavaScript. Somehow, these introduce much less security problems.

JavaScript doesn’t give you nearly as much access to host OS features as the JVM does. (And there sometimes are security problems when it does.)

But it's not really interesting to compare js to java, we should be comparing to ebpf.

Re: BPF: A New Type of Software

#130

Post by kasabali » Tue, Dec 03, 2019, 6:55 PM UTC

Aissen wrote: post #58

gregkh said at Kernel Recipes this year that "we have a micro kernel and nobody noticed" while talking about eBPF.

I think he may have said that about "ELF modules" [1] specifically. Because plain BPF code runs in kernel mode and that wouldn't make it a micro kernel. I don't know if elf modules feature has been merged upstream.

1. https://lwn.net/Articles/749108/