From patchwork Wed Nov 2 11:52:54 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sweet Tea Dorminy X-Patchwork-Id: 13028039 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 3DF91C4332F for ; Wed, 2 Nov 2022 11:53:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229877AbiKBLxW (ORCPT ); Wed, 2 Nov 2022 07:53:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48842 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230290AbiKBLxV (ORCPT ); Wed, 2 Nov 2022 07:53:21 -0400 Received: from box.fidei.email (box.fidei.email [71.19.144.250]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D901228E34; Wed, 2 Nov 2022 04:53:19 -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 217DA81462; Wed, 2 Nov 2022 07:53:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorminy.me; s=mail; t=1667389999; bh=2lp+qYuc8tIXu6f0eDTY6kJSGdqRQdWs1nDI6UaO5l4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XhDqqDDdh/BcVR4+4DZaqB2hYqusHAbxeJ1X9SoablHmVHi0VL0p2cAxNZzoGlSVu pnX+z3PyKyefqZRmp4TQ5dm5a0hIsGq6Jy3tT7FWsy5MRHSXKhwQEuzipAdhOVK2p3 blhMkDS5FTGtiuH+TqSL3x7hy9MI4iBkTRGCXNbHh1w8IAySfSWIGrjuSvC4eEqXwW 3kPZzPmGzGbVO3z3xLiRzD44mcvw4AgGz6RlHBB4tdGKV8rjJBOX3+tdhiX9QM9lGS ZVhhzHS1T6HG9ZuaVBloB8s667+VdiIDcXzqLp3ttVt+GU3DpwcpEOWzFx/GbwL8O3 UvKXYlNILDtgA== From: Sweet Tea Dorminy To: "Theodore Y. Ts'o" , Jaegeuk Kim , Eric Biggers , Chris Mason , Josef Bacik , David Sterba , linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org, kernel-team@meta.com Cc: Sweet Tea Dorminy Subject: [PATCH v5 05/18] fscrypt: extent direct key policies for extent-based encryption Date: Wed, 2 Nov 2022 07:52:54 -0400 Message-Id: <857cdf24a4b74b32f0c3e955f7e3d1e940cf1a43.1667389115.git.sweettea-kernel@dorminy.me> In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org For inode-based direct key encryption policies, the inode provides a nonce, and the encryption IV is generated by concatenating the nonce and the offset into the inode. For extent-based direct key policies, however, we would like to use 16-byte nonces in combination with various AES modes with 16-byte IVs. Additionally, since contents and filenames are encrypted with different context items in this case, we don't need to require the encryption modes match in the two cases. This change allows extent-based encryption to use 16-byte IVs with direct key policies, and allows a mismatch of modes (under the usual compatible modes constraints). Signed-off-by: Sweet Tea Dorminy --- fs/crypto/crypto.c | 15 +++++++++++++-- fs/crypto/fscrypt_private.h | 4 +--- fs/crypto/policy.c | 4 ++++ 3 files changed, 18 insertions(+), 5 deletions(-) diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c index 08b495dc5c0c..144a3a59ce51 100644 --- a/fs/crypto/crypto.c +++ b/fs/crypto/crypto.c @@ -93,8 +93,19 @@ void fscrypt_generate_iv(union fscrypt_iv *iv, u64 lblk_num, ret = fscrypt_get_extent_context(inode, lblk_num, &ctx, &extent_offset, NULL); WARN_ON_ONCE(ret); - memcpy(iv->raw, ctx.v1.iv.raw, sizeof(*iv)); - iv->lblk_num += cpu_to_le64(extent_offset); + if (ci->ci_mode->ivsize < offsetofend(union fscrypt_iv, nonce)) { + /* + * We need a 16 byte IV, but our nonce is 16 bytes. + * Copy to the start of the buffer and add the extent + * offset manually. + */ + memcpy(iv->raw, ctx.v1.nonce, FSCRYPT_FILE_NONCE_SIZE); + iv->lblk_num = cpu_to_le64(extent_offset + + le64_to_cpu(iv->lblk_num)); + return; + } + memcpy(iv->nonce, ctx.v1.nonce, FSCRYPT_FILE_NONCE_SIZE); + iv->lblk_num = cpu_to_le64(extent_offset); return; } diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h index 9c4cae2580de..bb2a18c83e56 100644 --- a/fs/crypto/fscrypt_private.h +++ b/fs/crypto/fscrypt_private.h @@ -292,7 +292,6 @@ union fscrypt_iv { __le64 dun[FSCRYPT_MAX_IV_SIZE / sizeof(__le64)]; }; - /* * fscrypt_extent_context - the encryption context for an extent * @@ -304,7 +303,7 @@ union fscrypt_iv { */ struct fscrypt_extent_context_v1 { u8 version; - union fscrypt_iv iv; + u8 nonce[FSCRYPT_FILE_NONCE_SIZE]; } __packed; union fscrypt_extent_context { @@ -312,7 +311,6 @@ union fscrypt_extent_context { struct fscrypt_extent_context_v1 v1; }; - void fscrypt_generate_iv(union fscrypt_iv *iv, u64 lblk_num, const struct fscrypt_info *ci); diff --git a/fs/crypto/policy.c b/fs/crypto/policy.c index a874afcf9652..39ef447ebaec 100644 --- a/fs/crypto/policy.c +++ b/fs/crypto/policy.c @@ -91,6 +91,10 @@ static bool supported_direct_key_modes(const struct inode *inode, { const struct fscrypt_mode *mode; + /* Extent-based encryption allows any mixed mode and IV size */ + if (inode->i_sb->s_cop->get_extent_context) + return true; + if (contents_mode != filenames_mode) { fscrypt_warn(inode, "Direct key flag not allowed with different contents and filenames modes");