Re: [f2fs-dev] [PATCH 0/3] f2fs: support encrypted inline data

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.

_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel