14 ms·

GCC eBPF for Linux port has landed

167 points by edelsohn 7y ago

haberman 7y ago
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.
- akhilcacharya 7y ago
  eBPF is by nature not Turing complete (user kernel code has to be guaranteed to halt) but WASM doesn't need those restrictions.
  - dsww2 7y ago
    Not true, the instruction set of eBPF itself /is/ Turing complete. Linux is one implementation of it and the verifier currently imposes restrictions in order to not destabilize the kernel (e.g. infinite loops). But that doesn't mean it's not not Turing complete. E.g. in future there could potentially also be a mode that allows to run unverified eBPF programs. Think of it like kernel modules which are also not verified for safety, but can be loaded with the right permissions like CAP_SYS_MODULE. In future I can image a similar mode/option for eBPF as well as long as the user has the right permissions to do so.
- Mic92 7y ago
  eBPF programs are supposed to finish in finite time, which is verified at load time. The kernel also provides some data structures like maps/arrays which are of constant size as I can recall. Hence it is not suitable for general purpose programs unlike WASM.
- kbumsik 7y ago
  They don't have any similarities at all, they have different features and different scopes. For example, you cannot even for-loop in eBPF.
  - haberman 7y ago
    One similarity seems to be the way they both restrict user access to the stack to prevent stack corruption or overflow. The article talks about how eBPF doesn't have an explicit stack pointer and doesn't give a function access to caller or callee stack frames. I have read similar things about how WASM protects its stack, though I don't know much of the details.
    - kbumsik 7y ago
      I mean, their runtime models might share similarities but eBPF is not meant to be a general purpose machine, it is kinda a kernel add-on for programmable tracing.
      - cthalupa 7y ago
        >it is kinda a kernel add-on for programmable tracing. Well, that's the thing I personally mostly use it for via bpftrace and bcc, but that's not the only thing. It's being used for a lot of networking related things too. XDP, CloudFlare uses it for a lot of their DDoS mitigation, etc.
  - strmpnk 7y ago
    There is ongoing to work to allow support for counted looping (including a working patchset that is under review) but in general it's true that an eBPF program does not allow a given segment of code to have multiple entry points (a generalization of the prior rule that jumps may only jump forward in the instruction stream).
  - monocasa 7y ago
    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).
- devwastaken 7y ago
  Wasm is not sandboxed. Wasm is simply another standard way of writing instructions that can be platform independent. Wasm has no standard library software for sandboxing. Sandboxing is entirely dependent upon software implimenting execution of wasm instructions. Very few do this, there are fewer from reputable sources that do it without a JavaScript engine, and none that put sandboxing first.
  - nynx 7y ago
    Wasm is sandboxed. It's designed to be entirely safe to run.
    - saagarjha 7y ago
      Apart from the fact that it can potentially run forever, which can be unacceptable in certain contexts.
      - AgentME 7y ago
        That can be addressed by pre-processing WASM like in https://github.com/ewasm/wasm-metering https://github.com/ewasm/wasm-metering so it aborts if it runs for too many steps.
        devwastaken 7y ago
        Instruction modification is a hack. The proper way is to control as a VM.
    - devwastaken 7y ago
      That's entirely dependent upon the runtime. Wasm is advertised as many things it's not. The only thing it is, is a set of instructions. Here, go through the list. https://github.com/appcypher/awesome-wasm-runtimes https://github.com/appcypher/awesome-wasm-runtimes
      - the_duke 7y ago
- throwaway2048 7y ago
  eBPF is not for general purpose computation, it mostly functions as a sophisticated query language for extracting data, it doesn't even have loops. it is not comparable to WASM.
  - Spivak 7y ago
    eBPF does have loops and it is absolutely for general purpose computation. The verifier that exists in the Linux kernel works very hard to make sure that you are not allowed to load programs with unbounded loops but you most certainly can when those restrictions are lifted.
    - throwaway2048 7y ago
      This is trivial, when people talk about eBPF they are talking about the implementation, its like saying you could put lisp code in C, if only you modified the C compiler.
      - loeg 7y ago
        Why do you think the Linux kernel is the only eBPF implementation?
      - Spivak 7y ago
        The implementation that exists in Linux is perfectly capable of running unbounded loops. But it runs your program through a function that rejects your program if it can't prove that it terminates. The point being that you could rip the eBPF implementation out of the kernel, remove the verify check and have a very usable VM. Here's a implementation that exists because of the GPL: https://github.com/iovisor/ubpf https://github.com/iovisor/ubpf.
nrclark 7y ago
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.
joelthelion 7y ago
What are the applications, besides network filtering?
- cthalupa 7y ago
  XDP and the performance tracing use cases are some of the big ones. https://www.iovisor.org/technology/xdp https://www.iovisor.org/technology/xdp https://github.com/iovisor/bcc https://github.com/iovisor/bcc https://github.com/iovisor/bpftrace https://github.com/iovisor/bpftrace
- nrclark 7y ago
  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.
jblwps 7y ago
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.
- anaphor 7y ago
  Presumably it means you can write your eBPF source code and have it get compiled through GCC (meaning you get all of its optimizations, architecture targets, etc).
  - sigjuice 7y ago
    Isn’t eBPF the architecture target in this case, i.e. gcc will translate C (and/or others?) to eBPF?
    - anaphor 7y ago
      eBPF is its own language as well that is (more or less) a subset of C, is my understanding, so presumably they can apply some of the same optimization / analysis to it as they would C code, right?
