All of
 help / color / mirror / Atom feed
From: Christoph Hellwig <>
To: Eric Biggers <>
Cc: Israel Rukshin <>,
	Max Gurtovoy <>,
	dm-devel <>, Nitzan Carmi <>,
	Milan Broz <>
Subject: Re: [dm-devel] [RFC PATCH 0/1] Add inline encryption support for dm-crypt
Date: Tue, 18 Jan 2022 21:18:26 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <YecXNYm63BL50hFL@sol.localdomain>

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

  reply	other threads:[~2022-01-19  5:18 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-13 18:09 [dm-devel] [RFC PATCH 0/1] Add inline encryption support for dm-crypt Israel Rukshin
2022-01-13 18:09 ` [dm-devel] [PATCH 1/1] dm crypt: Add inline encryption support Israel Rukshin
2022-01-14  8:06   ` Damien Le Moal
2022-01-14  8:14   ` Damien Le Moal
2022-01-16 10:29     ` Israel Rukshin
2022-01-13 21:22 ` [dm-devel] [RFC PATCH 0/1] Add inline encryption support for dm-crypt Bart Van Assche
2022-01-14 20:51 ` Milan Broz
2022-01-14 22:27   ` Eric Biggers
2022-01-15  9:22     ` Milan Broz
2022-01-18 19:38       ` Eric Biggers
2022-01-19  5:18         ` Christoph Hellwig [this message]
2022-01-17  7:52   ` Christoph Hellwig
2022-01-17 10:50     ` Milan Broz
2022-01-17 14:00       ` Israel Rukshin
2022-01-18 16:45         ` Christoph Hellwig
2022-01-18 20:27           ` Eric Biggers
2022-01-19  5:15             ` Christoph Hellwig
2022-01-14 22:49 ` Eric Biggers
2022-01-16 10:15   ` Israel Rukshin
2022-01-18 20:02     ` Eric Biggers
2022-01-19 15:45       ` Israel Rukshin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.