5 ms·

WAVM: standalone WebAssembly VM prototype

128 points by vmorgulis 10y ago

slimsag 10y ago
Am I correct that WebAssembly is the first browser language VM (like JVM, Flash, etc) that is developed as a specification and not an implementation? If so, I wonder how security will fare in comparison to JVM/Flash/etc, I imagine it'll be much better. WebAssembly is gonna be huge, esp. with languages like Rust supporting it!
- stepanhruda 10y ago
  I assume there will be no more security holes than there are in javascript, since it's effectively a sibling to it, implementing the exact same APIs
  - azakai 10y ago
    It's also being run using the same VMs as JavaScript. There is some new code, but overall it's the same JITs, so similar security risks.
  - akavel 10y ago
    I suspect it (the WASM VM) will "bubble out" from inside the JS VM in browsers sooner or later, as a distinct entity in browsers. To enable better optimizations, if only. And especially better optimizations means closer to metal, which I think makes it harder not to introduce security holes. Also, brand new external WASM VMs will be created (as in the OP link), and possibly used in future (or current but new versions?) browsers, again allowing for brand new security holes. So, I'm not very convinced by this argument as of now.
- duaneb 10y ago
  If there are N implementations, there are N times more chance for a security vulnerability. Roughly, anyway. I don't think the reference material matters as much as the rigor that goes into defining it.
  - colemickens 10y ago
    >If there are N implementations, there are N times more chance for a security vulnerability. I don't even understand what this is supposed to mean. Do you mean that a hole in the spec means that a sec vuln would occur in every implementation? Or that 5 implementations means 5 code bases to review? Either way, it seems like a sentence that is meant to carry weight but is ultimately nearly completely meaningless. N different desktop apps on my computer have N chances for sec vulns. I don't see what that statement is supposed to mean regarding WebAssembly.
    - fulafel 10y ago
      Implementation level bugs dominate, not spec bugs.
      - espadrine 10y ago
        In this instance, WASM shares JS' sandbox and security model down to the implementation, so the added risk is extremely limited. The only part that could be dangerous is the parser.
        fulafel 10y ago
        From WAVM's Github README: "This is a prototype of a simple standalone VM for WebAssembly" So it doesn't share code with a JS implementation in this case.
        espadrine 10y ago
        Browsers have their security model. On the other hand, when you install an executable binary or a Node.js program, you don't expect to have the same security model. This project fits in the latter category. It does not claim that downloaded binaries are protected by a sandbox, and the only security claim it makes is the following weak one: “The generated code should be unable to access any memory outside of the addresses allocated to it”.
  - 10y ago
- sievebrain 10y ago
  JVM's are a specification.
merb 10y ago
Without GC WebAssembly will still hold a shit load of languages away.
- k__ 10y ago
  Really? I had the impression it's the other way around. If it would have GC, other languages would have to use the supplied GC. If it wouldn't have GC, other languages could simply implement their own GC.
  - merb 10y ago
    > implement their own GC when that would be so easy, maybe. But especially on top of the browser restrictions that will be even harder.
    - sspiff 10y ago
      Garbage collection is not magic. It's a fairly simple (but byzantine) matter of tracking references, and allocating and freeing memory. Why would this be so much harder for WebAssembly? Why can't existing garbage collectors be compiled to WA?
      - chrisseaton 10y ago
        > Why can't existing garbage collectors be compiled to WA? Yes I think that's the idea.
        sspiff 10y ago
        Exactly. From what I've seen of WebAsm, you can request pages of memory using grow_memory. Upon this, you could implement a memory pool system to handle malloc and free. Using this, it is trivial to port existing GC's. I don't understand why people moan about GC in WebAsm. WebAsm is a compiler target for lower level languages, not the JVM.
  - bobajeff 10y ago
cm3 10y ago
I haven't been following WebAssembly, but I've asked myself why, given the elevated level of security threats, there is not effort to design a safer, tinier, web page scripting system. I have the feeling that based on the experience we could streamline and simplify much of the web client stack to allow (1) safer implementations, (2) smaller implementations and (3) less interpretation of the standards.
- deleted 10y ago
  [deleted]
- sievebrain 10y ago
  Once upon a time Javascript was tiny. Unfortunately, the web became the only app platform that was perceived as being politically neutral, and so there was huge pressure to add features to it. These features all hugely increased the complexity of HTML renderers, and with complexity came bugs. Could you build a smaller, simpler, safer web? Sure. It's called HTML4.
  - cm3 10y ago
    I get what you're saying, but what I meant is that it's surely possible to keep the current features while streamlining it into something coherent, much smaller, and easier to implement. The modern web platform's bloat and what you can achieve with it always reminds me of 1990s demo scene mags on floppy disks and their mag engines. I think most of the problems stem from adding more stuff to HTML rather than taking what we build today building the smallest possible DSL and its engine around it. At some point we have to do a cut like that or we'll have browsers that'll have to support many, many HTML profiles and become monstrosities.
    - vmorgulis 10y ago
      I expect a reboot of the web with wasm. As wasm defines a VM, the browser could become useless.
      - 10y ago
fizzbatter 10y ago
Dumb question, but is the purpose of this to run WASM code (binaries/etc) in standalone? Ie, is Nodejs to Javascript as WAVM is to WASM?
- ascheidecker 10y ago
  Not exactly. Node.js will probably integrate a future release of V8 that supports WebAssembly, and WAVM isn't a suitable replacement for that. WAVM is more like V8, but for WebAssembly only instead of both JavaScript and WebAssembly. The purpose is to serve as a simple VM for my programming language that compiles to WebAssembly.

