3 ms·
I expect OSes to be compartimentalized similarly. There’s no way to manage a system with 2^trillions of states otherwise. For example, memory protection mechan
by Someone 5y ago
I expect OSes to be compartimentalized similarly. There’s no way to manage a system with 2^trillions of states otherwise.
For example, memory protection mechanisms can be used to protect boot code from tampering, a level above that the core OS used for ‘just above reinstall’ recovery can use a different protection regime, the OS proper allows user modifications after sudo, but otherwise is protected from user processes, etc.
Actually, even without disk space being memory mapped I think the MMU (and robust disk drivers) are what gives you that high probability of the file system staying intact when a process goes rogue. It used to be fairly common to lose a disk because some runaway process trashed the in-memory cache of essential on-disk data structures, and the OS than (blissfully unaware of the damage) flushed the incorrect data to disk.
- theamk 5y agoHaving the per-app compartments, recovery partition, or sudo-only memory is not going to help you if your text editor crashes, and loses all your documents. Or if photo app crashes and loses all the photos you ever had. What you really want is some sort of generic "document" abstraction. So that user app can specify intent (read or write or update) and a document name, and system will enforce it. This way if your photo app gets damaged, the "blast radius" is limited only to the "documents" which are being edited now, which will hopefully be very close to zero. Hm.. I wonder what this sounds like? :) (also: I used MS-DOS (with no memory protection, but with SMARTDRV disk cache) a lot, and crashed it a lot, often by my own code. The disk corruption was not that frequent at all. And in the worst case, you could often recover most of the data with NDD. The viruses and disk failures were far more common causes of data loss)