On Tue, Nov 05, 2019 at 10:35:44PM -0500, Theodore Y. Ts'o wrote:

On Thu, Oct 24, 2019 at 02:54:36PM -0700, Eric Biggers wrote:

quoted

@@ -83,6 +118,10 @@ bool fscrypt_supported_policy(const union fscrypt_policy *policy_u,
 			return false;
 		}
 
+		if ((policy->flags & FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64) &&
+		    !supported_iv_ino_lblk_64_policy(policy, inode))
+			return false;
+
 		if (memchr_inv(policy->__reserved, 0,
 			       sizeof(policy->__reserved))) {
 			fscrypt_warn(inode,

fscrypt_supported_policy is getting more and more complicated, and
supported_iv_ino_lblk_64_policy calls a fs-supplied callback function,
etc.  And we need to use this every single time we need to set up an
inode.  Granted that compared to the crypto, even if it is ICE, it's
probably small beer --- but perhaps we should think about caching some
of what fscrypt_supported_policy does on a per-file system basis at
some point?

I don't think this will make any difference given everything else that needs to
be done to set up a file's key.  Also, anything extra we spend here will be far
less than the amount of time we save with IV_INO_LBLK_64 policies by not having
to do the key derivation and tfm allocation for every file.

Christoph suggested replacing ->has_stable_inodes() and
->get_ino_and_lblk_bits() with a new SB_* flag like SB_IV_INO_LBLK_64_SUPPORT.
But I don't like that that would result in worse error messages and would "leak"
a specific fscrypt policy flag into filesystems rather than having the
filesystems declare their properties.

If we really wanted to optimize fscrypt_get_encryption_info(), I think we
probably shouldn't try to microoptimize fscrypt_supported_policy(), but rather
take advantage of the fact that fscrypt_has_permitted_context() already ran.
E.g., we could cache the xattr, or skip both the keyring lookup and
fscrypt_supported_policy() by grabbing them from the parent directory.

- Eric