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/[email protected]/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 [email protected] https://listman.redhat.com/mailman/listinfo/dm-devel
