On 5/16/2026 2:41 AM, Eric Biggers wrote: > 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? > > - EricThanks for the feedback. I reworked the crypto part to reduce the memory concern. The inlinecrypt data-block path still uses ci_enc_key.blk_key, and the software tfm is prepared only for the encrypted inline_data path. So this no longer adds an extra software tfm for every encrypted inlinecrypt inode.
I also ran a small-file workload on an Android F2FS /data device with inlinecrypt. The test created 10000 encrypted files under the same fscrypt policy. Results: - 1K files, encrypted inline_data enabled: inline sample 200/200 fs_used_delta_kb 46344 avg bytes/file 4745.63 time 430.23s - 4K files, encrypted inline_data enabled: inline sample 0/200 fs_used_delta_kb 85280 avg bytes/file 8732.67 time 435.06s - 1K files, encrypted inline_data disabled: inline sample 0/200 fs_used_delta_kb 88808 avg bytes/file 9093.94 time 429.37s - 4K files, encrypted inline_data disabled: inline sample 0/200 fs_used_delta_kb 80728 avg bytes/file 8266.55 time 430.78s For the 1K workload, encrypted inline_data saved 42464 KiB across 10000 files, which is about 4348 bytes per file, or a 47.8% reduction in filesystem used space. A raw inode check of a sampled file also confirmed that the inline region did not contain plaintext. To check the memory concern, I added temporary counters for software tfm allocations. Under this Android policy, I observed 3 per-mode tfms and 0 per-file tfms. Creating the 10000-file workload did not increase the tfm allocation counters, so in this setup the extra memory cost is a small per-mode cost rather than something that grows with the number of files. For the 4K control workload, inline_data was not retained and no extra tfm was allocated. This is Android-focused, but I think the use case is still meaningful. Real phones can have more than 200000 encrypted files smaller than 4K under /data. Avoiding one 4K data block for a large fraction of those files can save several hundred MiB, and in some cases close to 1 GiB. That seems worth considering if the implementation stays simple and does not introduce per-file memory growth for common Android policies.
