[+Cc [email protected]] 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
