Wasmer 1.0 Beta Released For Running WebAssembly Code Anywhere

[ssokolow]

Thanks for moving people from python to rust !
You fit the mantra: "Ask not what linux can do for you, but what it is I can do for linux."

*nod* Rust has some very nice benefits there compared to Python.

For example, if you use it to write little command-line utilities, they start instantly, while Python risks a seek storm on rotating media, and every invariant you can encode in the type system or something like StructOpt or Serde+validator is one more bit of your attention you can direct to logic the system can't check for you.

It makes it much easier for people to write high-quality tools. (Plus, StructOpt can generate shell completion definitions for you, which helps there.)

[illwieckz]

Why should I ran WebAssembly on the desktop? For instance, it wouldn't make any sense to do this for languages like C#, C++, Go, Rust and so on, because they run on the desktop anyway.

I can name one usage: the Daemon engine powering the Unvanquished game enables people to compile their c++ code once and distribute their game modification (or a new game) on the engine, whatever the supported platform. Also, this code is sandboxed so you don't mind that much executing random code downloaded from random game servers you join. That's a game so you want your C++ performance back, and that's a moddable game so you want to try out new gameplays just by joining game servers (or as a game developer you want to reach all players) so you need cross-platform bytecode and sandboxed execution.

At first we used the Q3VM, a virtual machine designed 20 years later for Quake 3, but that required to compile code with a non-free and aging C compiler, missing any language feature coverage that would have happened since (we had to stick to that very specific C of that era), missing optimizations that would have been implemented since, etc. We jumped to NaCl (Native Client) first, so it began possible to do more than C (like C++) and to make more possible to reuse off-the-shelves libraries that would then build properly without quirks. Now that NaCl is deprecated in favor of Wasm, we are investigating Wasm to replace NaCl with it.

This Wasm effort in Dæmon engine would not be to run the game in a web browser, but to make the engine a game browser.

[ssokolow]

This Wasm effort in Dæmon engine would not be to run the game in a web browser, but to make the engine a game browser.

Plugin systems and sandboxing individual dependencies within a process without adding overhead are actually part of the vision for it. (Ctrl+F for nanoprocess in this page.)

The idea being that, as pioneered with NaCl, the platform APIs are incapable of describing actions not granted to the code as permissions and, as part of compiling and caching machine code from the WebAssembly bytecode, the loader verifies that no attempt is being made to synthesize a syscall or other operation outside the allowed set.

The example they give is the electron-native-notify module getting backdoored to exfiltrate crypto credentials where, if a package manifest, displayed to the developer for approval at the time the version was set into the lockfile, had restricted it to the APIs it legitimately needed, and the permissions have sufficient granularity, that wouldn't be possible.

(I say "have sufficient granularity" because you can access a lot more than just org.freedesktop.Notifications over D-Bus, so, to be reasonably certain, it'd be important to follow the lead of other Linux sandboxing systems and implement per-endpoint whitelisting for D-Bus in the manifest... still, an exploit would require a lot more work and be a lot less portable than just asking the Node runtime for other variables in the JavaScript environment and then firing off a network request to exfiltrate the data.)

[Michael_S]

Why should I ran WebAssembly on the desktop? For instance, it wouldn't make any sense to do this for languages like C#, C++, Go, Rust and so on, because they run on the desktop anyway.

1. It offers a platform-independent cross-platform low level target. Instead of compiling your C++, Go, Rust, or C for Windows x86_64 or Linux ARM32 or Mac x86_64, you compile for WASM and then one binary can be distributed anywhere.

2. It offers a cross-language low-level target that, in theory, is easier to use than foreign function interfaces to C libraries. So your C# WASM code can use WASM libraries written in Go, and your Go WASM code can use WASM libraries written in C++, and so forth.

3. The WASM runtime protects against buffer overruns and several other classes of memory error, for - supposedly - a relatively low amount of runtime overhead. That's not important for C#, Java, Python, or anything else with automatic garbage collection but it adds a safety net to C and C++ code.

4. Wasmer and the other WASM-for-desktop projects sandbox application network, graphics, filesystem, and so forth access by default, so there are fewer security risks to audit when deciding to use a WASM application than a random binary.

As ssokolow said, it's trying to be a better Java (write once, run anywhere) than Java itself - more platforms, better performance, more cross-language integration, more safety.

It's too early to declare success or failure. I think it's interesting, but I haven't tried to use it yet.

And before anyone says it, if maximum performance is critical then yes you better stick with your compile-to-native C, C++, maybe Rust, Pascal, Fortran, Ada, etc...

[darkoverlordofdata]

From the website: Run it on any OS
But I get Your platform is not yet supported (freebsd-amd64).

Cant say I'm surprise that it doesn't run on FreeBSD - but they why advertise Any OS?

[ssokolow]

3. The WASM runtime protects against buffer overruns and several other classes of memory error, for - supposedly - a relatively low amount of runtime overhead. That's not important for C#, Java, Python, or anything else with automatic garbage collection but it adds a safety net to C and C++ code.

That's not quite correct.

See WebAssembly doesn’t make unsafe languages safe (yet) and Everything Old is New Again:Binary Security of WebAssembly for more.

(Basically, it's well sandboxed from the outside world, but the v1.0 Minimum Viable Product for C and C++ running in the browser didn't need various memory security mechanisms used for C and C++ running as native applications, so those are still among the stuff on the roadmap.)

[Michael_S]

That's not quite correct.

See WebAssembly doesn’t make unsafe languages safe (yet) and Everything Old is New Again:Binary Security of WebAssembly for more.

(Basically, it's well sandboxed from the outside world, but the v1.0 Minimum Viable Product for C and C++ running in the browser didn't need various memory security mechanisms used for C and C++ running as native applications, so those are still among the stuff on the roadmap.)

Thanks for the correction. My enthusiasm for Webassembly is dampened by this information - I thought Webassembly solves these problems already, not that solutions are planned.