| Message ID | 4429f6365c3250efe9bf7bc0a1a22e642b149f61.1617908086.git.boris@bur.io (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | tests for btrfs fsverity | expand |
On Thu, Apr 08, 2021 at 11:57:50AM -0700, Boris Burkov wrote: > generic/574 has tests for corrupting the merkle tree data stored by the > filesystem. Since btrfs uses a different scheme 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. > > Note that there is a bit of a kludge here: since btrfs_corrupt_block > doesn't handle streaming corruption bytes from stdin (I could change > that, but it feels like overkill for this purpose), I just read the > first corruption byte and duplicate it for the desired length. That is > how the test is using the interface in practice, anyway. > > This relies on the following kernel patch for btrfs verity support: > <btrfs-verity-patch> > And the following btrfs-progs patch for btrfs_corrupt_block support: > <btrfs-corrupt-block-patch> > > Signed-off-by: Boris Burkov <boris@bur.io> > --- > common/verity | 15 +++++++++++++-- > 1 file changed, 13 insertions(+), 2 deletions(-) > > diff --git a/common/verity b/common/verity > index d2c1ea24..fdd05783 100644 > --- a/common/verity > +++ b/common/verity > @@ -3,8 +3,7 @@ > # > # Functions for setting up and testing fs-verity > > -_require_scratch_verity() > -{ > +_require_scratch_verity() { No need to change this. > _require_scratch > _require_command "$FSVERITY_PROG" fsverity > > @@ -315,6 +314,18 @@ _fsv_scratch_corrupt_merkle_tree() > (( offset += ($(_get_filesize $file) + 65535) & ~65535 )) > _fsv_scratch_corrupt_bytes $file $offset > ;; > + btrfs) > + ino=$(ls -i $file | awk '{print $1}') stat -c %i $1 And declare local variables with local. > + sync Why a system wide sync is needed here? > + cat > $tmp.bytes I think this cat would just hang there. > + sz=$(_get_filesize $tmp.bytes) > + read -n 1 byte < $tmp.bytes > + ascii=$(printf "%d" "'$byte'") > + _scratch_unmount > + $BTRFS_CORRUPT_BLOCK_PROG -r 5 -I $ino,37,0 -v $ascii -o $offset -b $sz $SCRATCH_DEV It'd be better to explain this command in comments. > + sync Again, is this sync really needed? Thanks, Eryu > + _scratch_mount > + ;; > *) > _fail "_fsv_scratch_corrupt_merkle_tree() unimplemented on $FSTYP" > ;; > -- > 2.30.2
diff --git a/common/verity b/common/verity index d2c1ea24..fdd05783 100644 --- a/common/verity +++ b/common/verity @@ -3,8 +3,7 @@ # # Functions for setting up and testing fs-verity -_require_scratch_verity() -{ +_require_scratch_verity() { _require_scratch _require_command "$FSVERITY_PROG" fsverity @@ -315,6 +314,18 @@ _fsv_scratch_corrupt_merkle_tree() (( offset += ($(_get_filesize $file) + 65535) & ~65535 )) _fsv_scratch_corrupt_bytes $file $offset ;; + btrfs) + ino=$(ls -i $file | awk '{print $1}') + sync + cat > $tmp.bytes + sz=$(_get_filesize $tmp.bytes) + read -n 1 byte < $tmp.bytes + ascii=$(printf "%d" "'$byte'") + _scratch_unmount + $BTRFS_CORRUPT_BLOCK_PROG -r 5 -I $ino,37,0 -v $ascii -o $offset -b $sz $SCRATCH_DEV + sync + _scratch_mount + ;; *) _fail "_fsv_scratch_corrupt_merkle_tree() unimplemented on $FSTYP" ;;
generic/574 has tests for corrupting the merkle tree data stored by the filesystem. Since btrfs uses a different scheme 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. Note that there is a bit of a kludge here: since btrfs_corrupt_block doesn't handle streaming corruption bytes from stdin (I could change that, but it feels like overkill for this purpose), I just read the first corruption byte and duplicate it for the desired length. That is how the test is using the interface in practice, anyway. This relies on the following kernel patch for btrfs verity support: <btrfs-verity-patch> And the following btrfs-progs patch for btrfs_corrupt_block support: <btrfs-corrupt-block-patch> Signed-off-by: Boris Burkov <boris@bur.io> --- common/verity | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)