On Tue, Sep 24, 2024 at 12:44:53AM -0700, 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.
What about a block device ioctl, as was previously proposed (https://lore.kernel.org/linux-block/1658316391-13472-1-git-send-email-isra...@nvidia.com/T/#u)? > > It looks like this patch not only does not support that, but it ignores the > > existence of fscrypt (or any other use of inline encryption by filesystems) > > entirely, and overrides any filesystem-provided key with the block > > device's. At > > the very least, this case would need to be explicitly not supported > > initially, > > i.e. dm-inlinecrypt would error out if the upper layer already provided a > > key. > > I agree that we have an incompatibility here, but simply erroring out > feels like the wrong way to approach the stacking. If a stacking driver > consumes the inline encryption capability it must not advertise it to > the upper layers. Right, I missed that's actually already how it works. The crypto capabilities are only passed through if the target sets DM_TARGET_PASSES_CRYPTO. - Eric
