Cervus: A WebAssembly subsystem for Linux

> Note that modern CPUs store a tag of the current "address space ID" next to the TLB line, thus the cost of the flushing is heavily reduced.

Yes, tagged TLBs are much better, but the overhead is still not negligible. You can check the microkernel literature for all of the inefficiencies encountered in modern CPUs, and a language-based OS would eliminate most of them because protection is moved into the language itself.

> Unless you mean swapping, this doesn't apply as x86_64 long mode requires paging to be enabled.

a) This benefits from better caching since there's only one set of page tables, and b) CPUs are designed around the common uses, so if this OS design catches on, you'll start seeing CPUs that don't require page tables.

I was aware of the Java CPUs, but somehow that seems less interesting. Maybe because at that point, it's not so different from any other CPU architecture.

Ling has the concept of hypercalls, as if you were running plain Linux on xen. So, it's less an actual unikernel and more like a skin that molds itself to xen, and looks like a unikernel.

So yes. But no.

Why do you claim this?

1. Hardware sandboxing (i.e., ring not-0) isn't much better, as seen by Meltdown.

2. Most production-ready UNIXish kernels have had support for running untrusted code (namely BPF bytecode) in the kernel for decades.

3. Do you really trust all the code currently running in ring 0 on your computer? In particular, do you trust the executable loader. which handles complex untrusted input? What's the line between "code" and "not code"?

4. On most desktop machines, there's a single user, and malware being unable to get to ring 0 isn't particularly stymied; it can still exfiltrate your files, stream your webcam, log into your bank, etc. Why is ring 0 more of a concern than untrusted code elsewhere? (In fact, on most Linux desktops, malware can wait until the user runs sudo, inject itself in, and then run insmod and get to ring 0 directly....)

5. These same machines make a practice of running untrusted, JITted JavaScript and WebAssemy all the time inside the same sandbox you think is too dangerous, and the sandbox works. Not perfectly, of course, but also certainly much better than, say, the Linux kernel protects itself from local privilege escalations. Why is the same software sandbox too dangerous for use in kernelspace?

> 1. Hardware sandboxing (i.e., ring not-0) isn't much better, as seen by Meltdown.

Meltdown was a single Intel bug, it did not occur on other CPU architectures or on AMD chips. It was a result of asynchronous permission checking and it is a side-channel disclosure (a non-write bug). It is objectively not as bad as the tens of thousands of buffer overruns and memory write vulnerabilities in software.

> 2. Most production-ready UNIXish kernels have had support for running untrusted code (namely BPF bytecode) in the kernel for decades.

Actually it is a security vulnerability as well. In fact, the Project Zero proof of concept for Variant 1 of Spectre was an attack on the BPF interpreter, not even a JIT, it's even worse with a JIT.

> 3. Do you really trust all the code currently running in ring 0 on your computer? In particular, do you trust the executable loader. which handles complex untrusted input? What's the line between "code" and "not code"?

There are levels of trust, of course. I trust the Linux kernel a heck of a lot more than, e.g. V8. And I work on V8. On the WebAssembly implementation. I didn't want to mention it, but yeah, no, I would not put my own code into the kernel.

> 4. On most desktop machines, there's a single user

Again, levels of trust. I would not, e.g. run most userspace software in the kernel, just because it's so broken it will probably bring down the system. All the other things you mention are made easier, not harder by running in the kernel.

> 5. These same machines make a practice of running untrusted, JITted JavaScript and WebAssemy all the time inside the same sandbox you think is too dangerous, and the sandbox works.

I don't want to scare you, but please don't labor under the assumption that web browsers are 100% secure. We have tons of bugs. I mentioned above that the WebAssembly implementation in Chrome is a lot of my work. We've had security vulnerabilities.

> Not perfectly, of course, but also certainly much better than, say, the Linux kernel protects itself from local privilege escalations. Why is the same software sandbox too dangerous for use in kernelspace?

Objectively, no, it isn't better than the Linux kernel. And yes, it is too dangerous. This is based on the hundreds of security bugs that I've been involved with while working on Chrome, and the hundreds more that I wasn't involved with, and the probably hundreds more that are hiding in there. Yes, we take security seriously, and we are very sober about this.