3 ms·

> Separate address spaces are definitely needed these days in order to avoid Spectre vulnerabilities That's nonsense! Separate address spaces have nothing to d

by qayxc 7y ago

> Separate address spaces are definitely needed these days in order to avoid Spectre vulnerabilities That's nonsense! Separate address spaces have nothing to do with hardware vulnerabilities. The MMU uses address spaces to isolate processes from each other, which is required for proper multi-tasking. If you don't use process isolation, every task can overwrite the heap and stack of every other running task (including the OS kernel and drivers!). Information disclosure (in this context) is only relevant in virtual environments, where multiple tenants have to be strictly isolated from each other and affects (hardware) VM supervisors. It's a different topic entirely.

zozbot234 7y ago
> If you don't use process isolation, every task can overwrite the heap and stack of every other running task (including the OS kernel and drivers!). This is not a concern if all code is rigorously checked for memory safety which is quite feasible in principle, and possibly already the case for some uses of WASM/WASI. (Native binary code would need to be annotated with low-level proofs, to be checked by the OS.)
- qayxc 7y ago
  Right. That's why no sandbox has ever been broken... So no. WASM relies on process isolation like every other system. It's impossible to automatically check memory safety at compile time as that implies solving the Halting Problem. Runtime checks would need to rely on the compiler enforcing these checks in the RTL. This, however, can easily circumvented using return-oriented programming (remember: you don't want the MMU to protect stack spaces). No amount of software-based sandboxing or compile-time checks can effectively prevent non-isolated processes from accessing and corrupting each other's state. That's exactly why MMU were introduced in the first place. Experiments using Software-Isolated Processes like Microsoft's Singularity [1] rely on complete toolchains from OS kernel to "safe" languages and runtimes and are not suitable for every requirement (e.g. hard real-time becomes near impossible). The SIP concept also just shifts the burden of proving correctness from app and system developers to compiler and toolchain developers and we all know that those guys never make mistakes ;) [1] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/osr2007_rethinkingsoftwarestack.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
  - zozbot234 7y ago
    I agree that current sandboxes and even current compilers/toolchains do not provide these rigorous guarantees, as of yet. WASM/WASI is however quite simple, and could thus be up to the challenge. It's certainly simpler than MS's Singularity approach.
    - qayxc 7y ago
      Singularity just was a PoC, though. I'm not saying it can't be done, it's just not practical for every use case.
  - jfkebwjsbx 7y ago
    > It's impossible to automatically check memory safety at compile time as that implies solving the Halting Problem. For the general case, yeah. And while I agree that I would not remove process isolation, I think they have a point about "almost guaranteed to be safe" languages could be potentially used without isolation (not with zero risk, of course).
josefx 7y ago
> If you don't use process isolation, every task can overwrite the heap and stack of every other running task We have a lot of modern languages that are memory safe at least in theory. However quite a few rely on the OS using these safety features in the background. For example the Java Runtime uses segfaults to catch null pointers instead of actively checking for them, at least as far as I remember.

by qayxc 7y ago

zozbot234 7y ago

> If you don't use process isolation, every task can overwrite the heap and stack of every other running task (including the OS kernel and drivers!). This is not a concern if all code is rigorously checked for memory safety which is quite feasible in principle, and possibly already the case for some uses of WASM/WASI. (Native binary code would need to be annotated with low-level proofs, to be checked by the OS.)

qayxc 7y ago
Right. That's why no sandbox has ever been broken... So no. WASM relies on process isolation like every other system. It's impossible to automatically check memory safety at compile time as that implies solving the Halting Problem. Runtime checks would need to rely on the compiler enforcing these checks in the RTL. This, however, can easily circumvented using return-oriented programming (remember: you don't want the MMU to protect stack spaces). No amount of software-based sandboxing or compile-time checks can effectively prevent non-isolated processes from accessing and corrupting each other's state. That's exactly why MMU were introduced in the first place. Experiments using Software-Isolated Processes like Microsoft's Singularity [1] rely on complete toolchains from OS kernel to "safe" languages and runtimes and are not suitable for every requirement (e.g. hard real-time becomes near impossible). The SIP concept also just shifts the burden of proving correctness from app and system developers to compiler and toolchain developers and we all know that those guys never make mistakes ;) [1] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/osr2007_rethinkingsoftwarestack.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
- zozbot234 7y ago
  I agree that current sandboxes and even current compilers/toolchains do not provide these rigorous guarantees, as of yet. WASM/WASI is however quite simple, and could thus be up to the challenge. It's certainly simpler than MS's Singularity approach.
  - qayxc 7y ago
    Singularity just was a PoC, though. I'm not saying it can't be done, it's just not practical for every use case.
- jfkebwjsbx 7y ago
  > It's impossible to automatically check memory safety at compile time as that implies solving the Halting Problem. For the general case, yeah. And while I agree that I would not remove process isolation, I think they have a point about "almost guaranteed to be safe" languages could be potentially used without isolation (not with zero risk, of course).

josefx 7y ago

> If you don't use process isolation, every task can overwrite the heap and stack of every other running task We have a lot of modern languages that are memory safe at least in theory. However quite a few rely on the OS using these safety features in the background. For example the Java Runtime uses segfaults to catch null pointers instead of actively checking for them, at least as far as I remember.