[dm-devel] Integrity checking fails with Atmel SHA hw accelerator enabled

Fri Feb 23 12:25:09 UTC 2018

Thanks for the input!

See below

On Fri, Feb 23, 2018 at 10:53 AM Gilad Ben-Yossef <gilad at benyossef.com>
wrote:

> On Fri, Feb 23, 2018 at 10:30 AM, Gigi W <gigitekwork at gmail.com> 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.

Best regards.

>
> > Using the 4.14.14 kernel, I removed the patches that were applied on the
> > atmel-sha.c file in the kernel, one by one, until I got the version from
> the
> > 4.8.4
> > Basically I reverted the changes from
> > here:https://git.kernel.org/pub/scm/linux/kernel/git/
> stable/linux-stable.git/log/drivers/crypto/atmel-sha.c?h=v4.14.14
> > until I got this:
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/
> linux-stable.git/log/drivers/crypto/atmel-sha.c?h=v4.8.4
> >
> > It still didn't work. I assumed something there broke the hashing, not
> the
> > case. It was still not working with all those commits reverted.
> >
> > Furthermore, using the Cryptodev-linux module [1], and the sample [2],
> > adapted to use sha256, I tested the output hashes, with
> > CONFIG_CRYPTO_DEV_ATMEL_SHA enabled and then disabled.
> >
> > I got the same results in both cases, hardware and software algorithm.
> So it
> > doesn't look like the SHA hw accelerator is broken.
> >
> >
> > Any help is appreciated !
> >
> > Thanks in advanced and have a nice day.
> >
> >
> > [1] http://cryptodev-linux.org/documentation.html
> > [2] https://github.com/nmav/cryptodev-linux/blob/master/examples/sha.c
> > [3]
> > https://gist.githubusercontent.com/gmircea/
> 6e1cc029ef5ed7a16b0fedb8b9524f66/raw/eece8a8faadd2de9373e150ef1daf3
> cf25f4135c/.config
> >
> >
> > --
> > dm-devel mailing list
> > dm-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/dm-devel
>
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20180223/841cbcfe/attachment.htm>