- jabl 7y ago
  > 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
sevagh 7y ago
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.

167 points by edelsohn 7y ago

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.

akhilcacharya 7y ago
eBPF is by nature not Turing complete (user kernel code has to be guaranteed to halt) but WASM doesn't need those restrictions.
- dsww2 7y ago
  Not true, the instruction set of eBPF itself /is/ Turing complete. Linux is one implementation of it and the verifier currently imposes restrictions in order to not destabilize the kernel (e.g. infinite loops). But that doesn't mean it's not not Turing complete. E.g. in future there could potentially also be a mode that allows to run unverified eBPF programs. Think of it like kernel modules which are also not verified for safety, but can be loaded with the right permissions like CAP_SYS_MODULE. In future I can image a similar mode/option for eBPF as well as long as the user has the right permissions to do so.
Mic92 7y ago
eBPF programs are supposed to finish in finite time, which is verified at load time. The kernel also provides some data structures like maps/arrays which are of constant size as I can recall. Hence it is not suitable for general purpose programs unlike WASM.
kbumsik 7y ago
They don't have any similarities at all, they have different features and different scopes. For example, you cannot even for-loop in eBPF.
- haberman 7y ago
  One similarity seems to be the way they both restrict user access to the stack to prevent stack corruption or overflow. The article talks about how eBPF doesn't have an explicit stack pointer and doesn't give a function access to caller or callee stack frames. I have read similar things about how WASM protects its stack, though I don't know much of the details.
  - kbumsik 7y ago
    I mean, their runtime models might share similarities but eBPF is not meant to be a general purpose machine, it is kinda a kernel add-on for programmable tracing.
    - cthalupa 7y ago
      >it is kinda a kernel add-on for programmable tracing. Well, that's the thing I personally mostly use it for via bpftrace and bcc, but that's not the only thing. It's being used for a lot of networking related things too. XDP, CloudFlare uses it for a lot of their DDoS mitigation, etc.
- strmpnk 7y ago
  There is ongoing to work to allow support for counted looping (including a working patchset that is under review) but in general it's true that an eBPF program does not allow a given segment of code to have multiple entry points (a generalization of the prior rule that jumps may only jump forward in the instruction stream).
- monocasa 7y ago
  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).
devwastaken 7y ago
Wasm is not sandboxed. Wasm is simply another standard way of writing instructions that can be platform independent. Wasm has no standard library software for sandboxing. Sandboxing is entirely dependent upon software implimenting execution of wasm instructions. Very few do this, there are fewer from reputable sources that do it without a JavaScript engine, and none that put sandboxing first.
- nynx 7y ago
  Wasm is sandboxed. It's designed to be entirely safe to run.
  - saagarjha 7y ago
    Apart from the fact that it can potentially run forever, which can be unacceptable in certain contexts.
    - AgentME 7y ago
      That can be addressed by pre-processing WASM like in https://github.com/ewasm/wasm-metering https://github.com/ewasm/wasm-metering so it aborts if it runs for too many steps.
      - devwastaken 7y ago
        Instruction modification is a hack. The proper way is to control as a VM.
  - devwastaken 7y ago
    That's entirely dependent upon the runtime. Wasm is advertised as many things it's not. The only thing it is, is a set of instructions. Here, go through the list. https://github.com/appcypher/awesome-wasm-runtimes https://github.com/appcypher/awesome-wasm-runtimes
    - the_duke 7y ago
throwaway2048 7y ago
eBPF is not for general purpose computation, it mostly functions as a sophisticated query language for extracting data, it doesn't even have loops. it is not comparable to WASM.
- Spivak 7y ago
  eBPF does have loops and it is absolutely for general purpose computation. The verifier that exists in the Linux kernel works very hard to make sure that you are not allowed to load programs with unbounded loops but you most certainly can when those restrictions are lifted.
  - throwaway2048 7y ago
    This is trivial, when people talk about eBPF they are talking about the implementation, its like saying you could put lisp code in C, if only you modified the C compiler.
    - loeg 7y ago
      Why do you think the Linux kernel is the only eBPF implementation?
    - Spivak 7y ago
      The implementation that exists in Linux is perfectly capable of running unbounded loops. But it runs your program through a function that rejects your program if it can't prove that it terminates. The point being that you could rip the eBPF implementation out of the kernel, remove the verify check and have a very usable VM. Here's a implementation that exists because of the GPL: https://github.com/iovisor/ubpf https://github.com/iovisor/ubpf.

nrclark 7y ago

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.

joelthelion 7y ago

What are the applications, besides network filtering?

cthalupa 7y ago
XDP and the performance tracing use cases are some of the big ones. https://www.iovisor.org/technology/xdp https://www.iovisor.org/technology/xdp https://github.com/iovisor/bcc https://github.com/iovisor/bcc https://github.com/iovisor/bpftrace https://github.com/iovisor/bpftrace
nrclark 7y ago
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.

jblwps 7y ago

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.

anaphor 7y ago
Presumably it means you can write your eBPF source code and have it get compiled through GCC (meaning you get all of its optimizations, architecture targets, etc).
- sigjuice 7y ago
  Isn’t eBPF the architecture target in this case, i.e. gcc will translate C (and/or others?) to eBPF?
  - anaphor 7y ago
    eBPF is its own language as well that is (more or less) a subset of C, is my understanding, so presumably they can apply some of the same optimization / analysis to it as they would C code, right?
jabl 7y ago
> 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

sevagh 7y ago

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.