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
