mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Milan Broz <gmazyland@gmail.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Eric Biggers <ebiggers@kernel.org>,
	dm-devel@lists.linux.dev, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Md Sadre Alam <quic_mdalam@quicinc.com>,
	Israel Rukshin <israelr@nvidia.com>
Subject: Re: [RFC PATCH] dm-inlinecrypt: add target for inline block device encryption
Date: Mon, 7 Oct 2024 10:25:56 +0200	[thread overview]
Message-ID: <89fe49aa-4c7c-42ef-a59c-c962f4403145@gmail.com> (raw)
In-Reply-To: <ZwN1hDK34h0du5qp@infradead.org>


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


  reply	other threads:[~2024-10-07  8:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-04  0:41 Eric Biggers
2024-10-04  5:44 ` Christoph Hellwig
2024-10-04 18:48   ` Eric Biggers
2024-10-04 19:21     ` Milan Broz
2024-10-07  5:45       ` Christoph Hellwig
2024-10-07  8:25         ` Milan Broz [this message]
2024-10-08  9:20           ` Christoph Hellwig
2024-10-04 20:17 ` Bart Van Assche

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=89fe49aa-4c7c-42ef-a59c-c962f4403145@gmail.com \
    --to=gmazyland@gmail.com \
    --cc=dm-devel@lists.linux.dev \
    --cc=ebiggers@kernel.org \
    --cc=hch@infradead.org \
    --cc=israelr@nvidia.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_mdalam@quicinc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®