On 9/24/24 03:44, Christoph Hellwig wrote:
On Sat, Sep 21, 2024 at 11:55:19AM -0700, Eric Biggers wrote:
(https://android.googlesource.com/kernel/common/+/refs/heads/android-mainline/drivers/md/dm-default-key.c),
and I've been looking for the best way to get the functionality upstream. The
main challenge is that dm-default-key is integrated with fscrypt, such that if
fscrypt encrypts the data, then the data isn't also encrypted with the block
device key. There are also cases such as f2fs garbage collection in which
filesystems read/write raw data without en/decryption by any key. So
essentially a passthrough mode is supported on individual I/O requests.
Adding a default key is not the job of a block remapping driver. You'll
need to fit that into the file system and/or file system level helpers.
fscrypt isn't the only thing that would use such functionality. If you
put it in the filesystem layer then you're only serving fscrypt when
there are other usecases that don't involve filesystems at all.
Let's say I'm using LVM, so I've got a physical partition that stores a
couple different virtual partitions. I can use dm-default-key both
underneath the physical partition, and on top of some of the virtual
partitions. In such a configuration, the virtual partitions with their
own dm-default-key instance get encrypted with their own key and passed
through the lower dm-default-key instance onto the hardware. Virtual
partitions that lack their own dm-default-key are encrypted once by the
lower dm-default-key instance. There's no filesystem involved here, and
yet to avoid the cost of double-encryption we need the passthrough
functionality of dm-default-key. This scenario is constrained entirely
to the block layer.
Other usecases involve loopback devices. This is a real scenario of
something we do in userspace. I have a loopback file, with a partition
table inside where some partitions are encrypted and others are not. I
would like to store this loopback file in a filesystem that sits on top
of a dm-crypt protected partition. With the current capabilities of the
kernel, I'd have to double-encrypt. But with dm-default-key, I could
encrypt just once. Unlike the previous case, this time there's a layer
of filesystem between the block devices, but it still can't do anything:
the filesystem that stores the loopback device can't do anything because
it has no idea that any encryption is happening. fscrypt isn't being
used, nor can it be used since the file is only partially encrypted, so
the filesystem is unaware that the contents of the loopback file are
encrypted. And the filesystem doesn't know that it's encrypted from
below by its block device. So what can the filesystem do if, as far as
it can tell, nothing is being encrypted?
Best,
Adrian
