4 ms·

How does eBPF compare to WebAsm? I'm a bit more familiar with the latter (thanks to some great articles) and I know that they use the same general approach of s

How does eBPF compare to WebAsm? I'm a bit more familiar with the latter (thanks to some great articles) and I know that they use the same general approach of safety via linear-time verification and translation to machine code+buffer overflow checks, but I'm curious about the differences.

tptacek 5y ago
BPF has a much more limited execution model (in general, eBPF programs aren't even allowed to loop, though the verifier may allow some loops that it can prove are bounded), but freer access to the underlying machine (by design, your programs are usually handling live kernel memory directly).
- monocasa 5y ago
  In more general terms, the eBPF VM goes out of it's way to not be Turing complete in order to solve it's version of the halting problem. Instruction stream graphs must be able to be translated to a acyclic graph by the verifier.
  - infogulch 5y ago
    Interesting, that makes me wonder if a similar restricted "acyclic control flow" mode could be built into WA; I bet that would be pretty useful.
    - tptacek 5y ago
      It is extremely limiting and makes programming very difficult.
      - infogulch 5y ago
        Yes, clearly. But it could be used in places where you want performance guarantees. Like, a client sends a custom sort function to a server to build responses, wide-open WA would not be appropriate for this but maybe a guaranteed acyclic control flow could work. Etc.
        monocasa 5y ago
        Sort is interesting because it's difficult to make a sort algorithm without unbounded loops. Although I guess a comparison function is probably easier, and leave the sort itself in the trusted computing base.
pjmlp 5y ago
Basically only now the security community is starting to validate the security claims from WebAssembly, while founding there is room for improvement. "Everything Old is New Again: Binary Security of WebAssembly" https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat... I expect more papers to start showing up.
- infogulch 5y ago
  That paper has been discussed on HN a few times ( https://news.ycombinator.com/item?id=26994741 https://news.ycombinator.com/item?id=26994741 ; https://news.ycombinator.com/item?id=24216764 https://news.ycombinator.com/item?id=24216764 ). The conclusion I came to in the comments on those threads is the authors of this paper discuss webasm program correctness ('insecure C is still insecure, whaddyaknow'), but they don't even attempt to break the host barrier (aka the whole point of the spec) so this doesn't really say much about the WebAssembly spec from a host security perspective. I am also interested in new papers that directly discuss webasm host security.
  - pjmlp 5y ago
    It doesn't matter if the host remains untouched, when its behaviour depends on outputs from WASM functions. So you can get upgraded security credentials, while the host remains 100% safe, as a possible attack scenario. Security is only effective as the weakest link.
    - infogulch 5y ago
      WA's goal posts are "protect the host from the program, not the program from itself"; the program is assumed to be malicious in this context. If you want to turn around and eval the output of a potentially malicious program in the context of the host, that's on you. You haven't 'broken' the WA memory barrier and blaming WA is an attempt to move the goal posts. WA adds a specific (hitherto unbroken) security layer; intentionally poking a hole in it and prancing about like you've found something is just crying wolf. Edit to add that I agree that whole-program security is obviously still important when a WA-sandbox is part of the whole program, but WA is not advertised to be a solution to the halting problem, it's still just a tool. Be aware of the capabilities of the tools you use, wishing that your tools are made of magic does not make them more capable than what they were designed for.

tptacek 5y ago

BPF has a much more limited execution model (in general, eBPF programs aren't even allowed to loop, though the verifier may allow some loops that it can prove are bounded), but freer access to the underlying machine (by design, your programs are usually handling live kernel memory directly).

monocasa 5y ago
In more general terms, the eBPF VM goes out of it's way to not be Turing complete in order to solve it's version of the halting problem. Instruction stream graphs must be able to be translated to a acyclic graph by the verifier.
- infogulch 5y ago
  Interesting, that makes me wonder if a similar restricted "acyclic control flow" mode could be built into WA; I bet that would be pretty useful.
  - tptacek 5y ago
    It is extremely limiting and makes programming very difficult.
    - infogulch 5y ago
      Yes, clearly. But it could be used in places where you want performance guarantees. Like, a client sends a custom sort function to a server to build responses, wide-open WA would not be appropriate for this but maybe a guaranteed acyclic control flow could work. Etc.
      - monocasa 5y ago
        Sort is interesting because it's difficult to make a sort algorithm without unbounded loops. Although I guess a comparison function is probably easier, and leave the sort itself in the trusted computing base.

pjmlp 5y ago

Basically only now the security community is starting to validate the security claims from WebAssembly, while founding there is room for improvement. "Everything Old is New Again: Binary Security of WebAssembly" https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat... I expect more papers to start showing up.

infogulch 5y ago
That paper has been discussed on HN a few times ( https://news.ycombinator.com/item?id=26994741 https://news.ycombinator.com/item?id=26994741 ; https://news.ycombinator.com/item?id=24216764 https://news.ycombinator.com/item?id=24216764 ). The conclusion I came to in the comments on those threads is the authors of this paper discuss webasm program correctness ('insecure C is still insecure, whaddyaknow'), but they don't even attempt to break the host barrier (aka the whole point of the spec) so this doesn't really say much about the WebAssembly spec from a host security perspective. I am also interested in new papers that directly discuss webasm host security.
- pjmlp 5y ago
  It doesn't matter if the host remains untouched, when its behaviour depends on outputs from WASM functions. So you can get upgraded security credentials, while the host remains 100% safe, as a possible attack scenario. Security is only effective as the weakest link.
  - infogulch 5y ago
    WA's goal posts are "protect the host from the program, not the program from itself"; the program is assumed to be malicious in this context. If you want to turn around and eval the output of a potentially malicious program in the context of the host, that's on you. You haven't 'broken' the WA memory barrier and blaming WA is an attempt to move the goal posts. WA adds a specific (hitherto unbroken) security layer; intentionally poking a hole in it and prancing about like you've found something is just crying wolf. Edit to add that I agree that whole-program security is obviously still important when a WA-sandbox is part of the whole program, but WA is not advertised to be a solution to the halting problem, it's still just a tool. Be aware of the capabilities of the tools you use, wishing that your tools are made of magic does not make them more capable than what they were designed for.