Re: [PATCH v2 1/3] dm-inlinecrypt: Add inline encryption support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux