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@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. 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. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
