Making WebAssembly better for Rust and for all languages
hacks.mozilla.org
hacks.mozilla.org
Compilers could stop worrying about obscure/old architectures. Deploying an application onto multiple platforms is no longer a problem. Sandboxing is much simpler. Formal verification becomes possible (the WebAssembly spec actually reads like a spec, unlike the C standard which reads more like a religious text).
I'm so excited about WebAssembly, but really not because of the web.
No they wouldn't. They still need to turn WebAsm/IR into assembly, which is the thing they already do today anyway. Nothing changes for compilers, other than the potential for optimizations gets much, much worse as the IR is comparatively crippled and restricted to the IR they already have.
> Deploying an application onto multiple platforms is no longer a problem.
This has never been the result of CPU instructions. That's a library problem, not an IR problem. WebAsm does nothing to help with this, particularly as it intentionally has no real standard library to speak of.
Or put another way every compiled program is already on a perfectly portable IR called x86_64. Runs on just about every desktop, laptop, and nearly every server in the world. Yet good luck writing a portable "hello world" in it.
It marginally reduces your release artifacts as you only produce a single webasm set instead of x86, x86_64, arm7, and armv8, but using webasm instead comes at non-trivial costs, too. Instead of compiling once on a known toolchain you're now compiling millions of times on uncontrolled, unknown toolchains. That's not a great trade-off in many, if not most, circumstances.
> Sandboxing is much simpler.
Sandboxing is already a solved problem using process isolation, which has the nice property of not caring how your process runs at all. What benefit does WebAsm add to this?
> Formal verification becomes possible (the WebAssembly spec actually reads like a spec, unlike the C standard which reads more like a religious text).
WebAsm is an intermediate, not a source. Formally verifying it is about as useful as formally verifying assembly. Which is to say, not useful at all. That doesn't help you verify anything about your code, which was a compiler, optimizer, and god knows what else away from the webasm that was generated.
It's good that the spec is actually a spec, but this isn't a unique trait to webasm and it won't help your code any since your code isn't in webasm. It's still in C/C++, Rust, or whatever else and they all remain just as verifiable (or not) as they always were.
But not mobile.
(Besides, I'm also somewhat uneasy with accepting that the computing lingua franca will forever be proprietary to Intel, covered by innumerable patents, and backwards compatible to 1978.)
> Sandboxing is already a solved problem using process isolation
If only it were. Process isolation does not protect against kernel attacks or attacks against whatever IPC mechanism you use to call out to the privileged broker process.
> Formally verifying it is about as useful as formally verifying assembly. Which is to say, not useful at all.
You can verify memory safety of the compiled code, which is a useful and important property.
(I think nobody seriously doubts that Web Assembly is memory safe assuming a bounds checked heap, though, so it's not that practically interesting of a result. Maybe it'll be more so when GC support lands.)
Well, x86_64 is actually AMD's creation not Intel's. But replace x86_64 with ARM on mobile and it's the same thing - a portable IR/instruction set does not result in a portable application.
> Process isolation does not protect against kernel attacks or attacks against whatever IPC mechanism you use to call out to the privileged broker process.
Neither does webasm, other than by just not having any features currently. But that's obviously not a viable long-term strategy, certainly not for anything standalone-ish.
> You can verify memory safety of the compiled code, which is a useful and important property.
My native code is perfectly memory safe as well, enforced in hardware even. Has been that way for decades.
Of course that's not what anyone actually means by a "memory safe" language, but as soon as you go plop malloc/free on top of a single webasm allocation you're back to all the same memory-unsafeness of C despite the "memory safe" claims of webasm anyway. A memory safe IR is meaningless outside of the context of being embedded in another process. Aka, when used in a web browser. Or I guess as a massively overcomplicated replacement for Lua.
But the point is verifying the resulting webasm doesn't mean your code was correct, it means your code plus current toolchain selection happened to result in verified code. Whether or not that was the result of a fluke or well defined behavior is not something webasm has any impact on.
That's not true. Web Assembly semantics don't allow interpreting data as code or explicitly messing with the machine stack. This guarantees control flow integrity, preventing problems like ROP or traditional buffer overflows.
Memory protection in terms of r/w/x been solved for at least about 3 decades now. It would be absolutely trivial to enforce via binary/IR distribution.
At the end of the day webasm is just a shitty IR that only exists because it's the path of least resistance on the web. There's really no point in going from lang-> llvm -> webasm -> llvm -> exec when you can just go from lang -> llvm -> asm.
edit: not to mention that WebAssembly is currently missing security mitigations that long have been standard in native code, such as ASLR, and… maybe stack overflow protection? (It looks like emscripten handles the latter manually by checking STACKTOP against STACK_MAX, but I'm not sure LLVM's native WebAssembly target does.) Maybe these will be addressed in the future, but for now there are some interesting exploitation opportunities.
But you get a lot more than security for your trouble using Web Assembly. So the performance-vs.-security tradeoff isn't the only part of the calculus here.
> And there are CFI designs that provide equivalent or better guarantees for native code, such as Clang CFI + SafeStack.
Clang CFI only protects indirect calls. And SafeStack looks like it has issues, according to the Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=505015
"No. We are currently looking at other alternatives (all look grim, though). Before trying to proceed with SafeStack please get the agreement from security folks, since SafeStack doesn't actually sounds too secure any more :("
Not sure what's up with SafeStack - though I bet it has to do with more hardware timing attacks, in this case to leak the address. The whole design is a bit of a hack since the only thing preventing the attacker from accessing the safe stack is their (theoretical) inability to guess the address. If only x86-64 hadn't gotten rid of segmentation, so normal memory accesses and stack accesses could actually use entirely separate memory regions… On the other hand, Intel CET should allow for some subset of that functionality on future hardware.
But again, to be fair, one should note that "grim" has a different meaning when the budget for acceptable performance loss is perhaps 1-5%, not 30-50% :P
Most compilers today have separate assembly generation for MIPS, ARM, x86_64. They could turn source into WebAssembly and no more (the job of WebAssembly -> native is left to some other architecture specific compiler).
> This has never been the result of CPU instructions. That's a library problem, not an IR problem. WebAsm does nothing to help with this, particularly as it intentionally has no real standard library to speak of.
If any one language targets WebAssembly, as long as you resolve your libraries within that language, you'll be able to deploy to any target that supports WebAssembly. This is pretty much the defacto solution to the library problem in a variety of ecosystems: in Java you'll make a fatjar and in C/C++/Rust you'll make a staticly linked binary.
> WebAsm is an intermediate, not a source. Formally verifying it is about as useful as formally verifying assembly. Which is to say, not useful at all. That doesn't help you verify anything about your code, which was a compiler, optimizer, and god knows what else away from the webasm that was generated.
Are you familiar with binary analysis?
Perhaps you meant: why not use LLVM IR instead of WebAssembly? If so, allow me to refer you to this comment[1] (from a bit further down in this thread).
The performance of an application that doesn't work is worse than a cripple application.
You and me both. I wrote a backend for the JVM [0] and there is one in dev targetting native [1] (in Rust using an interesting alt-llvm project [2]). I suspect where you'll start to see this really shine is when a popular langauge targets WASM as the primary target and lets second-level backends compile to a specific arch. The other problem is interoperability. Until host bindings come along and the community standardizes on things like string representation and syscalls, many of uses are siloed by the frontend compilers. I think we can do better than libc+posix.
0 - https://github.com/cretz/asmble 1 - https://github.com/sunfishcode/wasmstandalone 2 - https://github.com/Cretonne/cretonne
Some of these previous efforts might have one or two of these features, but none of them meet all of these criteria.
You seem to imply this approach wasn't successful before. IMHO it's been successful, more than once actually, just not awesome.
EDIT: you've since added some examples. Here are my (very subjective) opinions:
- The JVM isn't really all that low-level - it eeks out a lot of performance at runtime. Plus, you need to have GC, which tends to increase memory requirements and complicate real-time constraints.
- NaCL was interesting but its spec wasn't as good. IIRC Google didn't do too much in the way of asking for public input. I think some folks had some security concerns too. I really like WebAssembly's spec - I don't see any typing judgements or small-step rules for NaCL.
- Wasn't ANDF unix-bound?
Using bytecode as portable executable format has been a tradition in mainframes since the early 60's.
At its peak, there were many different vendors delivering JVM implementations. How we forget Kaffe, even.
* JVM - Most heavily used implementation borked the sandboxing. It also forces a GC down your throat, which is great for 95% of use cases, but the other 5% are really important too.
* NaCl - Really cool, but ultimately reliant on weird CPU features for protection. PNaCl was trying to fit a square peg into a round hole with the whole trying to make LLVM IR platform independent thing. WebAsm took a lot of ideas from these projects (and asm.js).
* P-Code - Really cool, but ultimately probably a victim of it's time. A little simplistic for modern architectures as it has no real concept of a memory model or atomic primitives.
* TIMI - Unbelievably proprietary. Even if you were to document it well enough to build an implementation, IBM would almost certainly sue you into oblivion.
And the reason running in a browser matters is that it guarantees a lot of teams will put effort into improving it.
some used to, until browsers banned them
[0]: https://nwat.xyz/blog/2018/03/13/video-of-my-talk-at-lua-wor...
https://www.destroyallsoftware.com/talks/the-birth-and-death...
The true advantage of WebAssembly is that it's so sandboxed that it literally can't do anything on it's own. It can only do something when hosted in a browser where it can use JavaScript to interact with outside world.
This is completely wrong. The JVM works at an extremely high level. Everything is a garbage collected JVM object. You will never see raw memory at the bytecode layer.
WebAssembly gives you access to the heap and stack at byte granularity. You have to bring your own memory allocator or garbage collector. It's in the damn name: "WebAssembly"
The closest equivalent is NaCL but Google didn't really put a lot of effort into pushing it for wide adoption. If I recall correctly it is also based on LLVM IR and LLVM IR isn't known for maintaining backwards compatibility which turns it into a dead end. Of course if LLVM IR was stable then WebAssembly would be redundant.
We're not living in that world. We're living in a world were WebAssembly is winning not only because of popularity but also because of strong technical fundamentals.
Honestly it seems like HN is blind to fundamentals and everything new is just some hyped up useless piece of shit.
In JS land new = always good. On HN new = always bad. There is no middle ground. Both sides are equally bad.
I'll give you that; it was just one example. There have been plenty of others in history, Pascal P-code is closer to WebAssembly and that's from the 70's! The concept of a portable assembly language is neither new or interesting. WebAssembly is just another compiler target -- if you can compile to it, you can compile to every other native CPU directly. That's just not that interesting as an intermediate form. Java was slightly more interesting as they abstracted the entire platform not just the CPU.
I stand by my statement that WebAssembly is only valuable because it's sandboxed in the browser.
> Honestly it seems like HN is blind to fundamentals and everything new is just some hyped up useless piece of shit.
Maybe being blind to the fundamentals is not knowing the 50 years of technology that has already been done. Remixing old technology in new ways is valuable and in this case remixing portable assembly with the browser sandbox is the cool part.
I share the parents' excitement in this regard. The spec is well written for this kind of thing, and I think it has a lot of potential. We'll see!
IMO WASM can probably learn from the JVM mistakes a lot, especially when the runtime gets baked in so you don't need it on your computer just to run it (looking hard at you JVM, don't try to hide!)
>What about the JVM? too high level
>What about llvm IR and bitcode? no backwards compatibility
>What about .net/CLR? too high level
What the majority of people here do not comprehend is that if you look at each individual feature (low level, stable) each of them is nothing new. It's the combination of these existing features (low level and stable) that existing technologies are simply not capable of.
LLVM had almost two decades to stabilise their IR and yet they didn't so someone else has to step up and fix what they failed to do.
Probably because WASM is a runtime blackbox locked inside a web page running in a browser. There is a huge amount of overhead to that and the ability to interact with anything external to the blackbox is severely limited.
I get that you are excited that WASM is a compile target for many languages, but it comes with a heavy dose of isolation and performance costs.
The phrase you're looking for is "Ahead-of-Time" or "AoT" compiler. It's not clear if the OP was specifically looking for an AoT compiler, or if a JIT suffices for her/his use case.
> import {myFunction} from "myModule.wasm"
> We’re working with TC39 and the WebAssembly community group to standardize this.
Note that this is already possible using Webpack 4.
0 - https://github.com/WebAssembly/reference-types 1 - https://github.com/WebAssembly/host-bindings
Then, two weeks ago https://github.com/rust-lang-nursery/rand/pull/272
> Would anything that depended on that need to use a random function from js instead?
Your instinct is right, that's what the above does. (more specifically, with https://developer.mozilla.org/en-US/docs/Web/API/RandomSourc... )
It really isn't, though. Maybe less bad with ES6. I feel like this was thrown in to mollify the scores of people who <strike>wasted their lives with</strike> invested a lot into javascript.
I know the unfortunate story of how javascript came to be the "web language". It's a shame even a tiny bit more thought didn't go into it.
So... The only overlap between Javascript and webassembly is floating point numbers? Are they the same type of floating point?
And is the conversion unicode-string > js float > ws int - or something else?
Or does js have integers now?
We know how to write a UI library, I think the basic components are pretty well-defined. Qt and NextStep (surviving to some extent in Cocoa) are well-regarded. Java Swing is okay. So if we could get a real UI library for use in the browser, instead a JavaScript framework poorly re-inventing it, that would be wonderful. And, best of all, it doesn't have to be in JavaScript!
There's no reason one couldn't wrote a UI frame work like the ones mentioned by the parent that use the dom under the covers.
Browsers should always have been a well defined VM with everything else built on top. I'm hoping we can get away from being shackled to what Microsoft, Google, and even Mozilla think is necessary and important for developing software.
What we'll lose of course is interoperability. But I think it will be worth it.
> What we'll lose of course is interoperability. But I think it will be worth it.
Maybe i misunderstood, but what is the web without interoperability?
Without DOM access I fail to see how that would happen. So until WASM gets DOM access no other language(except JS) can become a(first class) web language.
What is JavaScript without DOM access?
Even then, there's tons of logic you want to execute in the browser that aren't related to UI. For example, any sort of number crunching. That stuff is now feasible, which opens up all kinds of applications.
This required only a handful of changes across the codebase (mostly handling external resources such as the filesystem and the random generator) and then implementing a bit of JavaScript that took the drawcalls from the WASM core and rendered them on the canvas. And vice-versa, a bit of JS that passed the browser input into the WASM game.
Since the original game had no concept of a DOM, it didn't matter to it. I think WASM can be huge for browser games.
But like Steve said, you can call any JavaScript function and manipulate the DOM that way. At least for Rust, there's also a library that does this for you. So you can have Rust code that uses a DOM API and the WASM <-> JS bridge is handled for you:
This can be easily achieved by buffering calls to the DOM and merging batches of actions together (you could probably even divide DOM actions into priority queues to improve reaction time at expense of throughput in less important UI elements)
But I don't think languages will interact with the DOM extensively once it has been properly abstracted.
One major difficulty would be to have it available quickly so a page refresh doesn't take until the WASM binary has sorted out it's internal state.
Not really. You're still hamstrung by either being single threaded & time sliced with the UI thread (huzzah for cooperative multitasking still somehow not being dead), or you need to jump through the webworkers hoop if you're lucky enough to have a problem & dataset that's compatible with webworker's rather severe limitations.
webasm claims to have threading support on the roadmap but until that happens anything truly involving heavy number crunching is still largely infeasible. And with SharedArrayBuffer being killed by spectre there's a lot of rather major unknowns to deal with.
That's why it's one of few languages: 1) with mainstream transpilation; 2) more than one transpiler.
So if JS is the lowest possible level language, than that will be the compilation target for a program going into that context.
x86 has its many, many critics, but I've never heard any of them say that x86 is bad because so many things compile to it....
There are so many superior languages to it.
In the end, it doesn't matter. JS is here to stay. If you don't want to write it, don't write code for projects that need it. Constant complaining about its faults does nothing at all except produce noise in threads like this.
And, fwiw, I don't see too many C projects for Front-end solutions like e.g. React. Maybe that means JS is a superior language in the context of the problem is was made to address. Holy shit! Who would have thought that "it depends" applies to development?!
Only in terms of access/availability but that was his point...
Go on. Say we're "wrong". I could use a chuckle. :)
I used to smarm about it. I was wrong to. You should stop, because you are wrong now.
I never made any such 'claims', but I'm happy for you. I enjoy those things, too...
> and the mind-meltingly stupid sneering nonsense should just end. Just...end. I used to smarm about it. I was wrong to.
You're the one sneering, smarming, etc. and attempting to create drama. I never said anything about using Node being bad. Maybe you should re-read what I wrote?
> You should stop, because you are wrong now.
Hey, keep believing that if it makes you feel better.
In other words, we have node.js and not node.xxx because other languages at that time did not provide a suitable ecosystem for building asynchronous programs. Today most languages have much better async support, or they have features (like goroutines in golang) which achieve the same objective in a different way.
Is it a mystery to you why this situation is different from your favorite language that you aren't source-to-source compiling?