linux-hardening - Re: [PATCH v2 1/3] dm-inlinecrypt: Add inline encryption support

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zxnl4VnD6K6No4UQ@infradead.org>
Date: Wed, 23 Oct 2024 23:14:57 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Adrian Vovk <adrianvovk@...il.com>
Cc: Christoph Hellwig <hch@...radead.org>,
	Eric Biggers <ebiggers@...nel.org>,
	Md Sadre Alam <quic_mdalam@...cinc.com>, axboe@...nel.dk,
	song@...nel.org, yukuai3@...wei.com, agk@...hat.com,
	snitzer@...nel.org, Mikulas Patocka <mpatocka@...hat.com>,
	adrian.hunter@...el.com, quic_asutoshd@...cinc.com,
	ritesh.list@...il.com, ulf.hansson@...aro.org, andersson@...nel.org,
	konradybcio@...nel.org, kees@...nel.org, gustavoars@...nel.org,
	linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-raid@...r.kernel.org, dm-devel@...ts.linux.dev,
	linux-mmc@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	linux-hardening@...r.kernel.org, quic_srichara@...cinc.com,
	quic_varada@...cinc.com
Subject: Re: [PATCH v2 1/3] dm-inlinecrypt: Add inline encryption support

On Wed, Oct 23, 2024 at 10:52:06PM -0400, Adrian Vovk wrote:
> > Why do you assume the encryption would happen twice?
> 
> I'm not assuming. That's the behavior of dm-crypt without passthrough.
> It just encrypts everything that moves through it. If I stack two
> layers of dm-crypt on top of each other my data is encrypted twice.

Sure.  But why would you do that?

> > No one knows that it actually is encryped.  The lower layer just knows
> > the skip encryption flag was set, but it has zero assurance data
> > actually was encrypted.
> 
> I think it makes sense to require that the data is actually encrypted
> whenever the flag is set. Of course there's no way to enforce that
> programmatically, but code that sets the flag without making sure the
> data gets encrypted some other way wouldn't pass review.

You have a lot of trusted in reviers. But even that doesn't help as
the kernel can load code that never passed review.

> Alternatively, if I recall correctly it should be possible to just
> check if the bio has an attached encryption context. If it has one,
> then just pass-through. If it doesn't, then attach your own. No flag
> required this way, and dm-default-key would only add encryption iff
> the data isn't already encrypted.

That at least sounds a little better.  But it still doesn't answer
why we need this hack instead always encrypting at one layer instead
of splitting it up.