<div dir="ltr"><div style="color:rgb(0,0,0)">Hello,</div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)"><span style="white-space:pre-wrap">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</span>, 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:</div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">- 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:</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div style="color:rgb(0,0,0)">1. Something somewhere writes a file</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div style="color:rgb(0,0,0)">2. In response, Btrfs updates one of its structures and writes it to dm-integrity</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div style="color:rgb(0,0,0)">3. dm-integrity writes the data to disk and starts recalculating the hash</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div style="color:rgb(0,0,0)">4. At this moment, the system crashes. dm-integrity never gets to write the new hash</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div style="color:rgb(0,0,0)">5. The system reboots, unlocks dm-integrity and tries to mount the fs</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div style="color:rgb(0,0,0)">6. Btrfs reads through its structures and encounters the bad hash, causing an I/O error</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div style="color:rgb(0,0,0)">7. The OS fails to mount the rootfs and bails on the boot</div></blockquote><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">- 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?</div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">- 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? </div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">What are your thoughts on these points? What mode did you plan to have systemd-homed use?</div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">Regards,</div><div style="color:rgb(0,0,0)">Adrian Vovk</div></div>