Integrity checking fails with Atmel SHA hw accelerator enabled

Integrity checking fails with Atmel SHA hw accelerator enabled

[Mircea Gliga]

[-- Attachment #1: Type: text/plain, Size: 2762 bytes --]

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: 
https://gist.githubusercontent.com/gmircea/6e1cc029ef5ed7a16b0fedb8b9524f66/raw/eece8a8faadd2de9373e150ef1daf3cf25f4135c/.config

Using the 4.8.4 Kernel and Atmel SHA hw accelerator enabled, everything 
was ok.

So it looks like the new commits, from 4.8.4 to 4.14.14, on atmel-sha.c 
(or at least I assume that may be a possible source of the problem) 
changes the behavior and breaks our use case:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/drivers/crypto/atmel-sha.c?h=v4.8.4

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/drivers/crypto/atmel-sha.c?h=v4.14.14

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/
Smartcom initramfs init failed
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 ...

Any help is appreciated !

Thanks in advanced and have a nice day.

Mircea


[-- Attachment #2: Type: text/html, Size: 4294 bytes --]

Re: Integrity checking fails with Atmel SHA hw accelerator enabled

[Gigi W]

[-- Attachment #1.1: Type: text/plain, Size: 5421 bytes --]

Thanks again for feedback !
Yes, I can do some additional tests in order to isolate the problem.
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.

Best regards
Mircea


On Sat, Feb 24, 2018 at 10:59 AM, Gilad Ben-Yossef <gilad@benyossef.com>
wrote:

> Hi,
>
> I'm adding the linux crypto mailing list because it seems relevant.
>
>
> On Fri, Feb 23, 2018 at 2:25 PM, Gigi W <gigitekwork@gmail.com> wrote:
> > Thanks for the input!
> >
> > See below
> >
> >
> > On Fri, Feb 23, 2018 at 10:53 AM Gilad Ben-Yossef <gilad@benyossef.com>
> > wrote:
> >>
> >> On Fri, Feb 23, 2018 at 10:30 AM, Gigi W <gigitekwork@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.
> >
>
> 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
>

[-- Attachment #1.2: Type: text/html, Size: 7260 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Integrity checking fails with Atmel SHA hw accelerator enabled

[Gilad Ben-Yossef]

Hi,

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


On Fri, Feb 23, 2018 at 2:25 PM, Gigi W <gigitekwork@gmail.com> wrote:
> Thanks for the input!
>
> See below
>
>
> On Fri, Feb 23, 2018 at 10:53 AM Gilad Ben-Yossef <gilad@benyossef.com>
> wrote:
>>
>> On Fri, Feb 23, 2018 at 10:30 AM, Gigi W <gigitekwork@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.
>

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

Re: Integrity checking fails with Atmel SHA hw accelerator enabled

[Gigi W]

[-- Attachment #1.1: Type: text/plain, Size: 5165 bytes --]

Thanks for the input!

See below


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

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

[-- Attachment #1.2: Type: text/html, Size: 7588 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Integrity checking fails with Atmel SHA hw accelerator enabled

[Gilad Ben-Yossef]

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

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?


> 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
>
>
> --
> dm-devel mailing list
> dm-devel@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

Integrity checking fails with Atmel SHA hw accelerator enabled

[Gigi W]

[-- Attachment #1.1: Type: text/plain, Size: 3276 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 4983 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]