Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WAVM: standalone WebAssembly VM prototype

github.com

Post reply on HN
Print view View original

11–20 of 30 posts

Re: WAVM: standalone WebAssembly VM prototype

#11

Post by espadrine »

fulafel wrote: post #10
espadrine wrote: post #8

Earlier quoted context omitted.

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

Re: WAVM: standalone WebAssembly VM prototype

#12

Post by akavel »

stepanhruda wrote: post #3
slimsag wrote: post #2

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

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.

Re: WAVM: standalone WebAssembly VM prototype

#14

Post by k__ »

merb wrote: post #13

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.

Re: WAVM: standalone WebAssembly VM prototype

#15

Post by merb »

k__ wrote: post #14
merb wrote: post #13

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.

Re: WAVM: standalone WebAssembly VM prototype

#16

Post by bobajeff »

k__ wrote: post #14
merb wrote: post #13

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.

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.

Re: WAVM: standalone WebAssembly VM prototype

#17

Post by ascheidecker »

k__ wrote: post #14
merb wrote: post #13

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.

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

Re: WAVM: standalone WebAssembly VM prototype

#18

Post by cm3 »

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.

Re: WAVM: standalone WebAssembly VM prototype

#19

Post by sspiff »

merb wrote: post #15
k__ wrote: post #14

Earlier quoted context omitted.

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?

Re: WAVM: standalone WebAssembly VM prototype

#20

Post by [deleted] »

cm3 wrote: post #18

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]
Post reply on HN