From patchwork Wed Jul 20 00:49:46 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Boris Burkov X-Patchwork-Id: 12923215 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 B6314C43334 for ; Wed, 20 Jul 2022 00:50:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236765AbiGTAt7 (ORCPT ); Tue, 19 Jul 2022 20:49:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46240 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229869AbiGTAt6 (ORCPT ); Tue, 19 Jul 2022 20:49:58 -0400 Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9E28E61B3D; Tue, 19 Jul 2022 17:49:57 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id ABCEA3200681; Tue, 19 Jul 2022 20:49:56 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 19 Jul 2022 20:49:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bur.io; h=cc :content-transfer-encoding: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=1658278196; x=1658364596; bh=ic szR0M7gLuJJF10HMx7zt0pqzTzn9tc7/VnThZs7uA=; b=a4Q5OD4O4BGwky5JDZ AeUJCYRhnfAyCzDHFgZxlFiUN0mYWPpbCLmbva2jyf4wyQdmUvanVWdW485hZ6wj P6yGMzT+qIS1DAbWbn1+aXno6sl2btUgmOZAh4i26z+miyo0r0gl1peaTKppZhaB 51EJhltfdr9+ViwjO3+ITQ2sk6AoY7+kY4KVGPiq5LNmpbXmZgqPnBmTQDj7LhCx yDttvV3rcXyPtWrlsv/NDZxUtIWuao17QkmEWNYLNI2Z8Nlp6prPwKfTAIQsEVWU JbOZqFObEv14BiD+974OYZro7DIggw5OupyFvK05Nlfsliw2+euy2J3WQXB4xNtj heyg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm3; t=1658278196; x=1658364596; bh=icszR0M7gLuJJ F10HMx7zt0pqzTzn9tc7/VnThZs7uA=; b=WS6qr9KLsWReMzahF9uE8hc/uGcIf IpghUM0iKlXzouip5hC7R6WlEs1Un2ujcruCHwqHvsmfkkOOAxaGzwSsMHCtuGgF qob10Cxa+qj+6eUJF2DDxNbqgtxFHdXRBtEA2ZgT2b6D3/b+XyF9ZYRI3fJq6IGA icw22eknp417Desk8JUhGIH+bzywx4sgNfh71eZ9aRUEFSG4ItVVe5MXVlPEjVGN 4KG1paKPHOvD0GOx6DON5/XDfPGflPoMDkTHvrtetpBL/56VvE3NdhsHA0YDoBA4 yBPLt/4Q+a+qWXwLKJ0w3dUdg2HPUoqOiDAJhHiYsf47MUIzfHaVi4kbA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudeluddgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkofgjfhgggfestdekre dtredttdenucfhrhhomhepuehorhhishcuuehurhhkohhvuceosghorhhishessghurhdr ihhoqeenucggtffrrghtthgvrhhnpeeiueffuedvieeujefhheeigfekvedujeejjeffve dvhedtudefiefhkeegueehleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhep mhgrihhlfhhrohhmpegsohhrihhssegsuhhrrdhioh X-ME-Proxy: Feedback-ID: i083147f8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 19 Jul 2022 20:49:55 -0400 (EDT) From: Boris Burkov To: fstests@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org, kernel-team@fb.com Subject: [PATCH v13 1/5] common/verity: require corruption functionality Date: Tue, 19 Jul 2022 17:49:46 -0700 Message-Id: X-Mailer: git-send-email 2.37.0 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org Corrupting ext4 and f2fs relies on xfs_io fiemap. Btrfs corruption testing will rely on a btrfs specific corruption utility. Add the ability to require corruption functionality to make this properly modular. To start, just check for fiemap, as that is needed universally for _fsv_scratch_corrupt_bytes. Signed-off-by: Boris Burkov Reviewed-by: Josef Bacik Reviewed-by: Eric Biggers Reviewed-by: Sweet Tea Dorminy --- common/verity | 6 ++++++ tests/generic/574 | 1 + tests/generic/576 | 1 + 3 files changed, 8 insertions(+) diff --git a/common/verity b/common/verity index 38eea157..d58cad90 100644 --- a/common/verity +++ b/common/verity @@ -141,6 +141,12 @@ _require_fsverity_dump_metadata() _fail "Unexpected output from 'fsverity dump_metadata': $(<"$tmpfile")" } +# Check for userspace tools needed to corrupt verity data or metadata. +_require_fsverity_corruption() +{ + _require_xfs_io_command "fiemap" +} + _scratch_mkfs_verity() { case $FSTYP in diff --git a/tests/generic/574 b/tests/generic/574 index 882baa21..17fdea52 100755 --- a/tests/generic/574 +++ b/tests/generic/574 @@ -28,6 +28,7 @@ _cleanup() _supported_fs generic _require_scratch_verity _disable_fsverity_signatures +_require_fsverity_corruption _scratch_mkfs_verity &>> $seqres.full _scratch_mount diff --git a/tests/generic/576 b/tests/generic/576 index 3ef04953..c8862de2 100755 --- a/tests/generic/576 +++ b/tests/generic/576 @@ -28,6 +28,7 @@ _supported_fs generic _require_scratch_verity _require_scratch_encryption _require_command "$KEYCTL_PROG" keyctl +_require_fsverity_corruption _disable_fsverity_signatures _scratch_mkfs_encrypted_verity &>> $seqres.full From patchwork Wed Jul 20 00:49:47 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Boris Burkov X-Patchwork-Id: 12923216 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 9AB5BC43334 for ; Wed, 20 Jul 2022 00:50:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238943AbiGTAuC (ORCPT ); Tue, 19 Jul 2022 20:50:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46308 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229869AbiGTAuB (ORCPT ); Tue, 19 Jul 2022 20:50:01 -0400 Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 62E3A61D6B; Tue, 19 Jul 2022 17:50:00 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 7CCFE3200681; Tue, 19 Jul 2022 20:49:59 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 19 Jul 2022 20:49:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bur.io; h=cc :content-transfer-encoding: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=1658278199; x=1658364599; bh=Uk rYvFlRpiuI9bgGcj6/LVlmIrB89hPXFscFDCWi2WA=; b=mXwQ/S/xFxFHPePKO9 CzbqFUhHUcRFd54aDngtR/7r1tuc54A+HmLPbCazl95enfAbGHgyJVl7w6WpuxCo KIwZrlXFuPX1s8ltnDivB0GHZ8fPw48FLDFXGog1jm+C6hBcEs0Bh5snYO2v+v/z EyIto/ruXrAC0K8EB7TmGreuXKifBK4z4uDXq9I88AuGXYqW4Pa6TNQo2MpfCNAo ATA65IeNvorCyu7TUQ6p7Awo7d7hOuE3nDhTIQvuKr2BjKuhZIxe7U8r7JE2FsFh acKVEgfMbBOAkc9UPj/bC/pWeoA6MpD/PIqNrXKj8mUEEmZXxAIwIpavMuLDvbAH IWtg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm3; t=1658278199; x=1658364599; bh=UkrYvFlRpiuI9 bgGcj6/LVlmIrB89hPXFscFDCWi2WA=; b=WmZmGNkahu7HYJUgOPClEa0dM1Ozp d1AA/I51CZPz9d/NuYlJpMBD03m/ezj+GZEMfz9V5s5bbp5Zf7cDlDiGhzKA03sn W2KAQC/cjbvHDtFwAAT9M9AXc2Mzpfnrs3RVzykUhiQg0Qupz5+oZNegnyD+lbLq 6ZqAKvR9BoEv3+yk721uE3rnKAS5DvgYbNmtznieV7o0SrxHqfScdsUVtOSkNE2H LB/h9HlIww8LaJYC+7wfOVRiw0XuF6kSWETrvQyNxRYWLJg1t1oUqxyoWGyzF3z6 Cs0ZZrpjqqVMkysAUqqmnU2r5CpEFGHuE8Q/XxOzoJX7EJuG87Useq2uQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudeluddgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkofgjfhgggfestdekre dtredttdenucfhrhhomhepuehorhhishcuuehurhhkohhvuceosghorhhishessghurhdr ihhoqeenucggtffrrghtthgvrhhnpeeiueffuedvieeujefhheeigfekvedujeejjeffve dvhedtudefiefhkeegueehleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhep mhgrihhlfhhrohhmpegsohhrihhssegsuhhrrdhioh X-ME-Proxy: Feedback-ID: i083147f8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 19 Jul 2022 20:49:58 -0400 (EDT) From: Boris Burkov To: fstests@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org, kernel-team@fb.com Subject: [PATCH v13 2/5] common/verity: support btrfs in generic fsverity tests Date: Tue, 19 Jul 2022 17:49:47 -0700 Message-Id: <2bbb68b90691a82b8143ba4612ea2cc761e44ecb.1658277755.git.boris@bur.io> X-Mailer: git-send-email 2.37.0 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org generic/572-579 have tests for fsverity. Now that btrfs supports fsverity, make these tests function as well. For a majority of the tests that pass, simply adding the case to mkfs a btrfs filesystem with no extra options is sufficient. However, generic/574 has tests for corrupting the merkle tree itself. Since btrfs uses a different scheme from ext4 and f2fs for storing this data, the existing logic for corrupting it doesn't work out of the box. Adapt it to properly corrupt btrfs merkle items. 576 does not run because btrfs does not support transparent encryption. This test relies on the btrfs implementation of fsverity in the patch: btrfs: initial fsverity support and on btrfs-corrupt-block for corruption in the patches titled: btrfs-progs: corrupt generic item data with btrfs-corrupt-block btrfs-progs: expand corrupt_file_extent in btrfs-corrupt-block Signed-off-by: Boris Burkov Reviewed-by: Sweet Tea Dorminy Reviewed-by: Eric Biggers --- common/btrfs | 5 +++++ common/config | 1 + common/verity | 31 +++++++++++++++++++++++++++++++ tests/generic/574 | 37 ++++++++++++++++++++++++++++++++++--- tests/generic/574.out | 13 ++++--------- 5 files changed, 75 insertions(+), 12 deletions(-) diff --git a/common/btrfs b/common/btrfs index 14ad890e..bd2639bf 100644 --- a/common/btrfs +++ b/common/btrfs @@ -580,3 +580,8 @@ _btrfs_buffered_read_on_mirror() : done } + +_require_btrfs_corrupt_block() +{ + _require_command "$BTRFS_CORRUPT_BLOCK_PROG" btrfs-corrupt-block +} diff --git a/common/config b/common/config index de3aba15..c30eec6d 100644 --- a/common/config +++ b/common/config @@ -297,6 +297,7 @@ export BTRFS_UTIL_PROG=$(type -P btrfs) export BTRFS_SHOW_SUPER_PROG=$(type -P btrfs-show-super) export BTRFS_CONVERT_PROG=$(type -P btrfs-convert) export BTRFS_TUNE_PROG=$(type -P btrfstune) +export BTRFS_CORRUPT_BLOCK_PROG=$(type -P btrfs-corrupt-block) export XFS_FSR_PROG=$(type -P xfs_fsr) export MKFS_NFS_PROG="false" export MKFS_CIFS_PROG="false" diff --git a/common/verity b/common/verity index d58cad90..4c50d2b1 100644 --- a/common/verity +++ b/common/verity @@ -3,6 +3,16 @@ # # Functions for setting up and testing fs-verity +# btrfs will return IO errors on corrupted data with or without fs-verity. +# to really test fs-verity, use nodatasum. +if [ "$FSTYP" == "btrfs" ]; then + if [ -z "$MOUNT_OPTIONS" ]; then + export MOUNT_OPTIONS="-o nodatasum" + else + export MOUNT_OPTIONS+=" -o nodatasum" + fi +fi + _require_scratch_verity() { _require_scratch @@ -145,6 +155,9 @@ _require_fsverity_dump_metadata() _require_fsverity_corruption() { _require_xfs_io_command "fiemap" + if [ $FSTYP == "btrfs" ]; then + _require_btrfs_corrupt_block + fi } _scratch_mkfs_verity() @@ -153,6 +166,9 @@ _scratch_mkfs_verity() ext4|f2fs) _scratch_mkfs -O verity ;; + btrfs) + _scratch_mkfs + ;; *) _notrun "No verity support for $FSTYP" ;; @@ -314,6 +330,21 @@ _fsv_scratch_corrupt_merkle_tree() (( offset += ($(_get_filesize $file) + 65535) & ~65535 )) _fsv_scratch_corrupt_bytes $file $offset ;; + btrfs) + local ino=$(stat -c '%i' $file) + _scratch_unmount + local byte="" + while read -n 1 byte; do + local ascii=$(printf "%d" "'$byte'") + # This command will find a Merkle tree item for the inode (-I $ino,37,0) + # in the default filesystem tree (-r 5) and corrupt one byte (-b 1) at + # $offset (-o $offset) with the ascii representation of the byte we read + # (-v $ascii) + $BTRFS_CORRUPT_BLOCK_PROG -r 5 -I $ino,37,0 -v $ascii -o $offset -b 1 $SCRATCH_DEV + (( offset += 1 )) + done + _scratch_mount + ;; *) _fail "_fsv_scratch_corrupt_merkle_tree() unimplemented on $FSTYP" ;; diff --git a/tests/generic/574 b/tests/generic/574 index 17fdea52..fd4488c9 100755 --- a/tests/generic/574 +++ b/tests/generic/574 @@ -126,6 +126,39 @@ corruption_test() fi } +# Reading the last block of the file with mmap is tricky, so we need to be +# a bit careful. Some filesystems read the last block in full, while others +# return zeros in the last block past EOF, regardless of the contents on +# disk. In the former, corruption should be detected and result in SIGBUS, +# while in the latter we would expect zeros past EOF, but no error. +corrupt_eof_block_test() { + local file_len=$1 + local zap_len=$2 + local page_aligned_eof=$(round_up_to_page_boundary $file_len) + _fsv_scratch_begin_subtest "Corruption test: EOF block" + setup_zeroed_file $file_len false + cmp $fsv_file $fsv_orig_file + echo "Corrupting bytes..." + head -c $zap_len /dev/zero | tr '\0' X \ + | _fsv_scratch_corrupt_bytes $fsv_file $file_len + + echo "Reading eof block via mmap into a temporary file..." + bash -c "trap '' SIGBUS; $XFS_IO_PROG -r $fsv_file \ + -c 'mmap -r 0 $page_aligned_eof' \ + -c 'mread -v $file_len $zap_len'" \ + |& filter_sigbus >$tmp.eof_block_read 2>&1 + + head -c $file_len /dev/zero > $tmp.zero_cmp_file + $XFS_IO_PROG -r $tmp.zero_cmp_file \ + -c "mmap -r 0 $page_aligned_eof" \ + -c "mread -v $file_len $zap_len" >$tmp.eof_zero_read + + echo "Checking for SIGBUS or zeros..." + grep -q -e '^Bus error$' $tmp.eof_block_read \ + || diff $tmp.eof_block_read $tmp.eof_zero_read \ + && echo "OK" +} + # Note: these tests just overwrite some bytes without checking their original # values. Therefore, make sure to overwrite at least 5 or so bytes, to make it # nearly guaranteed that there will be a change -- even when the test file is @@ -136,9 +169,7 @@ corruption_test 131072 4091 5 corruption_test 131072 65536 65536 corruption_test 131072 131067 5 -# Non-zeroed bytes in the final partial block beyond EOF should cause reads to -# fail too. Such bytes would be visible via mmap(). -corruption_test 130999 131000 72 +corrupt_eof_block_test 130999 72 # Merkle tree corruption. corruption_test 200000 100 10 true diff --git a/tests/generic/574.out b/tests/generic/574.out index 3c08d3e8..d40d1263 100644 --- a/tests/generic/574.out +++ b/tests/generic/574.out @@ -56,17 +56,12 @@ Bus error Validating corruption (reading just corrupted part via mmap)... Bus error -# Corruption test: file_len=130999 zap_offset=131000 zap_len=72 +# Corruption test: EOF block f5cca0d7fbb8b02bc6118a9954d5d306 SCRATCH_MNT/file.fsv Corrupting bytes... -Validating corruption (reading full file)... -md5sum: SCRATCH_MNT/file.fsv: Input/output error -Validating corruption (direct I/O)... -dd: error reading 'SCRATCH_MNT/file.fsv': Input/output error -Validating corruption (reading full file via mmap)... -Bus error -Validating corruption (reading just corrupted part via mmap)... -Bus error +Reading eof block via mmap into a temporary file... +Checking for SIGBUS or zeros... +OK # Corruption test: file_len=200000 zap_offset=100 (in Merkle tree) zap_len=10 4a1e4325031b13f933ac4f1db9ecb63f SCRATCH_MNT/file.fsv From patchwork Wed Jul 20 00:49:48 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Boris Burkov X-Patchwork-Id: 12923217 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 AEEECCCA47F for ; Wed, 20 Jul 2022 00:50:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238982AbiGTAuG (ORCPT ); Tue, 19 Jul 2022 20:50:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46592 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229869AbiGTAuF (ORCPT ); Tue, 19 Jul 2022 20:50:05 -0400 Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 339D2E8; Tue, 19 Jul 2022 17:50:03 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 4F3B63200406; Tue, 19 Jul 2022 20:50:02 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 19 Jul 2022 20:50:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bur.io; h=cc :content-transfer-encoding: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=1658278201; x=1658364601; bh=AI FnraB5iB9/z8lb6KnRIZ6/m/iog9WfL9cXis/yvLo=; b=HSTlBtV6njGhLxQGqk pFvTxeiQ+sk9Ns4fIbSoqG6kH7VdcQRyfSF2BsCti9rhOSpGyk4VnkeAzhpljRx4 HTE66Z0bzuZ8Uhsmxkcn1vMlBgPRbXzJxo+yLv7lQnqF+x4uNXvybULU4JYm6S9e XBLOMTUAvfqnuReTRXUrTL1gqGSfVQu/Lkl73pWMkqrM+kZEFoougfpATKDOi/WP 3kHjXjBAcBwgVfF+DjWFAMIIT8Bjwz9HjwcAkKaZXnx3PK1X7+JaZq5btZrPoJws K+qlMM9L8wzjY9emGI/kiNK52zqQbA9Hbj9e0MHmlUR7oxtvH4rRh1imDpRvb4EB M0OA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm3; t=1658278201; x=1658364601; bh=AIFnraB5iB9/z 8lb6KnRIZ6/m/iog9WfL9cXis/yvLo=; b=jvVnpcaO5PjZiCGpseOTni0VCr+sf jhtAJqMWad1U4gSbuARDE19XVqVVGBSyqlgXpQV6ZcGyC+lHfS86/4Dg6D8sQ0Bb /QaFsGZTBG4QonxZ6N2kHg4wFQb79K0cs0ELc0iwwbXB+d1fMx7oRn6TeRZFyrWt wZZaNl+2MWqlhTk8r5kFTw7Ggz1dWTAYOLC793iF0RufzK6Fj9X9HGOEnhNSiGw9 SSm4LTY++lxJdozy18Fy7BTKxQgRiY6d5WxlQEOWztwACsejYsjR7uH3kbMGep6R s28Nj4bU2CxxtJYmlfyQ2BhRI9MowHLcLjq2QxioT4NkmxrnvwnNjaViQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudeluddgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkofgjfhgggfestdekre dtredttdenucfhrhhomhepuehorhhishcuuehurhhkohhvuceosghorhhishessghurhdr ihhoqeenucggtffrrghtthgvrhhnpeeiueffuedvieeujefhheeigfekvedujeejjeffve dvhedtudefiefhkeegueehleenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhep mhgrihhlfhhrohhmpegsohhrihhssegsuhhrrdhioh X-ME-Proxy: Feedback-ID: i083147f8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 19 Jul 2022 20:50:01 -0400 (EDT) From: Boris Burkov To: fstests@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org, kernel-team@fb.com Subject: [PATCH v13 3/5] btrfs: test btrfs specific fsverity corruption Date: Tue, 19 Jul 2022 17:49:48 -0700 Message-Id: <533ebd60aa4eabe5b9a205b927443722f8f1597f.1658277755.git.boris@bur.io> X-Mailer: git-send-email 2.37.0 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org There are some btrfs specific fsverity scenarios that don't map neatly onto the tests in generic/574 like holes, inline extents, and preallocated extents. Cover those in a btrfs specific test. This test relies on the btrfs implementation of fsverity in the patch: btrfs: initial fsverity support and on btrfs-corrupt-block for corruption in the patches titled: btrfs-progs: corrupt generic item data with btrfs-corrupt-block btrfs-progs: expand corrupt_file_extent in btrfs-corrupt-block Signed-off-by: Boris Burkov Reviewed-by: Sweet Tea Dorminy --- tests/btrfs/290 | 172 ++++++++++++++++++++++++++++++++++++++++++++ tests/btrfs/290.out | 25 +++++++ 2 files changed, 197 insertions(+) create mode 100755 tests/btrfs/290 create mode 100644 tests/btrfs/290.out diff --git a/tests/btrfs/290 b/tests/btrfs/290 new file mode 100755 index 00000000..b7254c5e --- /dev/null +++ b/tests/btrfs/290 @@ -0,0 +1,172 @@ +#! /bin/bash +# SPDX-License-Identifier: GPL-2.0 +# Copyright (C) 2021 Facebook, Inc. All Rights Reserved. +# +# FS QA Test 290 +# +# Test btrfs support for fsverity. +# This test extends the generic fsverity testing by corrupting inline extents, +# preallocated extents, holes, and the Merkle descriptor in a btrfs-aware way. +# +. ./common/preamble +_begin_fstest auto quick verity + +# Import common functions. +. ./common/filter +. ./common/verity + +# real QA test starts here +_supported_fs btrfs +_require_scratch_verity +_require_scratch_nocheck +_require_odirect +_require_xfs_io_command "falloc" +_require_xfs_io_command "pread" +_require_xfs_io_command "pwrite" +_require_btrfs_corrupt_block + +get_ino() { + local file=$1 + stat -c "%i" $file +} + +validate() { + local f=$1 + local sz=$(_get_filesize $f) + # buffered io + echo $(basename $f) + $XFS_IO_PROG -rc "pread -q 0 $sz" $f 2>&1 | _filter_scratch + # direct io + $XFS_IO_PROG -rdc "pread -q 0 $sz" $f 2>&1 | _filter_scratch +} + +# corrupt the data portion of an inline extent +corrupt_inline() { + local f=$SCRATCH_MNT/inl + $XFS_IO_PROG -fc "pwrite -q -S 0x58 0 42" $f + local ino=$(get_ino $f) + _fsv_enable $f + _scratch_unmount + # inline data starts at disk_bytenr + # overwrite the first u64 with random bogus junk + $BTRFS_CORRUPT_BLOCK_PROG -i $ino -x 0 -f disk_bytenr $SCRATCH_DEV > /dev/null 2>&1 + _scratch_mount + validate $f +} + +# preallocate a file, then corrupt it by changing it to a regular file +corrupt_prealloc_to_reg() { + local f=$SCRATCH_MNT/prealloc + $XFS_IO_PROG -fc "falloc 0 12k" $f + local ino=$(get_ino $f) + _fsv_enable $f + _scratch_unmount + # ensure non-zero at the pre-allocated region on disk + # set extent type from prealloc (2) to reg (1) + $BTRFS_CORRUPT_BLOCK_PROG -i $ino -x 0 -f type -v 1 $SCRATCH_DEV >/dev/null 2>&1 + _scratch_mount + # now that it's a regular file, reading actually looks at the previously + # preallocated region, so ensure that has non-zero contents. + head -c 5 /dev/zero | tr '\0' X | _fsv_scratch_corrupt_bytes $f 0 + validate $f +} + +# corrupt a regular file by changing the type to preallocated +corrupt_reg_to_prealloc() { + local f=$SCRATCH_MNT/reg + $XFS_IO_PROG -fc "pwrite -q -S 0x58 0 12288" $f + local ino=$(get_ino $f) + _fsv_enable $f + _scratch_unmount + # set type from reg (1) to prealloc (2) + $BTRFS_CORRUPT_BLOCK_PROG -i $ino -x 0 -f type -v 2 $SCRATCH_DEV >/dev/null 2>&1 + _scratch_mount + validate $f +} + +# corrupt a file by punching a hole +corrupt_punch_hole() { + local f=$SCRATCH_MNT/punch + $XFS_IO_PROG -fc "pwrite -q -S 0x58 0 12288" $f + local ino=$(get_ino $f) + # make a new extent in the middle, sync so the writes don't coalesce + $XFS_IO_PROG -c sync $SCRATCH_MNT + $XFS_IO_PROG -fc "pwrite -q -S 0x59 4096 4096" $f + _fsv_enable $f + _scratch_unmount + # change disk_bytenr to 0, representing a hole + $BTRFS_CORRUPT_BLOCK_PROG -i $ino -x 4096 -f disk_bytenr -v 0 $SCRATCH_DEV > /dev/null 2>&1 + _scratch_mount + validate $f +} + +# plug hole +corrupt_plug_hole() { + local f=$SCRATCH_MNT/plug + $XFS_IO_PROG -fc "pwrite -q -S 0x58 0 12288" $f + local ino=$(get_ino $f) + $XFS_IO_PROG -fc "falloc 4k 4k" $f + _fsv_enable $f + _scratch_unmount + # change disk_bytenr to some value, plugging the hole + $BTRFS_CORRUPT_BLOCK_PROG -i $ino -x 4096 -f disk_bytenr -v 13639680 $SCRATCH_DEV > /dev/null 2>&1 + _scratch_mount + validate $f +} + +# corrupt the fsverity descriptor item indiscriminately (causes EINVAL) +corrupt_verity_descriptor() { + local f=$SCRATCH_MNT/desc + $XFS_IO_PROG -fc "pwrite -q -S 0x58 0 12288" $f + local ino=$(get_ino $f) + _fsv_enable $f + _scratch_unmount + # key for the descriptor item is , + # 88 is X. So we write 5 Xs to the start of the descriptor + $BTRFS_CORRUPT_BLOCK_PROG -r 5 -I $ino,36,1 -v 88 -o 0 -b 5 $SCRATCH_DEV > /dev/null 2>&1 + _scratch_mount + validate $f +} + +# specifically target the root hash in the descriptor (causes EIO) +corrupt_root_hash() { + local f=$SCRATCH_MNT/roothash + $XFS_IO_PROG -fc "pwrite -q -S 0x58 0 12288" $f + local ino=$(get_ino $f) + _fsv_enable $f + _scratch_unmount + $BTRFS_CORRUPT_BLOCK_PROG -r 5 -I $ino,36,1 -v 88 -o 16 -b 1 $SCRATCH_DEV > /dev/null 2>&1 + _scratch_mount + validate $f +} + +# corrupt the Merkle tree data itself +corrupt_merkle_tree() { + local f=$SCRATCH_MNT/merkle + $XFS_IO_PROG -fc "pwrite -q -S 0x58 0 12288" $f + local ino=$(get_ino $f) + _fsv_enable $f + _scratch_unmount + # key for the descriptor item is , + # 88 is X. So we write 5 Xs to somewhere in the middle of the first + # merkle item + $BTRFS_CORRUPT_BLOCK_PROG -r 5 -I $ino,37,0 -v 88 -o 100 -b 5 $SCRATCH_DEV > /dev/null 2>&1 + _scratch_mount + validate $f +} + +# real QA test starts here +_scratch_mkfs >/dev/null +_scratch_mount + +corrupt_inline +corrupt_prealloc_to_reg +corrupt_reg_to_prealloc +corrupt_punch_hole +corrupt_plug_hole +corrupt_verity_descriptor +corrupt_root_hash +corrupt_merkle_tree + +status=0 +exit diff --git a/tests/btrfs/290.out b/tests/btrfs/290.out new file mode 100644 index 00000000..056b114b --- /dev/null +++ b/tests/btrfs/290.out @@ -0,0 +1,25 @@ +QA output created by 290 +inl +pread: Input/output error +pread: Input/output error +prealloc +pread: Input/output error +pread: Input/output error +reg +pread: Input/output error +pread: Input/output error +punch +pread: Input/output error +pread: Input/output error +plug +pread: Input/output error +pread: Input/output error +desc +SCRATCH_MNT/desc: Invalid argument +SCRATCH_MNT/desc: Invalid argument +roothash +pread: Input/output error +pread: Input/output error +merkle +pread: Input/output error +pread: Input/output error From patchwork Wed Jul 20 00:49:49 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Boris Burkov X-Patchwork-Id: 12923218 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 E3BF7C433EF for ; Wed, 20 Jul 2022 00:50:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238980AbiGTAuI (ORCPT ); Tue, 19 Jul 2022 20:50:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46736 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229869AbiGTAuH (ORCPT ); Tue, 19 Jul 2022 20:50:07 -0400 Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 033D5E79; Tue, 19 Jul 2022 17:50:05 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 181B23200901; Tue, 19 Jul 2022 20:50:05 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 19 Jul 2022 20:50:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bur.io; h=cc :content-transfer-encoding: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=1658278204; x=1658364604; bh=OD ZmgbrhVrxYeIj7xGH9Be+izw+faEUFSqtv/9vlspA=; b=bA9W3KRhfCOlziPi79 3BZr6gTYzx5p4abCe+jpLcuzOqKuWILfHl5WMEgQ9NTUFIZEr4RjgwYLbg+G9M3A dX6IBzng4/2l9b4eaqXBILTseMz97hjT/l+XrAJM0NcOgZ5pU/kiUUXLf+3P9fwm m6OzuE7zYMpoTpy7zcZJ1lGdN6USem++cAW7b9zVEsRpej+PrjM9NWPcS5k+5VVm I7FCjU4jlQYisiJb6toFVgo5+TMvXxZW+7E1JC+pEBNBh/scJsRHZHRiXzdd68zD OAA4sWvsjmdbPkXUrKa3xcADKrgcuCf4O5K0IbcyIZYWNI4pjSzfO+mu/QKx1sM5 5PMw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm3; t=1658278204; x=1658364604; bh=ODZmgbrhVrxYe Ij7xGH9Be+izw+faEUFSqtv/9vlspA=; b=e66f/NhIcxgPLH4k6O6rDby7or7S/ JQ1h9/vR1J+0GN0WrxE8WLx/cKUquMUdz1rzsERy9hPNrXUzeIACRf+Ak909AKkK Cj9uy4/cAtAyYhkw2fMVOIdD/zCi8VXnX60fSdLVPEg4MBUGj/jY7GRjloGxdbmA iJuU8H7xTi3zmHJ7zJmykCvsR1uVneUkjNpf61oR3ey2nBW/Po+4J/mwjN1qAPx1 ZU8fuVRorWWz4YXP91CI1qweOMvCcLerSNi4cOpCis0KyoJ3/1AAGgv8SuJ8iaiE B5Fa62Nnav7B1PkvuyVvy4KanIhC6yC6+k3toCbmtKHrcPJuJUN0+WY2Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudeluddgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkofgjfhgggfestdekre dtredttdenucfhrhhomhepuehorhhishcuuehurhhkohhvuceosghorhhishessghurhdr ihhoqeenucggtffrrghtthgvrhhnpeeiueffuedvieeujefhheeigfekvedujeejjeffve dvhedtudefiefhkeegueehleenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhep mhgrihhlfhhrohhmpegsohhrihhssegsuhhrrdhioh X-ME-Proxy: Feedback-ID: i083147f8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 19 Jul 2022 20:50:04 -0400 (EDT) From: Boris Burkov To: fstests@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org, kernel-team@fb.com Subject: [PATCH v13 4/5] btrfs: test verity orphans with dmlogwrites Date: Tue, 19 Jul 2022 17:49:49 -0700 Message-Id: <57123fe31da2886cfae01e27ffc43095ef7db7d1.1658277755.git.boris@bur.io> X-Mailer: git-send-email 2.37.0 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org The behavior of orphans is most interesting across mounts, interrupted at arbitrary points during fsverity enable. To cover as many such cases as possible, use dmlogwrites and dmsnapshot as in log-writes/replay-individual.sh. As we replay the log events, we run a state machine with different invariants enforced at each state. There are three possible states for a given point in the log: 0. Verity has not yet started 1. Verity has started but not finished 2. Verity has finished. The possible transitions with causes are: 0->1: We see an orphan item for the file. 1->2: Running 'fsverity measure' succeeds on the file. Each state has its own invariant for testing: 0: No verity items exist. 1: Mount should handle the orphan and blow away verity data: expect 0 Merkle items after mounting. 2: The orphan should be gone and mount should not blow away merkle items. Expect the same number of merkle items before and after mounting. As a result, we can be confident that if the file system loses power at any point during enabling verity on a file, the work is either completed, or gets rolled-back by mount. Signed-off-by: Boris Burkov Reviewed-by: Sweet Tea Dorminy --- tests/btrfs/291 | 168 ++++++++++++++++++++++++++++++++++++++++++++ tests/btrfs/291.out | 2 + 2 files changed, 170 insertions(+) create mode 100755 tests/btrfs/291 create mode 100644 tests/btrfs/291.out diff --git a/tests/btrfs/291 b/tests/btrfs/291 new file mode 100755 index 00000000..bbdd183d --- /dev/null +++ b/tests/btrfs/291 @@ -0,0 +1,168 @@ +#! /bin/bash +# SPDX-License-Identifier: GPL-2.0 +# Copyright (C) 2021 Facebook, Inc. All Rights Reserved. +# +# FS QA Test 291 +# +# Test btrfs consistency after each FUA while enabling verity on a file +# This test works by following the pattern in log-writes/replay-individual.sh: +# 1. run a workload (verity + sync) while logging to the log device +# 2. replay an entry to the replay device +# 3. snapshot the replay device to the snapshot device +# 4. run destructive tests on the snapshot device (e.g. mount with orphans) +# 5. goto 2 +# +. ./common/preamble +_begin_fstest auto verity recoveryloop + +# Override the default cleanup function. +_cleanup() +{ + cd / + _log_writes_cleanup &> /dev/null + rm -f $img + $LVM_PROG vgremove -f -y $vgname >>$seqres.full 2>&1 + losetup -d $loop_dev >>$seqres.full 2>&1 +} + +# Import common functions. +. ./common/filter +. ./common/attr +. ./common/dmlogwrites +. ./common/verity + +# real QA test starts here +_supported_fs btrfs + +_require_scratch +_require_test +_require_loop +_require_log_writes +_require_dm_target snapshot +_require_command $LVM_PROG lvm +_require_scratch_verity +_require_btrfs_command inspect-internal dump-tree +_require_test_program "log-writes/replay-log" + +sync_loop() { + i=$1 + [ -z "$i" ] && _fail "sync loop needs a number of iterations" + while [ $i -gt 0 ] + do + $XFS_IO_PROG -c sync $SCRATCH_MNT + let i-=1 + done +} + +dump_tree() { + local dev=$1 + $BTRFS_UTIL_PROG inspect-internal dump-tree $dev +} + +count_item() { + local dev=$1 + local item=$2 + dump_tree $dev | grep -c "$item" +} + +count_merkle_items() { + local dev=$1 + count_item $dev 'VERITY_\(DESC\|MERKLE\)_ITEM' +} + +_log_writes_init $SCRATCH_DEV +_log_writes_mkfs +_log_writes_mount + +f=$SCRATCH_MNT/fsv +MB=$((1024 * 1024)) +img=$TEST_DIR/$$.img +$XFS_IO_PROG -fc "pwrite -q 0 $((10 * $MB))" $f +$XFS_IO_PROG -c sync $SCRATCH_MNT +sync_loop 10 & +sync_proc=$! +_fsv_enable $f +$XFS_IO_PROG -c sync $SCRATCH_MNT +wait $sync_proc + +_log_writes_unmount +_log_writes_remove + +# the snapshot and the replay will each be the size of the log writes dev +# so we create a loop device of size 2 * logwrites and then split it into +# replay and snapshot with lvm. +log_writes_blocks=$(blockdev --getsz $LOGWRITES_DEV) +replay_bytes=$((512 * $log_writes_blocks)) +img_bytes=$((2 * $replay_bytes)) + +$XFS_IO_PROG -fc "pwrite -q -S 0 $img_bytes $MB" $img >>$seqres.full 2>&1 || \ + _fail "failed to create image for loop device" +loop_dev=$(losetup -f --show $img) +vgname=vg_replay +lvname=lv_replay +replay_dev=/dev/mapper/vg_replay-lv_replay +snapname=lv_snap +snap_dev=/dev/mapper/vg_replay-$snapname + +$LVM_PROG vgcreate -f $vgname $loop_dev >>$seqres.full 2>&1 || _fail "failed to vgcreate $vgname" +$LVM_PROG lvcreate -L "$replay_bytes"B -n $lvname $vgname -y >>$seqres.full 2>&1 || \ + _fail "failed to lvcreate $lvname" +$UDEV_SETTLE_PROG >>$seqres.full 2>&1 + +replay_log_prog=$here/src/log-writes/replay-log +num_entries=$($replay_log_prog --log $LOGWRITES_DEV --num-entries) +entry=$($replay_log_prog --log $LOGWRITES_DEV --replay $replay_dev --find --end-mark mkfs | cut -d@ -f1) +prev=$(_log_writes_mark_to_entry_number mkfs) +[ -z "$prev" ] && _fail "failed to locate entry mark 'mkfs'" +cur=$(_log_writes_find_next_fua $prev) + +# state = 0: verity hasn't started +# state = 1: verity underway +# state = 2: verity done +state=0 +while [ ! -z "$cur" ]; +do + _log_writes_replay_log_range $cur $replay_dev >> $seqres.full + + $LVM_PROG lvcreate -s -L 4M -n $snapname $vgname/$lvname >>$seqres.full 2>&1 || \ + _fail "Failed to create snapshot" + $UDEV_SETTLE_PROG >>$seqres.full 2>&1 + + orphan=$(count_item $snap_dev ORPHAN) + [ $state -eq 0 ] && [ $orphan -gt 0 ] && state=1 + + pre_mount=$(count_merkle_items $snap_dev) + _mount $snap_dev $SCRATCH_MNT || _fail "mount failed at entry $cur" + fsverity measure $SCRATCH_MNT/fsv >>$seqres.full 2>&1 + measured=$? + umount $SCRATCH_MNT + [ $state -eq 1 ] && [ $measured -eq 0 ] && state=2 + [ $state -eq 2 ] && ([ $measured -eq 0 ] || _fail "verity done, but measurement failed at entry $cur") + post_mount=$(count_merkle_items $snap_dev) + + echo "entry: $cur, state: $state, orphan: $orphan, pre_mount: $pre_mount, post_mount: $post_mount" >> $seqres.full + + if [ $state -eq 1 ]; then + [ $post_mount -eq 0 ] || \ + _fail "mount failed to clear under-construction merkle items pre: $pre_mount, post: $post_mount at entry $cur"; + fi + if [ $state -eq 2 ]; then + [ $pre_mount -gt 0 ] || \ + _fail "expected to have verity items before mount at entry $cur" + [ $pre_mount -eq $post_mount ] || \ + _fail "mount cleared merkle items after verity was enabled $pre_mount vs $post_mount at entry $cur"; + fi + + $LVM_PROG lvremove $vgname/$snapname -y >>$seqres.full + + prev=$cur + cur=$(_log_writes_find_next_fua $(($cur + 1))) +done + +[ $state -eq 2 ] || _fail "expected to reach verity done state" + +echo "Silence is golden" + +# success, all done +status=0 +exit diff --git a/tests/btrfs/291.out b/tests/btrfs/291.out new file mode 100644 index 00000000..04605c70 --- /dev/null +++ b/tests/btrfs/291.out @@ -0,0 +1,2 @@ +QA output created by 291 +Silence is golden From patchwork Wed Jul 20 00:49:50 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Boris Burkov X-Patchwork-Id: 12923219 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 C68CCC433EF for ; Wed, 20 Jul 2022 00:50:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238423AbiGTAuL (ORCPT ); Tue, 19 Jul 2022 20:50:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47002 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229585AbiGTAuK (ORCPT ); Tue, 19 Jul 2022 20:50:10 -0400 Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 07BF8284; Tue, 19 Jul 2022 17:50:09 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 2229332001FF; Tue, 19 Jul 2022 20:50:07 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 19 Jul 2022 20:50:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bur.io; h=cc :content-transfer-encoding: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=1658278207; x=1658364607; bh=Z/ ScZcYly62LPugXqA1E0RFAVGO1KRdhrR/RtutZVQU=; b=FVmBlks/BqbtwugQbA 5ZaVFW133P0/K6KAlMthoEHcVeGdRtoyv/fZUAPtkGZEvL7k9GcX+rKGc4oaBwo4 gwpBsspkP3vcaOcrGCRaQh6vyWNXY09KP8bhhoX6wRaMqTb9ll2LKPfz3mMPqXJo KenYHtzDzFpinx7k2VFLxrzmsTMT/7HUZt+Jlfv0AtZmQcxswbvFPXUYs2EAPujI 84V+ClhO3I3AhysUZMuUZTUsWJCCpcq4vCLU9Dhvb+LNA2u3TfeK2BEX1CGx+iAK K80eFMrxNYvyVK/oDWpuIIPly3Rfg2JO6gKePJmuGMrXY/jc7GU9RoXns74GOmeO CRZw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm3; t=1658278207; x=1658364607; bh=Z/ScZcYly62LP ugXqA1E0RFAVGO1KRdhrR/RtutZVQU=; b=zjzF88279Z+sAFoC4vXDREx1ApAPh tdscfRpKLX8V2UeH3+H1cw0FGBu23jQsSZi/40zuKoEQYkF/uON/eHF1axRWC2bk lAbMl3msl7WI/P6zqUokf9ehJ2EY8DoktXuTIsqeXzyUF3XYMhl8qs8BZGHI1jri m4Sl8yLVwvD06x6rwC+HMQR7jOpybK42WprbvN+x2M+hr9jTt5Et+qf35BAE54Ac wtCctiPBwW1GWFicXHKhekL5oO5IybtkB4+tDpNzC6qkZqFqOXa6aALQORZoGEk2 9sxPNkeXzOMVAHZqPu8fnUP9zQ3u5zm/YZVZpyC8WV7NuKBCUPGJFfWRw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudeluddgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkofgjfhgggfestdekre dtredttdenucfhrhhomhepuehorhhishcuuehurhhkohhvuceosghorhhishessghurhdr ihhoqeenucggtffrrghtthgvrhhnpeeiueffuedvieeujefhheeigfekvedujeejjeffve dvhedtudefiefhkeegueehleenucevlhhushhtvghrufhiiigvpedvnecurfgrrhgrmhep mhgrihhlfhhrohhmpegsohhrihhssegsuhhrrdhioh X-ME-Proxy: Feedback-ID: i083147f8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 19 Jul 2022 20:50:06 -0400 (EDT) From: Boris Burkov To: fstests@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org, kernel-team@fb.com Subject: [PATCH v13 5/5] generic: test fs-verity EFBIG scenarios Date: Tue, 19 Jul 2022 17:49:50 -0700 Message-Id: X-Mailer: git-send-email 2.37.0 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org btrfs, ext4, and f2fs cache the Merkle tree past EOF, which restricts the maximum file size beneath the normal maximum. Test the logic in those filesystems against files with sizes near the maximum. To work properly, this does require some understanding of the practical but not standardized layout of the Merkle tree. This is a bit unpleasant and could make the test incorrect in the future, if the implementation changes. On the other hand, it feels quite useful to test this tricky edge case. It could perhaps be made more generic by adding some ioctls to let the file system communicate the maximum file size for a verity file or some information about the storage of the Merkle tree. Signed-off-by: Boris Burkov Reviewed-by: Eric Biggers Reviewed-by: Sweet Tea Dorminy --- common/verity | 11 ++++++++ tests/generic/692 | 64 +++++++++++++++++++++++++++++++++++++++++++ tests/generic/692.out | 7 +++++ 3 files changed, 82 insertions(+) create mode 100644 tests/generic/692 create mode 100644 tests/generic/692.out diff --git a/common/verity b/common/verity index 4c50d2b1..65a39d3e 100644 --- a/common/verity +++ b/common/verity @@ -350,3 +350,14 @@ _fsv_scratch_corrupt_merkle_tree() ;; esac } + +_require_fsverity_max_file_size_limit() +{ + case $FSTYP in + btrfs|ext4|f2fs) + ;; + *) + _notrun "$FSTYP does not store verity data past EOF; no special file size limit" + ;; + esac +} diff --git a/tests/generic/692 b/tests/generic/692 new file mode 100644 index 00000000..0bb1fd33 --- /dev/null +++ b/tests/generic/692 @@ -0,0 +1,64 @@ +#! /bin/bash +# SPDX-License-Identifier: GPL-2.0 +# Copyright (c) 2022 Meta, Inc. All Rights Reserved. +# +# FS QA Test 692 +# +# fs-verity requires the filesystem to decide how it stores the Merkle tree, +# which can be quite large. +# It is convenient to treat the Merkle tree as past EOF, and ext4, f2fs, and +# btrfs do so in at least some fashion. This leads to an edge case where a +# large file can be under the file system file size limit, but trigger EFBIG +# on enabling fs-verity. Test enabling verity on some large files to exercise +# EFBIG logic for filesystems with fs-verity specific limits. +# +. ./common/preamble +_begin_fstest auto quick verity + + +# Import common functions. +. ./common/filter +. ./common/verity + +# real QA test starts here +_supported_fs generic +_require_test +_require_math +_require_scratch_verity +_require_fsverity_max_file_size_limit + +_scratch_mkfs_verity &>> $seqres.full +_scratch_mount + +fsv_file=$SCRATCH_MNT/file.fsv + +max_sz=$(_get_max_file_size) +_fsv_scratch_begin_subtest "way too big: fail on first merkle block" +truncate -s $max_sz $fsv_file +_fsv_enable $fsv_file |& _filter_scratch + +# The goal of this second test is to make a big enough file that we trip the +# EFBIG codepath, but not so big that we hit it immediately when writing the +# first Merkle leaf. +# +# The Merkle tree is stored with the leaf node level (L0) last, but it is +# written first. To get an interesting overflow, we need the maximum file size +# (MAX) to be in the middle of L0 -- ideally near the beginning of L0 so that we +# don't have to write many blocks before getting an error. +# +# With SHA-256 and 4K blocks, there are 128 hashes per block. Thus, ignoring +# padding, L0 is 1/128 of the file size while the other levels in total are +# 1/128**2 + 1/128**3 + 1/128**4 + ... = 1/16256 of the file size. So still +# ignoring padding, for L0 start exactly at MAX, the file size must be s such +# that s + s/16256 = MAX, i.e. s = MAX * (16256/16257). Then to get a file size +# where MAX occurs *near* the start of L0 rather than *at* the start, we can +# just subtract an overestimate of the padding: 64K after the file contents, +# then 4K per level, where the consideration of 8 levels is sufficient. +sz=$(echo "scale=20; $max_sz * (16256/16257) - 65536 - 4096*8" | $BC -q | cut -d. -f1) +_fsv_scratch_begin_subtest "still too big: fail on first invalid merkle block" +truncate -s $sz $fsv_file +_fsv_enable $fsv_file |& _filter_scratch + +# success, all done +status=0 +exit diff --git a/tests/generic/692.out b/tests/generic/692.out new file mode 100644 index 00000000..05996713 --- /dev/null +++ b/tests/generic/692.out @@ -0,0 +1,7 @@ +QA output created by 692 + +# way too big: fail on first merkle block +ERROR: FS_IOC_ENABLE_VERITY failed on 'SCRATCH_MNT/file.fsv': File too large + +# still too big: fail on first invalid merkle block +ERROR: FS_IOC_ENABLE_VERITY failed on 'SCRATCH_MNT/file.fsv': File too large