5 ms·

This may prove useful: > eBPF (often aliased BPF)[2][5] is a technology that can run sandboxed programs in a privileged context such as the operating system ke

This may prove useful: > eBPF (often aliased BPF)[2][5] is a technology that can run sandboxed programs in a privileged context such as the operating system kernel.[6] It is used to safely and efficiently extend the capabilities of the kernel at runtime without requiring to change kernel source code or load kernel modules.[7] Safety is provided through an in-kernel verifier which performs static code analysis and rejects programs which crash, hang or otherwise interfere with the kernel negatively.[8][9] Examples of programs that are automatically rejected are programs without strong exit guarantees (i.e. for/while loops without exit conditions) and programs dereferencing pointers without safety-checks.[10] Loaded programs which passed the verifier are either interpreted or in-kernel JIT compiled for native execution performance. The execution model is event-driven and with few exceptions run-to-completion,[2] meaning, programs can be attached to various hook points in the operating system kernel and are run upon triggering of an event. eBPF use cases include (but are not limited to) networking such as XDP, tracing and security subsystems.[6] Given eBPF's efficiency and flexibility opened up new possibilities to solve production issues, Brendan Gregg famously coined eBPF as "superpowers for Linux".[11] Linus Torvalds expressed that "BPF has actually been really useful, and the real power of it is how it allows people to do specialized code that isn't enabled until asked for".[12] Due to its success in Linux, the eBPF runtime has been ported to other operating systems such as Windows.[4] https://en.wikipedia.org/wiki/EBPF https://en.wikipedia.org/wiki/EBPF

awesomegoat_com 3y ago
Haven't sandboxed programs in a privileged context been the root cause of me seeing BSOD so often in the late 90ties?
- Glemotooo 3y ago
  I'm only aware of drivers, which were not sandboxed due to the nature of drivers (at least in late 90ties there was pobably not much of abstraction on that level, kernel features, hardware features available?)
  - kqr 3y ago
    There was -- Minix was developed in the 90s and ran drivers in user space. But it was (perceived to be?) slow, so mainstream OSes did not do it.
- vilaca 3y ago
  AFAIK the cause of BSOD were, among others, the lack of sandboxing.
- tptacek 3y ago
  This is a different kind of sandbox. BPF functions by drastically limiting the shape of the control flow graph that will be accepted for a program; most working C functions will not be accepted in a BPF program. The simplest example (complexified by more recent BPF verifier work that relaxes this... somewhat) is that BPF programs can't have loops, at least in the sense that a normal program can. You can crash a kernel with a BPF program. But it's overwhelmingly likely that the crash will arise from buggy pre-existing kernel code that just hadn't been seriously exercised before eBPF gave people new tools to push that code with. What's much, much less likely to happen is a segfault or NPE in your own BPF code.
wittjeff 3y ago
A paragraph like this one should be the first thing in the Readme.

awesomegoat_com 3y ago

Haven't sandboxed programs in a privileged context been the root cause of me seeing BSOD so often in the late 90ties?

Glemotooo 3y ago
I'm only aware of drivers, which were not sandboxed due to the nature of drivers (at least in late 90ties there was pobably not much of abstraction on that level, kernel features, hardware features available?)
- kqr 3y ago
  There was -- Minix was developed in the 90s and ran drivers in user space. But it was (perceived to be?) slow, so mainstream OSes did not do it.
vilaca 3y ago
AFAIK the cause of BSOD were, among others, the lack of sandboxing.
tptacek 3y ago
This is a different kind of sandbox. BPF functions by drastically limiting the shape of the control flow graph that will be accepted for a program; most working C functions will not be accepted in a BPF program. The simplest example (complexified by more recent BPF verifier work that relaxes this... somewhat) is that BPF programs can't have loops, at least in the sense that a normal program can. You can crash a kernel with a BPF program. But it's overwhelmingly likely that the crash will arise from buggy pre-existing kernel code that just hadn't been seriously exercised before eBPF gave people new tools to push that code with. What's much, much less likely to happen is a segfault or NPE in your own BPF code.

wittjeff 3y ago

A paragraph like this one should be the first thing in the Readme.