[elihu]

I think unikernels make sense in conjunction with languages like Rust. If your compiler is making sure it won't generate code that could cause a segfault, the run-time checks to do the same are unnecessary overhead.

(There are, of course, some details that would need to be worked out like how to handle unsafe code blocks, how to run programs written in unsafe languages, and how to enforce a policy of only executing code compiled with a trusted compiler, but none of these seem like fundamentally insurmountable obstacles and the benefits of being able to make a system call without any more overhead than a function call are pretty big for certain applications.)

[michaelmrose]

I think you misunderstand the benefits of rust if you believe that writing the whole OS in rust makes any other security pointless.

[elihu]

I'm assuming that applications are written in Rust as well and that the OS is configured to either refuse to run binaries compiled with an unknown compiler or it runs them inside a CPU emulator.

And no, I don't think this solves all of the potential security problems that could exist. What it does accomplish (if you're willing to trust a compiler in the same way that we're expected to trust the MMU in our computers, which might not be warranted at this stage of the development of Rust) is that it solves the problem of one program reaching into another program's address space when it isn't supposed to.

Strictly speaking, it would be more secure to have both compiler-enforced protections and an MMU, so that a compiler bug won't compromise the whole system. It is, however, at least theoretically possible to have secure process isolation without relying on an MMU. That's a big deal, because context switches are expensive and if there's a way to get the same safety without the overhead, someone is likely to build a system that takes advantage of that.