2 ms·

Unfortunately Unix processes aren't up to snuff, hence we introduced a bunch of dubious add-ons. Recently HN had a post on seL4; microkernels and capabilities w

Unfortunately Unix processes aren't up to snuff, hence we introduced a bunch of dubious add-ons. Recently HN had a post on seL4; microkernels and capabilities were brought up. But of course backwards compatibility is tough...

anon291 2y ago
Right but the course of action should be to add on to them, not invent entirely new stacks.
- deleted 2y ago
  [deleted]
wahern 2y ago
The reason processes aren't enough for isolation is primarily because of the large (and growing) number of syscalls, especially for complicated, bleeding-edge subsystems, exposing significant kernel surface area that's susceptible to exploits when kernel bugs are discovered. The WASM ecosystem is recapitulating this stage of affairs by increasing the surface area with external systems in the same fashion. Unix processes combined with seccomp (or pledge) to reduce exposed kernel surface and landlock (or unveil) to limit filesystem access puts you back at square one. Processes running WASM interpreters should be leveraging those interfaces, anyhow. What really differentiates WASM is the "compile once, run anywhere" portability allure. But we live in an age of open source (in the literal sense). Ecosystems like Go and Rust assume source code availability; binary blobs are the exception. There's not much of a difference between C, Go, or Rust textual source code on the one hand and a WASM binary on the other; both are going to be compiled to native code by the downstream user. When you have the source code available to compile, then standards like POSIX should suffice. But they don't (at least not completely), because people are always chasing newer features that various environments invent to differentiate themselves. I don't see how WASM resolves that fundamental dynamic. Though I don't deny there are marginal benefits, just like there were with the JVM, which in many niches effectively resolved the Unix/Windows portability issue, allowing people to migrate platforms easier as preferences and requirements change.

anon291 2y ago

Right but the course of action should be to add on to them, not invent entirely new stacks.

deleted 2y ago
[deleted]

wahern 2y ago

The reason processes aren't enough for isolation is primarily because of the large (and growing) number of syscalls, especially for complicated, bleeding-edge subsystems, exposing significant kernel surface area that's susceptible to exploits when kernel bugs are discovered. The WASM ecosystem is recapitulating this stage of affairs by increasing the surface area with external systems in the same fashion. Unix processes combined with seccomp (or pledge) to reduce exposed kernel surface and landlock (or unveil) to limit filesystem access puts you back at square one. Processes running WASM interpreters should be leveraging those interfaces, anyhow. What really differentiates WASM is the "compile once, run anywhere" portability allure. But we live in an age of open source (in the literal sense). Ecosystems like Go and Rust assume source code availability; binary blobs are the exception. There's not much of a difference between C, Go, or Rust textual source code on the one hand and a WASM binary on the other; both are going to be compiled to native code by the downstream user. When you have the source code available to compile, then standards like POSIX should suffice. But they don't (at least not completely), because people are always chasing newer features that various environments invent to differentiate themselves. I don't see how WASM resolves that fundamental dynamic. Though I don't deny there are marginal benefits, just like there were with the JVM, which in many niches effectively resolved the Unix/Windows portability issue, allowing people to migrate platforms easier as preferences and requirements change.