[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