5 ms·

I like to think of it more that Javascript/WebASM will finally accomplish what Java spent decades trying to do: be the completely ubiquitous hardware-independen

I like to think of it more that Javascript/WebASM will finally accomplish what Java spent decades trying to do: be the completely ubiquitous hardware-independent code platform. Javascript has truly become the "Write Once, Run Anywhere" language. https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... (2014)

bsagdiyev 7y ago
Please, no.
- xena 7y ago
  Bad news, that talk has been a constant source of inspiration for my entire endeavors :)
  - bsagdiyev 7y ago
    That's fine, I'll continue to disagree and understand that we'll never work together since we move fast and don't break things where I work.
- dang 7y ago
  "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
Negitivefrags 7y ago
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.
xena 7y ago
I basically want to do this _without_ javascript though. My implementation is in Go: https://github.com/Xe/olin https://github.com/Xe/olin
AnIdiotOnTheNet 7y ago
How do you figure, when certain features of javascript are supported on some browsers and not others? You've just swapped OS dependence for runtime dependence. JS's solution to this problem? Another layer of abstraction to make the JS cross-browser. WASM already has this problem, what with 5 or 6 different incompatible runtimes already in existence.
- erikpukinskis 7y ago
  You just use the lowest common denominator, depending on your definition if “everywhere”. When in need use shims. It’s not literally “run anywhere” it’s “for all intents and purposes run anywhere”.

bsagdiyev 7y ago

Please, no.

xena 7y ago
Bad news, that talk has been a constant source of inspiration for my entire endeavors :)
- bsagdiyev 7y ago
  That's fine, I'll continue to disagree and understand that we'll never work together since we move fast and don't break things where I work.
dang 7y ago
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

Negitivefrags 7y ago

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.

xena 7y ago

I basically want to do this _without_ javascript though. My implementation is in Go: https://github.com/Xe/olin https://github.com/Xe/olin

AnIdiotOnTheNet 7y ago

How do you figure, when certain features of javascript are supported on some browsers and not others? You've just swapped OS dependence for runtime dependence. JS's solution to this problem? Another layer of abstraction to make the JS cross-browser. WASM already has this problem, what with 5 or 6 different incompatible runtimes already in existence.

erikpukinskis 7y ago
You just use the lowest common denominator, depending on your definition if “everywhere”. When in need use shims. It’s not literally “run anywhere” it’s “for all intents and purposes run anywhere”.