A pretty reasonable summary of things from an outside perspective - have my thumbs up ;)

(And a very good question, to be answered at a later stage.)

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.

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.

I haven't come across this specific feature before. From reading about it, it seems closely related to Arm (E)MTE ISA extensions - Memory Tagging Extension?

What's interesting is that approach (software-defined 'random' numbers to associate memory regions and valid pointers) provides only probabilistic memory safety. A malicious actor may find a way to spoof/guess the tag needed to access a particular piece of memory. Given Arm MTE has been breached in the last year, it's hard to argue that it's a good enough security guarantee. EMTE may fix issues (e.g. side-channels) but leaves open the probabilistic pathway (i.e. "guess the tag") which is a hole MTE isn't designed to try to close (so, a software breach on top of a chip with EMTE can't necessarily be argued to be a violation of the hardware's security properties, though it may exploit the architectural security hole).

In contrast, CHERI and OMA (Object Memory Architecture) are both providing hardware-enforced guarantees of memory safety properties - unbreakable even if the attacker has perfect knowledge - backed up by formal proofs of these claims.

CHERI offers referential and spatial safety as hardware guarantees, with temporal being achievable in software. OMA offers referential, spatial and temporal safety as hardware guarantees.

Also the discussion for Apple “Memory Integrity Enforcement” announcement https://news.ycombinator.com/item?id=45186265 , which attracted CHERI people like jrtc27 .

Yep air-gapped security is a thing. But servicing, patching and communicating with air-gapped devices still needs to happen, which involves connecting to them somehow. Likely a manufacturing plant has started to connect everything together to streamline the process and created an attack surface that way.

You can see the appeal for not needing to go through all the issues, complexity and costs that entails.

I suppose we could all do what Asahi have been forced to do and go back to using pens, paper and fax machines: https://www.bbc.co.uk/news/articles/cly64g5y744o

Malware can hop through airgaps on USB keys, so that's not enough: https://en.wikipedia.org/wiki/Stuxnet

How else do you expect to move the information around between sites and use it?

My interpretation, going off on the linked integrated GC research: extensions to the ISA and thus compiler backend, no modifications to 'well formed' applications, some changes to the language runtime dealing with memory management.

Unless the CPU hardware becomes some kind of hybrid monster with both OMA and traditional paged MMU, you will need to make changes to the kernel. You may be able to emulate some of the kernel's page table shenanigans with the object-based system, but I don't think that the kernel's C code is typically 'well-formed'. It's probably a lot of engineering effort to make the necessary kernel changes, but so are all those complex kernel hardening efforts that hardware-level memory security like OMA would render moot.

Fil-C is basically CHERI in software, with large speed and memory overhead.