From: Liao Yuanhong <liaoyuanhong@vivo.com>

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.

Liao Yuanhong (3):
  fscrypt: prepare software keys for filesystem-managed data units
  f2fs: support encrypted inline data
  Documentation: f2fs: document encrypted inline data

 Documentation/ABI/testing/sysfs-fs-f2fs |   5 +-
 Documentation/filesystems/f2fs.rst      |  27 ++++++
 fs/crypto/crypto.c                      |  63 +++++++++++++
 fs/crypto/fscrypt_private.h             |   3 +-
 fs/crypto/keysetup.c                    |  59 +++++++++---
 fs/f2fs/Kconfig                         |  14 +++
 fs/f2fs/data.c                          |   8 +-
 fs/f2fs/f2fs.h                          |  37 +++++++-
 fs/f2fs/file.c                          |  24 ++++-
 fs/f2fs/inline.c                        | 119 +++++++++++++++++++++---
 fs/f2fs/super.c                         |  12 +++
 fs/f2fs/sysfs.c                         |   8 ++
 include/linux/fscrypt.h                 |  28 ++++++
 13 files changed, 370 insertions(+), 37 deletions(-)

-- 
2.34.1

On Wed, May 13, 2026 at 06:04:27PM +0800, LiaoYuanhong-vivo wrote:
> From: Liao Yuanhong <liaoyuanhong@vivo.com>
> 
> 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

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 <liaoyuanhong@vivo.com>
>>
>> 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.