Message-ID: <Zxpuzbjtq0eNP49Z@infradead.org>
Date: Thu, 24 Oct 2024 08:59:09 -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 Thu, Oct 24, 2024 at 11:32:58AM -0400, Adrian Vovk wrote:
> >> 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?
> 
> As mentioned earlier in the thread: I don't have a usecase
> specifically for this and it was an example of a situation where
> passthrough is necessary and no filesystem is involved at all. Though,
> as I also pointed out, a usecase where you're putting encrypted
> virtual partitions on an encrypted LVM setup isn't all that absurd.

It's a little odd but not entirely absurd indeed.  But it can also
be easily handled by setting up a dm-crypt table just for the
partition table.

> In my real-world case, I'm putting encrypted loop devices on top of a
> filesystem that holds its own sensitive data. Each loop device has
> dm-crypt inside and uses a unique key, but the filesystem needs to be
> encrypted too (because, again, it has its own sensitive data outside
> of the loop devices). The loop devices cannot be put onto their own
> separate partition because there's no good way to know ahead of time
> how much space either of the partitions would need: sometimes the loop
> devices need to take up loads of space on the partition, and other
> times the non-loop-device data needs to take up that space. And to top
> it all off, the distribution of allocated space needs to change
> dynamically.

And that's exactly the case I worry about.  The file system can't
trust a layer entirely above it.  If we want to be able to have a
space pool between a file systems with one encryption policy and
images with another we'll need to replace the loop driver with a 
block driver taking blocks from the file system space pool.  Which
might be a good idea for various other reasons.

> Ultimately, I'm unsure what the concern is here.
> 
> It's a glaringly loud opt-in marker that encryption was already
> performed or is otherwise intentionally unnecessary. The flag existing
> isn't what punches through the security model. It's the use of the
> flag that does. I can't imagine anything setting the flag by accident.
> So what are you actually concerned about? How are you expecting this
> flag to actually be misused?
> 
> As for third party modules that might punch holes, so what? 3rd party
> modules aren't the kernel's responsibility or problem

On the one hand they are not.  On the other if you have a file system
encryption scheme that is bypassed by a random other loadable code
setting a single flag I would not consider it very trust worth or in
fact actively dangerous.

> In my loopback file scenario, what would be the one layer that could
> handle the encryption?

But getting rid of loopback devices.

Powered by blists - more mailing lists