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 251CAEB64D9 for ; Fri, 7 Jul 2023 23:37:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229663AbjGGXhR (ORCPT ); Fri, 7 Jul 2023 19:37:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42438 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229458AbjGGXhP (ORCPT ); Fri, 7 Jul 2023 19:37:15 -0400 Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DCB3A210B; Fri, 7 Jul 2023 16:37:14 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 53AC75C0092; Fri, 7 Jul 2023 19:37:14 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 07 Jul 2023 19:37:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bur.io; h=cc:cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1688773034; x=1688859434; bh=QF KkZ42Oa0NCInHkVTSfJ7m2sKCTgrV9e/fb7epwRDE=; b=SY12sPDICkuBHYMNoi RTTNO67APMrsD8pWiyrfjBzaBDzGoVoRUDiIdCwd7TrziOyGBFDvlvO9AkSZ1nLT SA3EMdQ5R72dkfTAYOpwHaJ3XX6nJkwFYrQzKiNRFqmIqxpXZLglK8Y38R+u0wsB uWr0nM29m09wxb91qXPnSqEnR6lrDxQOFkXLKJj831Yq98MNmMxBcL9ed+FxxJKv XM13DtH+9ap2tjQJvHBrW9a6I4heCR/Tv6FBddF+H+BwuNIl1qshmrCbBUODtXr3 whpCOTqzylHxAEcX82MN6a1oyb8VFhUH7qzTLkakDKGvJovdIrItouuONZ0G6iO8 aU4g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1688773034; x=1688859434; bh=QFKkZ42Oa0NCI nHkVTSfJ7m2sKCTgrV9e/fb7epwRDE=; b=Y+kPQCKJWa5Xgo+DeVO6QO43CqVn9 EDvdATyAe8eO36OIgctUp10nDQxh+Z+At1824Qy6XFtDyeqK0fQqYeWBGG1zraAt 81D8g272vwQMKRn3V+tbTMCVI+gDSkmVRjn3VC5qIPbLwO8J7gU4sQoyeV2D3IPb S2ps3yxExBuWZMWFJ4+qk2ISgpUvWTYuBUQxTXsfaWr/W1pySFsl2Grpq7JL3Liq KAY8puNOohZ6zcZn4++3UVXPUJgU03fV+AKQDtuCTFZ5qSq/3yYBqJ6SqxrDvGgA /3lvnTo6W+RzkexGY3xMMq6068s7wMXsh6EuXuBrbIVvHoFlCMfjjpJig== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrvddvgddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeeuohhrihhs uceuuhhrkhhovhcuoegsohhrihhssegsuhhrrdhioheqnecuggftrfgrthhtvghrnhepke dvkeffjeellefhveehvdejudfhjedthfdvveeiieeiudfguefgtdejgfefleejnecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghorhhishessg hurhdrihho X-ME-Proxy: Feedback-ID: i083147f8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 7 Jul 2023 19:37:13 -0400 (EDT) Date: Fri, 7 Jul 2023 16:36:05 -0700 From: Boris Burkov To: Sweet Tea Dorminy Cc: Chris Mason , Josef Bacik , David Sterba , Eric Biggers , "Theodore Y. Ts'o" , Jaegeuk Kim , kernel-team@meta.com, linux-btrfs@vger.kernel.org, linux-fscrypt@vger.kernel.org, Omar Sandoval Subject: Re: [PATCH v1 01/17] btrfs: disable various operations on encrypted inodes Message-ID: <20230707233605.GB2579580@zen> 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 Wed, Jun 28, 2023 at 08:35:24PM -0400, Sweet Tea Dorminy wrote: > From: Omar Sandoval > > Initially, only normal data extents, using the normal (non-direct) IO > path, will be encrypted. This change forbids various other bits: > - allows reflinking only if both inodes have the same encryption status > - disables direct IO on encrypted inodes > - disable inline data on encrypted inodes > > Signed-off-by: Omar Sandoval > Signed-off-by: Sweet Tea Dorminy > --- > fs/btrfs/file.c | 4 ++-- > fs/btrfs/inode.c | 3 ++- > fs/btrfs/reflink.c | 7 +++++++ > 3 files changed, 11 insertions(+), 3 deletions(-) > > diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c > index 392bc7d512a0..354962a7dd72 100644 > --- a/fs/btrfs/file.c > +++ b/fs/btrfs/file.c > @@ -1502,7 +1502,7 @@ static ssize_t btrfs_direct_write(struct kiocb *iocb, struct iov_iter *from) > goto relock; > } > > - if (check_direct_IO(fs_info, from, pos)) { > + if (IS_ENCRYPTED(inode) || check_direct_IO(fs_info, from, pos)) { > btrfs_inode_unlock(BTRFS_I(inode), ilock_flags); > goto buffered; > } > @@ -3741,7 +3741,7 @@ static ssize_t btrfs_direct_read(struct kiocb *iocb, struct iov_iter *to) > ssize_t read = 0; > ssize_t ret; > > - if (fsverity_active(inode)) > + if (IS_ENCRYPTED(inode) || fsverity_active(inode)) What's different about fscrypt vs fsverity that makes the inode flag a good check for encryption while verity relies on the presence of the extra context metadata? Is the enable model not subject to the same race where S_VERITY gets set ahead of actually storing the verity info/item? I think it's fine for these "skip" cases, but I imagine if we have cases of "I want a fully ready encrypted file" the verity-style check could be better? > return 0; > > if (check_direct_read(btrfs_sb(inode->i_sb), to, iocb->ki_pos)) > diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c > index dbbb67293e34..48eadc4f187f 100644 > --- a/fs/btrfs/inode.c > +++ b/fs/btrfs/inode.c > @@ -630,7 +630,8 @@ static noinline int cow_file_range_inline(struct btrfs_inode *inode, u64 size, > * compressed) data fits in a leaf and the configured maximum inline > * size. > */ > - if (size < i_size_read(&inode->vfs_inode) || > + if (IS_ENCRYPTED(&inode->vfs_inode) || > + size < i_size_read(&inode->vfs_inode) || > size > fs_info->sectorsize || > data_len > BTRFS_MAX_INLINE_DATA_SIZE(fs_info) || > data_len > fs_info->max_inline) > diff --git a/fs/btrfs/reflink.c b/fs/btrfs/reflink.c > index 0474bbe39da7..ad722f495c9b 100644 > --- a/fs/btrfs/reflink.c > +++ b/fs/btrfs/reflink.c > @@ -1,6 +1,7 @@ > // SPDX-License-Identifier: GPL-2.0 > > #include > +#include > #include > #include "ctree.h" > #include "fs.h" > @@ -811,6 +812,12 @@ static int btrfs_remap_file_range_prep(struct file *file_in, loff_t pos_in, > ASSERT(inode_in->i_sb == inode_out->i_sb); > } > > + /* > + * Can only reflink encrypted files if both files are encrypted. > + */ > + if (IS_ENCRYPTED(inode_in) != IS_ENCRYPTED(inode_out)) > + return -EINVAL; > + > /* Don't make the dst file partly checksummed */ > if ((BTRFS_I(inode_in)->flags & BTRFS_INODE_NODATASUM) != > (BTRFS_I(inode_out)->flags & BTRFS_INODE_NODATASUM)) { > -- > 2.40.1 >