Comment by onjectic
4 months ago
The MMU leads to horribly leaky operating system abstractions. IME it’s leaky due to the lack of separation between address space remapping(preventing fragmentation) and memory protection(security).
Perhaps unintentionally, RISC-V provides more flexibility to kernel developers by also including a physical memory protection unit that can run underneath and simultaneously with the MMU. This can make it far cheaper to switch memory protection on and off for arbitrarily sized areas of physical memory since this capability is no longer needlessly coupled to expensive memory remapping operations. Kernels can move away from the typical “process is its own virtual computer” model, and towards things closer to single address space designs or some middle ground between the two.
Thinking of bunny huang’s open source hardware efforts, a 28nm nommu system seems like a good long term open source target. How much complexity in the system is the mmu, and so how much complexity could we cut out while still having the ability to run third-party untrusted code?
1 Do you have benchmarks for the RISC-V "physical memory protection unit" and/or where can I read more? I'm looking ideally for things like type 1/2 hypervisor or Kernel tutorials for RISC-V to exemplify technical trade-offs. 2 Separation of virtual memory<->security sounds reasonable to offload security eventually to simpler and verified (and ideally eventually synthesized) hypervisors instead of complex Kernels, but I am wondering about capability and debugging limits. 3 The last sentence is very speculative and I dont get how that could be reached.
You can find more in the RISC-V privileged specification[1], section 3.7 I don't have any benchmarks and I think no such generalized benchmarks exists since its a specification and every core brings its own implementation (or none, its optional). With that said, its simple and probably effectively zero overhead, but its also much less capable than what a MMU can do. Its a "protect some firmware against the OS" or "absolute minimum hardware for some memory protection in a cheap MCU", not a competitor to full fat virtual memory.
[1]: https://docs.riscv.org/reference/isa/_attachments/riscv-priv...
What are examples of the MMU leading to poor abstractions? I agree it's not ideal, and encourages some poor abstractions, but I think it's moreso the case that mainstream operating systems have failed to innovate sufficiently. For example, the notion of a 1:1 bijection of address space and process doesn't have to be the case, but it is, I suppose, the most obvious use. (There is vfork(...), heh.)
> lack of separation between address space remapping(preventing fragmentation) and memory protection(security
Maybe segments weren't such a bad thing.