I'm one of the folks working with the Alliance, and I'm incredibly excited about WebAssembly outside the browser. Happy to answer questions.
Imagine extensions for applications or databases, written in any language you want, with no ability to exfiltrate data. Imagine supporting a safe plugin API that isn't just for C and languages that FFI to C, but works natively with safe datatypes.
Today, if you want to be extensible, you typically expose a C API for people to link to, or you embed a specific language like Lua or Python. Imagine embedding a WebAssembly runtime like wasmtime, and telling people they can write their extensions in any language they want.
But, I've looked at this in the past and concluded wasm was a pretty poor fit for small devices: 1) it only addresses memory in 64KB pages (perhaps more SRAM than you might have) and 2) requires both single and double float support.
(1) might be possible to work-around by backing the memory space with smaller page allocations -- at the cost of indirection for every memory access. (2) seems pretty insurmountable -- it'll just need a chunk of extra C library.
Are you aware of any projects working on this for smallish microcontrollers?
You don't have to support floats; you can, for instance, support loading and validating WebAssembly modules only if they don't use any floating-point operations.
Much like C, which also requires floating point support. WebAssembly implementations for tiny IoT environments can emulate floating point in reliance on people not using it heavily, just as you'd expect them not to run Node.js. But at least the developer has the option, which can have significant value, such as during exploration and experimentation phases.
Similarly, compilers like GCC will synthesize 64-bit arithmetic inline for i386 and other targets lacking 64-bit support. These days few people think twice about using 64-bit data types even though 32-bit processors are still in heavy use. (Though, AFAIU emulation has largely moved from compiler to the instruction decoder or microcode.)
This isn't entirely accurate. Exploitations in whatever code is converted to wasm instructions still work inside the wasm memory space.
As in, if you write your program in c, python, whatever, and put it in wasm, then have a wasm extension system of some sort - if that c or python is exploitable, then whatever external access that wasm instance has is now useable. And whatever memory is in the memory space can be modified.
This is an important distinction. Wasm should be thought of as a tool to containerise execution and memory if the implimentation is proven to do so.
The point is that you can more easily and clearly sandbox the wasm plugin. If the python implementation tries to send http requests but the wasm sandbox has no network access you are safer in wasm than in python.
Unless you choose to sandbox your python. Obviously the language itself doesn't support this, but most OSes have functionality for this that can be applied to any application or code, not just wasm.
No. Marking memory as executable is a native machine level capability (as in x86_64 assembly machine instructions). Wasm is a stack machine interpreter that can read only Wasm binaries. The binary format is essentially just a compressed/minimized form of the bytecode format, which used to essentially be an AST of the original source code, but now I believe they modified it a bit to be more analogous to hypothetical machine code, but still abstracted. The Wasm interpreter does not understand x86 or ARM or whatever machine code it's fed it and rightly so. If that was possible, anyone could just send over a buffer to the browser to execute whatever they want.
Yes, assuming there's no flaws in the interpreter. But they're all moving full steam ahead in the browsers right now, so imagine it's deemed as safe as javascript. The current push is to divvy up the permissions of certain resources such as sockets and filesystem (browser code don't have filesystem access) and make an API to ensure that modules don't overstep their granted permissions. It'll probably look a lot like node and npm, where you could add a module to your source and know that it can't access things it shouldn't. Pretty exciting stuff. It's a true merger of all languages together under one runtime.
That's true, but that's a class of exploits that is mostly impossible anyway (except in an embedded environment). Most systems that have an MMU ensure that no page is both writeable and executable, meaning you can't inject code. This forces attackers to use ROP.
"There is unfortunately one less straightforward way that attackers can access another module’s memory—side-channel attacks like Spectre. OS processes attempt to provide something called time protection, and this helps protect against these attacks. Unfortunately, CPUs and OSes don’t offer finer-than-process granularity time protection features."
"[snip] Making a shift to nanoprocesses here would take careful analysis."
"But there are lots of situations where timing protection isn’t needed, or where people aren’t using processes at all right now. These are good candidates for nanoprocesses."
"Plus, as CPUs evolve to provide cheaper time protection features, WebAssembly nanoprocesses will be in a good position to quickly take advantage of these features, at which point you won’t need to use OS processes for this."
I'm particularly interested in a world where wasm binaries replace (or supplement) containers (or even VMs?). I'm specifically imagining Kubernetes or AWS Lambda but with direct wasm execution (instead of wasm-in-container or wasm-in-VM). I'd be curious if anyone has put more thought into this and what possibilities they envision.
I am very interested in the inter "process" comm (or, inter "module" comm to be precised). From the surface, this runtime and modular system look pretty similar to the based OSGi runtime plus OSGi security. Not that I wanted to scare folks here as OSGi has a bad reputation of being bloated :-)
You can use a security manager and define permission on what the loaded java code can do.
Unfortunately, it's fraught with danger because of the confused lieutenant issue ( you'd need to give parts of the app permission but not others - doing so isn't trivial).
Just to help others searching for "confused lieutenant," I believe it's usually known as the "confused deputy problem," perhaps as a reference to Barney Fife. I do like the image of a confused lieutenant though.
Fantastic!
Since I made quite a few Silverlight RIAs, WASM is like Silverlgitht on steroids.
I am surprised that Uno Platform is not a founding member of the Alliance. AFAIK, they are the most devoted group for WASM (hope not offending you). I use Uno Platform to make WASM apps with ease and pleasure. The current major issue is the long startup time. Hope there will be a significant improvement in this area soon.
Is there a plan to bring together a bunch of these extensions under one roof with a package/dependency manager similar to cargo or npm, or is it intended to be glued together on the developer side? To me this looks massive, like to be able to pull down modules knowing what permissions they need, and to be able to have some kind of assurances that the code can't misbehave.
Imagine extensions for applications or databases, written in any language you want, with no ability to exfiltrate data. Imagine supporting a safe plugin API that isn't just for C and languages that FFI to C, but works natively with safe datatypes.
Today, if you want to be extensible, you typically expose a C API for people to link to, or you embed a specific language like Lua or Python. Imagine embedding a WebAssembly runtime like wasmtime, and telling people they can write their extensions in any language they want.