6 ms·

You can compile C, C++ and a bunch of other languages to Wasm, while you can't do that with Java as a target. A lot of existing C code compiles unchanged. And W

You can compile C, C++ and a bunch of other languages to Wasm, while you can't do that with Java as a target. A lot of existing C code compiles unchanged. And Wasm also actually runs in all browsers nowadays without the user noticing a difference (eg. iOS Safari too).

brian_herman 4y ago
What we should be comparing it is to activeX and flash will it have the security that those two technologies didn't?
- Georgelemental 4y ago
  WASM uses the browser sandbox, from what I understand it re-uses the same facilities that browsers use for JIT
  - ridiculous_fish 4y ago
    WASM's sandboxing as implemented in practice is different from JITs. It works by allocating a 4GB region of virtual memory and treating the base address as NULL. Pointers in WASM are 32 bit so they are unable to point outside the region. The big win is the runtime doesn't need to check pointers for validity. However there are some downsides relative to native code: 1. Can't address more than 4GB of memory 2. Can't be efficiently implemented on 32 bit systems 3. Can't share memory between WASM modules 4. NULL dereferences don't trap (I think) I would not be surprised if future CPUs had hardware support for this stuff, e.g. load/stores with a mask to confine the pointers.
    - pjmlp 4y ago
      Just like Solaris SPARC has been doing like for 10 years.
    - jb1991 4y ago
      Neat. I thought Web pages were limited to 2 GB memory. I guess tines have changed.
    - int_19h 4y ago
      The other way it ensures isolation is by separating code and data. All executable code lives in a separate address space that is not accessible from within wasm. Call stack is also a separate area, making it impossible to muck around or even look at the return pointer. Function pointers are opaque - they can live in global or local variables and in table entries (which are also completely separate from memory), but not in memory; when one needs such a pointer as part of the data structure (e.g. vtables), an index into a table is used instead.
- simonw 4y ago
  Yes, because it's learned from their experience. WASM has been designed with security in mind from the very start, and implemented by experienced browser teams with a very deep understanding of the security risks of doing so.
  - pjmlp 4y ago
    "Usenix Security '20-Everything Old Is New Again: Binary Security of WebAssembly" https://www.youtube.com/watch?v=glL__xjviro https://www.youtube.com/watch?v=glL__xjviro "The Security Risk of Lacking Compiler Protection in WebAssembly" https://arxiv.org/abs/2111.01421 https://arxiv.org/abs/2111.01421
- nikki93 4y ago
  One of the things that killed Flash was not being supported on iOS while Wasm runs fine (and actually pretty well!) on iOS which is pretty good for reach.
  - pmontra 4y ago
    On the other side, not being able to run on iOS didn't kill any server side language (think Java.) And Java client side (Android) is very different from Java server side, down to the sets of developers. Currently WASM is both a client side and server side runtime. It's not clear where it will be in 5 or 10 years. I don't see a compelling server side story. Why WASM and not C#, Java, Node, Python, Rails (I intentionally don't write Ruby) or whatever any of us is using now with its standard runtime?
    - nikki93 4y ago
      Personally I'm not super familiar with its benefits if any on the server and would actually not use it on the server myself and just build binaries directly, probably using Go. But I've seen some references to Wasm on the serverside for something similar to containerization or loading plugins. It does seem less obvious to me than the client side. What makes you say Wasm is a server side runtime / imply that it's meant to be one?
      - 0x20cowboy 4y ago
        With go as an example, you know the saying “cgo isn’t go”? Well, you could use C, C++, Rust or anything else that compiles to wasm from any other language. There have been a few people who say if wasm (WASI on the server) existed already, Docker wouldn’t need to exist. Docker runs a whole OS just to run your binary - imagine the benefits of Docker but just running your binary. It’s all early days so I am slightly waving my hands, but a lot of this works now. Check out _wasmtime_.
        nikki93 4y ago
        For the client I use a simple go -> c++ compiler I wrote and compile to wasm from that actually, on my side projects. It had zero overhead interfacing to / calls to C/C++ (including generics<->templates) since it's just generating that. Example web game made with that: https://github.com/nikki93/raylib-5k https://github.com/nikki93/raylib-5k I think I've seen wasmtime before. If I needed to interface to any C/C++ things on the server I would probably just write in C/C++ (or Gx) yeah.
pjmlp 4y ago
So basically CLR, not to mention the 60 and 70's bytecode environments.
- nikki93 4y ago
  I think you missed the part about it running in the browser? But yes, some previous technologies are similar to some new technologies, that's not really an insight at this point. Especially not about bytecode interpreters which seems like a standard practice.
  - debugnik 4y ago
    > I think you missed the part about it running in the browser? .NET Core started as the Silverlight runtime, didn't it?
    - nikki93 4y ago
      The extent of Wasm's availability on browsers is quite big right now. Both iOS and Android and all major desktop browsers. That sort of reach is what I meant by the term "the browser" used generically. Different from being an extension to one or a few browsers or something like that.
    - idontpost 4y ago
      Silverlight was never a native part of the browser.
  - pjmlp 4y ago
    .NET did run in the browser from day 1, even if only on IE.
  - worik 4y ago
    > I think you missed the part about it running in the browser? The article expressly stated that was not the exciting part, for them. This is another iteration of the same old byte code blah blah, and each iteration has gotten better, and this is the best yet. Maybe.
