[dm-devel] [RFC PATCH 0/1] Add inline encryption support for dm-crypt

[Eric Biggers]

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@google.com/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@google.com/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