From patchwork Wed Nov 2 11:52:55 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: 13028040 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 E052CC43219 for ; Wed, 2 Nov 2022 11:54:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230342AbiKBLxa (ORCPT ); Wed, 2 Nov 2022 07:53:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230290AbiKBLxX (ORCPT ); Wed, 2 Nov 2022 07:53:23 -0400 Received: from box.fidei.email (box.fidei.email [71.19.144.250]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 519631128; Wed, 2 Nov 2022 04:53:21 -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 ED81181472; Wed, 2 Nov 2022 07:53:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorminy.me; s=mail; t=1667390001; bh=jE2leRa5ZMbP3asOwLPiuZHq7U+RHYnAn/YhcDunJ/k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=htuquujX46HzwHuhqMOrMKbzpvC/5SPDtyUi9GONUUN7ob4ICrfF8ypConvwiX6dD Smf1bAAOsOj87Kmo8eww57Ytyora5aR7cc1O35b9YGK8JcFv+bInEfHh90UF1U2tWP 5qnPL0WKcn0Vu5g6sNKSN/FwYYdROmEvxzhOxQJOy2ASRvTDEnnODJ4l13YBehbbFs LxSwwkdISoju6E8lfCZ0brFY8e7bOnFS7JZvOslt/BJM0l1/0xDrzPQpJCUefPqHJ+ 8pZMwkGhUF9NMipZUItpu6jKhhmk8mtrGN3Cq1fwPvUF//K2NsPNeGhTmvxBSgdLJy 8dEK2WjIj6cFQ== 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 06/18] fscrypt: document btrfs' fscrypt quirks. Date: Wed, 2 Nov 2022 07:52:55 -0400 Message-Id: In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org As btrfs has a couple of quirks in its encryption compared to other filesystems, they should be documented like ext4's quirks. Additionally, extent-based contents encryption, being wholly new, deserves its own section to compare against inode-based contents encryption. Signed-off-by: Sweet Tea Dorminy Reviewed-by: Josef Bacik --- Documentation/filesystems/fscrypt.rst | 31 +++++++++++++++++++++------ 1 file changed, 25 insertions(+), 6 deletions(-) diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index 5ba5817c17c2..d551635865c3 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 @@ -280,6 +280,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 ----------------------- @@ -374,12 +379,12 @@ 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. +For most filesystems, each filesystem block within each file 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: @@ -403,6 +408,20 @@ 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. Each filesystem block in a data extent is encrypted +independently. Multiple files may refer to the extent, as long as they +all share the same key. The filesystem may relocate the extent on disk, +as long as the encrypted data within the extent retains its offset +within the data extent. + +Each extent stores a nonce; each block within the extent has an IV +based on this nonce and the logical block number within the extent as a +little endian number. + Filenames encryption --------------------