dm-integrity stalls with iMX6q CAAM

dm-integrity stalls with iMX6q CAAM

[Neil Armstrong]

Hi,

I recently configured dm-crypt + dm-integrity on an iMX6q platform with CAAM Hash functions enabled using the following command lines :

Linux 4.14.71

cryptsetup luksFormat /dev/mmcblk1p3 --cipher aes-xts-plain64 --type luks2 --integrity hmac-sha256 --sector-size 512 --use-urandom
cryptsetup open /dev/mmcblk1p3 root
mkfs.ext4 -v -F /dev/mapper/root

luksFormat and open finishes correctly, luksDump and status reports correct dm and luks properties.

but when trying to access the /dev/mapper/root (mkfs, sha256sum or whatever), it blocks without any warning or errors reported by the kernel.
I can see a few (~170) interrupts on the jr0 interrupt then nothing.

Is there a particular issue with hmac-sha256 with the linux CAAM driver ?

When disabling the CAAM hash functions or using another cipher & integrity pair, it works like a charm.

Thanks,
Neil

-- 
Neil Armstrong
Embedded Linux Software Engineer
BayLibre - At the Heart of Embedded Linux
www.baylibre.com

Re: dm-integrity stalls with iMX6q CAAM

[Horia Geanta]

On 9/21/2018 3:06 PM, Neil Armstrong wrote:
> Hi,
> 
> I recently configured dm-crypt + dm-integrity on an iMX6q platform with CAAM Hash functions enabled using the following command lines :
> 
> Linux 4.14.71
> 
> cryptsetup luksFormat /dev/mmcblk1p3 --cipher aes-xts-plain64 --type luks2 --integrity hmac-sha256 --sector-size 512 --use-urandom
> cryptsetup open /dev/mmcblk1p3 root
> mkfs.ext4 -v -F /dev/mapper/root
> 
> luksFormat and open finishes correctly, luksDump and status reports correct dm and luks properties.
> 
> but when trying to access the /dev/mapper/root (mkfs, sha256sum or whatever), it blocks without any warning or errors reported by the kernel.
> I can see a few (~170) interrupts on the jr0 interrupt then nothing.
> 
> Is there a particular issue with hmac-sha256 with the linux CAAM driver ?
> 
> When disabling the CAAM hash functions or using another cipher & integrity pair, it works like a charm.
> 
The issue you are seeing is most probably related to CAAM driver not
implementing correctly the crypto requests "backlogging".
See commit c0403ec0bb5a ("Revert "dm crypt: fix deadlock when async crypto
algorithm returns -EBUSY"") for a detailed description.

Historically, there have been several CAAM backlogging implementations proposed
- but all were rejected:
v1: https://patchwork.kernel.org/patch/7144701
v2: https://patchwork.kernel.org/patch/7199241
v3: https://patchwork.kernel.org/patch/7221941
v4: https://patchwork.kernel.org/patch/7230241
v5: https://patchwork.kernel.org/patch/9033121

Discussion here: https://community.nxp.com/message/1020096
mentions v2 as solving the issue.
You could try it while we find a solution that would be accepted upstream.

Hope this helps,
Horia

Re: dm-integrity stalls with iMX6q CAAM

[Gilad Ben-Yossef]

On Wed, Oct 17, 2018 at 4:35 PM Horia Geanta <horia.geanta@nxp.com> wrote:
>
> On 9/21/2018 3:06 PM, Neil Armstrong wrote:
> > Hi,
> >
> > I recently configured dm-crypt + dm-integrity on an iMX6q platform with CAAM Hash functions enabled using the following command lines :
> >
> > Linux 4.14.71
> >
> > cryptsetup luksFormat /dev/mmcblk1p3 --cipher aes-xts-plain64 --type luks2 --integrity hmac-sha256 --sector-size 512 --use-urandom
> > cryptsetup open /dev/mmcblk1p3 root
> > mkfs.ext4 -v -F /dev/mapper/root
> >
> > luksFormat and open finishes correctly, luksDump and status reports correct dm and luks properties.
> >
> > but when trying to access the /dev/mapper/root (mkfs, sha256sum or whatever), it blocks without any warning or errors reported by the kernel.
> > I can see a few (~170) interrupts on the jr0 interrupt then nothing.
> >
> > Is there a particular issue with hmac-sha256 with the linux CAAM driver ?
> >
> > When disabling the CAAM hash functions or using another cipher & integrity pair, it works like a charm.
> >
> The issue you are seeing is most probably related to CAAM driver not
> implementing correctly the crypto requests "backlogging".
> See commit c0403ec0bb5a ("Revert "dm crypt: fix deadlock when async crypto
> algorithm returns -EBUSY"") for a detailed description.
>
> Historically, there have been several CAAM backlogging implementations proposed
> - but all were rejected:

