> Rust's memory model largely makes those isolated address spaces unnecessary,

I think you're confusing several concepts. Rust's "memory model" is the C++11 memory model. Maybe you meant the borrow checker and the distinction between shared and exclusive references? Yes, those make it much harder to accidentally screw up other parts of your address space, but it's downright trivial to do it on purpose – you just need an unsafe block and std::ptr::write.

There's nothing about Rust that could replace isolated address spaces. Rust is typically compiled to native machine instructions, there's no sandbox or virtual machine that will protect different modules from each other.

I meant the ownership model.

I'm also imagining a usage model where all the various components of the microkernel come from the same place and have passed various minimum standards like "doesn't have any unsafe blocks". If some program really needs an unsafe block to do something, then that goes into a (hopefully small) library of heavily-scrutinized functions that do dangerous things but expose safe interfaces.

If we compare with the Linux kernel: in Linux, any part of the kernel can clobber memory in any other part; there's no protection at all. Users generally accept that because the Linux kernel is a pretty well-run project, but still bugs slip in from time to time. If instead you imagine a system where the compiler simply doesn't allow one part of the kernel to clobber memory that belongs to some other part, that would be a significant improvement over what Linux offers.

Anyways, security mechanisms don't necessarily have to be enforced at run-time if they can be enforced at compile-time. That assumes you compile the code yourself with a trusted compiler, or you get the binaries from a trusted source. (Though unfortunately Spectre has become a big problem for compiler-enforced data isolation within one big shared address space; I'm not sure whether compilers these days can do code generation in such a way that it doesn't suffer from sidechannel attacks, or if for the foreseeable future it's just something that software developers have to be wary of.)

In theory you might eventually be able to run device drivers from random people or run arbitrary applications in the same address space as the kernel, but that would require a lot of faith in the compiler to reject anything that could be a security hole. It's an interesting model, though; a pure unikernel approach everything shares the same page tables and there's no need to swap them in or out when context switches happen. And invoking a system call can be as cheap as executing an ordinary function. It might even be inlined by the compiler.

> If some program really needs an unsafe block to do something, then that goes into a (hopefully small) library of heavily-scrutinized functions that do dangerous things but expose safe interfaces.

Device drivers make up the largest part of the Linux kernel, and they would by necessity contain lots of unsafe blocks – the compiler can't reason about the interaction with some device. This is typically different from device to device, and there's no way this could be separated into a small library or module.

Look, I agree that a kernel written in Rust could be much safer than one written in C, and even those instances of 'unsafe' blocks would be easier to audit than C's "everything is unsafe". But it still couldn't replace all the advantages you get from micro-kernels with separate address spaces.

For example, it's impossible in Rust to safely unload a dynamically loaded library. The reason for this is, that such a library could contain static data, like string literals, which are of type &'static str. Passing a 'static reference from the library to the program doesn't require 'unsafe', but will leave a dangling reference when you unload the library. Of course, the unloading operation is itself 'unsafe', but that doesn't help you prevent, locate, or track the transfer of a 'static reference.

Exactly. Looking towards the language to keep you safe is essentially client side security, it's the memory model that isn't safe: dumping everything in on executable allows for all kinds of tricks to be performed. Only a micro kernel has with the present architectures the ability to isolate one driver from another in such a way that those drivers can not accidentally or purposefully attack each others address space.

Another advantage is that there is no such thing as a kernel crash, worst case you get a device driver that needs restarting. The whole loadable module model is broken by design and replicating it in Rust isn't going to solve that particular problem (and it isn't one that Rust is trying to solve).

The point was to use compile-time checks instead of a MMU to separate kernel services.

The concept is interesting (if maybe untested) it allows to have explicit opt-in sharing while blocking accidental sharing

> The point was to use compile-time checks instead of a MMU to separate kernel services.

Rust's compile time checks cannot replace the MMU. There were experimental SAS (single address space) operating systems which didn't depend on the MMU for protection, but they used "managed" languages, i.e., all code was executed in a sandboxed JIT.

I think we have to assume that people aren't putting malicious code into the kernel, don't we?

But that's one of the big promises of micro-kernels: You don't have to have 100% trust in the driver for that gamepad you bought from some unknown company.

What about that WiFi driver with 10,000s of lines of code? Are you absolutely sure there isn't some code in it that accidentally or purposefully leaks the rest of your kernel data structures to the outside world? With drivers in their own isolated address space, you wouldn't have to be.

That was the point behind Singularity OS[1] IIRC. Using managed code which could be verified safe by the OS using static analysis.

Can't find it right now, but I recall reading they implemented a network driver with minimal overhead compared to a traditional OS. While they used message passing, a lot of overhead could be eliminated due to the assumptions of safe code.

[1]: https://en.wikipedia.org/wiki/Singularity_%28operating_syste...

Message passing by itself doesn't have to be slow (you can use the paging subsystem for this purpose), but you are looking at two more context switches per system call.

The kernel will have a lot of "unsafe" (the keyword) code.