linux-kernel - Re: Backlog support for CAAM?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 25 Jul 2019 05:57:28 +0000
From:   Horia Geanta <horia.geanta@....com>
To:     Richard Weinberger <richard@....at>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
CC:     Aymen Sghaier <aymen.sghaier@....com>, david <david@...ma-star.at>,
        Baolin Wang <baolin.wang@...aro.org>
Subject: Re: Backlog support for CAAM?

On 7/25/2019 12:22 AM, Richard Weinberger wrote:
> Hi!
> 
> Recently I had the pleasure to debug a lockup on a imx6 based platform.
> It turned out that the lockup was caused by the CAAM driver because it
> just returns -EBUSY upon a full job ring.
> 
> Then I found commits:
> 0618764cb25f ("dm crypt: fix deadlock when async crypto algorithm returns -EBUSY")
> c0403ec0bb5a ("Revert "dm crypt: fix deadlock when async crypto algorithm returns -EBUSY"")
> 
Truly sorry for the inconvenience.
Indeed this is a caam driver issue, and not a dm-crypt one.

> Is there a reason why the driver has still no proper backlog support?
> 
We've been rejected a few times or the implementation had performance issues:
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

and we haven't been persistent enough.

> If it is just a matter of -ENOPATCH, I have some cycles left an can help.
> But before working on this topic I'd like to figure what the current state
> or plans are. :-)
> 
Right now we're evaluating two options:
-reworking v5 above
-using crypto engine (crypto/crypto_engine.c)

Ideally crypto engine should be the way to go.
However we need to make sure performance degradation is negligible,
which unfortunately is not case.

Currently it seems that crypto engine has an issue with sending
multiple crypto requests from (SW) engine queue -> (HW) caam queue.

More exactly, crypto_pump_requests() performs this check:
        /* Make sure we are not already running a request */
        if (engine->cur_req)
                goto out;

thus it's not possible to add more crypto requests to the caam queue
until HW finishes the work on the current crypto request and
calls crypto_finalize_request():
        if (finalize_cur_req) {
		[...]
                engine->cur_req = NULL;

Horia