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

[Gigi W]

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.
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/eece8a8faadd2de9373e150ef1daf3cf25f4135c/.config
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20180223/ecd76778/attachment.htm>