* Re: [PATCH v3 0/3] f2fs: support encrypted inline data [not found] <20260615125517.362294-1-liaoyuanhong@vivo.com> @ 2026-06-15 19:37 ` Eric Biggers 2026-06-16 9:46 ` LiaoYuanhong-vivo 0 siblings, 1 reply; 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
* Re: [PATCH v3 0/3] f2fs: support encrypted inline data 2026-06-15 19:37 ` [PATCH v3 0/3] f2fs: support encrypted inline data Eric Biggers @ 2026-06-16 9:46 ` LiaoYuanhong-vivo 2026-06-16 23:02 ` Eric Biggers 0 siblings, 1 reply; 3+ messages in thread From: LiaoYuanhong-vivo @ 2026-06-16 9:46 UTC (permalink / raw) To: ebiggers Cc: chao, corbet, jaegeuk, liaoyuanhong, linux-doc, linux-ext4, linux-f2fs-devel, linux-fscrypt, linux-kernel, skhan, tytso Hi Eric, Thanks for the explanation. I understand the concern about deriving software contents keys from sw_secret for hardware-wrapped-key files. I agree this is not the right security model, and I will stop pursuing this direction for now. Could you share more about the direction you have in mind for simplifying f2fs/ext4 contents encryption around blk-crypto? For f2fs inline_data, there is still a real space-saving benefit on phones, since many encrypted files are smaller than 4K. Is there any acceptable future direction to support this kind of inode-resident data with blk-crypto or hardware-wrapped keys? Thanks, Liao Yuanhong ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v3 0/3] f2fs: support encrypted inline data 2026-06-16 9:46 ` LiaoYuanhong-vivo @ 2026-06-16 23:02 ` Eric Biggers 0 siblings, 0 replies; 3+ messages in thread From: Eric Biggers @ 2026-06-16 23:02 UTC (permalink / raw) To: LiaoYuanhong-vivo Cc: chao, corbet, jaegeuk, linux-doc, linux-ext4, linux-f2fs-devel, linux-fscrypt, linux-kernel, skhan, tytso On Tue, Jun 16, 2026 at 05:46:12PM +0800, LiaoYuanhong-vivo wrote: > Could you share more about the direction you have in mind for simplifying > f2fs/ext4 contents encryption around blk-crypto? Currently ext4 and f2fs each have two implementations of file contents encryption and decryption: - One where the en/decryption is done in the filesystem layer - One where the filesystem attaches a bio_crypt_ctx to the bios and the en/decryption is done either in the block layer by blk-crypto-fallback or by inline encryption hardware I'd like to drop the first one, for simplicity and to reduce the burden on ongoing developments like large folio support. > For f2fs inline_data, there is still a real space-saving benefit on phones, > since many encrypted files are smaller than 4K. Is there any acceptable > future direction to support this kind of inode-resident data with > blk-crypto or hardware-wrapped keys? It is incompatible with inline encryption hardware. A CPU-based solution like Intel Key Locker or RISC-V High Assurance Cryptography could provide similar security properties. But there's nothing for arm64 yet. And I should mention that no one has wanted to use Key Locker anyway because it's really slow. - Eric ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-06-16 23:02 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20260615125517.362294-1-liaoyuanhong@vivo.com>
2026-06-15 19:37 ` [PATCH v3 0/3] f2fs: support encrypted inline data Eric Biggers
2026-06-16 9:46 ` LiaoYuanhong-vivo
2026-06-16 23:02 ` Eric Biggers
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox