Thanks for your answer.
That's also my understanding that it has something to do with the
kernel, the way it is configured.
I've put here the output of lsmod and /proc/crypto:
https://gist.githubusercontent.com/gmircea/55f5b031a366c5d35d81dca2563916eb/raw/b24d4431635991c85f20641b11662eb7b2021735/proc_crypto
There is also the atmel-sha256 driver, but with priority 100
sha256-generic has priority 0
I'll disable the atmel driver and have a go.
Meanwhile, I've also tested on an Archlinux box running the 4.14.14
kernel and there it works ...
Regards
Mircea
On 25/01/18 13:50, Milan Broz wrote:
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
