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: <89fe49aa-4c7c-42ef-a59c-c962f4403145@gmail.com>
Date: Mon, 7 Oct 2024 10:25:56 +0200
From: Milan Broz <gmazyland@...il.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: Eric Biggers <ebiggers@...nel.org>, 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/7/24 7:45 AM, Christoph Hellwig wrote:
> On Fri, Oct 04, 2024 at 09:21:47PM +0200, Milan Broz wrote:
>> 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.
> 
> As should any other stackable crypto driver, so that's not an argument
> per se.  Allowing to bypass encryption in a lower layer is simply
> broken, no matter what you call the target.

I am talking from the security point of view. Now, dm-crypt does not trust
storage devices. Storage devices will never see plaintext (or key).
With inline crypto, it needs to see both.

My goal is to mitigate these risks completely with dm-crypt, while clearly
saying dm-inlinecrypt will have a different threat model.

(Yes, if inline crypto is used through crypto API, we have the same problem,
but you can mitigate it by turning off specific crypto modules.)

You are right that such a system is broken, but it is too late if it leaks.

I see several self-encryption hardware where it was so broken that vendors
basically say, "use sw crypto" but this will not stop users from using it
in a broken state.

Milan