[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAdYy_ms=VmvxZy9QiMkwcNk21a2kVy73c8-NxUh4dNJuLefCg@mail.gmail.com>
Date: Wed, 23 Oct 2024 22:52:06 -0400
From: Adrian Vovk <adrianvovk@...il.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: 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 2:57 AM Christoph Hellwig <hch@...radead.org> wrote:
>
> On Fri, Oct 18, 2024 at 11:03:50AM -0400, Adrian Vovk wrote:
> > Sure, but then this way you're encrypting each partition twice. Once by the dm-crypt inside of the partition, and again by the dm-crypt that's under the partition table. This double encryption is ruinous for performance, so it's just not a feasible solution and thus people don't do this. Would be nice if we had the flexibility though.
>
> 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.
> > >Because you are now bypassing encryption for certainl LBA ranges in
> > >the file system based on hints/flags for something sitting way above
> > >in the stack.
> > >
> >
> > Well the data is still encrypted. It's just encrypted with a different key. If the attacker has a FDE dump of the disk, the data is still just as inaccessible to them.
>
> 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.
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.
Would either of those solutions be acceptable?
Best,
Adrian
Powered by blists - more mailing lists