4 ms·

"eBPF Documentary: An exciting train wreck in progress" That would be a better title. eBPF started as a small extension to just be able to insert small trivial

"eBPF Documentary: An exciting train wreck in progress" That would be a better title. eBPF started as a small extension to just be able to insert small trivial hooks. It's now basically a hacked-up broken WebAssembly clone, with zero forethought put into it. NIH syndrome at its worst. It has recently grown unlimited loops with runtime metering, making the static verifier basically a worthless complexity. Before that, it had acquired exceptions and stack unwinding.

akira2501 3y ago
Architecture independent eBPF "rescue binaries" could be an interesting part of a distribution toolset.. or attack rootkit. It's hard to have nice things.
pjmlp 3y ago
While I agree its design isn't the best, versus something like Solaris DTrace, it predates WebAssembly, so hardly a clone.
- cyberax 3y ago
  eBPF itself is indeed ancient. However, the explosion of NIH-ed functionality is not. Most of it happened after the standardization of WASM.
  - pjmlp 3y ago
    Bytecode based execution goes back to the 1960's, yet another thing that WebAssembly advocates tend to forget when writing comments and blog posts about its greatness.
    - cyberax 3y ago
      Bytecode interpreters/JITs are indeed ancient. However, JITs designed to safely confine malicious bytecode are most definitely not. Java or .NET VMs are probably the earliest examples, and the WASM infrastructure is using experience gained there. My problem with eBPF is that it just ignored all of it, and proceeded to feature-creep an initially "simple" solution into a monster. The initial justification for the NIH stuff was: "but we need those static guarantees provided by the verifier, nothing else can do that". But of course, these justifications were forgotten as soon as the verifier became the limiting factor.
      - pjmlp 3y ago
        The lessons being learnt are more on the marketing side, there are already some USENIX papers about how secure WebAssembly actually is in practice, as it slowly becomes an interesting target. And by the way, Chrome recently had a CVE related to WASM, because as usual there are the paper definitions in theory, and then the actual runtimes. https://issues.chromium.org/issues/40067050 https://issues.chromium.org/issues/40067050
        cyberax 3y ago
        Code has bugs. News at 11. eBPF has had multiple CVEs. E.g.: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3489 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3489 or maybe https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0500 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0500 (there are about 20 CVE entries for eBPF).
misiek08 3y ago
Also in article we can read "like putting JavaScript into the Linux kernel" :rotfl:
deleted 3y ago
[deleted]
imetatroll 3y ago
It seems that reasonable changes - well vetted ones - seldom happen. What to do? It is a pretty common pattern now that if you allow someone to take on a "task" without guardrails it just explodes into nonsensical feature creep.

akira2501 3y ago

Architecture independent eBPF "rescue binaries" could be an interesting part of a distribution toolset.. or attack rootkit. It's hard to have nice things.

pjmlp 3y ago

While I agree its design isn't the best, versus something like Solaris DTrace, it predates WebAssembly, so hardly a clone.

cyberax 3y ago
eBPF itself is indeed ancient. However, the explosion of NIH-ed functionality is not. Most of it happened after the standardization of WASM.
- pjmlp 3y ago
  Bytecode based execution goes back to the 1960's, yet another thing that WebAssembly advocates tend to forget when writing comments and blog posts about its greatness.
  - cyberax 3y ago
    Bytecode interpreters/JITs are indeed ancient. However, JITs designed to safely confine malicious bytecode are most definitely not. Java or .NET VMs are probably the earliest examples, and the WASM infrastructure is using experience gained there. My problem with eBPF is that it just ignored all of it, and proceeded to feature-creep an initially "simple" solution into a monster. The initial justification for the NIH stuff was: "but we need those static guarantees provided by the verifier, nothing else can do that". But of course, these justifications were forgotten as soon as the verifier became the limiting factor.
    - pjmlp 3y ago
      The lessons being learnt are more on the marketing side, there are already some USENIX papers about how secure WebAssembly actually is in practice, as it slowly becomes an interesting target. And by the way, Chrome recently had a CVE related to WASM, because as usual there are the paper definitions in theory, and then the actual runtimes. https://issues.chromium.org/issues/40067050 https://issues.chromium.org/issues/40067050
      - cyberax 3y ago
        Code has bugs. News at 11. eBPF has had multiple CVEs. E.g.: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3489 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3489 or maybe https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0500 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0500 (there are about 20 CVE entries for eBPF).

misiek08 3y ago

Also in article we can read "like putting JavaScript into the Linux kernel" :rotfl:

deleted 3y ago

[deleted]

imetatroll 3y ago

It seems that reasonable changes - well vetted ones - seldom happen. What to do? It is a pretty common pattern now that if you allow someone to take on a "task" without guardrails it just explodes into nonsensical feature creep.