linux-kernel - Re: [RFC PATCH] Crypto-engine support for parallel requests

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <VI1PR04MB444594375C6CAAEE125C65C48C0D0@VI1PR04MB4445.eurprd04.prod.outlook.com>
Date:   Tue, 21 Jan 2020 10:08:53 +0000
From:   Iuliana Prodan <iuliana.prodan@....com>
To:     Herbert Xu <herbert@...dor.apana.org.au>
CC:     Baolin Wang <baolin.wang@...aro.org>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Corentin Labbe <clabbe.montjoie@...il.com>,
        Horia Geanta <horia.geanta@....com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre Torgue <alexandre.torgue@...com>,
        Maxime Ripard <mripard@...nel.org>,
        Aymen Sghaier <aymen.sghaier@....com>,
        "David S. Miller" <davem@...emloft.net>,
        Silvano Di Ninno <silvano.dininno@....com>,
        Franck Lenormand <franck.lenormand@....com>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>
Subject: Re: [RFC PATCH] Crypto-engine support for parallel requests

On 1/21/2020 11:11 AM, Herbert Xu wrote:
> On Tue, Jan 21, 2020 at 01:32:29AM +0200, Iuliana Prodan wrote:
>>
>> +	if (engine->no_reqs < engine->max_no_reqs)
>> +		goto retry;
> 
> We should not hard-code this number into the engine.  Instead,
> we should just let the driver tell us when it is ready to accept
> more requests.
> 
This is not hardcoded in crypto-engine.
I've added the crypto_engine_alloc_init_and_set function to configure 
how crypto-engine works.
The max_no_req means how many request the driver can process in parallel.
If this doesn't apply on some drivers they can call 
crypto_engine_alloc_init, which has max_no_req = 1 - this is the current 
behavior. That is serialization of requests by crypto-engine which is a 
bottleneck.

> Perhaps we should add a new function for drivers that wish to
> support this that would accept a list of requests instead of
> a single one.  It would then process as many requests as it
> can from that list and only return either when the list is
> exhausted or when it can't process any more requests.
> 

Linking requests is something different that is not addressed by my 
proposal.
I want to remove this serialization, done by crypto-engine, of unrelated 
requests.