hmmm... obviously the right solution is to implement backlogging but
you might want to consider changing the driver to
return -ENOSPC or -ENOSYS instead in the meantime. It should cause
dm-crypt to fail rather than hang... which is not necessarily better,
but at least more obvious by the user what is going on?

Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

values of β will give rise to dom!

Re: dm-integrity stalls with iMX6q CAAM

[Gilad Ben-Yossef]

On Wed, Oct 17, 2018 at 4:35 PM Horia Geanta <horia.geanta@nxp.com> wrote:
>
> On 9/21/2018 3:06 PM, Neil Armstrong wrote:
> > Hi,
> >
> > I recently configured dm-crypt + dm-integrity on an iMX6q platform with CAAM Hash functions enabled using the following command lines :
> >
> > Linux 4.14.71
> >
> > cryptsetup luksFormat /dev/mmcblk1p3 --cipher aes-xts-plain64 --type luks2 --integrity hmac-sha256 --sector-size 512 --use-urandom
> > cryptsetup open /dev/mmcblk1p3 root
> > mkfs.ext4 -v -F /dev/mapper/root
> >
> > luksFormat and open finishes correctly, luksDump and status reports correct dm and luks properties.
> >
> > but when trying to access the /dev/mapper/root (mkfs, sha256sum or whatever), it blocks without any warning or errors reported by the kernel.
> > I can see a few (~170) interrupts on the jr0 interrupt then nothing.
> >
> > Is there a particular issue with hmac-sha256 with the linux CAAM driver ?
> >
> > When disabling the CAAM hash functions or using another cipher & integrity pair, it works like a charm.
> >
> The issue you are seeing is most probably related to CAAM driver not
> implementing correctly the crypto requests "backlogging".
> See commit c0403ec0bb5a ("Revert "dm crypt: fix deadlock when async crypto
> algorithm returns -EBUSY"") for a detailed description.
>
> Historically, there have been several CAAM backlogging implementations proposed
> - but all were rejected:

hmmm... obviously the right solution is to implement backlogging but
you might want to consider changing the driver to
return -ENOSPC or -ENOSYS instead in the meantime. It should cause
dm-crypt to fail rather than hang... which is not necessarily better,
but at least more obvious by the user what is going on?

Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

values of β will give rise to dom!

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Re: dm-integrity stalls with iMX6q CAAM

[Neil Armstrong]

On 17/10/2018 15:35, Horia Geanta wrote:
> On 9/21/2018 3:06 PM, Neil Armstrong wrote:
>> Hi,
>>
>> I recently configured dm-crypt + dm-integrity on an iMX6q platform with CAAM Hash functions enabled using the following command lines :
>>
>> Linux 4.14.71
>>
>> cryptsetup luksFormat /dev/mmcblk1p3 --cipher aes-xts-plain64 --type luks2 --integrity hmac-sha256 --sector-size 512 --use-urandom
>> cryptsetup open /dev/mmcblk1p3 root
>> mkfs.ext4 -v -F /dev/mapper/root
>>
>> luksFormat and open finishes correctly, luksDump and status reports correct dm and luks properties.
>>
>> but when trying to access the /dev/mapper/root (mkfs, sha256sum or whatever), it blocks without any warning or errors reported by the kernel.
>> I can see a few (~170) interrupts on the jr0 interrupt then nothing.
>>
>> Is there a particular issue with hmac-sha256 with the linux CAAM driver ?
>>
>> When disabling the CAAM hash functions or using another cipher & integrity pair, it works like a charm.
>>
> The issue you are seeing is most probably related to CAAM driver not
> implementing correctly the crypto requests "backlogging".
> See commit c0403ec0bb5a ("Revert "dm crypt: fix deadlock when async crypto
> algorithm returns -EBUSY"") for a detailed description.
> 
> Historically, there have been several CAAM backlogging implementations proposed
> - but all were rejected:
> v1: https://patchwork.kernel.org/patch/7144701
> v2: https://patchwork.kernel.org/patch/7199241
> v3: https://patchwork.kernel.org/patch/7221941
> v4: https://patchwork.kernel.org/patch/7230241
> v5: https://patchwork.kernel.org/patch/9033121
> 
> Discussion here: https://community.nxp.com/message/1020096
> mentions v2 as solving the issue.
> You could try it while we find a solution that would be accepted upstream.
> 
> Hope this helps,
> Horia
> 

Hi Horia,

Thanks for the pointers ! Hopefully you will find a solution soon.

Neil