
GCC eBPF for Linux port has landed - edelsohn
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01987.html
======
haberman
I'd love to see an eBPF vs. WASM compare/contrast. These seem to be two
emerging technologies for sandboxing code in non-GC-oriented runtimes. Both
have compiler backends now. It would be very informative to see how their
choices are similar and different. I'm also curious if there are differences
in the requirements.

~~~
kbumsik
They don't have any similarities at all, they have different features and
different scopes. For example, you cannot even for-loop in eBPF.

~~~
monocasa
You can, it just won't be validated as the CFG read by the kernel has to be a
DAG. But the compiler has no problems emitting code with arbitrary loops. cBPF
is different; branch offsets are unsigned there.

I'm working on an exokernel built around a eBPF VM that'll let you use loops
in certain circumstances (ie. more or less regular threads that happen to be
in kernel space and are preemptible).

~~~
justicezyx
> You can, it just won't be validated as the CFG read by the kernel has to be
> a DAG.

Are you saying the kernel bpf verifier can be disabled when loading a probe?
AFAIK, there is no such option.

TBH, I cannot understand this statement. I've written a few thousands of lines
of BCC C code as eBPF. Never encounter any reference to actually have loops in
the code.

~~~
comex
No, but you can write your own eBPF VM that doesn’t have the same
restrictions.

~~~
justicezyx
Do you have a link to the document?

I never heard of that one can write a new eBPF VM.

~~~
monocasa
What do you mean? The source is all open, and the bytecode format is well
documented. There's nothing stopping anyone from writing their own with
different semantics.

There's no doc on my work as it's private jerk offy personal project that I
work on when I get tired of jira tasks and process.

Edit: here's an example of one someone did in rust
[https://github.com/qmonnet/rbpf](https://github.com/qmonnet/rbpf)

~~~
justicezyx
I was saying a eBPF vm running inside the kernel.

A userspace VM that do not have the same capability as the kernel one is not
useful when tracing kernel internals.

~~~
monocasa
You can patch your kernel, or write your own vm. BPF is ultimately just a
kernel module under Linux. My vm runs in kernel space just fine as well (but
is built on something that looks more like sel4 rather than Linux on the
inside).

If you provided enough of std, or ported that VM to no_std that rust vm would
work just fine in the kernel too.

~~~
justicezyx
This is an interesting option.

Although in our case, our eBPF runs in external customer's environment, and we
cannot ask them to patch their kernels with our code.

~~~
monocasa
I feel like we're talking on two different levels here.

It's sort of like how Oak was this neat virtual machine for running on a early
90s PDA prototype. Then the writers of that VM realized that they had written
a really general purpose VM, cleaned it up and released the first Java.

This general of a VM (talking about eBPF now) hasn't been a first class
citizen of a mainstream kernel before. The devs are taking a very cautious
approach (as they should), but ultimately eBPF is way bigger than a tracing
tool. I wouldn't be surprised to see nearly everything you currently do with a
kernel module ultimately being allowed by eBPF too. Maybe more like emulating
other OS's kernels as easily as you'd start another container.

~~~
justicezyx
Also different time scale.

I am on existing stuff can be readily used. You are probably estimating the
future, I guess?

------
jblwps
Not-a-kernel-dev here. Is my understanding correct, that this is a GCC port
that can _target_ eBPF? If so, is there any particular purpose in that, beyond
making eBPF an easier place for people to write userspace software that would
otherwise be kernel modules?

Pretty wild and cool stuff, seems like.

~~~
jabl
> Is my understanding correct, that this is a GCC port that can target eBPF?

Yes. Though before a LLVM based eBPF target was available, so this adds the
option to use GCC instead. So in principle you could use GFortran to write
kernel code; ... profit!

> If so, is there any particular purpose in that, beyond making eBPF an easier
> place for people to write userspace software that would otherwise be kernel
> modules?

eBPF is an in-kernel virtual machine, with JIT for popular architectures like
x86-64 (maybe arm64 and ppc64le too, not sure?). So you use GCC (or LLVM) to
compile code into an eBPF compatible object format, load it into the kernel
(with a special syscall IIRC, or maybe it was something netlink-based?), then
an in-kernel verifier checks that it doesn't do anything that isn't allowed
before it's enabled.

So what can you do with it. Quite a lot, it seems ( _disclaimer_ I haven't
used it personally). The big use cases at the moment seem to be

\- network filtering

\- seccomp filtering (that is, check syscall arguments)

\- tracing (see bcc/bpftrace) for performance analysis

~~~
simcop2387
> \- seccomp filtering (that is, check syscall arguments)

Small correction there, seccomp still uses BPF not eBPF. That leaves a lot of
restrictions on what it can do and I believe the bytecode is incompatible too.

------
nrclark
This is very exciting! Nice work to the team that's doing this.

I've been waiting to dive into eBPF until the tools mature a bit, so it's
great to see eBPF support landing in GCC.

------
sevagh
Good timing on having recently began working with BPF + XDP. Here's my
project: [https://github.com/sevagh/ape](https://github.com/sevagh/ape), for
those curious about what itches XDP can scratch.

------
joelthelion
What are the applications, besides network filtering?

~~~
nrclark
If your kernel is configured for it, you can use BPF to write pretty advanced
seccomp filters for process sandboxing. One example could be something like:
"restrict open() to only work on files in a given directory, for this process
and all child processes", "only allow two write() calls ever", "disable all
filesystem access after the first network packet gets received", or basically
any arbitrary thing you want to do for syscall control.

