Re: veritysetup forward error correction failure

Thanks all

On 17/07/2019 8:49 pm, Milan Broz wrote:
> Well, the FEC code in userspace and kernel differs, it is quite possible
> that there could be some misconfiguration or a bug.
> 
> Please be sure you are testing access to the image and not
> some cached data in meory - better flush all caches between runs with the command
> "echo 3 > /proc/sys/vm/drop_caches".

This made no difference. I have also tried rebooting.

> If you can still reproduce it, please send version of the utility and
> kernel (and --debug output as suggested in another mail) and if you have some
> data/hash/fec images that can be used to reproduce it, let me know where I can find it.

I am running Debian Buster (stable). I recompiled the kernel to add support
for FEC devices, and building dm-verity and virtioblk support into the
kernel image (not modules). Versions are:

tomeccles@debian-kernel-builder:~$ uname -a
Linux debian-kernel-builder 4.19.37-verity #6 SMP Wed Jul 17 11:47:38 BST
2019 x86_64 GNU/Linux
tomeccles@debian-kernel-builder:~$ /usr/sbin/veritysetup --version
veritysetup 2.1.0

I can also reproduce the issue using veritysetup 2.2.0-rc1.

Running veritysetup verify with --verbose and --debug:

tomeccles@debian-kernel-builder:~$ sudo veritysetup --verbose --debug
--fec-device /dev/vdc --fec-roots 24 verify /dev/vdb1 /dev/vdd
04c260f3595e80104ad5e389df12f12b17a70c6b5284841c7260f859767948bd
# cryptsetup 2.1.0 processing "veritysetup --verbose --debug --fec-device
/dev/vdc --fec-roots 24 verify /dev/vdb1 /dev/vdd
04c260f3595e80104ad5e389df12f12b17a70c6b5284841c7260f859767948bd"
# Running command verify.
# Allocating context for crypt device /dev/vdd.
# Trying to open and read device /dev/vdd with direct-io.
# Initialising device-mapper backend library.
# Setting ciphertext data device to /dev/vdb1.
# Trying to open and read device /dev/vdb1 with direct-io.
# Trying to load VERITY crypt type from device /dev/vdd.
# Crypto backend (OpenSSL 1.1.1c  28 May 2019) initialized in cryptsetup
library version 2.1.0.
# Detected kernel Linux 4.19.37-verity x86_64.
# Reading VERITY header of size 512 on device /dev/vdd, offset 0.
# Trying to open and read device /dev/vdc with direct-io.
# Checking volume  by volume key.
# Trying to activate VERITY device [none] using hash sha256.
# Verification of data in userspace required.
# Hash verification sha256, data device /dev/vdb1, data blocks 1310208,
hash_device /dev/vdd, offset 1.
# Using 3 hash levels.
# Data device size required: 5366611968 bytes.
# Hash device size required: 42262528 bytes.
Verification failed at position 1119891456.
Verification of data area failed.
# Verification failed, trying to repair with FEC device.
Found 1 repairable errors with FEC device.
# Releasing crypt device /dev/vdd context.
# Releasing device-mapper backend.
Command successful.

I will try to reproduce the issue with smaller images and provide these later.

Also, I tried adding some prints to veritysetup and the kernel, and on the
face of it, the reed-solomon state (struct rs in veritysetup) seems the
same. I have checked:
- mm = 8
- nn = 255
- nroots = 24
- fcr = 0
- prim = 1
- iprim = 1
The kernel does not have an equivalent of the pad field.

Thanks,
Tom
_______________________________________________
dm-crypt mailing list
[email protected]
https://www.saout.de/mailman/listinfo/dm-crypt