Re: Immutable Images: Single Data Patition

[Lennart Poettering <mzqohf@xxxxxxxxxxx>]

On Do, 02.03.23 16:59, Adrian Vovk (adrianvovk@xxxxxxxxx) wrote:

> > /home/ with dm-integrity or OPAL for trust, TPM-bound, with homed managed homedirs inside that do encryption
>
> How big is the dm-integrity write performance hit? My understanding is
> that it is 2x slower, though I don't recall where I got this info.

Depends on your CPU and write patters I guess. (i.e. the hit is much
smaller as long as your access remain local) But it's certainly
slower, yes.

> Maybe it'd be more beneficial to push through authenticated BTRFS into
> the kernel and only support BTRFS on the unencrypted home partition?

This would be a much much weaker security model, to the point I
personally think it's useless.

btrfs is a complex beast, and the kernel fs maintainers made very
clear that they do not consider their code safe against rogue fs
images, that they do not consider this a valid attack surface they
protect against.

This means you need to establish trust *below* the file system, not
above. This means the authentication must be below btrfs, not in
btrfs, it's too late then.

But this all depends against what you want to protect yourself. If you
want to make it hard to exploit your kernel from a disk image someone
else might have gotten access to then avoiding
dm-verity/dm-integrity doesn't really work.

> > And suddenly we'd have a spec that would be particularly powerful
> > and generic: you could use it for subvols, for dirs, or for
> > loopback files, and mix and match freely, and it would always
> > behave somewhat the same way
>
> Makes sense. Is there someone I can collaborate with and/or somewhere
> to go to talk about this and maybe get that TODO resolved &
> implemented?

maybe file a github issue to discuss this in.

That said, I have started implementing something along these lines,
will file PR shortly I guess.

> > dm-linear
>
> Would we be able to reclaim the data if the partition shrinks?

Sure, this concept would always extend things at the end, and thus if
the disk space is not needed anymore it's sufficient to shrink the fs,
and get rid of the extensions again.

> How would we manage the size of the filesystem? Overcommit it to the
> size of the extension partition, but keep it minimal on disk? Have
> adjustable headroom? Will we expect the user to adjust the headroom?

note that btrfs is your only option for a model like this, as only
btrfs allows online shrink (xfs allows no shrinking at all, and ext4
only offline shrink + online grow).

The problem with all issues like this is that they are async: i.e. we
can watch the disk space usage and grow and shrink, but if some code
immediately needs something it might fail because we didn't notice.

Ideally, we would be able to tell btrfs natively "hey, so if you need
more space, feel free to extend the fs up to a size of X GB as you see
fit" or so.

Lennart

--
Lennart Poettering, Berlin