linux-kernel - Re: [RFC PATCH] dm-inlinecrypt: add target for inline block device 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <f335366a-3752-4272-8592-fe1ed9f43aee@gmail.com>
Date: Fri, 4 Oct 2024 21:21:47 +0200
From: Milan Broz <gmazyland@...il.com>
To: Eric Biggers <ebiggers@...nel.org>, Christoph Hellwig <hch@...radead.org>
Cc: dm-devel@...ts.linux.dev, linux-block@...r.kernel.org,
 linux-kernel@...r.kernel.org, Md Sadre Alam <quic_mdalam@...cinc.com>,
 Israel Rukshin <israelr@...dia.com>
Subject: Re: [RFC PATCH] dm-inlinecrypt: add target for inline block device
 encryption

On 10/4/24 8:48 PM, Eric Biggers wrote:
> On Thu, Oct 03, 2024 at 10:44:07PM -0700, Christoph Hellwig wrote:
>> On Thu, Oct 03, 2024 at 05:41:52PM -0700, Eric Biggers wrote:
>>> From: Eric Biggers <ebiggers@...gle.com>
>>>
>>> Add a new device-mapper target "dm-inlinecrypt" that is similar to
>>> dm-crypt but uses the blk-crypto API instead of the regular crypto API.
>>> This allows it to take advantage of inline encryption hardware such as
>>> that commonly built into UFS host controllers.
>>>
>>> The table syntax matches dm-crypt's, but for now only a stripped-down
>>> set of parameters is supported.  For example, for now AES-256-XTS is the
>>> only supported cipher.
>>
>> Maybe I'm stepping into a mine-field here, but if this simply uses
>> blk-crypto to accellerate a subset of dm-crypt, why isn't dm-crypt
>> simply enhanced to use blk-crypto when available?
>> compatible,
>>
> 
> Milan Broz (cryptsetup maintainer) has said that he prefers a separate dm
> target.  See
> https://lore.kernel.org/dm-devel/9ef95bbc-4eee-4c00-f199-0daa3cdd03ed@gmail.com/
> 
> That was a couple years ago though, and this discussion seems to have gone
> around in a circle.  Maybe things have changed.

There was another discussion recently. I also discussed this with Mikulas
as DM maintainer, and we agreed this is the best way.

Extending dm-crypt is possible, but the dm-crypt threat model should not allow
pushing plaintext down the level.
(I am currently investigating several issues with Opal hw encryption that just
cannot happen with sw dm-crypt. We opened can of worms supporting it in LUKS. :)

Actually, I like the inline encryption logic (and the sw fallback), just I would
prefer we clearly separate the code here (and dm-crypt is already complicated enough).

> A dm-crypt extension sounds fine to me too, though keep in mind there will
> eventually be inline crypto exclusive features such as hardware-wrapped keys.

Milan