From patchwork Tue Aug 8 17:08:18 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sweet Tea Dorminy X-Patchwork-Id: 13346620 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4B32BC41513 for ; Tue, 8 Aug 2023 18:08:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235233AbjHHSII (ORCPT ); Tue, 8 Aug 2023 14:08:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42520 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232793AbjHHSHb (ORCPT ); Tue, 8 Aug 2023 14:07:31 -0400 Received: from box.fidei.email (box.fidei.email [71.19.144.250]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 27561A79F; Tue, 8 Aug 2023 10:08:43 -0700 (PDT) Received: from authenticated-user (box.fidei.email [71.19.144.250]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by box.fidei.email (Postfix) with ESMTPSA id AAD3083542; Tue, 8 Aug 2023 13:08:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorminy.me; s=mail; t=1691514522; bh=EpXn3+Jbg9QKzxgKqdj40m8q6/qRVvmn6DMf3mB1H6M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SlBcPQozXmlyllCwjaKAuBH4FEgYdsv3LWrftDWC75PKg7esjTRKMinZtmpIYqKHU adjzybnJzXDBysonXM3x5RG/iqitMXGEhcl6TpswsuL3A7DOlwVDrcErunSri032MH 76yldCK0iQI7MFlI0tYI71Pci4y3SuH2jxYzaDjbOX57Pu6/JPxFJdUyl3aGGF0jy0 bl6gyUdiwOJ0R5mJOQZL6KvayinHTtWyOF82e3MGbhV8RPJXrZE9P8jkE6PjrlLBNm nUlbqENTn5cdPe/bRzuW8uh4yUliGxre2t0YsEUoeJ8Q+Gra5svbdDV+RvA+Cqsd7f TN6BalfJhoSJg== From: Sweet Tea Dorminy To: Chris Mason , Josef Bacik , David Sterba , "Theodore Y . Ts'o" , Jaegeuk Kim , kernel-team@meta.com, linux-btrfs@vger.kernel.org, linux-fscrypt@vger.kernel.org, Eric Biggers Cc: Sweet Tea Dorminy Subject: [PATCH v3 01/16] fscrypt: factor helper for locking master key Date: Tue, 8 Aug 2023 13:08:18 -0400 Message-ID: <5b791b93e0697db89c8a02df633f7be97f5ba58c.1691505882.git.sweettea-kernel@dorminy.me> In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org When we are making extent infos, we'll need to lock the master key in more places, so go on and factor out a helper. Signed-off-by: Sweet Tea Dorminy --- fs/crypto/keysetup.c | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c index a19650f954e2..c3d3da5da449 100644 --- a/fs/crypto/keysetup.c +++ b/fs/crypto/keysetup.c @@ -106,7 +106,18 @@ select_encryption_mode(const union fscrypt_policy *policy, return ERR_PTR(-EINVAL); } -/* Create a symmetric cipher object for the given encryption mode and key */ +static int lock_master_key(struct fscrypt_master_key *mk) +{ + down_read(&mk->mk_sem); + + /* Has the secret been removed (via FS_IOC_REMOVE_ENCRYPTION_KEY)? */ + if (!is_master_key_secret_present(&mk->mk_secret)) + return -ENOKEY; + + return 0; +} + +/* Create a symmetric cipher object for the given encryption mode */ static struct crypto_skcipher * fscrypt_allocate_skcipher(struct fscrypt_mode *mode, const u8 *raw_key, const struct inode *inode) @@ -556,13 +567,10 @@ static int find_and_lock_master_key(const struct fscrypt_info *ci, *mk_ret = NULL; return 0; } - down_read(&mk->mk_sem); - /* Has the secret been removed (via FS_IOC_REMOVE_ENCRYPTION_KEY)? */ - if (!is_master_key_secret_present(&mk->mk_secret)) { - err = -ENOKEY; + err = lock_master_key(mk); + if (err) goto out_release_key; - } if (!fscrypt_valid_master_key_size(mk, ci)) { err = -ENOKEY; From patchwork Tue Aug 8 17:08:19 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sweet Tea Dorminy X-Patchwork-Id: 13346621 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 44588C04FE1 for ; Tue, 8 Aug 2023 18:08:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235244AbjHHSIK (ORCPT ); Tue, 8 Aug 2023 14:08:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42530 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232239AbjHHSHo (ORCPT ); Tue, 8 Aug 2023 14:07:44 -0400 Received: from box.fidei.email (box.fidei.email [IPv6:2605:2700:0:2:a800:ff:feba:dc44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8B7DEA799; Tue, 8 Aug 2023 10:08:44 -0700 (PDT) Received: from authenticated-user (box.fidei.email [71.19.144.250]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by box.fidei.email (Postfix) with ESMTPSA id 21BCC83543; Tue, 8 Aug 2023 13:08:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorminy.me; s=mail; t=1691514524; bh=kxcFIEA+Tz7C5XSXfEIV9jwTiWVBlr8UrdIiPo4CwNM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RpXbYm2oW73XnXn6IIAir2piVjayWKOmwlkRCBPGqvC41pgZrJaFnIBJMocEd5WY0 HWG81e29yLflbD8mmMt9Uyq6VSA4mP/C6dlVZutDaIMQd+6BwBKGWaS2AJoqbOQ2nP 99ofWSwfE+8gB3qAZxKnIu1p6vf2qwP3hqjBlo6nVH0zirqcPy+NNI4GUv0D1HOFvV 5Gps7z7XkAZR8OAgFcFqDj8IDUDEy4qQeLC4Y6ki5Yn/BUhBD2qRM7MbSlqNETr0jt BCs862L2paztf1EqKV9na+F+KgZyQV185lveTIkQB83b8h42q9vYZNAr99voA432xJ K7YIefx2piozQ== From: Sweet Tea Dorminy To: Chris Mason , Josef Bacik , David Sterba , "Theodore Y . Ts'o" , Jaegeuk Kim , kernel-team@meta.com, linux-btrfs@vger.kernel.org, linux-fscrypt@vger.kernel.org, Eric Biggers Cc: Sweet Tea Dorminy Subject: [PATCH v3 02/16] fscrypt: factor getting info for a specific block Date: Tue, 8 Aug 2023 13:08:19 -0400 Message-ID: <88e9d0d51a7adff46ebca4868e802d2b598f27d7.1691505882.git.sweettea-kernel@dorminy.me> In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org For filesystems using extent-based encryption, the content of each extent will be encrypted with a different fscrypt_info for each extent. Meanwhile, directories and symlinks will continue to use the fscrypt_info for the inode. Therefore, merely grabbing inode->i_crypt_info will be insufficient; the caller must specifically request the inode info or the info for a specific block. Add fscrypt_get_lblk_info() to get info for a specific block, and update all relevant callsites. Signed-off-by: Sweet Tea Dorminy --- fs/crypto/crypto.c | 3 ++- fs/crypto/fscrypt_private.h | 29 +++++++++++++++++++++++++++++ fs/crypto/inline_crypt.c | 10 ++++++---- 3 files changed, 37 insertions(+), 5 deletions(-) diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c index 9f3bda18c797..1b7e375b1c6b 100644 --- a/fs/crypto/crypto.c +++ b/fs/crypto/crypto.c @@ -107,7 +107,8 @@ int fscrypt_crypt_block(const struct inode *inode, fscrypt_direction_t rw, struct skcipher_request *req = NULL; DECLARE_CRYPTO_WAIT(wait); struct scatterlist dst, src; - struct fscrypt_info *ci = inode->i_crypt_info; + struct fscrypt_info *ci = + fscrypt_get_lblk_info(inode, lblk_num, NULL, NULL); struct crypto_skcipher *tfm = ci->ci_enc_key->tfm; int res = 0; diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h index e2acd8894ea7..8a1fd1d33cfc 100644 --- a/fs/crypto/fscrypt_private.h +++ b/fs/crypto/fscrypt_private.h @@ -277,6 +277,35 @@ typedef enum { FS_ENCRYPT, } fscrypt_direction_t; +/** + * fscrypt_get_lblk_info() - get the fscrypt_info to crypt a particular block + * + * @inode: the inode to which the block belongs + * @lblk: the offset of the block within the file which the inode + * references + * @offset: a pointer to return the offset of the block from the first block + * that the info covers. For inode-based encryption, this will + * always be @lblk; for extent-based encryption, this will be in + * the range [0, lblk]. Can be NULL + * @extent_len: a pointer to return the minimum number of lblks starting at + * this offset which also belong to the same fscrypt_info. Can be + * NULL + * + * Return: the appropriate fscrypt_info if there is one, else NULL. + */ +static inline struct fscrypt_info * +fscrypt_get_lblk_info(const struct inode *inode, u64 lblk, u64 *offset, + u64 *extent_len) +{ + if (offset) + *offset = lblk; + if (extent_len) + *extent_len = U64_MAX; + + return inode->i_crypt_info; +} + + /* crypto.c */ extern struct kmem_cache *fscrypt_info_cachep; int fscrypt_initialize(struct super_block *sb); diff --git a/fs/crypto/inline_crypt.c b/fs/crypto/inline_crypt.c index 2063f7941ce6..885a2ec3d711 100644 --- a/fs/crypto/inline_crypt.c +++ b/fs/crypto/inline_crypt.c @@ -270,7 +270,7 @@ void fscrypt_set_bio_crypt_ctx(struct bio *bio, const struct inode *inode, if (!fscrypt_inode_uses_inline_crypto(inode)) return; - ci = inode->i_crypt_info; + ci = fscrypt_get_lblk_info(inode, first_lblk, NULL, NULL); fscrypt_generate_dun(ci, first_lblk, dun); bio_crypt_set_ctx(bio, ci->ci_enc_key->blk_key, dun, gfp_mask); @@ -349,21 +349,23 @@ bool fscrypt_mergeable_bio(struct bio *bio, const struct inode *inode, { const struct bio_crypt_ctx *bc = bio->bi_crypt_context; u64 next_dun[BLK_CRYPTO_DUN_ARRAY_SIZE]; + struct fscrypt_info *ci; if (!!bc != fscrypt_inode_uses_inline_crypto(inode)) return false; if (!bc) return true; + ci = fscrypt_get_lblk_info(inode, next_lblk, NULL, NULL); /* * Comparing the key pointers is good enough, as all I/O for each key * uses the same pointer. I.e., there's currently no need to support * merging requests where the keys are the same but the pointers differ. */ - if (bc->bc_key != inode->i_crypt_info->ci_enc_key->blk_key) + if (bc->bc_key != ci->ci_enc_key->blk_key) return false; - fscrypt_generate_dun(inode->i_crypt_info, next_lblk, next_dun); + fscrypt_generate_dun(ci, next_lblk, next_dun); return bio_crypt_dun_is_contiguous(bc, bio->bi_iter.bi_size, next_dun); } EXPORT_SYMBOL_GPL(fscrypt_mergeable_bio); @@ -465,7 +467,7 @@ u64 fscrypt_limit_io_blocks(const struct inode *inode, u64 lblk, u64 nr_blocks) if (nr_blocks <= 1) return nr_blocks; - ci = inode->i_crypt_info; + ci = fscrypt_get_lblk_info(inode, lblk, NULL, NULL); if (!(fscrypt_policy_flags(&ci->ci_policy) & FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32)) return nr_blocks; From patchwork Tue Aug 8 17:08:20 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sweet Tea Dorminy X-Patchwork-Id: 13346622 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9DA19C04A6A for ; Tue, 8 Aug 2023 18:08:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235316AbjHHSIO (ORCPT ); Tue, 8 Aug 2023 14:08:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41574 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235261AbjHHSHp (ORCPT ); Tue, 8 Aug 2023 14:07:45 -0400 Received: from box.fidei.email (box.fidei.email [IPv6:2605:2700:0:2:a800:ff:feba:dc44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 05E7AA7A0; Tue, 8 Aug 2023 10:08:45 -0700 (PDT) Received: from authenticated-user (box.fidei.email [71.19.144.250]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by box.fidei.email (Postfix) with ESMTPSA id 7D28C83545; Tue, 8 Aug 2023 13:08:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorminy.me; s=mail; t=1691514525; bh=EZsG1gGgKChupzzFm3iQhX2nJ7xoA/ZL78TwI1gPkn0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XcYAu9epsOV84klrqmlwxlZs903C7IVoYliPb83PGtlR49CQCZV9sAx8cAmt0cq39 ry7WrEN6pDLRi0noIhySBUyaIAhwC5lpRpDy/wlr0Ym0wO2dGE8Vr5AV2xD2Bszdn8 6meogotxoqe603eresbGH4cboRFAFj+B27PaEwXIvPrfzRUevDOsH4xmuOYbmr2WMP pIg/7ny+bVnVwb7vT3vAddF4xKRKlXFnhTxxzVW+oOmgNfXAR4Vxjs31aWBC/cGeno yl273LzeioVFaeHTbTAd/KjK0aw5YFQ4Z2dXRaSKyirI0ZeKPI3rkni3Jqco2gFLLu DBKFmTH81NLkw== From: Sweet Tea Dorminy To: Chris Mason , Josef Bacik , David Sterba , "Theodore Y . Ts'o" , Jaegeuk Kim , kernel-team@meta.com, linux-btrfs@vger.kernel.org, linux-fscrypt@vger.kernel.org, Eric Biggers Cc: Sweet Tea Dorminy Subject: [PATCH v3 03/16] fscrypt: adjust effective lblks based on extents Date: Tue, 8 Aug 2023 13:08:20 -0400 Message-ID: <18ea31ce7c82c80536a11fe605153cf34bb1b22f.1691505882.git.sweettea-kernel@dorminy.me> In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org If a filesystem uses extent-based encryption, then the offset within a file is not a constant which can be used for calculating an IV. For instance, the same extent could be blocks 0-8 in one file, and blocks 100-108 in another file. Instead, the block offset within the extent must be used instead. Update all uses of logical block offset within the file to use logical block offset within the extent, if applicable. Signed-off-by: Sweet Tea Dorminy --- fs/crypto/crypto.c | 3 ++- fs/crypto/inline_crypt.c | 20 ++++++++++++++------ 2 files changed, 16 insertions(+), 7 deletions(-) diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c index 1b7e375b1c6b..d75f1b3f5795 100644 --- a/fs/crypto/crypto.c +++ b/fs/crypto/crypto.c @@ -107,8 +107,9 @@ int fscrypt_crypt_block(const struct inode *inode, fscrypt_direction_t rw, struct skcipher_request *req = NULL; DECLARE_CRYPTO_WAIT(wait); struct scatterlist dst, src; + u64 ci_offset = 0; struct fscrypt_info *ci = - fscrypt_get_lblk_info(inode, lblk_num, NULL, NULL); + fscrypt_get_lblk_info(inode, lblk_num, &ci_offset, NULL); struct crypto_skcipher *tfm = ci->ci_enc_key->tfm; int res = 0; diff --git a/fs/crypto/inline_crypt.c b/fs/crypto/inline_crypt.c index 885a2ec3d711..2d08abbf5892 100644 --- a/fs/crypto/inline_crypt.c +++ b/fs/crypto/inline_crypt.c @@ -267,12 +267,13 @@ void fscrypt_set_bio_crypt_ctx(struct bio *bio, const struct inode *inode, { const struct fscrypt_info *ci; u64 dun[BLK_CRYPTO_DUN_ARRAY_SIZE]; + u64 ci_offset = 0; if (!fscrypt_inode_uses_inline_crypto(inode)) return; - ci = fscrypt_get_lblk_info(inode, first_lblk, NULL, NULL); + ci = fscrypt_get_lblk_info(inode, first_lblk, &ci_offset, NULL); - fscrypt_generate_dun(ci, first_lblk, dun); + fscrypt_generate_dun(ci, ci_offset, dun); bio_crypt_set_ctx(bio, ci->ci_enc_key->blk_key, dun, gfp_mask); } EXPORT_SYMBOL_GPL(fscrypt_set_bio_crypt_ctx); @@ -350,13 +351,14 @@ bool fscrypt_mergeable_bio(struct bio *bio, const struct inode *inode, const struct bio_crypt_ctx *bc = bio->bi_crypt_context; u64 next_dun[BLK_CRYPTO_DUN_ARRAY_SIZE]; struct fscrypt_info *ci; + u64 ci_offset = 0; if (!!bc != fscrypt_inode_uses_inline_crypto(inode)) return false; if (!bc) return true; - ci = fscrypt_get_lblk_info(inode, next_lblk, NULL, NULL); + ci = fscrypt_get_lblk_info(inode, next_lblk, &ci_offset, NULL); /* * Comparing the key pointers is good enough, as all I/O for each key * uses the same pointer. I.e., there's currently no need to support @@ -365,7 +367,7 @@ bool fscrypt_mergeable_bio(struct bio *bio, const struct inode *inode, if (bc->bc_key != ci->ci_enc_key->blk_key) return false; - fscrypt_generate_dun(ci, next_lblk, next_dun); + fscrypt_generate_dun(ci, ci_offset, next_dun); return bio_crypt_dun_is_contiguous(bc, bio->bi_iter.bi_size, next_dun); } EXPORT_SYMBOL_GPL(fscrypt_mergeable_bio); @@ -460,6 +462,8 @@ u64 fscrypt_limit_io_blocks(const struct inode *inode, u64 lblk, u64 nr_blocks) { const struct fscrypt_info *ci; u32 dun; + u64 ci_offset = 0; + u64 extent_len = 0; if (!fscrypt_inode_uses_inline_crypto(inode)) return nr_blocks; @@ -467,14 +471,18 @@ u64 fscrypt_limit_io_blocks(const struct inode *inode, u64 lblk, u64 nr_blocks) if (nr_blocks <= 1) return nr_blocks; - ci = fscrypt_get_lblk_info(inode, lblk, NULL, NULL); + ci = fscrypt_get_lblk_info(inode, lblk, &ci_offset, &extent_len); + + /* Spanning an extent boundary will change the DUN */ + nr_blocks = min_t(u64, nr_blocks, extent_len); + if (!(fscrypt_policy_flags(&ci->ci_policy) & FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32)) return nr_blocks; /* With IV_INO_LBLK_32, the DUN can wrap around from U32_MAX to 0. */ - dun = ci->ci_hashed_ino + lblk; + dun = ci->ci_hashed_ino + ci_offset; return min_t(u64, nr_blocks, (u64)U32_MAX + 1 - dun); } From patchwork Tue Aug 8 17:08:21 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sweet Tea Dorminy X-Patchwork-Id: 13346624 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EFCECC04FE0 for ; Tue, 8 Aug 2023 18:08:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235275AbjHHSIQ (ORCPT ); Tue, 8 Aug 2023 14:08:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43820 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235276AbjHHSHq (ORCPT ); Tue, 8 Aug 2023 14:07:46 -0400 Received: from box.fidei.email (box.fidei.email [IPv6:2605:2700:0:2:a800:ff:feba:dc44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 77FD4A7A7; Tue, 8 Aug 2023 10:08:47 -0700 (PDT) Received: from authenticated-user (box.fidei.email [71.19.144.250]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by box.fidei.email (Postfix) with ESMTPSA id 0A18783546; Tue, 8 Aug 2023 13:08:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorminy.me; s=mail; t=1691514527; bh=tVgXiL/66UVYLWPk5NcvopcfEqC0N8Mf2PBXpjtkfbA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LYg9dhlhzL0yUUnVNU1cjMRYUYmUAbid7uVtLYLieob2NZPu2fnyDUsoLIR7H0ac8 4GSqBQw0bvjyZiJfQiByOjeSMMXAWajUnC4PMpWC2yBa/Es311+vRWCLivPExC4+h4 DNrJ0ZZpyWHnzHFS1DJtHINQ/PR19BW/gDoXNMwYxix1brBDWH9pbD3Fk84pA7kI7S 7/1MuKTKW72QetSFf4UPbrQ8xLzVL5dowFkZxMOkujEBaDVGZBBlAI+Oo7Zj/7KkgS cjmlzAoexwZt/4uJXRliczkPvF6gdmvpmaWaUrwCA6IMMy8uUVOxqoW7SlveJ+B6tb 7cqj95FfEiXgg== From: Sweet Tea Dorminy To: Chris Mason , Josef Bacik , David Sterba , "Theodore Y . Ts'o" , Jaegeuk Kim , kernel-team@meta.com, linux-btrfs@vger.kernel.org, linux-fscrypt@vger.kernel.org, Eric Biggers Cc: Sweet Tea Dorminy Subject: [PATCH v3 04/16] fscrypt: add a super_block pointer to fscrypt_info Date: Tue, 8 Aug 2023 13:08:21 -0400 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org When fscrypt_infos are attached to extents instead of inodes, we can't go through the inode to get at the filesystems's superblock. Therefore, add a dedicated superblock pointer to fscrypt_info to keep track of it. Signed-off-by: Sweet Tea Dorminy --- fs/crypto/fscrypt_private.h | 3 +++ fs/crypto/inline_crypt.c | 4 ++-- fs/crypto/keysetup.c | 10 +++++----- fs/crypto/keysetup_v1.c | 6 +++--- 4 files changed, 13 insertions(+), 10 deletions(-) diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h index 8a1fd1d33cfc..8a6e359f96cf 100644 --- a/fs/crypto/fscrypt_private.h +++ b/fs/crypto/fscrypt_private.h @@ -241,6 +241,9 @@ struct fscrypt_info { /* Back-pointer to the inode */ struct inode *ci_inode; + /* The superblock of the filesystem to which this info pertains */ + struct super_block *ci_sb; + /* * The master key with which this inode was unlocked (decrypted). This * will be NULL if the master key was found in a process-subscribed diff --git a/fs/crypto/inline_crypt.c b/fs/crypto/inline_crypt.c index 2d08abbf5892..260152d5e673 100644 --- a/fs/crypto/inline_crypt.c +++ b/fs/crypto/inline_crypt.c @@ -41,7 +41,7 @@ static struct block_device **fscrypt_get_devices(struct super_block *sb, static unsigned int fscrypt_get_dun_bytes(const struct fscrypt_info *ci) { - struct super_block *sb = ci->ci_inode->i_sb; + struct super_block *sb = ci->ci_sb; unsigned int flags = fscrypt_policy_flags(&ci->ci_policy); int ino_bits = 64, lblk_bits = 64; @@ -155,7 +155,7 @@ int fscrypt_prepare_inline_crypt_key(struct fscrypt_prepared_key *prep_key, const struct fscrypt_info *ci) { const struct inode *inode = ci->ci_inode; - struct super_block *sb = inode->i_sb; + struct super_block *sb = ci->ci_sb; enum blk_crypto_mode_num crypto_mode = ci->ci_mode->blk_crypto_mode; struct blk_crypto_key *blk_key; struct block_device **devs; diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c index c3d3da5da449..c5f68cf65a6f 100644 --- a/fs/crypto/keysetup.c +++ b/fs/crypto/keysetup.c @@ -250,8 +250,7 @@ static int setup_new_mode_prepared_key(struct fscrypt_master_key *mk, struct fscrypt_prepared_key *prep_key, const struct fscrypt_info *ci) { - const struct inode *inode = ci->ci_inode; - const struct super_block *sb = inode->i_sb; + const struct super_block *sb = ci->ci_sb; unsigned int policy_flags = fscrypt_policy_flags(&ci->ci_policy); struct fscrypt_mode *mode = ci->ci_mode; const u8 mode_num = mode - fscrypt_modes; @@ -525,7 +524,7 @@ static bool fscrypt_valid_master_key_size(const struct fscrypt_master_key *mk, static int find_and_lock_master_key(const struct fscrypt_info *ci, struct fscrypt_master_key **mk_ret) { - struct super_block *sb = ci->ci_inode->i_sb; + struct super_block *sb = ci->ci_sb; struct fscrypt_key_specifier mk_spec; struct fscrypt_master_key *mk; int err; @@ -599,7 +598,7 @@ static void put_crypt_info(struct fscrypt_info *ci) if (type == FSCRYPT_KEY_DIRECT_V1) fscrypt_put_direct_key(ci->ci_enc_key); if (type == FSCRYPT_KEY_PER_INFO) { - fscrypt_destroy_prepared_key(ci->ci_inode->i_sb, + fscrypt_destroy_prepared_key(ci->ci_sb, ci->ci_enc_key); kfree_sensitive(ci->ci_enc_key); } @@ -616,7 +615,7 @@ static void put_crypt_info(struct fscrypt_info *ci) spin_lock(&mk->mk_decrypted_inodes_lock); list_del(&ci->ci_master_key_link); spin_unlock(&mk->mk_decrypted_inodes_lock); - fscrypt_put_master_key_activeref(ci->ci_inode->i_sb, mk); + fscrypt_put_master_key_activeref(ci->ci_sb, mk); } memzero_explicit(ci, sizeof(*ci)); kmem_cache_free(fscrypt_info_cachep, ci); @@ -642,6 +641,7 @@ fscrypt_setup_encryption_info(struct inode *inode, return -ENOMEM; crypt_info->ci_inode = inode; + crypt_info->ci_sb = inode->i_sb; crypt_info->ci_policy = *policy; memcpy(crypt_info->ci_nonce, nonce, FSCRYPT_FILE_NONCE_SIZE); diff --git a/fs/crypto/keysetup_v1.c b/fs/crypto/keysetup_v1.c index 1e785cedead0..41d317f08aeb 100644 --- a/fs/crypto/keysetup_v1.c +++ b/fs/crypto/keysetup_v1.c @@ -235,7 +235,7 @@ fscrypt_get_direct_key(const struct fscrypt_info *ci, const u8 *raw_key) dk = kzalloc(sizeof(*dk), GFP_KERNEL); if (!dk) return ERR_PTR(-ENOMEM); - dk->dk_sb = ci->ci_inode->i_sb; + dk->dk_sb = ci->ci_sb; refcount_set(&dk->dk_refcount, 1); dk->dk_mode = ci->ci_mode; dk->dk_key.type = FSCRYPT_KEY_DIRECT_V1; @@ -309,8 +309,8 @@ int fscrypt_setup_v1_file_key_via_subscribed_keyrings(struct fscrypt_info *ci) key = find_and_lock_process_key(FSCRYPT_KEY_DESC_PREFIX, ci->ci_policy.v1.master_key_descriptor, ci->ci_mode->keysize, &payload); - if (key == ERR_PTR(-ENOKEY) && ci->ci_inode->i_sb->s_cop->key_prefix) { - key = find_and_lock_process_key(ci->ci_inode->i_sb->s_cop->key_prefix, + if (key == ERR_PTR(-ENOKEY) && ci->ci_sb->s_cop->key_prefix) { + key = find_and_lock_process_key(ci->ci_sb->s_cop->key_prefix, ci->ci_policy.v1.master_key_descriptor, ci->ci_mode->keysize, &payload); } From patchwork Tue Aug 8 17:08:22 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sweet Tea Dorminy X-Patchwork-Id: 13346628 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0DE9DC04FDF for ; Tue, 8 Aug 2023 18:08:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230390AbjHHSIV (ORCPT ); Tue, 8 Aug 2023 14:08:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41658 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230368AbjHHSH6 (ORCPT ); Tue, 8 Aug 2023 14:07:58 -0400 Received: from box.fidei.email (box.fidei.email [71.19.144.250]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8EB34A7AB; Tue, 8 Aug 2023 10:08:50 -0700 (PDT) Received: from authenticated-user (box.fidei.email [71.19.144.250]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by box.fidei.email (Postfix) with ESMTPSA id 665A083548; Tue, 8 Aug 2023 13:08:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorminy.me; s=mail; t=1691514528; bh=Epty68b+w8wZKhrQqqPg88yNrPvpeNikltq+NN0Z/+g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bn/e8kTFFt4qaUKGuHYO6S/0ynZL5nYfkl+/nI9ga6XNTvzNnSVwgWIm6Yf650sz6 2j48R5flz6y6kti2Rr9BUIqgZQY8LuerNqBFEOuTdm/6Lxp6zShCwOjnAoTaTUh/WG 3oTbfuqCBbnDLT1zPJgppWF0BEdZjp/ej9j3U028yfwOPEpQxH9WmxfTnFKIYru5Cc UovZGzlsUHonV1XU9pU4RqK1hRdqufeloxSlPVi+GlLl+eYImVsFBESzjUyqFPgO5j MdF/9r/cm6LZVg1Zt8nQ6P/PhzV4PfgRLLnNIS3c5+r4L7RVhcor4pS7OgPqbhjc74 HRZhlnseIKk2g== From: Sweet Tea Dorminy To: Chris Mason , Josef Bacik , David Sterba , "Theodore Y . Ts'o" , Jaegeuk Kim , kernel-team@meta.com, linux-btrfs@vger.kernel.org, linux-fscrypt@vger.kernel.org, Eric Biggers Cc: Sweet Tea Dorminy Subject: [PATCH v3 05/16] fscrypt: setup leaf inodes for extent encryption Date: Tue, 8 Aug 2023 13:08:22 -0400 Message-ID: <7db769e801bc4a2b9ff935d76bc83cf3c1232235.1691505882.git.sweettea-kernel@dorminy.me> In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org For extent-based encryption, leaf/regular file inodes are special: it's useful to set their i_crypt_info field so that it's easy to inherit their encryption policy for a new extent, but they never need to do any encyption themselves. Additionally, since encryption can only be set up on a directory, not a single file, their encryption policy can always duplicate their parent inode's policy. Signed-off-by: Sweet Tea Dorminy --- fs/crypto/fscrypt_private.h | 17 +++++++++++ fs/crypto/keysetup.c | 60 ++++++++++++++++++++++++++++--------- 2 files changed, 63 insertions(+), 14 deletions(-) diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h index 8a6e359f96cf..df1c5ae82d85 100644 --- a/fs/crypto/fscrypt_private.h +++ b/fs/crypto/fscrypt_private.h @@ -308,6 +308,23 @@ fscrypt_get_lblk_info(const struct inode *inode, u64 lblk, u64 *offset, return inode->i_crypt_info; } +/** + * fscrypt_uses_extent_encryption() -- whether an inode uses per-extent + * encryption + * + * @inode: the inode in question + * + * Return: true if the inode uses per-extent fscrypt_infos, false otherwise + */ +static inline bool fscrypt_uses_extent_encryption(const struct inode *inode) +{ + /* Non-regular files don't have extents */ + if (!S_ISREG(inode->i_mode)) + return false; + + /* No filesystems currently use per-extent infos */ + return false; +} /* crypto.c */ extern struct kmem_cache *fscrypt_info_cachep; diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c index c5f68cf65a6f..9b3806ab7ccb 100644 --- a/fs/crypto/keysetup.c +++ b/fs/crypto/keysetup.c @@ -726,6 +726,26 @@ fscrypt_setup_encryption_info(struct inode *inode, return res; } +static bool get_parent_policy_and_nonce(struct inode *inode, + union fscrypt_policy *policy, + u8 *nonce) +{ + struct dentry *dentry = d_find_any_alias(inode); + struct dentry *parent_dentry = dget_parent(dentry); + struct inode *dir = parent_dentry->d_inode; + bool found = false; + + if (dir->i_crypt_info) { + found = true; + *policy = dir->i_crypt_info->ci_policy; + memcpy(nonce, dir->i_crypt_info->ci_nonce, + FSCRYPT_FILE_NONCE_SIZE); + } + dput(parent_dentry); + dput(dentry); + return found; +} + /** * fscrypt_get_encryption_info() - set up an inode's encryption key * @inode: the inode to set up the key for. Must be encrypted. @@ -747,27 +767,39 @@ fscrypt_setup_encryption_info(struct inode *inode, int fscrypt_get_encryption_info(struct inode *inode, bool allow_unsupported) { int res; - union fscrypt_context ctx; + union fscrypt_context ctx = { 0 }; union fscrypt_policy policy; + const u8 *nonce; + u8 nonce_bytes[FSCRYPT_FILE_NONCE_SIZE]; if (fscrypt_has_encryption_key(inode)) return 0; - res = inode->i_sb->s_cop->get_context(inode, &ctx, sizeof(ctx)); - if (res < 0) { - if (res == -ERANGE && allow_unsupported) + if (fscrypt_uses_extent_encryption(inode)) { + /* + * Nothing will be encrypted with this info, so we can borrow + * the parent (dir) inode's policy and use a zero nonce. + */ + if (!get_parent_policy_and_nonce(inode, &policy, nonce_bytes)) return 0; - fscrypt_warn(inode, "Error %d getting encryption context", res); - return res; - } + nonce = nonce_bytes; + } else { + res = inode->i_sb->s_cop->get_context(inode, &ctx, sizeof(ctx)); + if (res < 0) { + if (res == -ERANGE && allow_unsupported) + return 0; + fscrypt_warn(inode, "Error %d getting encryption context", res); + return res; + } - res = fscrypt_policy_from_context(&policy, &ctx, res); - if (res) { - if (allow_unsupported) - return 0; - fscrypt_warn(inode, - "Unrecognized or corrupt encryption context"); - return res; + res = fscrypt_policy_from_context(&policy, &ctx, res); + if (res) { + if (allow_unsupported) + return 0; + fscrypt_warn(inode, + "Unrecognized or corrupt encryption context"); + return res; + } } if (!fscrypt_supported_policy(&policy, inode)) { From patchwork Tue Aug 8 17:08:23 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sweet Tea Dorminy X-Patchwork-Id: 13346627 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C46C9C07E8B for ; Tue, 8 Aug 2023 18:08:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235289AbjHHSIT (ORCPT ); Tue, 8 Aug 2023 14:08:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41632 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235286AbjHHSHw (ORCPT ); Tue, 8 Aug 2023 14:07:52 -0400 Received: from box.fidei.email (box.fidei.email [IPv6:2605:2700:0:2:a800:ff:feba:dc44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8EBD615C796; Tue, 8 Aug 2023 10:08:50 -0700 (PDT) Received: from authenticated-user (box.fidei.email [71.19.144.250]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by box.fidei.email (Postfix) with ESMTPSA id BE4B383549; Tue, 8 Aug 2023 13:08:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorminy.me; s=mail; t=1691514530; bh=30Kvlvez90KN6W/1ONh+BWInubmHeWXe255twvMwCxA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uaBI+xYcNIDamNIhrFVD0jVPQoECum0RVXnj/tXPHkZkalXn0yR1K8gcAN/AoLUzY UgYOXffc9cKgVU2ywf/TfIVnr7wXj50sAsTulZ7bnNEmGUNRLuf28krGNDNrhydVay eU4hgFh2XVjM/hHEzr/uNKGsPnuhO0TvrTymrvJNjNW2ENgA4As4GbNEIhbZUka22c dzGOik6oafCyDDlxLQ4+TdE3EjGG077o32U3kpKzVBqnNNbnq/addsdwPdoaCu4SD/ YcgjhfkPX7gai2cGE91rROC2iWfRtHjD4spixJz4YCT5ObtwiU6jqR/S0lUUTJHVSX vGEVpaBQ8ljhA== From: Sweet Tea Dorminy To: Chris Mason , Josef Bacik , David Sterba , "Theodore Y . Ts'o" , Jaegeuk Kim , kernel-team@meta.com, linux-btrfs@vger.kernel.org, linux-fscrypt@vger.kernel.org, Eric Biggers Cc: Sweet Tea Dorminy Subject: [PATCH v3 06/16] fscrypt: allow infos to be owned by extents Date: Tue, 8 Aug 2023 13:08:23 -0400 Message-ID: <6f3c4013a48c973a913fab08757fc2a4437ebf75.1691505882.git.sweettea-kernel@dorminy.me> In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org In order to notify extents when their info is part of a master key which is going away, the fscrypt_info must have a backpointer to the extent somehow. Similarly, if a fscrypt_info is owned by an extent, the info must not have a pointer to an inode -- multiple inodes may reference a extent, and the first inode to cause an extent's creation may have a lifetime much shorter than the extent, so there is no inode pointer safe to track in an extent-owned info. Therefore, this adds a new pointer for extent-owned infos to track their extent and updates fscrypt_setup_encryption_info() accordingly. Since it's simple to track the piece of extent memory pointing to the info, and for the extent to then go from such a pointer to the whole extent via container_of(), we store that. Although some sort of generic void * or some artificial fscrypt_extent embedded structure would also work, those would require additional plumbing which doesn't seem strictly required or clarifying. Signed-off-by: Sweet Tea Dorminy --- fs/crypto/fscrypt_private.h | 6 +++++ fs/crypto/keysetup.c | 45 ++++++++++++++++++++++++++++--------- 2 files changed, 40 insertions(+), 11 deletions(-) diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h index df1c5ae82d85..1244797cd8a9 100644 --- a/fs/crypto/fscrypt_private.h +++ b/fs/crypto/fscrypt_private.h @@ -241,6 +241,12 @@ struct fscrypt_info { /* Back-pointer to the inode */ struct inode *ci_inode; + /* + * Back-pointer to the info pointer in the extent, for infos owned by + * an extent. + */ + struct fscrypt_info **ci_info_ptr; + /* The superblock of the filesystem to which this info pertains */ struct super_block *ci_sb; diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c index 9b3806ab7ccb..c72f9015ed35 100644 --- a/fs/crypto/keysetup.c +++ b/fs/crypto/keysetup.c @@ -625,12 +625,17 @@ static int fscrypt_setup_encryption_info(struct inode *inode, const union fscrypt_policy *policy, const u8 nonce[FSCRYPT_FILE_NONCE_SIZE], - bool need_dirhash_key) + bool need_dirhash_key, + struct fscrypt_info **info_ptr) { struct fscrypt_info *crypt_info; struct fscrypt_mode *mode; struct fscrypt_master_key *mk = NULL; int res; + bool info_for_extent = !!info_ptr; + + if (!info_ptr) + info_ptr = &inode->i_crypt_info; res = fscrypt_initialize(inode->i_sb); if (res) @@ -640,6 +645,9 @@ fscrypt_setup_encryption_info(struct inode *inode, if (!crypt_info) return -ENOMEM; + if (fscrypt_uses_extent_encryption(inode) && info_for_extent) + crypt_info->ci_info_ptr = info_ptr; + crypt_info->ci_inode = inode; crypt_info->ci_sb = inode->i_sb; crypt_info->ci_policy = *policy; @@ -656,6 +664,12 @@ fscrypt_setup_encryption_info(struct inode *inode, res = fscrypt_select_encryption_impl(crypt_info); if (res) goto out; + if (info_for_extent && !fscrypt_using_inline_encryption(crypt_info)) { + fscrypt_warn(inode, + "extent encryption requires inlinecrypt mount option"); + res = -EINVAL; + goto out; + } res = find_and_lock_master_key(crypt_info, &mk); if (res) @@ -701,7 +715,7 @@ fscrypt_setup_encryption_info(struct inode *inode, * fscrypt_get_info(). I.e., here we publish ->i_crypt_info with a * RELEASE barrier so that other tasks can ACQUIRE it. */ - if (cmpxchg_release(&inode->i_crypt_info, NULL, crypt_info) == NULL) { + if (cmpxchg_release(info_ptr, NULL, crypt_info) == NULL) { /* * We won the race and set ->i_crypt_info to our crypt_info. * Now link it into the master key's inode list. @@ -755,7 +769,7 @@ static bool get_parent_policy_and_nonce(struct inode *inode, * %false unless the operation being performed is needed in * order for files (or directories) to be deleted. * - * Set up ->i_crypt_info, if it hasn't already been done. + * Set up inode->i_crypt_info, if it hasn't already been done. * * Note: unless ->i_crypt_info is already set, this isn't %GFP_NOFS-safe. So * generally this shouldn't be called from within a filesystem transaction. @@ -767,7 +781,7 @@ static bool get_parent_policy_and_nonce(struct inode *inode, int fscrypt_get_encryption_info(struct inode *inode, bool allow_unsupported) { int res; - union fscrypt_context ctx = { 0 }; + union fscrypt_context ctx; union fscrypt_policy policy; const u8 *nonce; u8 nonce_bytes[FSCRYPT_FILE_NONCE_SIZE]; @@ -778,7 +792,7 @@ int fscrypt_get_encryption_info(struct inode *inode, bool allow_unsupported) if (fscrypt_uses_extent_encryption(inode)) { /* * Nothing will be encrypted with this info, so we can borrow - * the parent (dir) inode's policy and use a zero nonce. + * the parent (dir) inode's policy and nonce. */ if (!get_parent_policy_and_nonce(inode, &policy, nonce_bytes)) return 0; @@ -800,6 +814,7 @@ int fscrypt_get_encryption_info(struct inode *inode, bool allow_unsupported) "Unrecognized or corrupt encryption context"); return res; } + nonce = fscrypt_context_nonce(&ctx); } if (!fscrypt_supported_policy(&policy, inode)) { @@ -808,10 +823,10 @@ int fscrypt_get_encryption_info(struct inode *inode, bool allow_unsupported) return -EINVAL; } - res = fscrypt_setup_encryption_info(inode, &policy, - fscrypt_context_nonce(&ctx), + res = fscrypt_setup_encryption_info(inode, &policy, nonce, IS_CASEFOLDED(inode) && - S_ISDIR(inode->i_mode)); + S_ISDIR(inode->i_mode), + NULL); if (res == -ENOPKG && allow_unsupported) /* Algorithm unavailable? */ res = 0; @@ -845,7 +860,8 @@ int fscrypt_prepare_new_inode(struct inode *dir, struct inode *inode, bool *encrypt_ret) { const union fscrypt_policy *policy; - u8 nonce[FSCRYPT_FILE_NONCE_SIZE]; + u8 nonce_bytes[FSCRYPT_FILE_NONCE_SIZE]; + const u8 *nonce; policy = fscrypt_policy_to_inherit(dir); if (policy == NULL) @@ -867,10 +883,17 @@ int fscrypt_prepare_new_inode(struct inode *dir, struct inode *inode, *encrypt_ret = true; - get_random_bytes(nonce, FSCRYPT_FILE_NONCE_SIZE); + if (fscrypt_uses_extent_encryption(inode)) { + nonce = dir->i_crypt_info->ci_nonce; + } else { + get_random_bytes(nonce_bytes, FSCRYPT_FILE_NONCE_SIZE); + nonce = nonce_bytes; + } + return fscrypt_setup_encryption_info(inode, policy, nonce, IS_CASEFOLDED(dir) && - S_ISDIR(inode->i_mode)); + S_ISDIR(inode->i_mode), + NULL); } EXPORT_SYMBOL_GPL(fscrypt_prepare_new_inode); From patchwork Tue Aug 8 17:08:24 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sweet Tea Dorminy X-Patchwork-Id: 13346626 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 347CEC05052 for ; Tue, 8 Aug 2023 18:08:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235287AbjHHSIS (ORCPT ); Tue, 8 Aug 2023 14:08:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41628 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234666AbjHHSHv (ORCPT ); Tue, 8 Aug 2023 14:07:51 -0400 Received: from box.fidei.email (box.fidei.email [IPv6:2605:2700:0:2:a800:ff:feba:dc44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1327D15C79C; Tue, 8 Aug 2023 10:08:52 -0700 (PDT) Received: from authenticated-user (box.fidei.email [71.19.144.250]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by box.fidei.email (Postfix) with ESMTPSA id 269A283541; Tue, 8 Aug 2023 13:08:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorminy.me; s=mail; t=1691514531; bh=3CMnpmL0Kr6obvHQbD6FakWQ2Z0IBBiXI6JhTNhzBqI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=E9aDoeE8+nCbA0TVEfa/v7WEWisrhA0lYU0ZIpLOaiLdkRN75YqN0mjMSms9aimjN JGxwcp+/G3Uz/em/jUgj/XBqC74vzB8fMuSOpuy/jK53RyxzTgGt5alCnYt5zvTePc hhZ4pFrvCPahMRv1rQeUNhCJPp82gQKl/O6vIx9W1bQcftyEGLqJJzxTnMUOvZmbGr yBXoK5Nw+Y8fs9F3faK9NQPZBl9srjoPO5dKTpkWVSc9+BY0CDSTOJrskeLPMDoKBf PqoOQMroL+QhfbTfylKDVqfnuSY+df+jvRcnXRXO/PTDGuUge9gJ414Heq2LDszow9 V2GaZPg6P2Qxg== From: Sweet Tea Dorminy To: Chris Mason , Josef Bacik , David Sterba , "Theodore Y . Ts'o" , Jaegeuk Kim , kernel-team@meta.com, linux-btrfs@vger.kernel.org, linux-fscrypt@vger.kernel.org, Eric Biggers Cc: Sweet Tea Dorminy Subject: [PATCH v3 07/16] fscrypt: use an optional ino equivalent for per-extent infos Date: Tue, 8 Aug 2023 13:08:24 -0400 Message-ID: <8c40d7b6897875be8f908ca4aabf280c2f15b8d4.1691505882.git.sweettea-kernel@dorminy.me> In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org Since per-extent infos are not tied to inodes, an ino-based policy cannot access the inode's i_ino to get the necessary information. Instead, this adds an optional fscrypt_operation pointer to get the ino equivalent for an extent, adds a wrapper to get the ino for an info, and uses this wrapper everywhere where the ci's inode's i_ino is currently accessed. Signed-off-by: Sweet Tea Dorminy --- fs/crypto/fscrypt_private.h | 18 ++++++++++++++++++ fs/crypto/keyring.c | 8 ++++---- fs/crypto/keysetup.c | 6 +++--- include/linux/fscrypt.h | 9 +++++++++ 4 files changed, 34 insertions(+), 7 deletions(-) diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h index 1244797cd8a9..4fe79b774f1f 100644 --- a/fs/crypto/fscrypt_private.h +++ b/fs/crypto/fscrypt_private.h @@ -332,6 +332,24 @@ static inline bool fscrypt_uses_extent_encryption(const struct inode *inode) return false; } +/** + * fscrypt_get_info_ino() - get the ino or ino equivalent for an info + * + * @ci: the fscrypt_info in question + * + * Return: For inode-based encryption, this will return the info's inode's ino. + * For extent-based encryption, this will return the extent's ino equivalent + * or 0 if it is not implemented. + */ +static inline u64 fscrypt_get_info_ino(const struct fscrypt_info *ci) +{ + if (ci->ci_inode) + return ci->ci_inode->i_ino; + if (!ci->ci_sb->s_cop->get_extent_ino_equivalent) + return 0; + return ci->ci_sb->s_cop->get_extent_ino_equivalent(ci->ci_info_ptr); +} + /* crypto.c */ extern struct kmem_cache *fscrypt_info_cachep; int fscrypt_initialize(struct super_block *sb); diff --git a/fs/crypto/keyring.c b/fs/crypto/keyring.c index 7cbb1fd872ac..53e37b8a822c 100644 --- a/fs/crypto/keyring.c +++ b/fs/crypto/keyring.c @@ -914,12 +914,12 @@ static int check_for_busy_inodes(struct super_block *sb, } { - /* select an example file to show for debugging purposes */ - struct inode *inode = + /* select an example info to show for debugging purposes */ + struct fscrypt_info *ci = list_first_entry(&mk->mk_decrypted_inodes, struct fscrypt_info, - ci_master_key_link)->ci_inode; - ino = inode->i_ino; + ci_master_key_link); + ino = fscrypt_get_info_ino(ci); } spin_unlock(&mk->mk_decrypted_inodes_lock); diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c index c72f9015ed35..32e62cc57708 100644 --- a/fs/crypto/keysetup.c +++ b/fs/crypto/keysetup.c @@ -380,10 +380,10 @@ int fscrypt_derive_dirhash_key(struct fscrypt_info *ci, void fscrypt_hash_inode_number(struct fscrypt_info *ci, const struct fscrypt_master_key *mk) { - WARN_ON_ONCE(ci->ci_inode->i_ino == 0); + WARN_ON_ONCE(fscrypt_get_info_ino(ci) == 0); WARN_ON_ONCE(!mk->mk_ino_hash_key_initialized); - ci->ci_hashed_ino = (u32)siphash_1u64(ci->ci_inode->i_ino, + ci->ci_hashed_ino = (u32)siphash_1u64(fscrypt_get_info_ino(ci), &mk->mk_ino_hash_key); } @@ -705,7 +705,7 @@ fscrypt_setup_encryption_info(struct inode *inode, if (res) goto out; - if (inode->i_ino) + if (fscrypt_get_info_ino(crypt_info)) fscrypt_hash_inode_number(crypt_info, mk); } diff --git a/include/linux/fscrypt.h b/include/linux/fscrypt.h index c895b12737a1..2a64e7a71a53 100644 --- a/include/linux/fscrypt.h +++ b/include/linux/fscrypt.h @@ -160,6 +160,15 @@ struct fscrypt_operations { void (*get_ino_and_lblk_bits)(struct super_block *sb, int *ino_bits_ret, int *lblk_bits_ret); + /* + * Get the inode number equivalent for filesystems using per-extent + * encryption keys. + * + * This function only needs to be implemented if support for one of the + * FSCRYPT_POLICY_FLAG_IV_INO_* flags is needed. + */ + u64 (*get_extent_ino_equivalent)(struct fscrypt_info **info_ptr); + /* * Return an array of pointers to the block devices to which the * filesystem may write encrypted file contents, NULL if the filesystem From patchwork Tue Aug 8 17:08:25 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sweet Tea Dorminy X-Patchwork-Id: 13346625 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 234ABC04FE2 for ; Tue, 8 Aug 2023 18:08:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235282AbjHHSIS (ORCPT ); Tue, 8 Aug 2023 14:08:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43942 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235284AbjHHSHw (ORCPT ); Tue, 8 Aug 2023 14:07:52 -0400 Received: from box.fidei.email (box.fidei.email [IPv6:2605:2700:0:2:a800:ff:feba:dc44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1357015C79D; Tue, 8 Aug 2023 10:08:52 -0700 (PDT) Received: from authenticated-user (box.fidei.email [71.19.144.250]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by box.fidei.email (Postfix) with ESMTPSA id 7D4C48354B; Tue, 8 Aug 2023 13:08:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorminy.me; s=mail; t=1691514532; bh=xrjfPasFbA6CG7iZqMar52Dj4MLDOfsgZokr8j3aMYw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OvjcCO/AYRNf05nzYP7Ecc+fUiTXnbVZC42y0MBcxQByjA9HLZuxhaFxiG+4XYbRG +WlRRfpiDU7nx3RSeoCoNePDycqAswEFsJnVYihWunb9jrDwvwfX/KCHgZZVkHYN0X wTtEAHBDKZ+cVx71bVOkjzlshIRMzMZbb+hOy+tZ3pkkh5d6VkOIUGoJh5DHoL1EAt v21IhDurSrXojZ8Qql9IDO3U0zE069+0QvqHPv2CSyiO8Y5w5E0RQugcEuyyqD6pAU EnlEdQcA01Le54aJ4NanLK4CG4O9d+gtScKvIIy/DzEn94YNMVaypV1uZi7ayme/O3 daMFyHS6FHJgA== From: Sweet Tea Dorminy To: Chris Mason , Josef Bacik , David Sterba , "Theodore Y . Ts'o" , Jaegeuk Kim , kernel-team@meta.com, linux-btrfs@vger.kernel.org, linux-fscrypt@vger.kernel.org, Eric Biggers Cc: Sweet Tea Dorminy Subject: [PATCH v3 08/16] fscrypt: move function call warning of busy inodes Date: Tue, 8 Aug 2023 13:08:25 -0400 Message-ID: <2e0b78a61f26eb7c3f17df759fa5bd2513f886ea.1691505882.git.sweettea-kernel@dorminy.me> In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org Extent encryption will want to attempt to evict inodes, and not warn of busy ones, before removing the key instead of after as it is at present. Therefore pull the call for check_for_busy_inodes() out of try_to_lock_encrypted_files() into its only callsite. Signed-off-by: Sweet Tea Dorminy --- fs/crypto/keyring.c | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/fs/crypto/keyring.c b/fs/crypto/keyring.c index 53e37b8a822c..9d00cadb19ee 100644 --- a/fs/crypto/keyring.c +++ b/fs/crypto/keyring.c @@ -938,8 +938,7 @@ static int check_for_busy_inodes(struct super_block *sb, static int try_to_lock_encrypted_files(struct super_block *sb, struct fscrypt_master_key *mk) { - int err1; - int err2; + int err; /* * An inode can't be evicted while it is dirty or has dirty pages. @@ -951,7 +950,7 @@ static int try_to_lock_encrypted_files(struct super_block *sb, * already call sync_filesystem() via sys_syncfs() or sys_sync(). */ down_read(&sb->s_umount); - err1 = sync_filesystem(sb); + err = sync_filesystem(sb); up_read(&sb->s_umount); /* If a sync error occurs, still try to evict as much as possible. */ @@ -963,16 +962,7 @@ static int try_to_lock_encrypted_files(struct super_block *sb, */ evict_dentries_for_decrypted_inodes(mk); - /* - * evict_dentries_for_decrypted_inodes() already iput() each inode in - * the list; any inodes for which that dropped the last reference will - * have been evicted due to fscrypt_drop_inode() detecting the key - * removal and telling the VFS to evict the inode. So to finish, we - * just need to check whether any inodes couldn't be evicted. - */ - err2 = check_for_busy_inodes(sb, mk); - - return err1 ?: err2; + return err; } /* @@ -1064,8 +1054,17 @@ static int do_remove_key(struct file *filp, void __user *_uarg, bool all_users) up_write(&mk->mk_sem); if (inodes_remain) { + int err2; /* Some inodes still reference this key; try to evict them. */ err = try_to_lock_encrypted_files(sb, mk); + /* We already tried to iput() each inode referencing this key + * which would cause the inode to be evicted if that was the + * last reference (since fscrypt_drop_inode() would see the + * key removal). So the only remaining inodes referencing this + * key are still busy and couldn't be evicted; check for them. + */ + err2 = check_for_busy_inodes(sb, mk); + err = err ?: err2; if (err == -EBUSY) { status_flags |= FSCRYPT_KEY_REMOVAL_STATUS_FLAG_FILES_BUSY; From patchwork Tue Aug 8 17:08:26 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sweet Tea Dorminy X-Patchwork-Id: 13346629 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7DE9C41513 for ; Tue, 8 Aug 2023 18:08:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235293AbjHHSIV (ORCPT ); Tue, 8 Aug 2023 14:08:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60356 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229506AbjHHSH5 (ORCPT ); Tue, 8 Aug 2023 14:07:57 -0400 Received: from box.fidei.email (box.fidei.email [IPv6:2605:2700:0:2:a800:ff:feba:dc44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4519015C7A0; Tue, 8 Aug 2023 10:08:55 -0700 (PDT) Received: from authenticated-user (box.fidei.email [71.19.144.250]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by box.fidei.email (Postfix) with ESMTPSA id D138683542; Tue, 8 Aug 2023 13:08:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorminy.me; s=mail; t=1691514534; bh=X5VZrDl+HOopD5CK3S8HzBpQk1qElsBaYmp5R12HdyE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=E1uL6sm01fSkdjao8WB4efclHN4Bp50SxCP6i2swQOD9z5kHwxqpSjCBeHR6Ul3H2 jXxxrjOL9rSiOdFJ55JB2lYQXennagQ3TBwCcU0tiHiywPEDilV8ZPvjSMe/smdB8d L8aq2K565DplaVUpjahn6GPl9pN4xenYzStUHcDsmMDj8yuHv9LAGAVekWgPI2yoyu xqtaSMGhv9MmW3ZYaNXArCw6JOSbxIXoZs3mvBgijlw9GrBHL1QoDX1DzeMHvSwsWX wHEZnxx1L8bq9yAyEWGSEeVDUngimlsiXz9Flnfyu1Bd7p8OOI+JzrfVBTCPNmmYfi nPKQIXpPfHeAw== From: Sweet Tea Dorminy To: Chris Mason , Josef Bacik , David Sterba , "Theodore Y . Ts'o" , Jaegeuk Kim , kernel-team@meta.com, linux-btrfs@vger.kernel.org, linux-fscrypt@vger.kernel.org, Eric Biggers Cc: Sweet Tea Dorminy Subject: [PATCH v3 09/16] fscrypt: revamp key removal for extent encryption Date: Tue, 8 Aug 2023 13:08:26 -0400 Message-ID: <25ca0cf3c15e92509718a0638563e21497a1d82d.1691505882.git.sweettea-kernel@dorminy.me> In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org Currently, for inode encryption, once an inode is open IO will not fail due to lack of key until the inode is closed. Even if the key is removed, open inodes will continue to use the key. For extent encryption, it's a little harder, since the extent may not be createdi/loaded until well after the REMOVE_KEY ioctl is called. To be as similar to inode based encryption as plausible, this changes key removal to be 'soft' for extent-based encryption, allowing new extents to use keys which were in use by open inodes at the time of removal; this hopefully follows the discussion at [1]. [1] https://lore.kernel.org/linux-fscrypt/248eac32-96cc-eb2e-85da-422a8d75a376@dorminy.me/T/#m48f43837cf98e0212de2e70aa6435320e3532d6e Signed-off-by: Sweet Tea Dorminy --- fs/crypto/fscrypt_private.h | 37 ++++++++++++++++++++++++++++++----- fs/crypto/keyring.c | 39 +++++++++++++++++++++++++++---------- fs/crypto/keysetup.c | 35 ++++++++++++++++++++++++++++++++- 3 files changed, 95 insertions(+), 16 deletions(-) diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h index 4fe79b774f1f..21e4e138cfcc 100644 --- a/fs/crypto/fscrypt_private.h +++ b/fs/crypto/fscrypt_private.h @@ -332,6 +332,21 @@ static inline bool fscrypt_uses_extent_encryption(const struct inode *inode) return false; } +/** + * fscrypt_fs_uses_extent_encryption() -- whether a filesystem uses per-extent + * encryption + * + * @sb: the superblock of the filesystem in question + * + * Return: true if the fs uses per-extent fscrypt_infos, false otherwise + */ +static inline bool +fscrypt_fs_uses_extent_encryption(const struct super_block *sb) +{ + // No filesystems currently use per-extent infos + return false; +} + /** * fscrypt_get_info_ino() - get the ino or ino equivalent for an info * @@ -556,11 +571,14 @@ struct fscrypt_master_key { /* * The secret key material. After FS_IOC_REMOVE_ENCRYPTION_KEY is - * executed, this is wiped and no new inodes can be unlocked with this - * key; however, there may still be inodes in ->mk_decrypted_inodes - * which could not be evicted. As long as some inodes still remain, - * FS_IOC_REMOVE_ENCRYPTION_KEY can be retried, or - * FS_IOC_ADD_ENCRYPTION_KEY can add the secret again. + * executed, no new inodes can be unlocked with this key; however, + * there may still be inodes in ->mk_decrypted_inodes which could not + * be evicted. For inode-based encryption, the secret is wiped; for + * extent-based encryption, the secret is preserved while inodes still + * reference it, as they may need to create new extents using the + * secret to service IO; @soft_deleted is set to true then. As long as + * some inodes still remain, FS_IOC_REMOVE_ENCRYPTION_KEY can be + * retried, or FS_IOC_ADD_ENCRYPTION_KEY can add the secret again. * * While ->mk_secret is present, one ref in ->mk_active_refs is held. * @@ -599,6 +617,13 @@ struct fscrypt_master_key { struct list_head mk_decrypted_inodes; spinlock_t mk_decrypted_inodes_lock; + /* + * Whether the key is unavailable to new inodes, but still available + * to new extents within decrypted inodes. Protected by ->mk_sem, except + * for race-okay access in fscrypt_drop_inode(). + */ + bool mk_soft_deleted; + /* * Per-mode encryption keys for the various types of encryption policies * that use them. Allocated and derived on-demand. @@ -626,6 +651,8 @@ is_master_key_secret_present(const struct fscrypt_master_key_secret *secret) return READ_ONCE(secret->size) != 0; } +void fscrypt_wipe_master_key_secret(struct fscrypt_master_key_secret *secret); + static inline const char *master_key_spec_type( const struct fscrypt_key_specifier *spec) { diff --git a/fs/crypto/keyring.c b/fs/crypto/keyring.c index 9d00cadb19ee..feca4a8410bb 100644 --- a/fs/crypto/keyring.c +++ b/fs/crypto/keyring.c @@ -38,7 +38,7 @@ struct fscrypt_keyring { struct hlist_head key_hashtable[128]; }; -static void wipe_master_key_secret(struct fscrypt_master_key_secret *secret) +void fscrypt_wipe_master_key_secret(struct fscrypt_master_key_secret *secret) { fscrypt_destroy_hkdf(&secret->hkdf); memzero_explicit(secret, sizeof(*secret)); @@ -239,8 +239,9 @@ void fscrypt_destroy_keyring(struct super_block *sb) */ WARN_ON_ONCE(refcount_read(&mk->mk_active_refs) != 1); WARN_ON_ONCE(refcount_read(&mk->mk_struct_refs) != 1); - WARN_ON_ONCE(!is_master_key_secret_present(&mk->mk_secret)); - wipe_master_key_secret(&mk->mk_secret); + WARN_ON_ONCE(!mk->mk_soft_deleted && + !is_master_key_secret_present(&mk->mk_secret)); + fscrypt_wipe_master_key_secret(&mk->mk_secret); fscrypt_put_master_key_activeref(sb, mk); } } @@ -485,6 +486,8 @@ static int add_existing_master_key(struct fscrypt_master_key *mk, move_master_key_secret(&mk->mk_secret, secret); } + mk->mk_soft_deleted = false; + return 0; } @@ -738,7 +741,7 @@ int fscrypt_ioctl_add_key(struct file *filp, void __user *_uarg) goto out_wipe_secret; err = 0; out_wipe_secret: - wipe_master_key_secret(&secret); + fscrypt_wipe_master_key_secret(&secret); return err; } EXPORT_SYMBOL_GPL(fscrypt_ioctl_add_key); @@ -770,7 +773,7 @@ int fscrypt_get_test_dummy_key_identifier( NULL, 0, key_identifier, FSCRYPT_KEY_IDENTIFIER_SIZE); out: - wipe_master_key_secret(&secret); + fscrypt_wipe_master_key_secret(&secret); return err; } @@ -794,7 +797,7 @@ int fscrypt_add_test_dummy_key(struct super_block *sb, fscrypt_get_test_dummy_secret(&secret); err = add_master_key(sb, &secret, key_spec); - wipe_master_key_secret(&secret); + fscrypt_wipe_master_key_secret(&secret); return err; } @@ -1017,6 +1020,12 @@ static int do_remove_key(struct file *filp, void __user *_uarg, bool all_users) mk = fscrypt_find_master_key(sb, &arg.key_spec); if (!mk) return -ENOKEY; + + if (fscrypt_fs_uses_extent_encryption(sb)) { + /* Keep going even if this has an error. */ + try_to_lock_encrypted_files(sb, mk); + } + down_write(&mk->mk_sem); /* If relevant, remove current user's (or all users) claim to the key */ @@ -1043,13 +1052,23 @@ static int do_remove_key(struct file *filp, void __user *_uarg, bool all_users) } } - /* No user claims remaining. Go ahead and wipe the secret. */ + /* No user claims remaining. */ err = -ENOKEY; - if (is_master_key_secret_present(&mk->mk_secret)) { - wipe_master_key_secret(&mk->mk_secret); + if (fscrypt_fs_uses_extent_encryption(sb) && refcount_read(&mk->mk_active_refs) > 1) { + mk->mk_soft_deleted = true; + err = 0; + } else if (is_master_key_secret_present(&mk->mk_secret)) { + fscrypt_wipe_master_key_secret(&mk->mk_secret); fscrypt_put_master_key_activeref(sb, mk); err = 0; + } else if (mk->mk_soft_deleted) { + /* + * Was soft deleted, but all inodes have stopped using it, and + * the secret was wiped by the last one. + */ + err = 0; } + inodes_remain = refcount_read(&mk->mk_active_refs) > 0; up_write(&mk->mk_sem); @@ -1149,7 +1168,7 @@ int fscrypt_ioctl_get_key_status(struct file *filp, void __user *uarg) } down_read(&mk->mk_sem); - if (!is_master_key_secret_present(&mk->mk_secret)) { + if (mk->mk_soft_deleted || !is_master_key_secret_present(&mk->mk_secret)) { arg.status = refcount_read(&mk->mk_active_refs) > 0 ? FSCRYPT_KEY_STATUS_INCOMPLETELY_REMOVED : FSCRYPT_KEY_STATUS_ABSENT /* raced with full removal */; diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c index 32e62cc57708..51d3787fc964 100644 --- a/fs/crypto/keysetup.c +++ b/fs/crypto/keysetup.c @@ -576,6 +576,15 @@ static int find_and_lock_master_key(const struct fscrypt_info *ci, goto out_release_key; } + if (!ci->ci_info_ptr && mk->mk_soft_deleted) { + /* + * This is an inode info, and only extent infos can use keys + * that have been soft deleted + */ + err = -ENOKEY; + goto out_release_key; + } + *mk_ret = mk; return 0; @@ -606,6 +615,8 @@ static void put_crypt_info(struct fscrypt_info *ci) mk = ci->ci_master_key; if (mk) { + bool any_inodes; + /* * Remove this inode from the list of inodes that were unlocked * with the master key. In addition, if we're removing the last @@ -614,7 +625,28 @@ static void put_crypt_info(struct fscrypt_info *ci) */ spin_lock(&mk->mk_decrypted_inodes_lock); list_del(&ci->ci_master_key_link); + any_inodes = list_empty(&mk->mk_decrypted_inodes); spin_unlock(&mk->mk_decrypted_inodes_lock); + if (any_inodes) { + bool soft_deleted; + /* It might be that someone tried to remove this key, + * but there were still inodes open that could need new + * extents, which needed to be able to access the key + * secret. But now this was the last reference. So we + * can delete the key secret now. (We don't need to + * check for new inodes on the decrypted_inode list + * because once ->mk_soft_deleted is set, no new inode + * can join the list. + */ + down_write(&mk->mk_sem); + soft_deleted = mk->mk_soft_deleted; + if (soft_deleted) + fscrypt_wipe_master_key_secret(&mk->mk_secret); + up_write(&mk->mk_sem); + if (soft_deleted) + fscrypt_put_master_key_activeref(ci->ci_sb, mk); + } + fscrypt_put_master_key_activeref(ci->ci_sb, mk); } memzero_explicit(ci, sizeof(*ci)); @@ -967,6 +999,7 @@ int fscrypt_drop_inode(struct inode *inode) * then the thread removing the key will either evict the inode itself * or will correctly detect that it wasn't evicted due to the race. */ - return !is_master_key_secret_present(&ci->ci_master_key->mk_secret); + return READ_ONCE(ci->ci_master_key->mk_soft_deleted) || + !is_master_key_secret_present(&ci->ci_master_key->mk_secret); } EXPORT_SYMBOL_GPL(fscrypt_drop_inode); From patchwork Tue Aug 8 17:08:27 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sweet Tea Dorminy X-Patchwork-Id: 13346623 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C8C05C04FDF for ; Tue, 8 Aug 2023 18:08:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235271AbjHHSIP (ORCPT ); Tue, 8 Aug 2023 14:08:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42566 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235265AbjHHSHp (ORCPT ); Tue, 8 Aug 2023 14:07:45 -0400 Received: from box.fidei.email (box.fidei.email [71.19.144.250]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A6F5B15C7A2; Tue, 8 Aug 2023 10:08:55 -0700 (PDT) Received: from authenticated-user (box.fidei.email [71.19.144.250]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by box.fidei.email (Postfix) with ESMTPSA id 3199C83543; Tue, 8 Aug 2023 13:08:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorminy.me; s=mail; t=1691514535; bh=fOSvrrVtQ5iVMFBJHPU0XoJq9Jff085wcvNJlZttEIs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ixv/kZv1JgW6Iwe6b9oWHgaCvuzgbYKXaIwRuaU7Uje5ghwIlTGMx3x5SoPoJepfc /hVadZUafX4Z60mfT57uOTQkty5IK+hk00DVFQfNZBneAkQzOqwaL+CuoE24/qi7tj JeUb2g8w3f1zKj4PBZxZiBgwJCLwfzmC1hzonuQ1S5DANswymNA/fG7OhGXFgMbVOg WZigw9FQN4d4iRe32s91L4PPP4M29jHCYORGtavhXnc5XD4Guyq+s4QE+JgOzs6WaN X/dE8UU9kSbC+FCdlAXwCdR7MgjJd7PsinenLLCz38xR3RYAkNl/B5EyS+8nOH5I7+ A75o3LVJEJPww== From: Sweet Tea Dorminy To: Chris Mason , Josef Bacik , David Sterba , "Theodore Y . Ts'o" , Jaegeuk Kim , kernel-team@meta.com, linux-btrfs@vger.kernel.org, linux-fscrypt@vger.kernel.org, Eric Biggers Cc: Sweet Tea Dorminy Subject: [PATCH v3 10/16] fscrypt: add creation/usage/freeing of per-extent infos Date: Tue, 8 Aug 2023 13:08:27 -0400 Message-ID: <9405e6a6ea1891b0fbe5b3e871b80b4079ab4df6.1691505882.git.sweettea-kernel@dorminy.me> In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org This change adds the superblock function pointer to get the info corresponding to a specific block in an inode for a filesystem using per-extent infos. It allows creating a info for a new extent and freeing that info, and uses the extent's info if appropriate in encrypting blocks of data. It also makes sure that the return value of fscrypt_get_lblk_info() is non-NULL before using it, since there's no longer a mechanical guarantee that we'll never call fscrypt_get_lblk_info() without having the relevant info loaded. We *oughtn't*, but we're not explicitly checking that it's loaded before these points. This change does not deal with saving and loading an extent's info, but introduces the mechanics necessary therefore. Signed-off-by: Sweet Tea Dorminy --- fs/crypto/crypto.c | 2 + fs/crypto/fscrypt_private.h | 74 +++++++++++++++++++++---------------- fs/crypto/inline_crypt.c | 5 ++- fs/crypto/keysetup.c | 54 +++++++++++++++++++++++++++ include/linux/fscrypt.h | 39 +++++++++++++++++++ 5 files changed, 141 insertions(+), 33 deletions(-) diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c index d75f1b3f5795..0f0c721e40fe 100644 --- a/fs/crypto/crypto.c +++ b/fs/crypto/crypto.c @@ -113,6 +113,8 @@ int fscrypt_crypt_block(const struct inode *inode, fscrypt_direction_t rw, struct crypto_skcipher *tfm = ci->ci_enc_key->tfm; int res = 0; + if (!ci) + return -EINVAL; if (WARN_ON_ONCE(len <= 0)) return -EINVAL; if (WARN_ON_ONCE(len % FSCRYPT_CONTENTS_ALIGNMENT != 0)) diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h index 21e4e138cfcc..c6bf0bd0259a 100644 --- a/fs/crypto/fscrypt_private.h +++ b/fs/crypto/fscrypt_private.h @@ -287,31 +287,17 @@ typedef enum { } fscrypt_direction_t; /** - * fscrypt_get_lblk_info() - get the fscrypt_info to crypt a particular block + * fscrypt_fs_uses_extent_encryption() -- whether a filesystem uses per-extent + * encryption * - * @inode: the inode to which the block belongs - * @lblk: the offset of the block within the file which the inode - * references - * @offset: a pointer to return the offset of the block from the first block - * that the info covers. For inode-based encryption, this will - * always be @lblk; for extent-based encryption, this will be in - * the range [0, lblk]. Can be NULL - * @extent_len: a pointer to return the minimum number of lblks starting at - * this offset which also belong to the same fscrypt_info. Can be - * NULL + * @sb: the superblock of the filesystem in question * - * Return: the appropriate fscrypt_info if there is one, else NULL. + * Return: true if the fs uses per-extent fscrypt_infos, false otherwise */ -static inline struct fscrypt_info * -fscrypt_get_lblk_info(const struct inode *inode, u64 lblk, u64 *offset, - u64 *extent_len) +static inline bool +fscrypt_fs_uses_extent_encryption(const struct super_block *sb) { - if (offset) - *offset = lblk; - if (extent_len) - *extent_len = U64_MAX; - - return inode->i_crypt_info; + return !!sb->s_cop->get_extent_info; } /** @@ -324,27 +310,51 @@ fscrypt_get_lblk_info(const struct inode *inode, u64 lblk, u64 *offset, */ static inline bool fscrypt_uses_extent_encryption(const struct inode *inode) { - /* Non-regular files don't have extents */ + /* Non-regular files don't have extents. */ if (!S_ISREG(inode->i_mode)) return false; - /* No filesystems currently use per-extent infos */ - return false; + return fscrypt_fs_uses_extent_encryption(inode->i_sb); } + /** - * fscrypt_fs_uses_extent_encryption() -- whether a filesystem uses per-extent - * encryption + * fscrypt_get_lblk_info() - get the fscrypt_info to crypt a particular block * - * @sb: the superblock of the filesystem in question + * @inode: the inode to which the block belongs + * @lblk: the offset of the block within the file which the inode + * references + * @offset: a pointer to return the offset of the block from the first block + * that the info covers. For inode-based encryption, this will + * always be @lblk; for extent-based encryption, this will be in + * the range [0, lblk]. Can be NULL + * @extent_len: a pointer to return the minimum number of lblks starting at + * this offset which also belong to the same fscrypt_info. Can be + * NULL * - * Return: true if the fs uses per-extent fscrypt_infos, false otherwise + * Return: the appropriate fscrypt_info if there is one, else NULL. */ -static inline bool -fscrypt_fs_uses_extent_encryption(const struct super_block *sb) +static inline struct fscrypt_info * +fscrypt_get_lblk_info(const struct inode *inode, u64 lblk, u64 *offset, + u64 *extent_len) { - // No filesystems currently use per-extent infos - return false; + if (fscrypt_uses_extent_encryption(inode)) { + struct fscrypt_info *info; + int res; + + res = inode->i_sb->s_cop->get_extent_info(inode, lblk, &info, + offset, extent_len); + if (res == 0) + return info; + return NULL; + } + + if (offset) + *offset = lblk; + if (extent_len) + *extent_len = U64_MAX; + + return inode->i_crypt_info; } /** diff --git a/fs/crypto/inline_crypt.c b/fs/crypto/inline_crypt.c index 260152d5e673..76274b736e1a 100644 --- a/fs/crypto/inline_crypt.c +++ b/fs/crypto/inline_crypt.c @@ -271,7 +271,10 @@ void fscrypt_set_bio_crypt_ctx(struct bio *bio, const struct inode *inode, if (!fscrypt_inode_uses_inline_crypto(inode)) return; + ci = fscrypt_get_lblk_info(inode, first_lblk, &ci_offset, NULL); + if (!ci) + return; fscrypt_generate_dun(ci, ci_offset, dun); bio_crypt_set_ctx(bio, ci->ci_enc_key->blk_key, dun, gfp_mask); @@ -364,7 +367,7 @@ bool fscrypt_mergeable_bio(struct bio *bio, const struct inode *inode, * uses the same pointer. I.e., there's currently no need to support * merging requests where the keys are the same but the pointers differ. */ - if (bc->bc_key != ci->ci_enc_key->blk_key) + if (!ci || bc->bc_key != ci->ci_enc_key->blk_key) return false; fscrypt_generate_dun(ci, ci_offset, next_dun); diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c index 51d3787fc964..c4ec042ca892 100644 --- a/fs/crypto/keysetup.c +++ b/fs/crypto/keysetup.c @@ -929,6 +929,60 @@ int fscrypt_prepare_new_inode(struct inode *dir, struct inode *inode, } EXPORT_SYMBOL_GPL(fscrypt_prepare_new_inode); +/** + * fscrypt_prepare_new_extent() - set up the fscrypt_info for a new extent + * @inode: the inode to which the extent belongs + * @info_ptr: a pointer to return the extent's fscrypt_info into. Should be + * a pointer to a member of the extent struct, as it will be passed + * back to the filesystem if key removal demands removal of the + * info from the extent + * @encrypt_ret: (output) set to %true if the new inode will be encrypted + * + * If the extent is part of an encrypted inode, set up its fscrypt_info in + * preparation for encrypting data and set *encrypt_ret=true. + * + * This isn't %GFP_NOFS-safe, and therefore it should be called before starting + * any filesystem transaction to create the inode. + * + * This doesn't persist the new inode's encryption context. That still needs to + * be done later by calling fscrypt_set_context(). + * + * Return: 0 on success, -ENOKEY if the encryption key is missing, or another + * -errno code + */ +int fscrypt_prepare_new_extent(struct inode *inode, + struct fscrypt_info **info_ptr) +{ + const union fscrypt_policy *policy; + u8 nonce[FSCRYPT_FILE_NONCE_SIZE]; + + policy = fscrypt_policy_to_inherit(inode); + if (policy == NULL) + return 0; + if (IS_ERR(policy)) + return PTR_ERR(policy); + + /* Only regular files can have extents. */ + if (WARN_ON_ONCE(!S_ISREG(inode->i_mode))) + return -EINVAL; + + get_random_bytes(nonce, FSCRYPT_FILE_NONCE_SIZE); + return fscrypt_setup_encryption_info(inode, policy, nonce, + false, info_ptr); +} +EXPORT_SYMBOL_GPL(fscrypt_prepare_new_extent); + +/** + * fscrypt_free_extent_info() - free an extent's fscrypt_info + * @info_ptr: a pointer containing the extent's fscrypt_info pointer. + */ +void fscrypt_free_extent_info(struct fscrypt_info **info_ptr) +{ + put_crypt_info(*info_ptr); + *info_ptr = NULL; +} +EXPORT_SYMBOL_GPL(fscrypt_free_extent_info); + /** * fscrypt_put_encryption_info() - free most of an inode's fscrypt data * @inode: an inode being evicted diff --git a/include/linux/fscrypt.h b/include/linux/fscrypt.h index 2a64e7a71a53..e39165fbed41 100644 --- a/include/linux/fscrypt.h +++ b/include/linux/fscrypt.h @@ -113,6 +113,29 @@ struct fscrypt_operations { int (*set_context)(struct inode *inode, const void *ctx, size_t len, void *fs_data); + /* + * Get the fscrypt_info for the given inode at the given block, for + * extent-based encryption only. + * + * @inode: the inode in question + * @lblk: the logical block number in question + * @ci: a pointer to return the fscrypt_info + * @offset: a pointer to return the offset of @lblk into the extent, + * in blocks (may be NULL) + * @extent_len: a pointer to return the number of blocks in this extent + * starting at this point (may be NULL) + * + * May cause the filesystem to allocate memory, which the filesystem + * must do with %GFP_NOFS, including calls into fscrypt to create or + * load an fscrypt_info. + * + * Return: 0 if an extent is found with an info, -ENODATA if the key is + * unavailable, or another -errno. + */ + int (*get_extent_info)(const struct inode *inode, u64 lblk, + struct fscrypt_info **ci, u64 *offset, + u64 *extent_len); + /* * Get the dummy fscrypt policy in use on the filesystem (if any). * @@ -339,6 +362,10 @@ void fscrypt_put_encryption_info(struct inode *inode); void fscrypt_free_inode(struct inode *inode); int fscrypt_drop_inode(struct inode *inode); +int fscrypt_prepare_new_extent(struct inode *inode, + struct fscrypt_info **info_ptr); +void fscrypt_free_extent_info(struct fscrypt_info **info_ptr); + /* fname.c */ int fscrypt_fname_encrypt(const struct inode *inode, const struct qstr *iname, u8 *out, unsigned int olen); @@ -600,6 +627,18 @@ static inline int fscrypt_drop_inode(struct inode *inode) return 0; } +static inline int fscrypt_prepare_new_extent(struct inode *inode, + struct fscrypt_info **info_ptr) +{ + if (IS_ENCRYPTED(inode)) + return -EOPNOTSUPP; + return 0; +} + +static inline void fscrypt_free_extent_info(struct fscrypt_info **info_ptr) +{ +} + /* fname.c */ static inline int fscrypt_setup_filename(struct inode *dir, const struct qstr *iname, From patchwork Tue Aug 8 17:08:28 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sweet Tea Dorminy X-Patchwork-Id: 13346775 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A5E8C04E69 for ; Tue, 8 Aug 2023 18:54:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232065AbjHHSyY (ORCPT ); Tue, 8 Aug 2023 14:54:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53820 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230156AbjHHSyG (ORCPT ); Tue, 8 Aug 2023 14:54:06 -0400 Received: from box.fidei.email (box.fidei.email [71.19.144.250]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2F01715C7AB; Tue, 8 Aug 2023 10:08:56 -0700 (PDT) Received: from authenticated-user (box.fidei.email [71.19.144.250]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by box.fidei.email (Postfix) with ESMTPSA id 8E1C983545; Tue, 8 Aug 2023 13:08:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorminy.me; s=mail; t=1691514536; bh=2ZaZcvfT6uFM7Cddjz5wTfSOll3Q7q+Pkodda/OJVXQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CS59DW8dgnl2QJcxT1wvYPH4cgF9BQpn/xf3es2ccHX6kv2xa3TNpZ6fehsy3zuhm 3DIkUF7E6/RW/6fhoCHOMLiq+B3Hmbtdp/nkXzmiOepZHBh0ztm8fXCLGxDlGuqBhk YHKxB5soApS/Vht3RcZPJlTQfhGseJPL8/4/NXaLqXGAD0U05qX0bNrEIX5gZylHq/ e87Fy0BcLbalc7jhTDNb321kq1dD2aLAR6XBctJuoMfU6eKWTwOEWbrwjK4ugdj+5p RUdgPVR+qJJ83eQ6EzFxlfjyqyRp7ZsMlJsQSiNc9OC3DyvqbUVTcu2h6tdD1y2nP+ yI6f0mU6ct6/Q== From: Sweet Tea Dorminy To: Chris Mason , Josef Bacik , David Sterba , "Theodore Y . Ts'o" , Jaegeuk Kim , kernel-team@meta.com, linux-btrfs@vger.kernel.org, linux-fscrypt@vger.kernel.org, Eric Biggers Cc: Sweet Tea Dorminy Subject: [PATCH v3 11/16] fscrypt: allow load/save of extent contexts Date: Tue, 8 Aug 2023 13:08:28 -0400 Message-ID: <6088e52bd6565c4e896033d0e79955b576f05048.1691505882.git.sweettea-kernel@dorminy.me> In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org The other half of using per-extent infos is saving and loading them from disk. Signed-off-by: Sweet Tea Dorminy --- fs/crypto/keysetup.c | 49 +++++++++++++++++++++++++++++++++++++++++ fs/crypto/policy.c | 20 +++++++++++++++++ include/linux/fscrypt.h | 17 ++++++++++++++ 3 files changed, 86 insertions(+) diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c index c4ec042ca892..0076c7f2af3d 100644 --- a/fs/crypto/keysetup.c +++ b/fs/crypto/keysetup.c @@ -983,6 +983,55 @@ void fscrypt_free_extent_info(struct fscrypt_info **info_ptr) } EXPORT_SYMBOL_GPL(fscrypt_free_extent_info); +/** + * fscrypt_load_extent_info() - set up a preexisting extent's fscrypt_info + * @inode: the inode to which the extent belongs. Must be encrypted. + * @buf: a buffer containing the extent's stored context + * @len: the length of the @ctx buffer + * @info_ptr: a pointer to return the extent's fscrypt_info into. Should be + * a pointer to a member of the extent struct, as it will be passed + * back to the filesystem if key removal demands removal of the + * info from the extent + * + * This is not %GFP_NOFS safe, so the caller is expected to call + * memalloc_nofs_save/restore() if appropriate. + * + * Return: 0 if successful, or -errno if it fails. + */ +int fscrypt_load_extent_info(struct inode *inode, void *buf, size_t len, + struct fscrypt_info **info_ptr) +{ + int res; + union fscrypt_context ctx; + union fscrypt_policy policy; + + if (!fscrypt_has_encryption_key(inode)) + return -EINVAL; + + memcpy(&ctx, buf, len); + + res = fscrypt_policy_from_context(&policy, &ctx, len); + if (res) { + fscrypt_warn(inode, + "Unrecognized or corrupt encryption context"); + return res; + } + + if (!fscrypt_supported_policy(&policy, inode)) + return -EINVAL; + + res = fscrypt_setup_encryption_info(inode, &policy, + fscrypt_context_nonce(&ctx), + IS_CASEFOLDED(inode) && + S_ISDIR(inode->i_mode), + info_ptr); + + if (res == -ENOPKG) /* Algorithm unavailable? */ + res = 0; + return res; +} +EXPORT_SYMBOL_GPL(fscrypt_load_extent_info); + /** * fscrypt_put_encryption_info() - free most of an inode's fscrypt data * @inode: an inode being evicted diff --git a/fs/crypto/policy.c b/fs/crypto/policy.c index f4456ecb3f87..9ecb01e49d33 100644 --- a/fs/crypto/policy.c +++ b/fs/crypto/policy.c @@ -762,6 +762,26 @@ int fscrypt_set_context(struct inode *inode, void *fs_data) } EXPORT_SYMBOL_GPL(fscrypt_set_context); +/** + * fscrypt_set_extent_context() - Set the fscrypt context for an extent + * @ci: info from which to fetch policy and nonce + * @ctx: where context should be written + * @len: the size of ctx + * + * Given an fscrypt_info belonging to an extent (generated via + * fscrypt_prepare_new_extent()), generate a new context and write it to @ctx. + * len is checked to be at least FSCRYPT_SET_CONTEXT_MAX_SIZE bytes. + * + * Return: size of the resulting context or a negative error code. + */ +int fscrypt_set_extent_context(struct fscrypt_info *ci, void *ctx, size_t len) +{ + if (len < FSCRYPT_SET_CONTEXT_MAX_SIZE) + return -EINVAL; + return fscrypt_new_context(ctx, &ci->ci_policy, ci->ci_nonce); +} +EXPORT_SYMBOL_GPL(fscrypt_set_extent_context); + /** * fscrypt_parse_test_dummy_encryption() - parse the test_dummy_encryption mount option * @param: the mount option diff --git a/include/linux/fscrypt.h b/include/linux/fscrypt.h index e39165fbed41..4ba624beea91 100644 --- a/include/linux/fscrypt.h +++ b/include/linux/fscrypt.h @@ -325,6 +325,8 @@ int fscrypt_ioctl_get_nonce(struct file *filp, void __user *arg); int fscrypt_has_permitted_context(struct inode *parent, struct inode *child); int fscrypt_context_for_new_inode(void *ctx, struct inode *inode); int fscrypt_set_context(struct inode *inode, void *fs_data); +int fscrypt_set_extent_context(struct fscrypt_info *info, void *ctx, + size_t len); struct fscrypt_dummy_policy { const union fscrypt_policy *policy; @@ -365,6 +367,8 @@ int fscrypt_drop_inode(struct inode *inode); int fscrypt_prepare_new_extent(struct inode *inode, struct fscrypt_info **info_ptr); void fscrypt_free_extent_info(struct fscrypt_info **info_ptr); +int fscrypt_load_extent_info(struct inode *inode, void *buf, size_t len, + struct fscrypt_info **info_ptr); /* fname.c */ int fscrypt_fname_encrypt(const struct inode *inode, const struct qstr *iname, @@ -541,6 +545,12 @@ static inline int fscrypt_set_context(struct inode *inode, void *fs_data) return -EOPNOTSUPP; } +static inline int fscrypt_set_extent_context(struct fscrypt_info *info, + void *ctx, size_t len) +{ + return -EOPNOTSUPP; +} + struct fscrypt_dummy_policy { }; @@ -639,6 +649,13 @@ static inline void fscrypt_free_extent_info(struct fscrypt_info **info_ptr) { } +static inline int fscrypt_load_extent_info(struct inode *inode, void *buf, + size_t len, + struct fscrypt_info **info_ptr) +{ + return -EOPNOTSUPP; +} + /* fname.c */ static inline int fscrypt_setup_filename(struct inode *dir, const struct qstr *iname, From patchwork Tue Aug 8 17:08:29 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sweet Tea Dorminy X-Patchwork-Id: 13346776 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 46D99C001B0 for ; Tue, 8 Aug 2023 18:54:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232671AbjHHSy1 (ORCPT ); Tue, 8 Aug 2023 14:54:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39662 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232623AbjHHSyI (ORCPT ); Tue, 8 Aug 2023 14:54:08 -0400 Received: from box.fidei.email (box.fidei.email [IPv6:2605:2700:0:2:a800:ff:feba:dc44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7BE4C15C7B6; Tue, 8 Aug 2023 10:08:58 -0700 (PDT) Received: from authenticated-user (box.fidei.email [71.19.144.250]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by box.fidei.email (Postfix) with ESMTPSA id E5F0F83546; Tue, 8 Aug 2023 13:08:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorminy.me; s=mail; t=1691514538; bh=scRHF9SMuL/YJh7S5rHdvyOT2nCxaggyg6QYNEXbEho=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bLDePPmrKReyQx+C6UHsWvZZ0zHYvUuEoF1sBUUHG4Iom+ZKTRVljpsPWUtcv01q3 Tw3StOWG5q5QY3EZ/RakMsPSsaDPXvDeCHk5zAZiO/SJy7fDUbyqHrlGmHK/wadKCx 5nfYcbLcu+17MqjbosJJngjMWarvqxOD71ftfKQqU6QXPRKZFUcaBi0rR+EhDSt2Np baY5qMZ6WQUAI0Pz+7m6VB1ajO2hVaj9IZutp4erwpOWEzsIE706yqLB42ZUbSCHg5 9r3A/TuuPQwTNj+1pn735KdmF2TTDxq/ehQLtb3YPvmReHafCbN6FPUrqSM+D+GiM7 8P/SW30R6N3zQ== From: Sweet Tea Dorminy To: Chris Mason , Josef Bacik , David Sterba , "Theodore Y . Ts'o" , Jaegeuk Kim , kernel-team@meta.com, linux-btrfs@vger.kernel.org, linux-fscrypt@vger.kernel.org, Eric Biggers Cc: Sweet Tea Dorminy Subject: [PATCH v3 12/16] fscrypt: save session key credentials for extent infos Date: Tue, 8 Aug 2023 13:08:29 -0400 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org For v1 encryption policies using per-session keys, the thread which opens the inode and therefore initializes the encryption info is part of the session, so it can get the key from the session keyring. However, for extent encryption, the extent infos are likely loaded from a different thread, which does not have access to the session keyring. This change saves the credentials of the inode opening thread and reuses those credentials temporarily when dealing with extent infos, allowing finding the encryption key correctly. v1 encryption policies using per-session keys should probably not exist for new usages such as extent encryption, but this makes more tests work without change; maybe the right answer is to disallow v1 session keys plus extent encryption and deal with editing tests to not use v1 session encryption so much. Signed-off-by: Sweet Tea Dorminy --- fs/crypto/fscrypt_private.h | 8 ++++++++ fs/crypto/keysetup.c | 14 ++++++++++++++ fs/crypto/keysetup_v1.c | 1 + 3 files changed, 23 insertions(+) diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h index c6bf0bd0259a..cd29c71b4349 100644 --- a/fs/crypto/fscrypt_private.h +++ b/fs/crypto/fscrypt_private.h @@ -231,6 +231,14 @@ struct fscrypt_info { */ bool ci_inlinecrypt; #endif + /* Credential struct from the thread which created this info. This is + * only used in v1 session keyrings with extent encryption; it allows + * the thread creating extents for an inode to join the session + * keyring temporarily, since otherwise the thread is usually part of + * kernel writeback and therefore unrelated to the thread with the + * right session key. + */ + struct cred *ci_session_creds; /* * Encryption mode used for this inode. It corresponds to either the diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c index 0076c7f2af3d..8d50716bdf11 100644 --- a/fs/crypto/keysetup.c +++ b/fs/crypto/keysetup.c @@ -649,6 +649,8 @@ static void put_crypt_info(struct fscrypt_info *ci) fscrypt_put_master_key_activeref(ci->ci_sb, mk); } + if (ci->ci_session_creds) + abort_creds(ci->ci_session_creds); memzero_explicit(ci, sizeof(*ci)); kmem_cache_free(fscrypt_info_cachep, ci); } @@ -665,6 +667,7 @@ fscrypt_setup_encryption_info(struct inode *inode, struct fscrypt_master_key *mk = NULL; int res; bool info_for_extent = !!info_ptr; + const struct cred *creds = NULL; if (!info_ptr) info_ptr = &inode->i_crypt_info; @@ -707,7 +710,18 @@ fscrypt_setup_encryption_info(struct inode *inode, if (res) goto out; + if (info_for_extent && inode->i_crypt_info->ci_session_creds) { + /* + * The inode this is being created for is using a session key, + * so we have to join this thread to that session temporarily + * in order to be able to find the right key... + */ + creds = override_creds(inode->i_crypt_info->ci_session_creds); + } + res = fscrypt_setup_file_key(crypt_info, mk); + if (creds) + revert_creds(creds); if (res) goto out; diff --git a/fs/crypto/keysetup_v1.c b/fs/crypto/keysetup_v1.c index 41d317f08aeb..4f2be2377dfa 100644 --- a/fs/crypto/keysetup_v1.c +++ b/fs/crypto/keysetup_v1.c @@ -318,6 +318,7 @@ int fscrypt_setup_v1_file_key_via_subscribed_keyrings(struct fscrypt_info *ci) return PTR_ERR(key); err = fscrypt_setup_v1_file_key(ci, payload->raw); + ci->ci_session_creds = prepare_creds(); up_read(&key->sem); key_put(key); return err; From patchwork Tue Aug 8 17:08:30 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sweet Tea Dorminy X-Patchwork-Id: 13346777 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 16434C04FE1 for ; Tue, 8 Aug 2023 18:54:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234313AbjHHSy3 (ORCPT ); Tue, 8 Aug 2023 14:54:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54214 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232062AbjHHSyM (ORCPT ); Tue, 8 Aug 2023 14:54:12 -0400 Received: from box.fidei.email (box.fidei.email [IPv6:2605:2700:0:2:a800:ff:feba:dc44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CF68D15C7BB; Tue, 8 Aug 2023 10:08:59 -0700 (PDT) Received: from authenticated-user (box.fidei.email [71.19.144.250]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by box.fidei.email (Postfix) with ESMTPSA id 503C083548; Tue, 8 Aug 2023 13:08:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorminy.me; s=mail; t=1691514539; bh=O+ozdjMuGyovsvKTmBrvw9gMGe4Wg30O95hUx8UcM0o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RJ0uwgzZL4nu/U/08WBPCCLT8IePa4qOS0L7fVuiWUEF4QpFk5rtikIKV6UhiOyYv NJDznH0Pjs4k0+PWnH4OxFAbMFKiUM8cYnghGHjiVafNsSwRjfgIp/pSDBK7Zq0l2b MkPnakOmEWiOewb09HZk5FeZ2/fGz2fq9LHhSPZzzHfBbqCYJ0EVMAEPVJxIh2UPFn DZoOTrHoHstPg8gLV4H/DzpaonYXSXbdXXCvbwTsu1ju8VHFm6ZJm8+K8THhkjkHKU tW+b4IWMzRz8fg1mispjQ9fbNkH6PZXQYGls6+t5ZuLJve7FQVWK8So1ECnD2XUZN0 3YyENr5uM3uqA== From: Sweet Tea Dorminy To: Chris Mason , Josef Bacik , David Sterba , "Theodore Y . Ts'o" , Jaegeuk Kim , kernel-team@meta.com, linux-btrfs@vger.kernel.org, linux-fscrypt@vger.kernel.org, Eric Biggers Cc: Sweet Tea Dorminy Subject: [PATCH v3 13/16] fscrypt: allow multiple extents to reference one info Date: Tue, 8 Aug 2023 13:08:30 -0400 Message-ID: <2fc070a3990716077dee122740f21abcea8121a8.1691505882.git.sweettea-kernel@dorminy.me> In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org btrfs occasionally splits in-memory extents while holding a mutex. This means we can't just copy the info, since setting up a new inlinecrypt key requires taking a semaphore. Thus adding a mechanism to split extents and merely take a new reference on the info is necessary. Signed-off-by: Sweet Tea Dorminy --- fs/crypto/fscrypt_private.h | 5 +++++ fs/crypto/keysetup.c | 18 +++++++++++++++++- include/linux/fscrypt.h | 2 ++ 3 files changed, 24 insertions(+), 1 deletion(-) diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h index cd29c71b4349..03be2c136c0e 100644 --- a/fs/crypto/fscrypt_private.h +++ b/fs/crypto/fscrypt_private.h @@ -287,6 +287,11 @@ struct fscrypt_info { /* Hashed inode number. Only set for IV_INO_LBLK_32 */ u32 ci_hashed_ino; + + /* Reference count. Normally 1, unless a extent info is shared by + * several virtual extents. + */ + refcount_t refs; }; typedef enum { diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c index 8d50716bdf11..12c3851b7cd6 100644 --- a/fs/crypto/keysetup.c +++ b/fs/crypto/keysetup.c @@ -598,7 +598,7 @@ static void put_crypt_info(struct fscrypt_info *ci) { struct fscrypt_master_key *mk; - if (!ci) + if (!ci || !refcount_dec_and_test(&ci->refs)) return; if (ci->ci_enc_key) { @@ -686,6 +686,7 @@ fscrypt_setup_encryption_info(struct inode *inode, crypt_info->ci_inode = inode; crypt_info->ci_sb = inode->i_sb; crypt_info->ci_policy = *policy; + refcount_set(&crypt_info->refs, 1); memcpy(crypt_info->ci_nonce, nonce, FSCRYPT_FILE_NONCE_SIZE); mode = select_encryption_mode(&crypt_info->ci_policy, inode); @@ -1046,6 +1047,21 @@ int fscrypt_load_extent_info(struct inode *inode, void *buf, size_t len, } EXPORT_SYMBOL_GPL(fscrypt_load_extent_info); +/** + * fscrypt_get_extent_info_ref() - mark a second extent using the same info + * @info: the info to be used by another extent + * + * Sometimes, an existing extent must be split into multiple extents in memory. + * In such a case, this function allows multiple extents to use the same extent + * info without allocating or taking any lock, which is necessary in certain IO + * paths. + */ +void fscrypt_get_extent_info_ref(struct fscrypt_info *info) +{ + if (info) + refcount_inc(&info->refs); +} + /** * fscrypt_put_encryption_info() - free most of an inode's fscrypt data * @inode: an inode being evicted diff --git a/include/linux/fscrypt.h b/include/linux/fscrypt.h index 4ba624beea91..b67054a2c965 100644 --- a/include/linux/fscrypt.h +++ b/include/linux/fscrypt.h @@ -370,6 +370,8 @@ void fscrypt_free_extent_info(struct fscrypt_info **info_ptr); int fscrypt_load_extent_info(struct inode *inode, void *buf, size_t len, struct fscrypt_info **info_ptr); +void fscrypt_get_extent_info_ref(struct fscrypt_info *info); + /* fname.c */ int fscrypt_fname_encrypt(const struct inode *inode, const struct qstr *iname, u8 *out, unsigned int olen); From patchwork Tue Aug 8 17:08:31 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sweet Tea Dorminy X-Patchwork-Id: 13346778 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63A24C04FE2 for ; Tue, 8 Aug 2023 18:54:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234368AbjHHSyc (ORCPT ); Tue, 8 Aug 2023 14:54:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46282 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234356AbjHHSyP (ORCPT ); Tue, 8 Aug 2023 14:54:15 -0400 Received: from box.fidei.email (box.fidei.email [71.19.144.250]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 24008A7B7; Tue, 8 Aug 2023 10:09:01 -0700 (PDT) Received: from authenticated-user (box.fidei.email [71.19.144.250]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by box.fidei.email (Postfix) with ESMTPSA id AC02083541; Tue, 8 Aug 2023 13:09:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorminy.me; s=mail; t=1691514540; bh=ntPuzPG8lqrcqAowHX8Wfy9zZUFP0oUAHsbjRXF+ud4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GqXdbIqjgbRsYCFAK8prqhrXbyjfvbWLspofmr3d5eKgwYiDgPUNi8NilgwWYEzjz lpwir42PGIs6uhiekcOGkNbJwukhqLECO0Ml+FDs6L+Fp/CPdXNeqcbP9mwTr+gdn7 vToiPLiIOxlK4MLuvCL+jxAObOBznggtOfKwrIvsGGAJymCMcPfxd0e0ONf/Gg2swj nPrh7Yr782zMKcnBaib3NbpgZghc0Rm+dwKKFe7AK/IuxNL5rYC5Ny20bBQLoAOr2Z QxenOogQ0TvZI/A4HldknHMg7i0pNcCaMrDRoMFcObwdjSldEpLiqOHSfTJl/i2Vwp V547dYwjlRkVA== From: Sweet Tea Dorminy To: Chris Mason , Josef Bacik , David Sterba , "Theodore Y . Ts'o" , Jaegeuk Kim , kernel-team@meta.com, linux-btrfs@vger.kernel.org, linux-fscrypt@vger.kernel.org, Eric Biggers Cc: Sweet Tea Dorminy Subject: [PATCH v3 14/16] fscrypt: cache list of inlinecrypt devices Date: Tue, 8 Aug 2023 13:08:31 -0400 Message-ID: <62170e01a2c0b107619018c859250c03b6023a57.1691505882.git.sweettea-kernel@dorminy.me> In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org btrfs sometimes frees extents while holding a mutex, which makes it impossible to free an inlinecrypt prepared key since that requires taking a semaphore. Therefore, we will need to offload prepared key freeing into an asynchronous process (rcu is insufficient since that can run in softirq context which is also incompatible with taking a semaphore). In order to avoid use-after-free on the filesystem superblock for keys being freed during shutdown, we need to cache the list of devices that the key has been loaded into, so that we can later remove it without reference to the superblock. Signed-off-by: Sweet Tea Dorminy --- fs/crypto/fscrypt_private.h | 13 +++++++++++-- fs/crypto/inline_crypt.c | 20 +++++++++----------- fs/crypto/keysetup.c | 2 +- 3 files changed, 21 insertions(+), 14 deletions(-) diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h index 03be2c136c0e..aba83509c735 100644 --- a/fs/crypto/fscrypt_private.h +++ b/fs/crypto/fscrypt_private.h @@ -205,6 +205,16 @@ struct fscrypt_prepared_key { struct crypto_skcipher *tfm; #ifdef CONFIG_FS_ENCRYPTION_INLINE_CRYPT struct blk_crypto_key *blk_key; + + /* + * The list of devices that have this block key. + */ + struct block_device **devices; + + /* + * The number of devices in @ci_devices. + */ + size_t device_count; #endif enum fscrypt_prepared_key_type type; }; @@ -470,8 +480,7 @@ int fscrypt_prepare_inline_crypt_key(struct fscrypt_prepared_key *prep_key, const u8 *raw_key, const struct fscrypt_info *ci); -void fscrypt_destroy_inline_crypt_key(struct super_block *sb, - struct fscrypt_prepared_key *prep_key); +void fscrypt_destroy_inline_crypt_key(struct fscrypt_prepared_key *prep_key); /* * Check whether the crypto transform or blk-crypto key has been allocated in diff --git a/fs/crypto/inline_crypt.c b/fs/crypto/inline_crypt.c index 76274b736e1a..91f8365b4194 100644 --- a/fs/crypto/inline_crypt.c +++ b/fs/crypto/inline_crypt.c @@ -185,12 +185,15 @@ int fscrypt_prepare_inline_crypt_key(struct fscrypt_prepared_key *prep_key, if (err) break; } - kfree(devs); + if (err) { fscrypt_err(inode, "error %d starting to use blk-crypto", err); goto fail; } + prep_key->devices = devs; + prep_key->device_count = num_devs; + /* * Pairs with the smp_load_acquire() in fscrypt_is_key_prepared(). * I.e., here we publish ->blk_key with a RELEASE barrier so that @@ -205,24 +208,19 @@ int fscrypt_prepare_inline_crypt_key(struct fscrypt_prepared_key *prep_key, return err; } -void fscrypt_destroy_inline_crypt_key(struct super_block *sb, - struct fscrypt_prepared_key *prep_key) +void fscrypt_destroy_inline_crypt_key(struct fscrypt_prepared_key *prep_key) { struct blk_crypto_key *blk_key = prep_key->blk_key; - struct block_device **devs; - unsigned int num_devs; unsigned int i; if (!blk_key) return; /* Evict the key from all the filesystem's block devices. */ - devs = fscrypt_get_devices(sb, &num_devs); - if (!IS_ERR(devs)) { - for (i = 0; i < num_devs; i++) - blk_crypto_evict_key(devs[i], blk_key); - kfree(devs); - } + for (i = 0; i < prep_key->device_count; i++) + blk_crypto_evict_key(prep_key->devices[i], blk_key); + + kfree(prep_key->devices); kfree_sensitive(blk_key); } diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c index 12c3851b7cd6..fe246229c869 100644 --- a/fs/crypto/keysetup.c +++ b/fs/crypto/keysetup.c @@ -195,7 +195,7 @@ void fscrypt_destroy_prepared_key(struct super_block *sb, struct fscrypt_prepared_key *prep_key) { crypto_free_skcipher(prep_key->tfm); - fscrypt_destroy_inline_crypt_key(sb, prep_key); + fscrypt_destroy_inline_crypt_key(prep_key); memzero_explicit(prep_key, sizeof(*prep_key)); } From patchwork Tue Aug 8 17:08:32 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sweet Tea Dorminy X-Patchwork-Id: 13346779 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0E72C05051 for ; Tue, 8 Aug 2023 18:54:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234356AbjHHSyd (ORCPT ); Tue, 8 Aug 2023 14:54:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55998 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229985AbjHHSyT (ORCPT ); Tue, 8 Aug 2023 14:54:19 -0400 Received: from box.fidei.email (box.fidei.email [71.19.144.250]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7B5123A8C; Tue, 8 Aug 2023 10:09:02 -0700 (PDT) Received: from authenticated-user (box.fidei.email [71.19.144.250]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by box.fidei.email (Postfix) with ESMTPSA id 0F2B280029; Tue, 8 Aug 2023 13:09:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorminy.me; s=mail; t=1691514542; bh=ukMXkhMtVtxX22ydxm2AoYUCCiVWA8QnfbaKw80mQOI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WE0WH8NCn+UUWlAkf10jlQNpe6XbhQ6SIiC4aF+HNqcLSpqUYBWDEcHhGkXJz4ZtD LB5LO+UNKuQI2Gbqcn1Yu1lw1eUkZPkd655lY7nQBBCq/BdP8tf3VFiY/r9V6y+yig vDj35n+imPKbM/IPXvU7iqs8CczUrmUIAjOjAVFJBwMyKEnGyY01YX697nDunBCFnK PtdqZbEyxBr4IeXbMsZNXKCRGbzVK8/7jLEJdGe4aLA1WvYzOL47erq+MdPl8lCV8+ 64ND1OHgjsOlrUEXzewZxwPVyuLSZ0s7PgmxG2AnAel3Zb54s/NUHT2izPUOfQMdUK 2lp9oC1IHq6QQ== From: Sweet Tea Dorminy To: Chris Mason , Josef Bacik , David Sterba , "Theodore Y . Ts'o" , Jaegeuk Kim , kernel-team@meta.com, linux-btrfs@vger.kernel.org, linux-fscrypt@vger.kernel.org, Eric Biggers Cc: Sweet Tea Dorminy Subject: [PATCH v3 15/16] fscrypt: allow asynchronous info freeing Date: Tue, 8 Aug 2023 13:08:32 -0400 Message-ID: <6c4a29fdfabf90f1a43dffff04debd54f941cf93.1691505882.git.sweettea-kernel@dorminy.me> In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org btrfs sometimes frees extents while holding a mutex. This makes it hard to free the prepared keys associated therewith, as the free process may need to take a semaphore. Just offloading freeing to rcu doesn't work, as rcu may call the callback in softirq context, which also doesn't allow taking a semaphore. Thus, for extent infos, offload their freeing to the general system workqueue. Signed-off-by: Sweet Tea Dorminy --- fs/crypto/fscrypt_private.h | 12 +++++++++--- fs/crypto/keyring.c | 6 +++--- fs/crypto/keysetup.c | 31 +++++++++++++++++++++++++++---- fs/crypto/keysetup_v1.c | 3 +-- 4 files changed, 40 insertions(+), 12 deletions(-) diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h index aba83509c735..2b95c3a9560f 100644 --- a/fs/crypto/fscrypt_private.h +++ b/fs/crypto/fscrypt_private.h @@ -216,6 +216,12 @@ struct fscrypt_prepared_key { */ size_t device_count; #endif + /* + * For destroying asynchronously. + */ + struct work_struct work; + /* A pointer to free after destroy. */ + void *ptr_to_free; enum fscrypt_prepared_key_type type; }; @@ -526,8 +532,7 @@ fscrypt_prepare_inline_crypt_key(struct fscrypt_prepared_key *prep_key, } static inline void -fscrypt_destroy_inline_crypt_key(struct super_block *sb, - struct fscrypt_prepared_key *prep_key) +fscrypt_destroy_inline_crypt_key(struct fscrypt_prepared_key *prep_key) { } @@ -748,7 +753,8 @@ int fscrypt_prepare_key(struct fscrypt_prepared_key *prep_key, const u8 *raw_key, const struct fscrypt_info *ci); void fscrypt_destroy_prepared_key(struct super_block *sb, - struct fscrypt_prepared_key *prep_key); + struct fscrypt_prepared_key *prep_key, + void *ptr_to_free); int fscrypt_set_per_file_enc_key(struct fscrypt_info *ci, const u8 *raw_key); diff --git a/fs/crypto/keyring.c b/fs/crypto/keyring.c index feca4a8410bb..7826322b8528 100644 --- a/fs/crypto/keyring.c +++ b/fs/crypto/keyring.c @@ -107,11 +107,11 @@ void fscrypt_put_master_key_activeref(struct super_block *sb, for (i = 0; i <= FSCRYPT_MODE_MAX; i++) { fscrypt_destroy_prepared_key( - sb, &mk->mk_direct_keys[i]); + sb, &mk->mk_direct_keys[i], NULL); fscrypt_destroy_prepared_key( - sb, &mk->mk_iv_ino_lblk_64_keys[i]); + sb, &mk->mk_iv_ino_lblk_64_keys[i], NULL); fscrypt_destroy_prepared_key( - sb, &mk->mk_iv_ino_lblk_32_keys[i]); + sb, &mk->mk_iv_ino_lblk_32_keys[i], NULL); } memzero_explicit(&mk->mk_ino_hash_key, sizeof(mk->mk_ino_hash_key)); diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c index fe246229c869..1acb676efe3e 100644 --- a/fs/crypto/keysetup.c +++ b/fs/crypto/keysetup.c @@ -190,13 +190,36 @@ int fscrypt_prepare_key(struct fscrypt_prepared_key *prep_key, return 0; } -/* Destroy a crypto transform object and/or blk-crypto key. */ -void fscrypt_destroy_prepared_key(struct super_block *sb, - struct fscrypt_prepared_key *prep_key) +static void __destroy_key(struct fscrypt_prepared_key *prep_key) { + void *ptr_to_free = prep_key->ptr_to_free; + crypto_free_skcipher(prep_key->tfm); fscrypt_destroy_inline_crypt_key(prep_key); memzero_explicit(prep_key, sizeof(*prep_key)); + if (ptr_to_free) + kfree_sensitive(ptr_to_free); +} + +static void __destroy_key_work(struct work_struct *work) +{ + struct fscrypt_prepared_key *prep_key = + container_of(work, struct fscrypt_prepared_key, work); + + __destroy_key(prep_key); +} + +/* Destroy a crypto transform object and/or blk-crypto key. */ +void fscrypt_destroy_prepared_key(struct super_block *sb, + struct fscrypt_prepared_key *prep_key, + void *ptr_to_free) +{ + prep_key->ptr_to_free = ptr_to_free; + if (fscrypt_fs_uses_extent_encryption(sb)) { + INIT_WORK(&prep_key->work, __destroy_key_work); + queue_work(system_unbound_wq, &prep_key->work); + } else + __destroy_key(prep_key); } /* Given a per-file encryption key, set up the file's crypto transform object */ @@ -608,8 +631,8 @@ static void put_crypt_info(struct fscrypt_info *ci) fscrypt_put_direct_key(ci->ci_enc_key); if (type == FSCRYPT_KEY_PER_INFO) { fscrypt_destroy_prepared_key(ci->ci_sb, + ci->ci_enc_key, ci->ci_enc_key); - kfree_sensitive(ci->ci_enc_key); } } diff --git a/fs/crypto/keysetup_v1.c b/fs/crypto/keysetup_v1.c index 4f2be2377dfa..4f45e99290d9 100644 --- a/fs/crypto/keysetup_v1.c +++ b/fs/crypto/keysetup_v1.c @@ -155,8 +155,7 @@ struct fscrypt_direct_key { static void free_direct_key(struct fscrypt_direct_key *dk) { if (dk) { - fscrypt_destroy_prepared_key(dk->dk_sb, &dk->dk_key); - kfree_sensitive(dk); + fscrypt_destroy_prepared_key(dk->dk_sb, &dk->dk_key, dk); } } From patchwork Tue Aug 8 17:08:33 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sweet Tea Dorminy X-Patchwork-Id: 13346781 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AD09DC04A94 for ; Tue, 8 Aug 2023 18:54:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231749AbjHHSyk (ORCPT ); Tue, 8 Aug 2023 14:54:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56228 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233895AbjHHSyW (ORCPT ); Tue, 8 Aug 2023 14:54:22 -0400 Received: from box.fidei.email (box.fidei.email [IPv6:2605:2700:0:2:a800:ff:feba:dc44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D286763F4D; Tue, 8 Aug 2023 10:09:03 -0700 (PDT) Received: from authenticated-user (box.fidei.email [71.19.144.250]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by box.fidei.email (Postfix) with ESMTPSA id 6601F800E0; Tue, 8 Aug 2023 13:09:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorminy.me; s=mail; t=1691514543; bh=vGSsk/5B1Ps74F/JCs2e0jmq8/pZ+D4gbano0VHmuZQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aDW3Iy3aRVCoRKOJfdYc26O3RzDa4ed6+KityPxSbopRgQyoy/rZnix2pDaPMiKjF Q+cPRqriTIB8RI/QkPTR7WdClP3S1zRTtABdM8Iu+fSLCKtB1KwmPQD07KYpYMpUXu UqqOWJjiEPHn5t9YkcCYjCGUK0ynuAINEsR2io9g6OWuhkyHiz4ITS6eKsLDQIm6K9 0PH7m68YqJIOEVpOeSPumQ96Ip6gnEdICvjj5yXnoAP7f/mNwm3MDweFIZ82EdMoLJ G4qItBXO3Z5gXL66QD+UVumnF3t1Rmma93enfxx3+sP2m+3pdGtJVednHWSLVPRpWr nWfDvPGen+2mQ== From: Sweet Tea Dorminy To: Chris Mason , Josef Bacik , David Sterba , "Theodore Y . Ts'o" , Jaegeuk Kim , kernel-team@meta.com, linux-btrfs@vger.kernel.org, linux-fscrypt@vger.kernel.org, Eric Biggers Cc: Sweet Tea Dorminy Subject: [PATCH v3 16/16] fscrypt: update documentation for per-extent keys Date: Tue, 8 Aug 2023 13:08:33 -0400 Message-ID: <8712f622048a514722c3d9ed71e6e32fc40f6ccb.1691505882.git.sweettea-kernel@dorminy.me> In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org Add some documentation of how extent-based encryption works, hopefully enough for future filesystem users. Signed-off-by: Sweet Tea Dorminy --- Documentation/filesystems/fscrypt.rst | 43 +++++++++++++++++++++++---- 1 file changed, 37 insertions(+), 6 deletions(-) diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index eccd327e6df5..e862d59bd5b5 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -31,7 +31,7 @@ However, except for filenames, fscrypt does not encrypt filesystem metadata. Unlike eCryptfs, which is a stacked filesystem, fscrypt is integrated -directly into supported filesystems --- currently ext4, F2FS, and +directly into supported filesystems --- currently btrfs, ext4, F2FS, and UBIFS. This allows encrypted files to be read and written without caching both the decrypted and encrypted pages in the pagecache, thereby nearly halving the memory used and bringing it in line with @@ -125,6 +125,11 @@ However, these ioctls have some limitations: well as kill any processes whose working directory is in an affected encrypted directory. +- If the filesystem is using extent-based encryption, the master + encryption key will *not* be wiped from kernel memory until all + inodes using the key have been evicted (requiring that all files + using the key are closed). + - The kernel cannot magically wipe copies of the master key(s) that userspace might have as well. Therefore, userspace must wipe all copies of the master key(s) it makes as well; normally this should @@ -280,6 +285,11 @@ included in the IV. Moreover: key derived using the KDF. Users may use the same master key for other v2 encryption policies. +For filesystems with extent-based content encryption (e.g. btrfs), +this is the only choice. Data shared among multiple inodes must share +the exact same key, therefore necessitating inodes using the same key +for contents encryption. + IV_INO_LBLK_64 policies ----------------------- @@ -381,12 +391,13 @@ to individual filesystems. However, authenticated encryption (AE) modes are not currently supported because of the difficulty of dealing with ciphertext expansion. -Contents encryption -------------------- +Inode-based contents encryption +------------------------------- -For file contents, each filesystem block is encrypted independently. -Starting from Linux kernel 5.5, encryption of filesystems with block -size less than system's page size is supported. +Most filesystems use the previously discussed per-file keys. For these +filesystems, for file contents, each filesystem block is encrypted +independently. Starting from Linux kernel 5.5, encryption of filesystems +with block size less than system's page size is supported. Each block's IV is set to the logical block number within the file as a little endian number, except that: @@ -410,6 +421,26 @@ Note that because file logical block numbers are included in the IVs, filesystems must enforce that blocks are never shifted around within encrypted files, e.g. via "collapse range" or "insert range". +Extent-based contents encryption +-------------------------------- + +For certain filesystems (currently only btrfs), data is encrypted on a +per-extent basis, for whatever the filesystem's notion of an extent is. The +scheme is exactly as with inode-based contents encryption, except that the +'inode number' for an extent is requested from the filesystem instead of from +the file's inode, and the 'logical block number' refers to an offset within the +extent. + +Because the encryption material is per-extent instead of per-inode, as long +as the extent's encryption context does not change, the filesystem may shift +around the position of the extent, and may have multiple files referring to +the same encrypted extent. + +Not all extents within a file are decrypted simultaneously, so it is possible +for a file read to fail partway through the file if it crosses into an extent +whose key is unavailable. However, all writes will succeed, unless the key is +removed mid-write. + Filenames encryption --------------------