Comment by pjmlp

Comment by pjmlp 2 days ago

WASI is basically CORBA, and DCOM, PDO for newer generations.

Or if you prefer the bytecode based evolution of them, RMI and .NET Remoting.

I don't see it going that far.

The WebAssembly development experience on the browser mostly still sucks, especially the debugging part, and on the server it is another yet another bytecode.

Finally, there is hardly any benefit over OS processes, talking over JSON-RPC (aka how REST gets mostly used), GraphQL, gRPC, or plain traditional OS IPC.

jart a day ago

You've named half of the weasel security technologies of the last three decades. The nice thing about SECCOMP BPF is it's so difficult to use that you get the comfort of knowing that only a very enlightened person could have written your security policy. Hell is being subjected to restrictions defined by people with less imagination than you.

Reply View 0 replies

IshKebab 2 days ago

> hardly any benefit over OS processes, talking over JSON-RPC

Hardly any benefit except portability and sandboxing, the main reasons WASM exists?

Reply View 6 replies

kllrnohj 2 days ago

WASM sacrifices guest security & performance in order to provide mediocre host sandboxing, though. It might be a useful tradeoff sometimes, but proper process-based sandboxing is so much stronger and lets the guest also have full security & performance.

Reply View | 3 replies
- IshKebab 2 days ago
  
  How is process-based sandboxing stronger? Also the performance penalty is not only due to sandboxing (I doubt it's even mostly due to it). Likely more significant is the portability.
  
  Reply View | 2 replies
  
  jacquesm 2 days ago
  
  > How is process-based sandboxing stronger?
  Because the guarantees themselves are stronger, process isolation is something we have decades of experience with, it goes wrong every now and then but those are rare instances whereas what amounts to application level isolation is much weaker in terms the guarantees it that it provides and the maturity level of the code. That suggests that if you base your isolation scheme on processes rather than 'just' sandboxing that you will come out ahead and even with all other things the same you'd have one more layer in your stack of swiss cheese slices. A VM would offer another layer of protection on top of that, one with yet stronger guarantees.
  
  Reply View | 0 replies
  
  kllrnohj 19 hours ago
  
  process-based sandboxing has hardware support and thus stronger defenses against things like spectre. So far every CPU on the market has only elected to address spectre as it relates to crossing ring or process boundaries. Nobody has added hardware spectre defenses for in-process sandboxing. Also, process-based sandboxing allows the guest to also have a full suite of security protections like ASLR. If you are doing sandboxing for defense in depth, reducing the security of what's inside the guest in turn reduces the security of your entire chain.
  And I didn't say the performance penalty was because of sandboxing (although in the case of WASM there is cost as it's doing software enforcement of things that otherwise are "for free" in hardware), but just that WASM has a performance cost compared to native. If you are using WASM just for sandboxing, you still then pay a performance cost for portability you didn't need.
  
  Reply View | 0 replies
pjmlp 2 days ago

WASM is only portable if the only thing it does is heating up CPU, given that everything else depends on the host.

Reply View | 1 reply
- IshKebab 2 days ago
  
  No because the host can present the same interface on every platform. I do think that WASI is waaay to much "let's just copy POSIX and screw other platforms", but it does work pretty well even on Windows.
  
  Reply View | 0 replies