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

[Eric Biggers]

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