Re: Integrity checking fails with Atmel SHA hw accelerator enabled

Hi,

I'm adding the linux crypto mailing list because it seems relevant.


On Fri, Feb 23, 2018 at 2:25 PM, Gigi W [off-list ref] wrote:

Thanks for the input!

See below


On Fri, Feb 23, 2018 at 10:53 AM Gilad Ben-Yossef [off-list ref]
wrote:

quoted

On Fri, Feb 23, 2018 at 10:30 AM, Gigi W [off-list ref] wrote:

quoted

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.

quoted

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.

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


-- 
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