moonchild 4y ago
https://github.com/oracle/graal/tree/master/sulong https://github.com/oracle/graal/tree/master/sulong

brian_herman 4y ago

What we should be comparing it is to activeX and flash will it have the security that those two technologies didn't?

Georgelemental 4y ago
WASM uses the browser sandbox, from what I understand it re-uses the same facilities that browsers use for JIT
- ridiculous_fish 4y ago
  WASM's sandboxing as implemented in practice is different from JITs. It works by allocating a 4GB region of virtual memory and treating the base address as NULL. Pointers in WASM are 32 bit so they are unable to point outside the region. The big win is the runtime doesn't need to check pointers for validity. However there are some downsides relative to native code: 1. Can't address more than 4GB of memory 2. Can't be efficiently implemented on 32 bit systems 3. Can't share memory between WASM modules 4. NULL dereferences don't trap (I think) I would not be surprised if future CPUs had hardware support for this stuff, e.g. load/stores with a mask to confine the pointers.
  - pjmlp 4y ago
    Just like Solaris SPARC has been doing like for 10 years.
  - jb1991 4y ago
    Neat. I thought Web pages were limited to 2 GB memory. I guess tines have changed.
  - int_19h 4y ago
    The other way it ensures isolation is by separating code and data. All executable code lives in a separate address space that is not accessible from within wasm. Call stack is also a separate area, making it impossible to muck around or even look at the return pointer. Function pointers are opaque - they can live in global or local variables and in table entries (which are also completely separate from memory), but not in memory; when one needs such a pointer as part of the data structure (e.g. vtables), an index into a table is used instead.
simonw 4y ago
Yes, because it's learned from their experience. WASM has been designed with security in mind from the very start, and implemented by experienced browser teams with a very deep understanding of the security risks of doing so.
- pjmlp 4y ago
  "Usenix Security '20-Everything Old Is New Again: Binary Security of WebAssembly" https://www.youtube.com/watch?v=glL__xjviro https://www.youtube.com/watch?v=glL__xjviro "The Security Risk of Lacking Compiler Protection in WebAssembly" https://arxiv.org/abs/2111.01421 https://arxiv.org/abs/2111.01421
nikki93 4y ago
One of the things that killed Flash was not being supported on iOS while Wasm runs fine (and actually pretty well!) on iOS which is pretty good for reach.
- pmontra 4y ago
  On the other side, not being able to run on iOS didn't kill any server side language (think Java.) And Java client side (Android) is very different from Java server side, down to the sets of developers. Currently WASM is both a client side and server side runtime. It's not clear where it will be in 5 or 10 years. I don't see a compelling server side story. Why WASM and not C#, Java, Node, Python, Rails (I intentionally don't write Ruby) or whatever any of us is using now with its standard runtime?
  - nikki93 4y ago
    Personally I'm not super familiar with its benefits if any on the server and would actually not use it on the server myself and just build binaries directly, probably using Go. But I've seen some references to Wasm on the serverside for something similar to containerization or loading plugins. It does seem less obvious to me than the client side. What makes you say Wasm is a server side runtime / imply that it's meant to be one?
    - 0x20cowboy 4y ago
      With go as an example, you know the saying “cgo isn’t go”? Well, you could use C, C++, Rust or anything else that compiles to wasm from any other language. There have been a few people who say if wasm (WASI on the server) existed already, Docker wouldn’t need to exist. Docker runs a whole OS just to run your binary - imagine the benefits of Docker but just running your binary. It’s all early days so I am slightly waving my hands, but a lot of this works now. Check out _wasmtime_.
      - nikki93 4y ago
        For the client I use a simple go -> c++ compiler I wrote and compile to wasm from that actually, on my side projects. It had zero overhead interfacing to / calls to C/C++ (including generics<->templates) since it's just generating that. Example web game made with that: https://github.com/nikki93/raylib-5k https://github.com/nikki93/raylib-5k I think I've seen wasmtime before. If I needed to interface to any C/C++ things on the server I would probably just write in C/C++ (or Gx) yeah.

pjmlp 4y ago

So basically CLR, not to mention the 60 and 70's bytecode environments.

nikki93 4y ago
I think you missed the part about it running in the browser? But yes, some previous technologies are similar to some new technologies, that's not really an insight at this point. Especially not about bytecode interpreters which seems like a standard practice.
- debugnik 4y ago
  > I think you missed the part about it running in the browser? .NET Core started as the Silverlight runtime, didn't it?
  - nikki93 4y ago
    The extent of Wasm's availability on browsers is quite big right now. Both iOS and Android and all major desktop browsers. That sort of reach is what I meant by the term "the browser" used generically. Different from being an extension to one or a few browsers or something like that.
  - idontpost 4y ago
    Silverlight was never a native part of the browser.
- pjmlp 4y ago
  .NET did run in the browser from day 1, even if only on IE.
- worik 4y ago
  > I think you missed the part about it running in the browser? The article expressly stated that was not the exciting part, for them. This is another iteration of the same old byte code blah blah, and each iteration has gotten better, and this is the best yet. Maybe.

moonchild 4y ago

https://github.com/oracle/graal/tree/master/sulong https://github.com/oracle/graal/tree/master/sulong