linux-kernel - 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <ZxH4lnkQNhTP5fe6@infradead.org>
Date: Thu, 17 Oct 2024 22:56:38 -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 Fri, Oct 18, 2024 at 01:44:19AM -0400, Adrian Vovk wrote:
> > So just run a target on each partition.
> 
> 
> That has different semantics. If I encrypt each virtual partition there's
> nothing encrypting the metadata around the virtual partitions. Of course,
> this is a rather contrived example but point stands, the semantics are
> different.

Then you set up an dm-crype device mapper table for the partition table as
well.

> > This is the prime example of why allowing higher layers to skip
> > encryption is a no-go.
> >
> 
> In what way does that break the file system's security model? Could you
> elaborate on what's objectionable about the behavior here?

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.