Re:Apple’s big test of data integrity
by bobbylarrybobby on Tuesday May 30, 2023 @07:44PM
(#36132717)
What's the failure mode if you try to access modified data post boot? Something akin to a kernel panic?
I 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.
From 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
Yeah, 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.
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.