* [PATCH v3 3/3] Documentation: f2fs: document encrypted inline data
2026-06-15 12:55 [PATCH v3 0/3] f2fs: support encrypted inline data LiaoYuanhong-vivo
@ 2026-06-15 12:55 ` LiaoYuanhong-vivo
2026-06-15 19:37 ` [PATCH v3 0/3] f2fs: support " Eric Biggers
1 sibling, 0 replies; 3+ messages in thread
From: LiaoYuanhong-vivo @ 2026-06-15 12:55 UTC (permalink / raw)
To: Jaegeuk Kim, Chao Yu, Jonathan Corbet, Shuah Khan,
open list:F2FS FILE SYSTEM, open list, open list:DOCUMENTATION
Cc: LiaoYuanhong-vivo
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 document the supported key combinations. Files using filesystem-layer
encryption reuse the normal software transform. Inlinecrypt is supported
for v2 IV_INO_LBLK_64/32 policies, including hardware-wrapped key
configurations supported by fscrypt. Per-file inlinecrypt keys and
DIRECT_KEY policies are not supported for encrypted inline data.
List encrypted_inline_data in the supported F2FS feature sysfs
documentation.
Signed-off-by: LiaoYuanhong-vivo <liaoyuanhong@vivo.com>
---
Changes in v3:
- Update the documented key support matrix.
Documentation/ABI/testing/sysfs-fs-f2fs | 5 +++--
Documentation/filesystems/f2fs.rst | 30 +++++++++++++++++++++++++
2 files changed, 33 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..651e84e8dd98 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -420,6 +420,36 @@ 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. Files using filesystem-layer encryption reuse the
+normal software contents-key transform. When the normal encrypted file
+contents path uses blk-crypto, encrypted inline data is supported for v2
+IV_INO_LBLK_64/32 policies, including hardware-wrapped key configurations
+supported by fscrypt. Per-file inlinecrypt keys and DIRECT_KEY policies are
+not supported for encrypted inline data.
+
+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 v3 0/3] f2fs: support encrypted inline data
2026-06-15 12:55 [PATCH v3 0/3] f2fs: support encrypted inline data LiaoYuanhong-vivo
2026-06-15 12:55 ` [PATCH v3 3/3] Documentation: f2fs: document " LiaoYuanhong-vivo
@ 2026-06-15 19:37 ` Eric Biggers
1 sibling, 0 replies; 3+ messages in thread
From: Eric Biggers @ 2026-06-15 19:37 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,
linux-ext4
[+Cc linux-ext4@vger.kernel.org]
On Mon, Jun 15, 2026 at 08:55:12PM +0800, LiaoYuanhong-vivo wrote:
> F2FS currently disables inline data for encrypted regular files because the
> inline payload is stored in the inode block and does not go through the
> regular bio-based fscrypt path. This wastes space for small encrypted
> files on Android devices using F2FS inlinecrypt.
>
> This series adds an encrypted_inline_data on-disk feature for F2FS.
> With this feature enabled, encrypted regular files may keep small contents
> in the inode block. The inline payload is encrypted before being stored in
> the inode and decrypted back into page-cache plaintext on read.
>
> The fscrypt changes are scoped to filesystem-managed data-unit crypto.
> F2FS first asks fscrypt whether the inode's key/policy supports this path.
> It prepares the software transform only when encrypted inline payloads are
> read or written. Inlinecrypt support is limited to v2 IV_INO_LBLK_64 and
> IV_INO_LBLK_32 policies, including the hardware-wrapped key configurations
> supported by fscrypt. Per-file inlinecrypt keys and DIRECT_KEY policies
> are not supported for encrypted inline data.
I still think we should hold off on this, for the reasons I gave at
https://lore.kernel.org/r/20260515184124.GA4903@quark/
As soon as you start using hardware-wrapped keys this will become
irrelevant, as it can't be used in that case. I see you added "support"
for that case anyway by deriving contents encryption keys from the
sw_secret. But that bypasses the security model, which isn't okay.
I'm also working to simplify ext4 and f2fs's file contents encryption
implementation by standardizing on blk-crypto. That aligns well with
what btrfs encryption is going to do as well. So this isn't a great
time to be making f2fs's file contents encryption implementation even
more complex by going in a different direction.
If there was demand for this feature from the ext4 side for
general-purpose Linux distros as well, that would make it a bit more
appealing, as it would show broader demand. But with the proposal being
f2fs-specific and effectively just for Android devices that *don't* use
wrapped keys, that feels too narrow for the added complexity.
This proposal also lacks test cases in xfstests and/or Android's
vts_kernel_encryption_test that verify that the inline data is actually
being encrypted correctly. Those tests are essential, and we *must not*
add new file contents encryption implementations without such tests.
- Eric
^ permalink raw reply [flat|nested] 3+ messages in thread