* Integrity checking fails with Atmel SHA hw accelerator enabled @ 2018-02-23 8:30 Gigi W 2018-02-23 8:53 ` Gilad Ben-Yossef 0 siblings, 1 reply; 6+ messages in thread From: Gigi W @ 2018-02-23 8:30 UTC (permalink / raw) To: dm-devel [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Integrity checking fails with Atmel SHA hw accelerator enabled 2018-02-23 8:30 Integrity checking fails with Atmel SHA hw accelerator enabled Gigi W @ 2018-02-23 8:53 ` Gilad Ben-Yossef 2018-02-23 12:25 ` Gigi W 0 siblings, 1 reply; 6+ messages in thread From: Gilad Ben-Yossef @ 2018-02-23 8:53 UTC (permalink / raw) To: Gigi W; +Cc: device-mapper development 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Integrity checking fails with Atmel SHA hw accelerator enabled 2018-02-23 8:53 ` Gilad Ben-Yossef @ 2018-02-23 12:25 ` Gigi W 2018-02-24 8:59 ` Gilad Ben-Yossef 0 siblings, 1 reply; 6+ messages in thread From: Gigi W @ 2018-02-23 12:25 UTC (permalink / raw) To: Gilad Ben-Yossef; +Cc: device-mapper development [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Integrity checking fails with Atmel SHA hw accelerator enabled 2018-02-23 12:25 ` Gigi W @ 2018-02-24 8:59 ` Gilad Ben-Yossef 2018-02-26 6:31 ` Gigi W 0 siblings, 1 reply; 6+ messages in thread From: Gilad Ben-Yossef @ 2018-02-24 8:59 UTC (permalink / raw) To: Gigi W; +Cc: device-mapper development, Linux Crypto Mailing List 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Integrity checking fails with Atmel SHA hw accelerator enabled 2018-02-24 8:59 ` Gilad Ben-Yossef @ 2018-02-26 6:31 ` Gigi W 0 siblings, 0 replies; 6+ messages in thread From: Gigi W @ 2018-02-26 6:31 UTC (permalink / raw) To: Gilad Ben-Yossef; +Cc: device-mapper development, Linux Crypto Mailing List [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <cd5aff60-6c1d-e695-2e59-d18ae2558e6c@vitheia.com>]
* Integrity checking fails with Atmel SHA hw accelerator enabled [not found] <cd5aff60-6c1d-e695-2e59-d18ae2558e6c@vitheia.com> @ 2018-02-21 8:25 ` Mircea Gliga 0 siblings, 0 replies; 6+ messages in thread From: Mircea Gliga @ 2018-02-21 8:25 UTC (permalink / raw) To: Yocto Project [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-02-26 6:31 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-02-23 8:30 Integrity checking fails with Atmel SHA hw accelerator enabled Gigi W 2018-02-23 8:53 ` Gilad Ben-Yossef 2018-02-23 12:25 ` Gigi W 2018-02-24 8:59 ` Gilad Ben-Yossef 2018-02-26 6:31 ` Gigi W [not found] <cd5aff60-6c1d-e695-2e59-d18ae2558e6c@vitheia.com> 2018-02-21 8:25 ` Mircea Gliga
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.