linux-ext4 - Re: [RFC PATCH 0/4] dm-default-key: target for filesystem metadata encryption

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20241021191008.GB1395714@google.com>
Date: Mon, 21 Oct 2024 19:10:08 +0000
From: Eric Biggers <ebiggers@...nel.org>
To: Mikulas Patocka <mpatocka@...hat.com>
Cc: dm-devel@...ts.linux.dev, linux-block@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-fscrypt@...r.kernel.org,
	linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
	Md Sadre Alam <quic_mdalam@...cinc.com>,
	Israel Rukshin <israelr@...dia.com>,
	Milan Broz <gmazyland@...il.com>,
	Adrian Vovk <adrianvovk@...il.com>
Subject: Re: [RFC PATCH 0/4] dm-default-key: target for filesystem metadata
 encryption

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