On 4/23/2026 7:27 AM, Eric Biggers wrote:
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
Thanks for the comments. They are very helpful.
I agree that the fscrypt changes should stay much closer to the
existing filesystem-layer encryption code. I will rework this so
that the fscrypt side is mainly limited to key setup: when
blk-crypto is used for normal file contents, fscrypt can also
prepare the existing software contents crypto state for
filesystem-managed regions that cannot go through bio/blk-crypto.
I will also drop the separate key object / key-selection path, and
try to reuse the existing contents key and software encryption
functions as much as possible.
I agree that supporting all IV generation methods is unnecessary
here. For the first version, I plan to limit this to the normal v2
per-file-key case.
Regarding hardware-wrapped keys: it may be technically possible to
make this work in some cases, but using a software crypto key for
these regions seems to conflict with the expected hardware-wrapped
key security model. What would you prefer for the initial version:
should this combination be disallowed, or is there another approach
you would recommend?
Thanks,
Liao Yuanhong
