* [PATCH 3/3] Documentation: f2fs: document encrypted inline data
2026-05-13 10:04 [PATCH 0/3] f2fs: support encrypted inline data LiaoYuanhong-vivo
@ 2026-05-13 10:04 ` LiaoYuanhong-vivo
2026-05-15 18:41 ` [PATCH 0/3] f2fs: support " Eric Biggers
1 sibling, 0 replies; 3+ messages in thread
From: LiaoYuanhong-vivo @ 2026-05-13 10:04 UTC (permalink / raw)
To: Jaegeuk Kim, Chao Yu, Jonathan Corbet, Shuah Khan,
open list:F2FS FILE SYSTEM, open list, open list:DOCUMENTATION
Cc: Liao Yuanhong
From: Liao Yuanhong <liaoyuanhong@vivo.com>
Document the F2FS encrypted_inline_data feature, including the on-disk
feature requirement, the CONFIG_F2FS_FS_ENCRYPTED_INLINE_DATA dependency,
how inline payloads are encrypted and decrypted, and the truncate
behavior.
Also list encrypted_inline_data in the supported F2FS feature sysfs
documentation.
Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com>
---
Documentation/ABI/testing/sysfs-fs-f2fs | 5 +++--
Documentation/filesystems/f2fs.rst | 27 +++++++++++++++++++++++++
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs
index 27d5e88facbe..dad483fb2fc1 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -258,7 +258,8 @@ Description: Expand /sys/fs/f2fs/<disk>/features to meet sysfs rule.
encryption, block_zoned (aka blkzoned), extra_attr,
project_quota (aka projquota), inode_checksum,
flexible_inline_xattr, quota_ino, inode_crtime, lost_found,
- verity, sb_checksum, casefold, readonly, compression.
+ verity, sb_checksum, casefold, readonly, compression,
+ encrypted_inline_data.
Note that, pin_file is moved into /sys/fs/f2fs/features/.
What: /sys/fs/f2fs/features/
@@ -271,7 +272,7 @@ Description: Shows all enabled kernel features.
inode_crtime, lost_found, verity, sb_checksum,
casefold, readonly, compression, test_dummy_encryption_v2,
atomic_write, pin_file, encrypted_casefold, linear_lookup,
- fserror.
+ fserror, encrypted_inline_data.
What: /sys/fs/f2fs/<disk>/inject_rate
Date: May 2016
diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst
index 5bc37a1c4e51..1f3e02352dd1 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -420,6 +420,33 @@ lookup_mode=%s Control the directory lookup behavior for casefolded
================== ========================================
======================== ============================================================
+Encrypted inline data
+=====================
+
+F2FS normally disables inline data for encrypted regular files, since inline
+data is stored inside the inode block and does not pass through the regular
+block I/O path. When a filesystem is formatted with the encrypted_inline_data
+feature, encrypted regular files may keep small file contents in the inode
+block. The inline payload is encrypted with fscrypt contents-key semantics
+before it is written to the inode, and it is decrypted back to page-cache
+plaintext when it is read.
+
+This feature requires the encrypt feature on disk and kernel support for
+CONFIG_F2FS_FS_ENCRYPTED_INLINE_DATA. It is intended to be used together with
+the inline_data mount option. When the normal encrypted file contents path uses
+blk-crypto, fscrypt also prepares a software contents-key transform for the
+filesystem-managed inline payload.
+
+Encrypted inline data is stored in fscrypt contents-aligned units. Therefore,
+the maximum plaintext size that can stay inline may be slightly smaller than the
+ordinary inline data capacity. If an encrypted inline-data file is truncated
+from a non-zero offset, F2FS first converts the inline payload to normal data
+blocks and then applies the truncate operation.
+
+Recovery copies inline payloads as on-disk bytes. Encryption and decryption are
+performed only when moving data between the inode inline area and page-cache
+plaintext.
+
Debugfs Entries
===============
--
2.34.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH 0/3] f2fs: support encrypted inline data
2026-05-13 10:04 [PATCH 0/3] f2fs: support encrypted inline data LiaoYuanhong-vivo
2026-05-13 10:04 ` [PATCH 3/3] Documentation: f2fs: document " LiaoYuanhong-vivo
@ 2026-05-15 18:41 ` Eric Biggers
1 sibling, 0 replies; 3+ messages in thread
From: Eric Biggers @ 2026-05-15 18:41 UTC (permalink / raw)
To: LiaoYuanhong-vivo
Cc: Jaegeuk Kim, Chao Yu, Jonathan Corbet, Shuah Khan,
Theodore Y. Ts'o, open list:F2FS FILE SYSTEM, open list,
open list:DOCUMENTATION,
open list:FSCRYPT: FILE SYSTEM LEVEL ENCRYPTION SUPPORT
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
^ permalink raw reply [flat|nested] 3+ messages in thread