From mboxrd@z Thu Jan 1 00:00:00 1970 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 8599CC433FE for ; Thu, 20 Oct 2022 21:46:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229674AbiJTVqB (ORCPT ); Thu, 20 Oct 2022 17:46:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229498AbiJTVqA (ORCPT ); Thu, 20 Oct 2022 17:46:00 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88E14186798; Thu, 20 Oct 2022 14:45:59 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 493B4B82929; Thu, 20 Oct 2022 21:45:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A721AC433D6; Thu, 20 Oct 2022 21:45:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1666302357; bh=09uvNF5Sr9n3QZOMnVNgfVN86W2apYnMzLbEB/jQio8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=I8A4tQQc/QEYVd694XEQa5iOhsI75LLGmTz3ZWWcBB9f0JdZFOtO3Uar+Y2EfYTYA MfWdyZngvHxCuFH2DZ8xulxGpqnS5oYZgpJ1ppeXWAQiAB4Y+TGK3MWJbyE6gS19b8 Noe7ACTFsNQCrZ3b8DU5jr+zVBmh9uSRhsHxBii3EOLfZWvkw5N5kHL3lS739DFHER VBhTgoGHURC3/lCJo044on3vnjfTPjhzQnOIDYf0sTCMFjCJMMkudYBFJPyQNRCrJa kQHtmdDbsHLLuio6NHLKilIGreKFuNVVDf/drI7JnYRYICCg7fRoDjQda/FA2TlQ+d pJvqPemxHyWcQ== Date: Thu, 20 Oct 2022 14:45:54 -0700 From: Eric Biggers To: Sweet Tea Dorminy Cc: "Theodore Y. Ts'o" , Jaegeuk Kim , Chris Mason , Josef Bacik , David Sterba , linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH v3 04/22] fscrypt: add extent-based encryption Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Thu, Oct 20, 2022 at 12:58:23PM -0400, Sweet Tea Dorminy wrote: > Some filesystems need to encrypt data based on extents, rather than on > inodes, due to features incompatible with inode-based encryption. For > instance, btrfs can have multiple inodes referencing a single block of > data, and moves logical data blocks to different physical locations on > disk in the background; these two features mean traditional inode-based > file contents encryption will not work for btrfs. > > This change introduces fscrypt_extent_context objects, in analogy to > existing context objects based on inodes. For a filesystem which opts to > use extent-based encryption, a new hook provides a new > fscrypt_extent_context, generated in close analogy to the IVs generated > with existing policies. During file content encryption/decryption, the > existing fscrypt_context object provides key information, while the new > fscrypt_extent_context provides IV information. For filename encryption, > the existing IV generation methods are still used, since filenames are > not stored in extents. > > Signed-off-by: Sweet Tea Dorminy > --- > fs/crypto/crypto.c | 20 ++++++++-- > fs/crypto/fscrypt_private.h | 25 +++++++++++- > fs/crypto/inline_crypt.c | 28 ++++++++++--- > fs/crypto/policy.c | 79 +++++++++++++++++++++++++++++++++++++ > include/linux/fscrypt.h | 47 ++++++++++++++++++++++ > 5 files changed, 189 insertions(+), 10 deletions(-) > > diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c > index 7fe5979fbea2..08b495dc5c0c 100644 > --- a/fs/crypto/crypto.c > +++ b/fs/crypto/crypto.c > @@ -81,8 +81,22 @@ void fscrypt_generate_iv(union fscrypt_iv *iv, u64 lblk_num, > const struct fscrypt_info *ci) > { > u8 flags = fscrypt_policy_flags(&ci->ci_policy); > + struct inode *inode = ci->ci_inode; > + const struct fscrypt_operations *s_cop = inode->i_sb->s_cop; > > - memset(iv, 0, ci->ci_mode->ivsize); > + memset(iv, 0, sizeof(*iv)); > + if (s_cop->get_extent_context && lblk_num != U64_MAX) { > + size_t extent_offset; > + union fscrypt_extent_context ctx; > + int ret; > + > + 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); > + return; > + } Please read through my review comment https://lore.kernel.org/linux-fscrypt/Yx6MnaUqUTdjCmX+@quark/ again, as it doesn't seem that you've addressed it. - Eric