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
