FSCRYPT Adding Direct I/O Support For Encrypted Files In Linux 5.18

[phoronix]

Phoronix: FSCRYPT Adding Direct I/O Support For Encrypted Files In Linux 5.18

It's been a while since having any shiny new features to talk about for FSCRYPT, the Linux kernel's file-system encryption framework that is used by the likes of EXT4 and F2FS. With Linux 5.18 that changes with FSCRYPT adding direct I/O support...

https://www.phoronix.com/scan.php?pa...x-5.18-FSCRYPT

[coder]

This will benefit some databases, but now that async file I/O no longer depends on O_DIRECT (thanks to io_uring), the need for it should be much less.

[linuxgeex]

Am I understanding this correctly - does this enable per-file hardware encryption by the backing device on a drive which supports hardware block encryption but which does not otherwise have (whole disk) encryption enabled?

So the partition table, filesystem etc are not encrypted, but individual file data blocks are?

This seems kinda bizarre to me. It makes me wonder about what happens if this were enabled on an LLVM/LUKS2 encrypted volume...? Is it then performing an additional hardware-level block encryption to the already encrypted blocks for the files/folders marked for encryption, and if so, what's the security risk-reward landscape? ie, comparing to whole-disk encryption. Is this somehow capable of using different IVs for different file contexts such that it's an upgrade from whole-disk hardware encryption, and if so, does that still happen in hardware? If so, how? lol. I'm not aware of any storage devices with crypto keystores sufficient to cope with thousands or millions of keys per volume...? And if this is a matter of the kernel passing keys to the storage device, isn't that going to be so slow that direct IO becomes a red herring?