Re: veritysetup forward error correction failure

Milan Broz <[email protected]>
Newsgroups gmane.linux.kernel.device-mapper.dm-crypt
Message-ID <[email protected]>
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
_______________________________________________
dm-crypt mailing list
[email protected]
https://www.saout.de/mailman/listinfo/dm-crypt
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.