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] [day] [month] [year] [list]

Message-ID: <ZwT5SOkYRbOkeRRe@infradead.org>
Date: Tue, 8 Oct 2024 02:20:08 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Milan Broz <gmazyland@...il.com>
Cc: Christoph Hellwig <hch@...radead.org>,
	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 Mon, Oct 07, 2024 at 10:25:56AM +0200, Milan Broz wrote:
> 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.

With inline crypto as implemented right now the actual storage device
does not see the plaintext and key, only the storage controller that
is part of the SOC that Linux runs on.

> 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.)

That same could be done by requiring an explicit opt-in for using inline
crypto.  But yes, at that point just using a different target should
not be a major inconvenience.

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

Well, with the crazy mess that the TCG storage specs are the quality of
implementation of key management or even crypto algorithms that is
everything but unexpected.  One important feature of inline crypto
engines is that they can't just do key management or pick their
algorithms and you can always validate the ciphertext vs that done by
software, something that can't work with the broken Opal-like full disk
encryption model.

Anyway, not wanting to second guess you here, just throwing in my 2
cents.