128 points by vmorgulis 10y ago

Am I correct that WebAssembly is the first browser language VM (like JVM, Flash, etc) that is developed as a specification and not an implementation? If so, I wonder how security will fare in comparison to JVM/Flash/etc, I imagine it'll be much better. WebAssembly is gonna be huge, esp. with languages like Rust supporting it!

stepanhruda 10y ago
I assume there will be no more security holes than there are in javascript, since it's effectively a sibling to it, implementing the exact same APIs
- azakai 10y ago
  It's also being run using the same VMs as JavaScript. There is some new code, but overall it's the same JITs, so similar security risks.
- akavel 10y ago
  I suspect it (the WASM VM) will "bubble out" from inside the JS VM in browsers sooner or later, as a distinct entity in browsers. To enable better optimizations, if only. And especially better optimizations means closer to metal, which I think makes it harder not to introduce security holes. Also, brand new external WASM VMs will be created (as in the OP link), and possibly used in future (or current but new versions?) browsers, again allowing for brand new security holes. So, I'm not very convinced by this argument as of now.
duaneb 10y ago
If there are N implementations, there are N times more chance for a security vulnerability. Roughly, anyway. I don't think the reference material matters as much as the rigor that goes into defining it.
- colemickens 10y ago
  >If there are N implementations, there are N times more chance for a security vulnerability. I don't even understand what this is supposed to mean. Do you mean that a hole in the spec means that a sec vuln would occur in every implementation? Or that 5 implementations means 5 code bases to review? Either way, it seems like a sentence that is meant to carry weight but is ultimately nearly completely meaningless. N different desktop apps on my computer have N chances for sec vulns. I don't see what that statement is supposed to mean regarding WebAssembly.
  - fulafel 10y ago
    Implementation level bugs dominate, not spec bugs.
    - espadrine 10y ago
      In this instance, WASM shares JS' sandbox and security model down to the implementation, so the added risk is extremely limited. The only part that could be dangerous is the parser.
      - fulafel 10y ago
        From WAVM's Github README: "This is a prototype of a simple standalone VM for WebAssembly" So it doesn't share code with a JS implementation in this case.
        espadrine 10y ago
        Browsers have their security model. On the other hand, when you install an executable binary or a Node.js program, you don't expect to have the same security model. This project fits in the latter category. It does not claim that downloaded binaries are protected by a sandbox, and the only security claim it makes is the following weak one: “The generated code should be unable to access any memory outside of the addresses allocated to it”.
- 10y ago
sievebrain 10y ago
JVM's are a specification.

merb 10y ago

Without GC WebAssembly will still hold a shit load of languages away.

k__ 10y ago
Really? I had the impression it's the other way around. If it would have GC, other languages would have to use the supplied GC. If it wouldn't have GC, other languages could simply implement their own GC.
- merb 10y ago
  > implement their own GC when that would be so easy, maybe. But especially on top of the browser restrictions that will be even harder.
  - sspiff 10y ago
    Garbage collection is not magic. It's a fairly simple (but byzantine) matter of tracking references, and allocating and freeing memory. Why would this be so much harder for WebAssembly? Why can't existing garbage collectors be compiled to WA?
    - chrisseaton 10y ago
      > Why can't existing garbage collectors be compiled to WA? Yes I think that's the idea.
      - sspiff 10y ago
        Exactly. From what I've seen of WebAsm, you can request pages of memory using grow_memory. Upon this, you could implement a memory pool system to handle malloc and free. Using this, it is trivial to port existing GC's. I don't understand why people moan about GC in WebAsm. WebAsm is a compiler target for lower level languages, not the JVM.
- bobajeff 10y ago

cm3 10y ago

I haven't been following WebAssembly, but I've asked myself why, given the elevated level of security threats, there is not effort to design a safer, tinier, web page scripting system. I have the feeling that based on the experience we could streamline and simplify much of the web client stack to allow (1) safer implementations, (2) smaller implementations and (3) less interpretation of the standards.

deleted 10y ago
[deleted]
sievebrain 10y ago
Once upon a time Javascript was tiny. Unfortunately, the web became the only app platform that was perceived as being politically neutral, and so there was huge pressure to add features to it. These features all hugely increased the complexity of HTML renderers, and with complexity came bugs. Could you build a smaller, simpler, safer web? Sure. It's called HTML4.
- cm3 10y ago
  I get what you're saying, but what I meant is that it's surely possible to keep the current features while streamlining it into something coherent, much smaller, and easier to implement. The modern web platform's bloat and what you can achieve with it always reminds me of 1990s demo scene mags on floppy disks and their mag engines. I think most of the problems stem from adding more stuff to HTML rather than taking what we build today building the smallest possible DSL and its engine around it. At some point we have to do a cut like that or we'll have browsers that'll have to support many, many HTML profiles and become monstrosities.
  - vmorgulis 10y ago
    I expect a reboot of the web with wasm. As wasm defines a VM, the browser could become useless.
    - 10y ago

fizzbatter 10y ago

Dumb question, but is the purpose of this to run WASM code (binaries/etc) in standalone? Ie, is Nodejs to Javascript as WAVM is to WASM?

ascheidecker 10y ago
Not exactly. Node.js will probably integrate a future release of V8 that supports WebAssembly, and WAVM isn't a suitable replacement for that. WAVM is more like V8, but for WebAssembly only instead of both JavaScript and WebAssembly. The purpose is to serve as a simple VM for my programming language that compiles to WebAssembly.