On Wed, May 13, 2026 at 06:04:27PM +0800, LiaoYuanhong-vivo wrote: > From: Liao Yuanhong <[email protected]> > > F2FS currently avoids inline data for encrypted regular files. This is > because inline data is stored in the inode block, outside the regular > bio-based data path where fscrypt and blk-crypto normally operate. > As a result, devices that enable blk-crypto for encrypted file contents > cannot use F2FS inline data for encrypted regular files, which wastes > space for small files. > > This series adds support for keeping small encrypted regular-file > contents as inline data. The f2fs side defines a new on-disk feature, > encrypted_inline_data, under which inline payloads of encrypted regular > files are interpreted as ciphertext. The payload is encrypted before > being stored in the inode block and decrypted back into page-cache > plaintext on read. > > The fscrypt side prepares a software contents-key transform even when > normal file contents use blk-crypto, so filesystems can encrypt > filesystem-managed data regions that do not go through bio submission. > The new fscrypt helper operates on fscrypt data units and leaves the > filesystem responsible for deciding which filesystem-managed byte ranges > need this treatment. > > The software crypto operation is limited to the inline payload. Since > these files are small enough to remain inline, the expected read/write > performance difference between hardware and software crypto is small, > while the space saving from keeping the data inline is significant. > > The feature is guarded by CONFIG_F2FS_FS_ENCRYPTED_INLINE_DATA and by the > F2FS encrypted_inline_data on-disk feature bit. Filesystems with this > feature set are rejected if the kernel lacks the config option. > > Hardware-wrapped keys are not supported by this initial version. I would > like to discuss whether this feature should remain disabled for > hardware-wrapped keys, or whether there is an acceptable way to support the > combination in the future. > > The f2fs-tools support for formatting filesystems with this feature will be > submitted separately. > > Basic testing passed. Encrypted small files can be kept as inline data, > and read/write verification succeeded.
Honestly, I'm not convinced this is worth the complexity and the additional memory use. First, it works only in the combination: 'f2fs && inlinecrypt && !hw_wrapped_keys'. That really limits how many users would use this. 'f2fs && inlinecrypt' de facto targets it to Android devices rather than "regular" Linux systems. But at the same time, the "best practice" on such devices is to use HW-wrapped keys, which has already been widely adopted. So this would be useful only on devices where the SoC doesn't support HW-wrapped keys. Its usefulness will go away when support for HW-wrapped keys is added. Second, in the per-file key case this makes every file use an additional 1 KiB of memory or so (assuming AES-XTS) to hold the "software key", just in case the file ever has inline data. That seems problematic, and maybe not a great direction to be going in right now, given the ongoing RAM shortage. There also seem to be quite a few bugs/issues. Sashiko found quite a few (https://sashiko.dev/#/message/20260513100431.299904-1-liaoyuanhong%40vivo.com). But just from a quick readthrough, anything that calls fscrypt_is_key_prepared() seems to be broken now, as that function isn't aware that both fields of fscrypt_prepared_key can be needed. I'm also not seeing what differentiates the new fscrypt_{en,decrypt}_data_unit_inplace() from the existing fscrypt_{en,decrypt}_block_inplace(). They seem redundant. There's already a lot of complexity in fscrypt, with the different settings and the different ways the filesystems do en/decryption. With this, plus the concurrent work to add support for extent-based encryption (for btrfs), it's really quite hard to keep track of everything. So I have to wonder if this patchset is really worth it. So, overall, I think this would need a bit more work. But also I'm wondering if it's actually worthwhile. Do you plan to never enable HW-wrapped keys, for example? And you're fine with using more RAM? - Eric
