Re: veritysetup forward error correction failure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

Should write access be required to the device be required? The kernel
doesn't allow writable verity devices:

drivers/md/dm-verity-target.c:954:

	if ((dm_table_get_mode(ti->table) & ~FMODE_READ)) {
		ti->error = "Device must be readonly";
		r = -EINVAL;
		goto bad;
	}

Thanks,
Tom
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
https://www.saout.de/mailman/listinfo/dm-crypt



[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux