4 ms·
eBPF itself is indeed ancient. However, the explosion of NIH-ed functionality is not. Most of it happened after the standardization of WASM.
by 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 agoBytecode 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 agoBytecode 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 agoThe 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 agoCode 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).