12 ms·

Spectre came along and ruined the awesome conclusion of that talk. The idea was that the cost of using WASM would be entirely offset by the speedup of removing

Spectre came along and ruined the awesome conclusion of that talk. The idea was that the cost of using WASM would be entirely offset by the speedup of removing the cost of hardware memory protection. We could do that if everything ran in one big VM because the VM would enforce the memory protection. Unfortunately, now we can't rely on a VM for memory protection anymore. We have to assume that any code running in the same address space can access any memory in the same address space. So we need the hardware memory protection after all. You can say goodbye to your WASM-only future.

colordrops 7y ago
I assume that new chips will address this vulnerability, correct? Couldn't the VM detect whether the hardware is secure and decide whether to use hardware memory protection or not?
- tntn 7y ago
  > new chips will address [these vulnerabilities] It doesn't seem likely. The chipmakers will fix the vulnerabilities that break isolation between processes and between user-kernel, but the within-process issues will probably stick around.
- Negitivefrags 7y ago
  At this point it seems practically impossible to deal with completely. V8 at least have given up on the concept of trying to protect memory within the same address space. https://v8.dev/blog/spectre https://v8.dev/blog/spectre
xena 7y ago
This is part of why I want to make a custom OS where each WebAssembly process can be in its own hardware protected memory space. I'm looking at building on top of seL4.
0815test 7y ago
Well, Spectre is a largely-theoretical class of vulnerabilities, that doesn't even apply to chips that don't do speculation in hardware, and that is purely about information disclosure via side-channel mechanisms. It might be a bit of a concern for some users, but it's not the end of the world - for instance, the designers of the Mill architecture have a whole talk discussing how Spectre as such doesn't really apply given the architectural choices they make. And if running stuff in different address spaces is enough to mitigate it effectively, that still provides quite a bit of efficiency compared to an entirely conventional OS.
- tntn 7y ago
  > doesn't even apply to chips that don't do speculation in hardware This is an interesting way to put it. I would have said "applies to pretty much every CPU manufactured in the last decades." Your statement would make sense if speculation in hardware was some niche thing, but I think you would be hard-pressed to find an invulnerable CPU that is used in situations where people care about both performance and security. That's great for the mill, but isn't relevant to the world outside of mill computing.
- fulafel 7y ago
  Nitpick re "chips that don't do speculation in hardware" - load forwarding and speculative cache prefetching and branch prediction are done even by lots of current (and past) processors that don't do speculative execution and hence are considered "in-order" microarchitectures.

colordrops 7y ago

I assume that new chips will address this vulnerability, correct? Couldn't the VM detect whether the hardware is secure and decide whether to use hardware memory protection or not?

tntn 7y ago
> new chips will address [these vulnerabilities] It doesn't seem likely. The chipmakers will fix the vulnerabilities that break isolation between processes and between user-kernel, but the within-process issues will probably stick around.
Negitivefrags 7y ago
At this point it seems practically impossible to deal with completely. V8 at least have given up on the concept of trying to protect memory within the same address space. https://v8.dev/blog/spectre https://v8.dev/blog/spectre

xena 7y ago

This is part of why I want to make a custom OS where each WebAssembly process can be in its own hardware protected memory space. I'm looking at building on top of seL4.

0815test 7y ago

Well, Spectre is a largely-theoretical class of vulnerabilities, that doesn't even apply to chips that don't do speculation in hardware, and that is purely about information disclosure via side-channel mechanisms. It might be a bit of a concern for some users, but it's not the end of the world - for instance, the designers of the Mill architecture have a whole talk discussing how Spectre as such doesn't really apply given the architectural choices they make. And if running stuff in different address spaces is enough to mitigate it effectively, that still provides quite a bit of efficiency compared to an entirely conventional OS.

tntn 7y ago
> doesn't even apply to chips that don't do speculation in hardware This is an interesting way to put it. I would have said "applies to pretty much every CPU manufactured in the last decades." Your statement would make sense if speculation in hardware was some niche thing, but I think you would be hard-pressed to find an invulnerable CPU that is used in situations where people care about both performance and security. That's great for the mill, but isn't relevant to the world outside of mill computing.
fulafel 7y ago
Nitpick re "chips that don't do speculation in hardware" - load forwarding and speculative cache prefetching and branch prediction are done even by lots of current (and past) processors that don't do speculative execution and hence are considered "in-order" microarchitectures.