<div dir="ltr"><div><div><div><div>Thanks again for feedback ! </div>Yes, I can do some additional tests in order to isolate the problem. </div>I'm not that familiar with the code responsible for this so I'll ask for your help with a patch. It will be quicker that way. </div>Best regards </div>Mircea </div><div class="gmail_extra"> <div class="gmail_quote">On Sat, Feb 24, 2018 at 10:59 AM, Gilad Ben-Yossef <<a href="mailto:gilad@benyossef.com" target="_blank">gilad@benyossef.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, I'm adding the linux crypto mailing list because it seems relevant. <div><div class="h5"> On Fri, Feb 23, 2018 at 2:25 PM, Gigi W <<a href="mailto:gigitekwork@gmail.com">gigitekwork@gmail.com</a>> wrote: > Thanks for the input! > > See below > > > On Fri, Feb 23, 2018 at 10:53 AM Gilad Ben-Yossef <<a href="mailto:gilad@benyossef.com">gilad@benyossef.com</a>> > wrote: >> >> On Fri, Feb 23, 2018 at 10:30 AM, Gigi W <<a href="mailto:gigitekwork@gmail.com">gigitekwork@gmail.com</a>> wrote: >> > Hi >> > >> > I'm having some trouble using dm-verity for a squashfs root file system >> > that >> > seems to be related to the >> > Atmel SHA hw accelerator in the kernel, CONFIG_CRYPTO_DEV_ATMEL_SHA >> > >> > Some info about my setup: >> > * I'm using a board with a SAMA5D4 CPU. >> > * I'm using Yocto rocko for building an image for that device. >> > >> > The idea is that Using the 4.14.14 Kernel, Integrity checking using >> > Kernel >> > crypto fails with Atmel SHA hw accelerator enabled in kernel. >> > By disabling it, `CONFIG_CRYPTO_DEV_ATMEL_SHA=n`, and using the software >> > sha256 algo, integrity checking works as expected. >> > This is my kernel config [3] >> > >> > Using the 4.8.4 Kernel and Atmel SHA hw accelerator enabled, everything >> > was >> > ok. >> > >> > This is what triggers the error during verified boot: >> > >> > status=`veritysetup create vroot $root_dev $verity_dev --hash-offset >> > $hashoffset $root_hash` >> > >> > mount /dev/mapper/vroot /mnt/ >> > mount_ok=`cat /proc/mounts | grep mnt` >> > if [ -z "$mount_ok" ] ; then >> > echo "Failed to mount $root_dev on mnt/" >> > else >> > echo "Switch rootfs" >> > exec switch_root -c /dev/console /mnt /sbin/init >> > fi >> > >> > The mount operation fails: >> > >> > device-mapper: verity: 179:4: metadata block 2 is corrupted >> > EXT4-fs (dm-0): unable to read superblock >> > device-mapper: verity: 179:4: metadata block 2 is corrupted >> > EXT4-fs (dm-0): unable to read superblock >> > device-mapper: verity: 179:4: metadata block 2 is corrupted >> > EXT4-fs (dm-0): unable to read superblock >> > device-mapper: verity: 179:4: 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:4: 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 >> > Failed to mount /dev/mmcblk0p4 on mnt/ >> > reboot: Restarting system >> > Reboot failed -- System halted >> > >> > Using veritysetup to verify the integrity against the hashes is >> > successful, >> > as it's not using the kernel for that ... >> > >> > >> > So it looks like it something changed from 4.8.4 to 4.14.14. >> >> If I am not mistaken the Atmel SHA hw accelerator is an async (read: >> off CPU) crypto accelerator. >> Up until 4.12 (I think...) DM-Verity did not use async crypto >> accelerators (even if present and have high >> priority). I've changed this is commit d1ac3ff008fb ("dm verity: >> switch to using asynchronous hash crypto API"). > > > This would explain some things, like the same speeds while reading from a > verity device, having the CONFIG_CRYPTO_DEV_ATMEL_SHA enabled and then > disabled, on the 4.8.4 kernel -> it was always using the sync API. > >> >> >> Is it possible that whatever issue you are seeing has always been >> there and when DM-Verity started using >> async. accelerators it was only exposed? > > > It looks like it. > > From my understandings + tests described above, Atmel SHA hw accelerator > works correctly - output hashes are ok, dm-verity with other async crypto > accelerators is working ok, > but dm-verity + Atmel SHA hw accelerator don't play nice together. > > I couldn't find anyone else complaining about this. > </div></div>I agree that that the possibility that there is something wrong in the Atmel SHA accelerator is one possible direction. The other one is that there is something wrong in DM-Verity that only manifests under certain conditions when working with async crypto HW providers. I don't think it is the case, because I tested DM-Verity after my changes with the CryptoCell async HW provider and did not get any other bug reports, but I'd like to be sure. Can you do a little experiment? add debug printk to show the data being hashed, the hash produced by atmel and the expected pre-calculated hash. If the theory that there is something wrong with atmel accelerator, we can calculate the hash on the data with other means (software) and should get a different hash. If you are having trouble adding the printk's in the right place let me know and I'll create a patch for you to test. Cheers, Gilad <div class="HOEnZb"><div class="h5"> -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru </div></div></blockquote></div> </div>