| Message ID | 20241018184339.66601-1-ebiggers@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | dm-default-key: target for filesystem metadata encryption | expand |
On Fri, 18 Oct 2024, Eric Biggers wrote: > This series adds "metadata encryption" support to ext4 and f2fs via a > new device-mapper target dm-default-key. dm-default-key encrypts all > data on a block device that isn't already encrypted by the filesystem. > > Except for the passthrough support, dm-default-key is basically the same > as the proposed dm-inlinecrypt which omits that feature > (https://lore.kernel.org/dm-devel/20241016232748.134211-1-ebiggers@kernel.org/). > > I am sending this out for reference, as dm-default-key (which Android > has been using for a while) hasn't previously been sent to the lists in > full, and there has been interest in it. However, my current impression > is that this feature will need to be redesigned as a filesystem native > feature in order to make it upstream. If that is indeed the case, then > IMO it would make sense to merge dm-inlinecrypt in the mean time instead > (or add its functionality to dm-crypt) so that anyone who just wants > "dm-crypt + inline encryption hardware" gets a solution for that. I we merge dm-inlinecrypt, we can't remove it later because users will depend on it. I think it is not sensible to have two targets (dm-inlinecrypt and dm-default-key) that do almost the same thing. I've got another idea - what about a new target "dm-metadata-switch" that will take two block devices as arguments and it will pass metadata bios to the first device and data bios to the second device - so that the logic to decide where the bio will go would be decoupled from the encryption. Then, you can put dm-crypt or dm-inlinecrypt underneath "dm-metadata-switch". ---------------------- | filesystem | ---------------------- | V ---------------------- | dm-metadata-switch | ---------------------- | | V | ------------ | | dm-crypt | | ------------ | | | V V ------------------------- | physical block device | ------------------------- Mikulas
On Mon, Oct 21, 2024 at 01:52:58PM +0200, Mikulas Patocka wrote: > On Fri, 18 Oct 2024, Eric Biggers wrote: > > > This series adds "metadata encryption" support to ext4 and f2fs via a > > new device-mapper target dm-default-key. dm-default-key encrypts all > > data on a block device that isn't already encrypted by the filesystem. > > > > Except for the passthrough support, dm-default-key is basically the same > > as the proposed dm-inlinecrypt which omits that feature > > (https://lore.kernel.org/dm-devel/20241016232748.134211-1-ebiggers@kernel.org/). > > > > I am sending this out for reference, as dm-default-key (which Android > > has been using for a while) hasn't previously been sent to the lists in > > full, and there has been interest in it. However, my current impression > > is that this feature will need to be redesigned as a filesystem native > > feature in order to make it upstream. If that is indeed the case, then > > IMO it would make sense to merge dm-inlinecrypt in the mean time instead > > (or add its functionality to dm-crypt) so that anyone who just wants > > "dm-crypt + inline encryption hardware" gets a solution for that. > > I we merge dm-inlinecrypt, we can't remove it later because users will > depend on it. I think it is not sensible to have two targets > (dm-inlinecrypt and dm-default-key) that do almost the same thing. The code would not need to be duplicated, though. E.g. dm-default-key functionality could be added as an enable_passthrough option to dm-inlinecrypt. Or the same .c file could register both targets sharing most of the same code. > I've got another idea - what about a new target "dm-metadata-switch" that > will take two block devices as arguments and it will pass metadata bios to > the first device and data bios to the second device - so that the logic > to decide where the bio will go would be decoupled from the encryption. > Then, you can put dm-crypt or dm-inlinecrypt underneath > "dm-metadata-switch". > > ---------------------- > | filesystem | > ---------------------- > | > V > ---------------------- > | dm-metadata-switch | > ---------------------- > | | > V | > ------------ | > | dm-crypt | | > ------------ | > | | > V V > ------------------------- > | physical block device | > ------------------------- Would this have any use case other than what dm-default-key does? Keep in mind that dm-metadata-switch would have to pass through all sector addresses unchanged. So if you wanted to reuse this to actually put your filesystem metadata on one disk and data on another, this wouldn't be very effective at that, as both data and metadata would take up the full space. - Eric