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 dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
