From 5befc19caec93f0088595b4d28baf10658c27a0f Mon Sep 17 00:00:00 2001 From: Xiubo Li Date: Thu, 1 Feb 2024 08:35:25 +0800 Subject: fscrypt: explicitly require that inode->i_blkbits be set Document that fscrypt_prepare_new_inode() requires inode->i_blkbits to be set, and make it WARN if it's not. This would have made the CephFS bug https://tracker.ceph.com/issues/64035 a bit easier to debug. Signed-off-by: Xiubo Li Link: https://lore.kernel.org/r/20240201003525.1788594-1-xiubli@redhat.com Signed-off-by: Eric Biggers --- fs/crypto/keysetup.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c index d71f7c799e79..9a0a40c81bf2 100644 --- a/fs/crypto/keysetup.c +++ b/fs/crypto/keysetup.c @@ -687,7 +687,7 @@ int fscrypt_get_encryption_info(struct inode *inode, bool allow_unsupported) /** * fscrypt_prepare_new_inode() - prepare to create a new inode in a directory * @dir: a possibly-encrypted directory - * @inode: the new inode. ->i_mode must be set already. + * @inode: the new inode. ->i_mode and ->i_blkbits must be set already. * ->i_ino doesn't need to be set yet. * @encrypt_ret: (output) set to %true if the new inode will be encrypted * @@ -717,6 +717,9 @@ int fscrypt_prepare_new_inode(struct inode *dir, struct inode *inode, if (IS_ERR(policy)) return PTR_ERR(policy); + if (WARN_ON_ONCE(inode->i_blkbits == 0)) + return -EINVAL; + if (WARN_ON_ONCE(inode->i_mode == 0)) return -EINVAL; -- cgit v1.2.3 From d3a7bd4200762d11c33ebe7e2c47c5813ddc65b4 Mon Sep 17 00:00:00 2001 From: Luis Henriques Date: Tue, 6 Feb 2024 10:16:19 +0000 Subject: fscrypt: clear keyring before calling key_put() Now that the key quotas are handled immediately on key_put() instead of being postponed to the key management garbage collection worker, a call to keyring_clear() is all that is required in fscrypt_put_master_key() so that the keyring clean-up is also done synchronously. This patch should fix the fstest generic/581 flakiness. Signed-off-by: Luis Henriques Link: https://lore.kernel.org/r/20240206101619.8083-1-lhenriques@suse.de [ebiggers: added comment] Signed-off-by: Eric Biggers --- fs/crypto/keyring.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/fs/crypto/keyring.c b/fs/crypto/keyring.c index 0edf0b58daa7..6681a71625f0 100644 --- a/fs/crypto/keyring.c +++ b/fs/crypto/keyring.c @@ -74,8 +74,12 @@ void fscrypt_put_master_key(struct fscrypt_master_key *mk) * that concurrent keyring lookups can no longer find it. */ WARN_ON_ONCE(refcount_read(&mk->mk_active_refs) != 0); - key_put(mk->mk_users); - mk->mk_users = NULL; + if (mk->mk_users) { + /* Clear the keyring so the quota gets released right away. */ + keyring_clear(mk->mk_users); + key_put(mk->mk_users); + mk->mk_users = NULL; + } call_rcu(&mk->mk_rcu_head, fscrypt_free_master_key); } -- cgit v1.2.3 From 2f944c66ae73eed4250607ccd3acdf2531afc194 Mon Sep 17 00:00:00 2001 From: Eric Biggers Date: Fri, 23 Feb 2024 21:35:49 -0800 Subject: fscrypt: write CBC-CTS instead of CTS-CBC Calling CBC with ciphertext stealing "CBC-CTS" seems to be more common than calling it "CTS-CBC". E.g., CBC-CTS is used by OpenSSL, Crypto++, RFC3962, and RFC6803. The NIST SP800-38A addendum uses CBC-CS1, CBC-CS2, and CBC-CS3, distinguishing between different CTS conventions but similarly putting the CBC part first. In the interest of avoiding any idiosyncratic terminology, update the fscrypt documentation and the fscrypt_mode "friendly names" to align with the more common convention. Changing the "friendly names" only affects some log messages. The actual mode constants in the API are unchanged; those call it simply "CTS". Add a note to the documentation that clarifies that "CBC" and "CTS" in the API really mean CBC-ESSIV and CBC-CTS, respectively. Link: https://lore.kernel.org/r/20240224053550.44659-1-ebiggers@kernel.org Signed-off-by: Eric Biggers --- Documentation/filesystems/fscrypt.rst | 27 +++++++++++++++------------ fs/crypto/keysetup.c | 6 +++--- 2 files changed, 18 insertions(+), 15 deletions(-) diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index e86b886b64d0..04eaab01314b 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -338,11 +338,14 @@ Supported modes Currently, the following pairs of encryption modes are supported: -- AES-256-XTS for contents and AES-256-CTS-CBC for filenames +- AES-256-XTS for contents and AES-256-CBC-CTS for filenames - AES-256-XTS for contents and AES-256-HCTR2 for filenames - Adiantum for both contents and filenames -- AES-128-CBC-ESSIV for contents and AES-128-CTS-CBC for filenames -- SM4-XTS for contents and SM4-CTS-CBC for filenames +- AES-128-CBC-ESSIV for contents and AES-128-CBC-CTS for filenames +- SM4-XTS for contents and SM4-CBC-CTS for filenames + +Note: in the API, "CBC" means CBC-ESSIV, and "CTS" means CBC-CTS. +So, for example, FSCRYPT_MODE_AES_256_CTS means AES-256-CBC-CTS. Authenticated encryption modes are not currently supported because of the difficulty of dealing with ciphertext expansion. Therefore, @@ -351,11 +354,11 @@ contents encryption uses a block cipher in `XTS mode `CBC-ESSIV mode `_, or a wide-block cipher. Filenames encryption uses a -block cipher in `CTS-CBC mode +block cipher in `CBC-CTS mode `_ or a wide-block cipher. -The (AES-256-XTS, AES-256-CTS-CBC) pair is the recommended default. +The (AES-256-XTS, AES-256-CBC-CTS) pair is the recommended default. It is also the only option that is *guaranteed* to always be supported if the kernel supports fscrypt at all; see `Kernel config options`_. @@ -364,7 +367,7 @@ upgrades the filenames encryption to use a wide-block cipher. (A *wide-block cipher*, also called a tweakable super-pseudorandom permutation, has the property that changing one bit scrambles the entire result.) As described in `Filenames encryption`_, a wide-block -cipher is the ideal mode for the problem domain, though CTS-CBC is the +cipher is the ideal mode for the problem domain, though CBC-CTS is the "least bad" choice among the alternatives. For more information about HCTR2, see `the HCTR2 paper `_. @@ -375,13 +378,13 @@ the work is done by XChaCha12, which is much faster than AES when AES acceleration is unavailable. For more information about Adiantum, see `the Adiantum paper `_. -The (AES-128-CBC-ESSIV, AES-128-CTS-CBC) pair exists only to support +The (AES-128-CBC-ESSIV, AES-128-CBC-CTS) pair exists only to support systems whose only form of AES acceleration is an off-CPU crypto accelerator such as CAAM or CESA that does not support XTS. The remaining mode pairs are the "national pride ciphers": -- (SM4-XTS, SM4-CTS-CBC) +- (SM4-XTS, SM4-CBC-CTS) Generally speaking, these ciphers aren't "bad" per se, but they receive limited security review compared to the usual choices such as @@ -393,7 +396,7 @@ Kernel config options Enabling fscrypt support (CONFIG_FS_ENCRYPTION) automatically pulls in only the basic support from the crypto API needed to use AES-256-XTS -and AES-256-CTS-CBC encryption. For optimal performance, it is +and AES-256-CBC-CTS encryption. For optimal performance, it is strongly recommended to also enable any available platform-specific kconfig options that provide acceleration for the algorithm(s) you wish to use. Support for any "non-default" encryption modes typically @@ -407,7 +410,7 @@ kernel crypto API (see `Inline encryption support`_); in that case, the file contents mode doesn't need to supported in the kernel crypto API, but the filenames mode still does. -- AES-256-XTS and AES-256-CTS-CBC +- AES-256-XTS and AES-256-CBC-CTS - Recommended: - arm64: CONFIG_CRYPTO_AES_ARM64_CE_BLK - x86: CONFIG_CRYPTO_AES_NI_INTEL @@ -433,7 +436,7 @@ API, but the filenames mode still does. - x86: CONFIG_CRYPTO_NHPOLY1305_SSE2 - x86: CONFIG_CRYPTO_NHPOLY1305_AVX2 -- AES-128-CBC-ESSIV and AES-128-CTS-CBC: +- AES-128-CBC-ESSIV and AES-128-CBC-CTS: - Mandatory: - CONFIG_CRYPTO_ESSIV - CONFIG_CRYPTO_SHA256 or another SHA-256 implementation @@ -521,7 +524,7 @@ alternatively has the file's nonce (for `DIRECT_KEY policies`_) or inode number (for `IV_INO_LBLK_64 policies`_) included in the IVs. Thus, IV reuse is limited to within a single directory. -With CTS-CBC, the IV reuse means that when the plaintext filenames share a +With CBC-CTS, the IV reuse means that when the plaintext filenames share a common prefix at least as long as the cipher block size (16 bytes for AES), the corresponding encrypted filenames will also share a common prefix. This is undesirable. Adiantum and HCTR2 do not have this weakness, as they are diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c index 9a0a40c81bf2..b4fe01ea4bd4 100644 --- a/fs/crypto/keysetup.c +++ b/fs/crypto/keysetup.c @@ -23,7 +23,7 @@ struct fscrypt_mode fscrypt_modes[] = { .blk_crypto_mode = BLK_ENCRYPTION_MODE_AES_256_XTS, }, [FSCRYPT_MODE_AES_256_CTS] = { - .friendly_name = "AES-256-CTS-CBC", + .friendly_name = "AES-256-CBC-CTS", .cipher_str = "cts(cbc(aes))", .keysize = 32, .security_strength = 32, @@ -38,7 +38,7 @@ struct fscrypt_mode fscrypt_modes[] = { .blk_crypto_mode = BLK_ENCRYPTION_MODE_AES_128_CBC_ESSIV, }, [FSCRYPT_MODE_AES_128_CTS] = { - .friendly_name = "AES-128-CTS-CBC", + .friendly_name = "AES-128-CBC-CTS", .cipher_str = "cts(cbc(aes))", .keysize = 16, .security_strength = 16, @@ -53,7 +53,7 @@ struct fscrypt_mode fscrypt_modes[] = { .blk_crypto_mode = BLK_ENCRYPTION_MODE_SM4_XTS, }, [FSCRYPT_MODE_SM4_CTS] = { - .friendly_name = "SM4-CTS-CBC", + .friendly_name = "SM4-CBC-CTS", .cipher_str = "cts(cbc(sm4))", .keysize = 16, .security_strength = 16, -- cgit v1.2.3 From 8c62f31eddb71c6f6878258579318c1156045247 Mon Sep 17 00:00:00 2001 From: Eric Biggers Date: Fri, 23 Feb 2024 22:01:03 -0800 Subject: fscrypt: shrink the size of struct fscrypt_inode_info slightly Shrink the size of struct fscrypt_inode_info by 8 bytes by packing the small fields into the 64 bits after ci_enc_key. Link: https://lore.kernel.org/r/20240224060103.91037-1-ebiggers@kernel.org Signed-off-by: Eric Biggers --- fs/crypto/fscrypt_private.h | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h index 1892356cf924..8371e4e1f596 100644 --- a/fs/crypto/fscrypt_private.h +++ b/fs/crypto/fscrypt_private.h @@ -222,16 +222,19 @@ struct fscrypt_inode_info { struct fscrypt_prepared_key ci_enc_key; /* True if ci_enc_key should be freed when this struct is freed */ - bool ci_owns_key; + u8 ci_owns_key : 1; #ifdef CONFIG_FS_ENCRYPTION_INLINE_CRYPT /* * True if this inode will use inline encryption (blk-crypto) instead of * the traditional filesystem-layer encryption. */ - bool ci_inlinecrypt; + u8 ci_inlinecrypt : 1; #endif + /* True if ci_dirhash_key is initialized */ + u8 ci_dirhash_key_initialized : 1; + /* * log2 of the data unit size (granularity of contents encryption) of * this file. This is computable from ci_policy and ci_inode but is @@ -242,6 +245,9 @@ struct fscrypt_inode_info { /* Cached value: log2 of number of data units per FS block */ u8 ci_data_units_per_block_bits; + /* Hashed inode number. Only set for IV_INO_LBLK_32 */ + u32 ci_hashed_ino; + /* * Encryption mode used for this inode. It corresponds to either the * contents or filenames encryption mode, depending on the inode type. @@ -276,16 +282,12 @@ struct fscrypt_inode_info { * the plaintext filenames -- currently just casefolded directories. */ siphash_key_t ci_dirhash_key; - bool ci_dirhash_key_initialized; /* The encryption policy used by this inode */ union fscrypt_policy ci_policy; /* This inode's nonce, copied from the fscrypt_context */ u8 ci_nonce[FSCRYPT_FILE_NONCE_SIZE]; - - /* Hashed inode number. Only set for IV_INO_LBLK_32 */ - u32 ci_hashed_ino; }; typedef enum { -- cgit v1.2.3