On Tue, Apr 21, 2026 at 03:57:17PM +0800, LiaoYuanhong-vivo wrote: > Some filesystems store small file contents in filesystem-managed regions > rather than in regular data blocks submitted through bios. One example is > F2FS inline_data, where the payload is stored inside the inode node block. > Such regions still need to follow the inode's fscrypt contents encryption > semantics, but they cannot rely on blk-crypto because they are not > submitted as standalone file data bios. > > As a result, when blk-crypto is enabled, mechanisms such as inline_data are > typically disabled outright. However, it is desirable to re-enable such > space-saving features while still preserving the required encryption > semantics. > > To support this, add fscrypt_crypt_fs_layer_page_inplace(), a helper that > encrypts or decrypts a caller-provided page region in place using > filesystem-layer software crypto and the inode's contents encryption > policy. > > This support is limited to v2 encryption policies. v1 policies do not > provide the key setup model used here, so this path returns -EOPNOTSUPP for > v1. Hardware-wrapped keys are not supported either, since deriving a > software skcipher key requires software-accessible key material, which > conflicts with the hardware-wrapped key model. > > When the inode's normal contents path uses blk-crypto, fscrypt may not have > a software skcipher key prepared for the inode contents key. Add an > optional filesystem-layer prepared key to fscrypt_inode_info. This key is > derived using the same v2 contents-encryption KDF as the normal contents > key, but is prepared as a software skcipher key and is used only by the new > filesystem-layer helper. > > Signed-off-by: LiaoYuanhong-vivo <[email protected]>
I don't have time for a super detailed review at the moment, but here are my initial thoughts: - This needs to be sent along with the code that actually uses it in ext4 and f2fs. Please also Cc the mailing lists for those filesystems. - This is going to require an "incompat" filesystem feature flag. After all, once a filesystem contains files that use this scheme, older kernels won't understand it. - UBIFS and CephFS already use fs/crypto/ but don't support blk-crypto (inline encryption). This new code feels duplicative of that. It should be possible to reuse the existing code instead. That would include, for example, reusing the existing en/decryption functions and the existing struct ci_enc_key field. This would keep the changes limited mainly to how the key is being set up. - Supporting all the different IV generation methods doesn't make sense when a per-file key is always used. - The fact that this is incompatible with hardware-wrapped keys greatly limits the usefulness of this. (Note that technically, it could be supported in combination with them anyway. But the security models would be inconsistent, which I assume is what you have in mind.) Hope this is helpful, - Eric
