The kernel can't do only memory safe operations by definition. That's why we separated the kernel from userland. The two serious attempts at a Rust OS are Redux and Asterinas. And at least one of them tries to separate the kernel in two: part with unsafe Rust, part with safe Rust. The other uses a microkernel, which will never work, and completely mixes safe and unsafe Rust together. Again, a pure safe Rust kernel is theoretically impossible: the kernel must do unsafe memory operations just as basic operations. Example: A user program calls read(). The kernel must copy bytes from a kernel buffer into a pointer the user provided. That pointer could be: null, unmapped, a kernel address (privilege escalation attempt), and maybe something else. In any case, the kernel must do an unsafe instruction to that pointer to do its job. There is no safe version of this operation
Memory safety is largely misunderstood and the arguments of it's proponents mostly come from people that don't understand the basics.
Even "Permissions are attached to users, not capabilities" is a failure of basic comprehension. Why and how are capability-based systems an obvious upgrade? How much resources went into seL4, Fuchsia/Zircon and other attempts? It's not even clear that such systems are well-defined.
There's also a failure to understand the actual historic sources of security flaws. Major kernel exploits don't usually come from "a rarely-used USB driver" being isolated. They come from core subsystems (memory management, syscall handling, privilege transitions) that a microkernel still has in its privileged layer. So you're really fixing a non-existent theoretical flaw and trading that for a geometric increase in transactions and complexity.
