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-prev] [day] [month] [year] [list]

Message-ID: <74adbf13-c778-ee00-0cd6-3931a4a518ec@redhat.com>
Date: Tue, 29 Oct 2024 12:08:44 +0100 (CET)
From: Mikulas Patocka <mpatocka@...hat.com>
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, 
    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, 24 Oct 2024, Adrian Vovk wrote:

> >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.
> 
> 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.
> 
> The current Linux kernel does not support this use-case without double 
> encryption. The loop devices are encrypted once with their own dm-crypt 
> instance. Then that same data is encrypted a second time over by the 
> partition.

You can add a flag to an inode, then you can modify the page cache code so 
that if it is reading/writing a flagged file, it will attach the flag to 
the bio. Then, you can create a device-mapper target "dm-flag-switch" that 
will forward unflagged bios to one underlying device and flagged bios to 
another underlying device.

I think this is not impossible. But this change needs to go through the 
VFS tree, so I suggest that you start asking about it there.

Mikulas