3 ms·
> During the boot process, unless boot security has been downgraded from Full Security, the contents of that SSV are verified against its tree of hashes. In the
by anyfoo 3y ago
> During the boot process, unless boot security has been downgraded from Full Security, the contents of that SSV are verified against its tree of hashes. In the event that they don’t match perfectly: “the startup process halts and the user is prompted to reinstall macOS”.
This is written a bit confusingly, if you don't already knows how it works (even though a later reply to a comment tries to clarify it). Because it sounds like the disk is fully and instantly validated at every boot, and "the startup process halts" if there is a mismatch.
Instead, depending a little on the actual implementation, most hashes will very likely only be validated when the corresponding block is actually accessed (up the entire path to the root, where the higher level hashes may be validated now or may have been validated already; this again is an implementation detail).
The result is also, that some blocks may never be validated during normal operation, simply if some files are never accessed. Unless there is some explicit whole disk validation sometime, e.g. during installation, though any corruption happening after that last "full disk check" will still lay dormant until access or the next full check.
But since this is a tree of hashes, it still provides all security and integrity benefits to anything that does get accessed. What never gets accessed does not matter per definition.
- bobbylarrybobby 3y agoWhat's the failure mode if you try to access modified data post boot? Something akin to a kernel panic?
- anyfoo 3y agoI don't know. I/O error and panic both make sense to me, but I'd say the latter only in specific situations. It seems unwarranted to me to panic the system when, say, a README.txt somewhere in the fs has a non-validating block.
- krackers 3y agoFrom https://support.apple.com/sr-rs/guide/security/secd698747c9/web https://support.apple.com/sr-rs/guide/security/secd698747c9/... >In case of mismatch, the system assumes the data has been tampered with and won’t return it to the requesting software. Whether this then leads to a kernel panic later on probably depends on if it's the kernel that needs this file, or a userspace process
- anyfoo 3y agoYeah, that's basically what I was getting at. For things like the root hash, it probably makes sense to panic (or otherwise impede boot), in order to have an early, more descriptive failure, than to later only implicitly access the root hash by validating the first accessed page of the init process (launchd, in macOS), and panicking with a less obvious I/O error reading launchd. In most situations, you likely just want the regular I/O error and then whatever happens downstream of that.