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
