3 ms·
Hardware protection rings are a holdover from a time when we didn't have program formats that could be statically transformed and verified to do exactly what th
by _wmd 8y ago
Hardware protection rings are a holdover from a time when we didn't have program formats that could be statically transformed and verified to do exactly what the operator desires. They have a nonzero performance overhead even when implemented in hardware, and in an ideal design should not be required at all
Re: your followup about defensive in depth, this is a common and frankly boring fallback argument. At some point computers had much less reliable internals, and for example even the result of strlen () could vary across runs. Should we also perpetually account for the presence of unreliable registers or memory too?
- IncRnd 8y agoThat doesn't apply to this discussion. What program verification or analysis were performed on this system? My position about defense in depth is not a fallback argument. It was my original point.
- kllrnohj 8y ago> when we didn't have program formats that could be statically transformed and verified to do exactly what the operator desires. Which we still don't. Rowhammer, spectre/meltdown, etc... proved that even if the code doesn't violate any sandbox constraints that doesn't mean it didn't violate everything the sandbox was attempting to protect. Hardware isolation is still very important and very necessary, now more than ever.
- deleted 8y ago[deleted]
- _wmd 8y agoJFC. The reason the bugs you refer to are so important is because they /spanned/ hardware protection domains.
- kllrnohj 8y agoYes, which means they also spanned software protection domains. Meaning your software protection didn't work, regardless of how "verifiable" the bytecode is. And a few of those so far have no known software protection domain fix, relying instead of hardware domains (eg spectre, which is why Chrome pushing site isolation hard - because they can't fix the software protection and are relying on hardware ones instead)