Hello,
I've been doing some planning to actually implement the authenticated boot process proposed by Lennart. My distro uses ostree, so the limitations of dm-verity are making this much more difficult than it could have been. Hence, I've been reading up on dm-integrity and its various modes. However, none of the modes available strike me as particularly appealing for the use-cases described in the blog post:
- Direct mode: seems brittle. A poorly-timed crash can cause the integrity check to start failing when it shouldn't be. And there's no way to differentiate between a crashed system and an attacker, so to protect the user I'd have to basically condemn the whole OS installation (forcing the user to reinstall the OS). The situation I'm envisioning goes like this:
1. Something somewhere writes a file
2. In response, Btrfs updates one of its structures and writes it to dm-integrity
3. dm-integrity writes the data to disk and starts recalculating the hash
4. At this moment, the system crashes. dm-integrity never gets to write the new hash
5. The system reboots, unlocks dm-integrity and tries to mount the fs
6. Btrfs reads through its structures and encounters the bad hash, causing an I/O error
7. The OS fails to mount the rootfs and bails on the boot
- Journal mode: is slow. It atomically writes data+hash, so the situation I describe above can never happen. However, to pull this off it writes the data twice. Effectively every layer of journaled dm-integrity will cut write speeds in half. This isn't too bad to protect the rootfs since writes there will be rare, but it is terrible for /home. Layering systemd-homed's LUKS+dm-integrity image on top of that will cut performance in half again. So with the whole setup proposed by the blog post (even with dm-verity) writes to home will be limited to 1/4 of the drive's performance and the data will be written four times over. On top of performance issues, won't writing the data 4x wear out SSDs faster? Am I missing something?
- Bitmap mode: seems insecure. From my understanding, an attacker can just modify the data and then set the right bit in the bitmap. Then, on activation dm-integrity will decide that the system must have crashed, recalculate a new hash, and accept the malicious data as valid. This mode seems ideal to find hardware errors, not malicious modifications. I might be wrong, though: is there anything protecting the bitmap from arbitrary modifications?
What are your thoughts on these points? What mode did you plan to have systemd-homed use?
Regards,
Adrian Vovk
