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

[Christoph Hellwig]

On Tue, Jan 18, 2022 at 11:38:29AM -0800, Eric Biggers wrote:
> 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.

Well, it was rejected because it pokes a hole into dm-crypt.  In a
purely inline crypto world a way to assign a key context if there is
none before is a little different, especially if it requires a different
setup than an unconditional encryption for the device.  It would also
not even require a flag.

> 
> 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.

Yes.  Especially in the inline crypto world it would seem just as
trivial to assign a default key in the file system itself.