>Why not put the effort into a great MMU
The people who are writing for OpenBSD can not "put their effort" into hardware changes to entire platforms.
They can do something to improve their own OS, however.
If it's just an interpreter, then the "sort-of executable" is just data being read, and the page can stay write-only.
We used to have that, they're called segments.
https://en.wikipedia.org/wiki/Intel_iAPX_432#Object-oriented...
EDIT: There's a passing mention in a book [1]
> The Intel i960 extended architecture processor used a tagged architecture with a bit on each memory word that marked the word as a "capability", not as an ordinary location for data or instructions. A capability controlled access to a variable-sized memory block or segment. The large number of possible tag values supported memory segments that ranged in size from 64 to 4 billion bytes, with a potential 2^256 different protection domains.
[1] https://books.google.co.uk/books?id=O3VB-zspJo4C&pg=PA189#v=...
EDIT: Now that I'm on a PC I've added the link here for you. Copy and paste of PDF's is a b on my mobile. ;)
https://en.wikipedia.org/wiki/Intel_i960
http://bitsavers.org/pdf/biin/BiiN_CPU_Architecture_Referenc...
There's some fascinating stuff in here. For example:
> 8.4 Object Lifetime
> To support the implicit deallocation of certain objects while preventing dangling references, the object lifetime concept is supported. The lifetime of an object can be local or global. "Local" objects have a lifetime that is tied to a particular program execution environment [...]. "Global" objects are not associated with a particular execution environment.
> Each job has a distinct set of local objects. No two jobs can have ADs [access descriptors] that reference the same local object. The processor does not allow an AD for a local object to be stored in a global object. Thus, when a job terminates, all the local objects associated with a job can be safely deallocated, and there cannot be any dangling pointers.
The machine was designed, to run Ada programs. Does this line up with how memory management works in Ada? It certainly resembles how it works in Rust!
Btw, since Im on mobile w/out links, type these into Google: capability computer systems book Levy; Army Secure Operatimg System ASOS. First is great book with many capability architectures like i432. Second is another HW and OS combo designed as secure foundation for embedded, Ada apps. It was interesting.
Do you perhaps mean "every allocation is its own address space"? I guess that would require pointers that are double the size of regular pointers (the first half pointing to the address space, and the second half being an index into that space).
These kind of protections are for widespread use protecting legacy codebases they don't want to straight up fix or take performance hit of tools like Softbound+CETS. Incidentally, tradeoffs like that usually fail. ;)