WAVM: standalone WebAssembly VM prototype | Hacker News Reader

WAVM: standalone WebAssembly VM prototype

github.com

128 pointsvmorgulis28 comments

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!

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

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.

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.

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.

>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.

Implementation level bugs dominate, not spec bugs.

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.

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.

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”.

N different implementations can also mean that any single implementation vulnerability will only affect 1/N of the total user base. Using a single implementation isn't always the best way to achieve security (cf OpenSSL).

JVM's are a specification.

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.

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.

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.

I expect a reboot of the web with wasm.

As wasm defines a VM, the browser could become useless.

Given how single page web sites are more or less like Flash in that they don't follow the document model anymore, maybe it's for the best, giving real web pages a chance to revive an effort like XHTML and get us document standards.

  in my mind, as it is aimed at replacing the sprawling forests of javascript
  many pages are powered by, wasm pretty clearly addresses your three
  points. with wasm web applications delivered to browsers can be written in
  c++, rust, haskell, whatever, and compiled and linked and optimized and
  profiled and reoptimized on developer machines before deployment to end
  users. the result of this is that performant applications won't require as
  much (or any) runtime optimization like javascript engines necessarily do now:
  
  - arbitrarily dynamic code needn't be jitted and traced and rejitted to raw
    machine code at runtime
  - object structure needn't be inferred and shared and monitored and reshaped
  - primitive types don't have to be inferred and guarded
  - functions needn't be inlined and guarded because they are all dynamically
    bound
  - objects needn't be tracked and freed and moved around
  - javascript is weird and irregular. half a point here but just look at the
    equality table.
  
  you can say that 'well formed' javascript eases the pain on these poor beasts
  but they still have to strive to support as much of the common language as
  they can, no matter how awful, because it's their job. wasm has to do exactly
  none of this:
  
  - jitting can occur once, at load, statically like the CLR not dynamically
    like HotSpot or luajit as inlining happened on some jenkins box somewhere.
  - there are no objects, there are four types and they're all 4 or 8 byte
    primitives and if you need a gc you baked it into your binary. no vm-level
    object or allocation headers, no gc-related finalizer bugs.
  - desugared there's about 20 instructions (expressions). implement those and
    you've implemented webassembly. standard lib? that was compiled into the
    binary*.
  
  because there's so much less to its job it will be safer, smaller, and more
  widely consistent than javascript. it's still young and definitely not without
  its warts but these three points are home runs.
  
  * ..ish, but it's definitely more spartan:
      https://webassembly.github.io/demo/AngryBots/Release/AngryBots.js
    ... that'll buff out :p

  edit: wow i suck at HN formatting

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?

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.

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

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.

> implement their own GC

when that would be so easy, maybe. But especially on top of the browser restrictions that will be even harder.

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?

> Why can't existing garbage collectors be compiled to WA?

Yes I think that's the idea.

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.

No. They could implement their own GC either way. However the native GC would be faster than one running inside the VM.

There might not be that big of a performance penalty once WebAssembly gets SIMD, shared memory threads and 64bit ints though.

(author of WAVM here)

WebAssembly definitely benefits from being able to avoid the JavaScript garbage collector.

I'm working on a garbage collected language that will use WebAssembly/WAVM as that backend. It's possible as-is, but may require some non-standard extensions to get good performance (e.g. to find GC roots on the stack). I'll certainly contribute anything I do there for standardization, but I suspect the WebAssembly committee will beat me to it.

Reply on news.ycombinator.com