From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Thu, 18 Jul 2019 15:59:27 +0200 (CEST) Received: by mail-wm1-x341.google.com with SMTP id s15so4451696wmj.3 for ; Thu, 18 Jul 2019 06:59:27 -0700 (PDT) References: <40fa6a57-ac08-1f50-dbce-cadefcbf1ff4@codethink.co.uk> <0ce29b38-3f32-d2bc-651e-071075941d43@gmail.com> <3671b534-ce49-ee1e-77a9-0ce7f5618992@gmail.com> <5764b0c8-c83f-ee10-c068-bf7a231858ec@codethink.co.uk> From: Milan Broz Message-ID: Date: Thu, 18 Jul 2019 15:59:18 +0200 MIME-Version: 1.0 In-Reply-To: <5764b0c8-c83f-ee10-c068-bf7a231858ec@codethink.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] veritysetup forward error correction failure List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Tom Eccles , Milan Broz , dm-crypt@saout.de Cc: richardmaw@codethink.co.uk 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.