Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v6.3 2023-02-08T06:30:30+00:00 2023-02-08T06:30:30+00:00 Eric Biggers ebiggers@google.com 2023-02-08T06:21:07+00:00 urn:sha1:097d7c1fcb8d4b52c62a36f94b8f18bc21a24934 Now that fscrypt_add_test_dummy_key() is only called by setup_file_encryption_key() and not by the individual filesystems, un-export it. Also change its prototype to take the fscrypt_key_specifier directly, as the caller already has it. Signed-off-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20230208062107.199831-6-ebiggers@kernel.org 2023-02-08T06:30:30+00:00 Eric Biggers ebiggers@google.com 2023-02-08T06:21:03+00:00 urn:sha1:60e463f0be9874692a56a7d419a6e39029b6290d When the key for an inode is not found but the inode is using the test_dummy_encryption policy, automatically add the test_dummy_encryption key to the filesystem keyring. This eliminates the need for all the individual filesystems to do this at mount time, which is a bit tricky to clean up from on failure. Note: this covers the call to fscrypt_find_master_key() from inode key setup, but not from the fscrypt ioctls. So, this isn't *exactly* the same as the key being present from the very beginning. I think we can tolerate that, though, since the inode key setup caller is the only one that actually matters in the context of test_dummy_encryption. Signed-off-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20230208062107.199831-2-ebiggers@kernel.org 2022-12-01T19:23:58+00:00 Tianjia Zhang tianjia.zhang@linux.alibaba.com 2022-12-01T12:58:19+00:00 urn:sha1:e0cefada1383c5ceb5a35f08369d0d40a6629c18 Add support for XTS and CTS mode variant of SM4 algorithm. The former is used to encrypt file contents, while the latter (SM4-CTS-CBC) is used to encrypt filenames. SM4 is a symmetric algorithm widely used in China, and is even mandatory algorithm in some special scenarios. We need to provide these users with the ability to encrypt files or disks using SM4-XTS. Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Signed-off-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20221201125819.36932-3-tianjia.zhang@linux.alibaba.com 2022-11-16T01:19:29+00:00 Eric Biggers ebiggers@google.com 2022-11-10T08:29:42+00:00 urn:sha1:02aef4225258fa6d022ce9040716aeecc3afc521 As this code confused Linus [1], pass the super_block as an argument to fscrypt_put_master_key_activeref(). This removes the need to have the back-pointer ->mk_sb, so remove that. [1] https://lore.kernel.org/linux-fscrypt/CAHk-=wgud4Bc_um+htgfagYpZAnOoCb3NUoW67hc9LhOKsMtJg@mail.gmail.com Signed-off-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20221110082942.351615-1-ebiggers@kernel.org 2022-09-22T03:33:06+00:00 Eric Biggers ebiggers@google.com 2022-09-01T19:32:07+00:00 urn:sha1:22e9947a4b2ba255888541bd0111cf00b9b16586 Now that the fscrypt_master_key lifetime has been reworked to not be subject to the quirks of the keyrings subsystem, blk_crypto_evict_key() no longer gets called after the filesystem has already been unmounted. Therefore, there is no longer any need to hold extra references to the filesystem's request_queue(s). (And these references didn't always do their intended job anyway, as pinning a request_queue doesn't necessarily pin the corresponding blk_crypto_profile.) Stop taking these extra references. Instead, just pass the super_block to fscrypt_destroy_inline_crypt_key(), and use it to get the list of block devices the key needs to be evicted from. Signed-off-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20220901193208.138056-3-ebiggers@kernel.org 2022-09-22T03:33:06+00:00 Eric Biggers ebiggers@google.com 2022-09-01T19:32:06+00:00 urn:sha1:d7e7b9af104c7b389a0c21eb26532511bce4b510 The approach of fs/crypto/ internally managing the fscrypt_master_key structs as the payloads of "struct key" objects contained in a "struct key" keyring has outlived its usefulness. The original idea was to simplify the code by reusing code from the keyrings subsystem. However, several issues have arisen that can't easily be resolved: - When a master key struct is destroyed, blk_crypto_evict_key() must be called on any per-mode keys embedded in it. (This started being the case when inline encryption support was added.) Yet, the keyrings subsystem can arbitrarily delay the destruction of keys, even past the time the filesystem was unmounted. Therefore, currently there is no easy way to call blk_crypto_evict_key() when a master key is destroyed. Currently, this is worked around by holding an extra reference to the filesystem's request_queue(s). But it was overlooked that the request_queue reference is *not* guaranteed to pin the corresponding blk_crypto_profile too; for device-mapper devices that support inline crypto, it doesn't. This can cause a use-after-free. - When the last inode that was using an incompletely-removed master key is evicted, the master key removal is completed by removing the key struct from the keyring. Currently this is done via key_invalidate(). Yet, key_invalidate() takes the key semaphore. This can deadlock when called from the shrinker, since in fscrypt_ioctl_add_key(), memory is allocated with GFP_KERNEL under the same semaphore. - More generally, the fact that the keyrings subsystem can arbitrarily delay the destruction of keys (via garbage collection delay, or via random processes getting temporary key references) is undesirable, as it means we can't strictly guarantee that all secrets are ever wiped. - Doing the master key lookups via the keyrings subsystem results in the key_permission LSM hook being called. fscrypt doesn't want this, as all access control for encrypted files is designed to happen via the files themselves, like any other files. The workaround which SELinux users are using is to change their SELinux policy to grant key search access to all domains. This works, but it is an odd extra step that shouldn't really have to be done. The fix for all these issues is to change the implementation to what I should have done originally: don't use the keyrings subsystem to keep track of the filesystem's fscrypt_master_key structs. Instead, just store them in a regular kernel data structure, and rework the reference counting, locking, and lifetime accordingly. Retain support for RCU-mode key lookups by using a hash table. Replace fscrypt_sb_free() with fscrypt_sb_delete(), which releases the keys synchronously and runs a bit earlier during unmount, so that block devices are still available. A side effect of this patch is that neither the master keys themselves nor the filesystem keyrings will be listed in /proc/keys anymore. ("Master key users" and the master key users keyrings will still be listed.) However, this was mostly an implementation detail, and it was intended just for debugging purposes. I don't know of anyone using it. This patch does *not* change how "master key users" (->mk_users) works; that still uses the keyrings subsystem. That is still needed for key quotas, and changing that isn't necessary to solve the issues listed above. If we decide to change that too, it would be a separate patch. I've marked this as fixing the original commit that added the fscrypt keyring, but as noted above the most important issue that this patch fixes wasn't introduced until the addition of inline encryption support. Fixes: 22d94f493bfb ("fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl") Signed-off-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20220901193208.138056-2-ebiggers@kernel.org 2022-06-10T08:40:18+00:00 Nathan Huckleberry nhuck@google.com 2022-05-20T18:15:01+00:00 urn:sha1:6b2a51ff03bf0c54cbc699ee85a9a49eb203ebfc HCTR2 is a tweakable, length-preserving encryption mode that is intended for use on CPUs with dedicated crypto instructions. HCTR2 has the property that a bitflip in the plaintext changes the entire ciphertext. This property fixes a known weakness with filename encryption: when two filenames in the same directory share a prefix of >= 16 bytes, with AES-CTS-CBC their encrypted filenames share a common substring, leaking information. HCTR2 does not have this problem. More information on HCTR2 can be found here: "Length-preserving encryption with HCTR2": https://eprint.iacr.org/2021/1441.pdf Signed-off-by: Nathan Huckleberry <nhuck@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 2022-05-09T23:18:54+00:00 Eric Biggers ebiggers@google.com 2022-05-01T05:08:53+00:00 urn:sha1:bfb9700bdf35417454a9bb8b67221d89d7c6e75a Factor out a function that builds the fscrypt_key_specifier for an fscrypt_policy. Before this was only needed when finding the key for a file, but now it will also be needed for test_dummy_encryption support. Signed-off-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20220501050857.538984-4-ebiggers@kernel.org 2022-04-14T05:35:25+00:00 Eric Biggers ebiggers@google.com 2022-04-14T05:34:15+00:00 urn:sha1:a7a5bc5fe8acc9381e38a34ef18f1115c5c22079 When inline encryption is used, the usual message "fscrypt: AES-256-XTS using implementation <impl>" doesn't appear in the kernel log. Add a similar message for the blk-crypto case that indicates that inline encryption was used, and whether blk-crypto-fallback was used or not. This can be useful for debugging performance problems. Signed-off-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20220414053415.158986-1-ebiggers@kernel.org 2021-10-26T02:11:50+00:00 Eric Biggers ebiggers@google.com 2021-10-26T02:10:42+00:00 urn:sha1:b7e072f9b77f4c516df96e0c22ec09f8b2e76ba1 Improve a few comments. These were extracted from the patch "fscrypt: add support for hardware-wrapped keys" (https://lore.kernel.org/r/20211021181608.54127-4-ebiggers@kernel.org). Link: https://lore.kernel.org/r/20211026021042.6581-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com>