Re: [PATCH v3 0/3] f2fs: support encrypted inline data
Eric Biggers <[email protected]> Tue, 16 Jun 2026 16:02:15 -0700
| Newsgroups | org.kernel.vger.linux-fscrypt,net.sourceforge.lists.linux-f2fs-devel,org.kernel.vger.linux-doc,org.kernel.vger.linux-ext4,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <20260616230215.GA1873@quark> |
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