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

Wol antlists at youngman.org.uk
Thu Dec 2 23:45:17 UTC 2021


On 02/12/2021 21:24, Adrian Vovk wrote:
> Hello Wol,
> 
> Please, read the blog post I'm responding to for context to what I'm
> saying: https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html
> 
>> dm-integrity is NOT ABOUT authentication
> dm-integrity provides authentication when configured to use
> sha256-hmac. I am not confusing dm-verity with dm-integrity.

Yup. Reading the blog makes it clearer ...

So HMAC provides integrity guarantees that it was written by users who 
knew the code, so I guess that is authentication.
> 
>> What if they're WRITTEN by things outside of the kernel? At which point, when the kernel tries to read it, things will go well pear-shaped for the system.
> Well that's my point. A clever attacker can modify the filesystem
> outside of the kernel and exploit a kernel vulnerability. The point of
> putting dm-integrity on the rootfs (in hmac mode) is to prevent the
> rootfs from being modified offline. My point is that it's entirely

> possible to maliciously modify other filesystems that *will* be
> mounted and *cannot* us dm-integrity

Understood ...
> 
>> You should always run dm-integrity on bare metal.
> Lennart was proposing to use dm-integrity (in HMAC mode) inside of the
> loopback image to verify that the filesystem inside of the image was
> not maliciously modified to hijack the kernel. My argument was that,
> given that the filesystem the image is stored on is authenticated, why
> does the content of the image have to be authenticated? As I've
> pointed out in a previous email, layering instances of dm-integrity on
> top of each other is catastrophic for write performance
> 
Seeing as it's a /home/user image I'd agree with you. If it's a rootfs, 
then that image needs to guarantee that the file-system hasn't been 
altered outside its own purview.

The only thing I don't understand is why layering dm-integrity in a loop 
device on top of dm-integrity on a real disk should necessarily hammer 
write performance. I can understand it chewing up ram cache and cpu, but 
it shouldn't magnify real writes that much.

Cheers,
Wol


More information about the systemd-devel mailing list