This series adds "metadata encryption" support to ext4 and f2fs via a
new device-mapper target dm-default-key.  dm-default-key encrypts all
data on a block device that isn't already encrypted by the filesystem.

Except for the passthrough support, dm-default-key is basically the same
as the proposed dm-inlinecrypt which omits that feature
(https://lore.kernel.org/dm-devel/20241016232748.134211-1-ebiggers@kernel.org/).

I am sending this out for reference, as dm-default-key (which Android
has been using for a while) hasn't previously been sent to the lists in
full, and there has been interest in it.  However, my current impression
is that this feature will need to be redesigned as a filesystem native
feature in order to make it upstream.  If that is indeed the case, then
IMO it would make sense to merge dm-inlinecrypt in the mean time instead
(or add its functionality to dm-crypt) so that anyone who just wants
"dm-crypt + inline encryption hardware" gets a solution for that.

Eric Biggers (4):
  block: export blk-crypto symbols required by dm-default-key
  block: add the bi_skip_dm_default_key flag
  dm-default-key: add target for filesystem metadata encryption
  ext4,f2fs: support metadata encryption via dm-default-key

 block/bio.c                 |   3 +
 block/blk-crypto-fallback.c |   2 +
 block/blk-crypto.c          |   3 +
 drivers/md/Kconfig          |  20 ++
 drivers/md/Makefile         |   1 +
 drivers/md/dm-default-key.c | 431 ++++++++++++++++++++++++++++++++++++
 fs/crypto/inline_crypt.c    |  14 +-
 fs/f2fs/data.c              |   6 +-
 include/linux/blk-crypto.h  |  36 +++
 include/linux/blk_types.h   |   3 +
 include/linux/fscrypt.h     |  14 ++
 11 files changed, 531 insertions(+), 2 deletions(-)
 create mode 100644 drivers/md/dm-default-key.c


base-commit: c964ced7726294d40913f2127c3f185a92cb4a41
-- 
2.47.0

On Fri, 18 Oct 2024, Eric Biggers wrote:

> This series adds "metadata encryption" support to ext4 and f2fs via a
> new device-mapper target dm-default-key.  dm-default-key encrypts all
> data on a block device that isn't already encrypted by the filesystem.
> 
> Except for the passthrough support, dm-default-key is basically the same
> as the proposed dm-inlinecrypt which omits that feature
> (https://lore.kernel.org/dm-devel/20241016232748.134211-1-ebiggers@kernel.org/).
> 
> I am sending this out for reference, as dm-default-key (which Android
> has been using for a while) hasn't previously been sent to the lists in
> full, and there has been interest in it.  However, my current impression
> is that this feature will need to be redesigned as a filesystem native
> feature in order to make it upstream.  If that is indeed the case, then
> IMO it would make sense to merge dm-inlinecrypt in the mean time instead
> (or add its functionality to dm-crypt) so that anyone who just wants
> "dm-crypt + inline encryption hardware" gets a solution for that.

I we merge dm-inlinecrypt, we can't remove it later because users will 
depend on it. I think it is not sensible to have two targets 
(dm-inlinecrypt and dm-default-key) that do almost the same thing.

I've got another idea - what about a new target "dm-metadata-switch" that 
will take two block devices as arguments and it will pass metadata bios to 
the first device and data bios to the second device - so that the logic 
to decide where the bio will go would be decoupled from the encryption. 
Then, you can put dm-crypt or dm-inlinecrypt underneath 
"dm-metadata-switch".

----------------------
|     filesystem     |
----------------------
          |
          V
----------------------
| dm-metadata-switch |
----------------------
      |           |
      V           |
------------      |
| dm-crypt |      |
------------      |
      |           |
      V           V
-------------------------
| physical block device |
-------------------------

Mikulas

On Mon, Oct 21, 2024 at 01:52:58PM +0200, Mikulas Patocka wrote:
> On Fri, 18 Oct 2024, Eric Biggers wrote:
> 
> > This series adds "metadata encryption" support to ext4 and f2fs via a
> > new device-mapper target dm-default-key.  dm-default-key encrypts all
> > data on a block device that isn't already encrypted by the filesystem.
> > 
> > Except for the passthrough support, dm-default-key is basically the same
> > as the proposed dm-inlinecrypt which omits that feature
> > (https://lore.kernel.org/dm-devel/20241016232748.134211-1-ebiggers@kernel.org/).
> > 
> > I am sending this out for reference, as dm-default-key (which Android
> > has been using for a while) hasn't previously been sent to the lists in
> > full, and there has been interest in it.  However, my current impression
> > is that this feature will need to be redesigned as a filesystem native
> > feature in order to make it upstream.  If that is indeed the case, then
> > IMO it would make sense to merge dm-inlinecrypt in the mean time instead
> > (or add its functionality to dm-crypt) so that anyone who just wants
> > "dm-crypt + inline encryption hardware" gets a solution for that.
> 
> I we merge dm-inlinecrypt, we can't remove it later because users will 
> depend on it. I think it is not sensible to have two targets 
> (dm-inlinecrypt and dm-default-key) that do almost the same thing.

The code would not need to be duplicated, though.  E.g. dm-default-key
functionality could be added as an enable_passthrough option to dm-inlinecrypt.
Or the same .c file could register both targets sharing most of the same code.

> I've got another idea - what about a new target "dm-metadata-switch" that 
> will take two block devices as arguments and it will pass metadata bios to 
> the first device and data bios to the second device - so that the logic 
> to decide where the bio will go would be decoupled from the encryption. 
> Then, you can put dm-crypt or dm-inlinecrypt underneath 
> "dm-metadata-switch".
> 
> ----------------------
> |     filesystem     |
> ----------------------
>           |
>           V
> ----------------------
> | dm-metadata-switch |
> ----------------------
>       |           |
>       V           |
> ------------      |
> | dm-crypt |      |
> ------------      |
>       |           |
>       V           V
> -------------------------
> | physical block device |
> -------------------------

Would this have any use case other than what dm-default-key does?

Keep in mind that dm-metadata-switch would have to pass through all sector
addresses unchanged.  So if you wanted to reuse this to actually put your
filesystem metadata on one disk and data on another, this wouldn't be very
effective at that, as both data and metadata would take up the full space.

- Eric