Nebulet is a microkernel that executes WebAssembly modules instead of ELF binaries. Furthermore, it does so in ring 0 and in the same address space as the kernel, instead of in ring 3. Normally, this would be super dangerous, but WebAssembly is designed to run safely on remote computers, so it can be securely sandboxed without losing performance.
Eventually, once the Cretonne compiler matures, applications running on Nebulet could be faster than their counterparts running on Linux due to syscalls just being function calls, low context-switch overhead, and exotic optimizations that aren’t possible on conventional operating systems.
How does this play together with things like Meltdown and Spectre, though? Some of the mitigations for those bugs are exactly on the syscall boundary.
I know that WebKit in particular has made some progress in their sandbox implementation to eliminate the use of branch instructions for any code performing security checks.
https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-for-webk…
My (limited) understanding of the way WebAssembly code works would lead me to believe if you completely eliminate branching in the underlying sandbox security model, you would automatically be immune to Spectre/Meltdown type attacks, at least at the underlying system level, because the sandbox is designed to keep anything from escaping it.
That doesn’t mean you couldn’t use such attacks within a sandbox (maybe? don’t know) to gain knowledge of other modules you shouldn’t have, but you still shouldn’t be able to use such knowledge to attack anything outside of your sandbox (because there are no mechanisms to allow you to escape it in the compiled code).
https://rsms.me/wasm-intro
https://webassembly.org/docs/security/
This is running WebAssembly instead of native code, so you can basically ask the same thing of native code. Since people tend to put a bunch of unverified native code into Ring0 anyway (in the form of blackbox drivers), running WebAssembly in Ring0 doesn’t sound crazy from a security perspective.
Yeah, they’re blackbox drivers, but they’re difficult to really get in an OS and loaded in a kernel. Webassembly would lower the bar to anyone thats able to get someone to go to a web page. Its significantly more risk.
With the difference that “native blackbox driver” are seldom by unknown sources and on-demand distributed over the internet.
Well, this is based on an experimental compiler cretonne.
https://github.com/cretonne/cretonne
That compiler has no mitigation for Specter/Meltdown. But it might in the future.
Which is absolutely irrelevant if everything is in ring0, isn’t it?
Web code in Ring 0. Nope, don’t do it, ain’t gonna happen, no, no, no, never!
Because sandbox…ahahahahahahahaha!
Not “Web code”, this is no different than any other os that is built on a virtual machine. The VM in this case is WebAssembly
When I run Java code, I don’t think the JVM is running on ring 0.
It is absolutely irrelevant in which “ring” somethings gets calculated – the speed is the same.
by the way is this “ring” nomenclature too intel specific….
the only thing that matters is how often to you need to switch between “rings” and/or address spaces.
Keeping everything in one address space is what all unikernels do. And there are enough JS/V8/WA engines (or any other runtime env.) on various unikernels already out there.
(rumprun, OSv, Mirage ,….)
but whatever of these you chose to run: you will better run it virtualized!
Do they not understand that WebAssembly is “sandboxed” because it is run in a separate process – a process that is executed at a higher ring than the kernel, and prevents arbitrary “communication” with other processes by being forced to make explicit system calls?