On 01/25/2018 11:51 AM, Mircea Gliga wrote: > We are using dm-verity for a squashfs root file system. > Using kernel 4.8.4 everything was ok, after upgrading to kernel 4.14.14 > mount fails, even though the `veritysetup verify` command validates the > image. The verify command uses userspace crypto lib (OpenSSL here) to validate image, while after activation it is the kernel that validates hashes. So here it seems like some corruption in that kernel, not a veritysetup problem. Sot would be better to discuss this on dm-devel list, where are kernel people. But just one guess: what crypto moddule provides sha256 here? (Paste somewhere contents of lsmod and /proc/crypto) If it is some platform-accelerated module, I would suggest to disable it and try with generic sha256 module. Milan > > > # veritysetup verify /dev/mmcblk0p5 /dev/mmcblk0p6 --hash-offset 4096 > d35f95a4 > b47c92332fbcf5aced9c4ed58eb2d5115bad4aa52bd9d64cc0ee676b --debug > # cryptsetup 1.7.4 processing "veritysetup verify /dev/mmcblk0p5 > /dev/mmcblk0p6 --hash-offset 4096 > d35f95a4b47c92332fbcf5aced9c4ed58eb2d5115bad4aa52bd9d64cc0ee676b --debug" > # Running command verify. > # Allocating crypt device /dev/mmcblk0p6 context. > # Trying to open and read device /dev/mmcblk0p6 with direct-io. > # Initialising device-mapper backend library. > # Trying to load VERITY crypt type from device /dev/mmcblk0p6. > # Crypto backend (OpenSSL 1.0.2m 2 Nov 2017) initialized in cryptsetup > library version 1.7.4. > # Detected kernel Linux 4.14.14-yocto-standard armv7l. > # Reading VERITY header of size 512 on device /dev/mmcblk0p6, offset 4096. > # Setting ciphertext data device to /dev/mmcblk0p5. > # Trying to open and read device /dev/mmcblk0p5 with direct-io. > # Activating volume [none] by volume key. > # Trying to activate VERITY device [none] using hash sha256. > # Verification of data in userspace required. > # Hash verification sha256, data device /dev/mmcblk0p5, data blocks > 10462, hash_device /dev/mmcblk0p6, offset 2. > # Using 2 hash levels. > # Data device size required: 42852352 bytes. > # Hash device size required: 348160 bytes. > # Verification of data area succeeded. > # Verification of root hash succeeded. > # Releasing crypt device /dev/mmcblk0p6 context. > # Releasing device-mapper backend. > Command successful. > > > # veritysetup create vroot /dev/mmcblk0p5 /dev/mmcblk0p6 --hash-offset > 4096 d3 > 5f95a4b47c92332fbcf5aced9c4ed58eb2d5115bad4aa52bd9d64cc0ee676b --debug > > # mount -o ro /dev/mapper/vroot /mnt/ > device-mapper: verity: 179:5: metadata block 2 is corrupted > EXT4-fs (dm-0): unable to read superblock > device-mapper: verity: 179:5: metadata block 2 is corrupted > EXT4-fs (dm-0): unable to read superblock > device-mapper: verity: 179:5: metadata block 2 is corrupted > EXT4-fs (dm-0): unable to read superblock > device-mapper: verity: 179:5: metadata block 2 is corrupted > SQUASHFS error: squashfs_read_data failed to read block 0x0 > squashfs: SQUASHFS error: unable to read squashfs_super_block > device-mapper: verity: 179:5: metadata block 2 is corrupted > FAT-fs (dm-0): unable to read boot sector > mount: mounting /dev/mapper/vroot on /mnt/ failed: Input/output error > > Same error message appears in dmesg. > The above commands were run on the target device. > > On my *host* machine, Debian 8 (kernel 3.16.0-5), using the files which > eventually ended up in /dev/mmcblk0p5 and /dev/mmcblk0p6, > I was able to set up everything working: > > # veritysetup create vroot rootfs-image.squashfs rootfs-image.hashtbl > --hash-offset 4096 > d35f95a4b47c92332fbcf5aced9c4ed58eb2d5115bad4aa52bd9d64cc0ee676b > # mount /dev/mapper/vroot /tmp/mnt > > Any help is appreciated. > > Thanks and regards > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
