Re: [dm-crypt] veritysetup forward error correction failure

[Milan Broz <gmazyland@gmail.com>]

On 18/07/2019 15:49, Tom Eccles wrote:
> On 18/07/2019 2:09 pm, Milan Broz wrote:
>> On 18/07/2019 13:41, Tom Eccles wrote:
>>> On 17/07/2019 8:49 pm, Milan Broz wrote:
>>>> 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.
>>>
>>> Attached is a bash script gen_image.sh which should reproduce the issue.
>>> find_and_corrupt.c should be in the working directory when gen_image.sh is
>>> run. find_and_corrupt.c corrupts the disk image by simply searching for a
>>> known string and introducing an error (see the diff outputted by gen_image.sh).
>>>
>>> See in particular the error and dmesg sample when reading the corrupted file
>>> (gen_image.sh:77) and the success when running veritysetup verify
>>> (gen_image.sh:86).
>>>
>>> I have created an issue at https://gitlab.com/cryptsetup/cryptsetup/issues/462
>>
>> Thanks.
>>
>> I think I see the problem, and it is actually not FEC related.
>>
>> Could you please try to manually allocate loop devices in RW mode (not read-only
>> as we have during automatic loop allocation if mapping image is in file)
>> over the provided images, and then use these loop device as arguments for
>> the veritysetup?
>>
>> Like
>>  # losetup /dev/loop0 data8M.img.corrupt 
>>  # losetup /dev/loop1 hash-img 
>>  # losetup /dev/loop2 fec-img 
>>
>> and
>>
>>  # veritysetup open --fec-roots 24 --fec-device /dev/loop2 /dev/loop0 test /dev/loop1 15546e6799bb13608c77fa9cb840682a2dec3cfdb948d942ff3487f537966c01 --debug
>>
>> Does it correct the data now? For me it prints
>>
>>   kernel: device-mapper: verity: sha256 using implementation "sha256-generic"
>>   kernel: fec_decode_bufs: 13 callbacks suppressed
>>   kernel: device-mapper: verity-fec: 7:0: FEC 0: corrected 153 errors
>>
>> Milan
>>
> 
> This is not working for me.

ok, I actually just tried dd the whole device, not through the mounted fs.
will try it later...

But anyway, it seems like a problem with some infrastructure inside dm/block layer
and not the FEC algorithm itself (errno -74 is EBADMSG, something that should not be here).

m.