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