On Sat, Jan 15, 2022 at 10:22:26AM +0100, Milan Broz wrote: > > Note that in the Android Common Kernels, there is already a dm target called > > "dm-default-key" which uses dm-crypt compatible syntax but uses blk-crypto > > (inline encryption) rather than the crypto API: > > https://android.googlesource.com/kernel/common/+/refs/heads/android-mainline/drivers/md/dm-default-key.c > > Any plans to submit this to mainline? Or it is just too controversial? > > > > > It differs slightly from what is being proposed here in that dm-default-key's > > purpose is to implement filesystem "metadata encryption", so it has logic to > > skip encrypting blocks that have their encryption controlled at the filesystem > > level due to being part of an encrypted file's contents. I expect that logic > > would be unacceptable upstream, as it's a layering violation. (The long-term > > plan is to handle metadata encryption entirely at the filesystem level instead.) > > Well, I wish that we have strong authenticated encryption in filesystem even for > metadata, where it fits better in the fist place.... > But fscrypt is still not here (or am I mistaken?) > I doubt that people would find Android's dm-default-key to be acceptable, given that it's a layering violation, and a similar approach was rejected in the past (https://lore.kernel.org/dm-devel/20170614234040.4326-1-mhalcrow@xxxxxxxxxx/T/#u). dm-default-key's purpose is filesystem metadata encryption; it encrypts all blocks that aren't already part of an encrypted file's contents. It differs from dm-crypt + fscrypt together (which the upstream kernel already supports) in that file contents aren't encrypted twice; this was a non-negotiable performance requirement. Obviously, this required a new flag in struct bio to indicate which bios are reading/writing from an encrypted file's contents. I doubt the block layer people would find that to be acceptable. In principle, the filesystem is the right place to implement metadata encryption in this way. This would also allow the kernel to enforce (via the key hierarchy) that fscrypt keys are never weaker than the metadata encryption key. Satya Tangirala previously implemented a proof of concept of this for f2fs (https://lore.kernel.org/linux-f2fs-devel/20201217150435.1505269-1-satyat@xxxxxxxxxx/T/#u). Unfortunately, Satya has left Google and no one is currently working on this. But it is still the long-term plan. Authenticated encryption is certainly desirable, but not really feasible to retrofit into filesystems that overwrite data in-place. (Yes, dm-integrity exists, but its performance impact is too much for the vast majority of users.) Even f2fs isn't entirely log-structured; it often overwrites blocks in-place. - Eric -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
