fscrypt: use smp_load_acquire() for fscrypt_prepared_key
authorEric Biggers <ebiggers@google.com>
Tue, 21 Jul 2020 22:59:17 +0000 (15:59 -0700)
committerEric Biggers <ebiggers@google.com>
Tue, 21 Jul 2020 23:02:13 +0000 (16:02 -0700)
Normally smp_store_release() or cmpxchg_release() is paired with
smp_load_acquire().  Sometimes smp_load_acquire() can be replaced with
the more lightweight READ_ONCE().  However, for this to be safe, all the
published memory must only be accessed in a way that involves the
pointer itself.  This may not be the case if allocating the object also
involves initializing a static or global variable, for example.

fscrypt_prepared_key includes a pointer to a crypto_skcipher object,
which is internal to and is allocated by the crypto subsystem.  By using
READ_ONCE() for it, we're relying on internal implementation details of
the crypto subsystem.

Remove this fragile assumption by using smp_load_acquire() instead.

(Note: I haven't seen any real-world problems here.  This change is just
fixing the code to be guaranteed correct and less fragile.)

Fixes: 5fee36095cda ("fscrypt: add inline encryption support")
Cc: Satya Tangirala <satyat@google.com>
Link: https://lore.kernel.org/r/20200721225920.114347-3-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
fs/crypto/fscrypt_private.h
fs/crypto/inline_crypt.c
fs/crypto/keysetup.c

index bc1a3fcd45ed0a1739e76386d719988023c7c918..8117a61b6f55844f8fe9fa5f09a869a47260c61f 100644 (file)
@@ -351,13 +351,16 @@ fscrypt_is_key_prepared(struct fscrypt_prepared_key *prep_key,
                        const struct fscrypt_info *ci)
 {
        /*
-        * The READ_ONCE() here pairs with the smp_store_release() in
-        * fscrypt_prepare_key().  (This only matters for the per-mode keys,
-        * which are shared by multiple inodes.)
+        * The two smp_load_acquire()'s here pair with the smp_store_release()'s
+        * in fscrypt_prepare_inline_crypt_key() and fscrypt_prepare_key().
+        * I.e., in some cases (namely, if this prep_key is a per-mode
+        * encryption key) another task can publish blk_key or tfm concurrently,
+        * executing a RELEASE barrier.  We need to use smp_load_acquire() here
+        * to safely ACQUIRE the memory the other task published.
         */
        if (fscrypt_using_inline_encryption(ci))
-               return READ_ONCE(prep_key->blk_key) != NULL;
-       return READ_ONCE(prep_key->tfm) != NULL;
+               return smp_load_acquire(&prep_key->blk_key) != NULL;
+       return smp_load_acquire(&prep_key->tfm) != NULL;
 }
 
 #else /* CONFIG_FS_ENCRYPTION_INLINE_CRYPT */
@@ -391,7 +394,7 @@ static inline bool
 fscrypt_is_key_prepared(struct fscrypt_prepared_key *prep_key,
                        const struct fscrypt_info *ci)
 {
-       return READ_ONCE(prep_key->tfm) != NULL;
+       return smp_load_acquire(&prep_key->tfm) != NULL;
 }
 #endif /* !CONFIG_FS_ENCRYPTION_INLINE_CRYPT */
 
index d7aecadf33c188c758bab16404608f0fcbb0518e..dfb06375099aec30e74c672b187001d798f4d2eb 100644 (file)
@@ -176,8 +176,10 @@ int fscrypt_prepare_inline_crypt_key(struct fscrypt_prepared_key *prep_key,
                }
        }
        /*
-        * Pairs with READ_ONCE() in fscrypt_is_key_prepared().  (Only matters
-        * for the per-mode keys, which are shared by multiple inodes.)
+        * Pairs with the smp_load_acquire() in fscrypt_is_key_prepared().
+        * I.e., here we publish ->blk_key with a RELEASE barrier so that
+        * concurrent tasks can ACQUIRE it.  Note that this concurrency is only
+        * possible for per-mode keys, not for per-file keys.
         */
        smp_store_release(&prep_key->blk_key, blk_key);
        return 0;
index 22a94b18fe70d1014ec188c9c000847a52dce9a1..7f85fc64560206e391542daf337bea6e0ca479ad 100644 (file)
@@ -129,8 +129,10 @@ int fscrypt_prepare_key(struct fscrypt_prepared_key *prep_key,
        if (IS_ERR(tfm))
                return PTR_ERR(tfm);
        /*
-        * Pairs with READ_ONCE() in fscrypt_is_key_prepared().  (Only matters
-        * for the per-mode keys, which are shared by multiple inodes.)
+        * Pairs with the smp_load_acquire() in fscrypt_is_key_prepared().
+        * I.e., here we publish ->tfm with a RELEASE barrier so that
+        * concurrent tasks can ACQUIRE it.  Note that this concurrency is only
+        * possible for per-mode keys, not for per-file keys.
         */
        smp_store_release(&prep_key->tfm, tfm);
        return 0;