[systemd-devel] Authenticated Boot: dm-integrity modes

[Adrian Vovk]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20211128/7baaae77/attachment.htm>