linux-kernel - Re: [PATCH] crypto: engine - fix crypto

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] [day] [month] [year] [list]

Message-ID: <ZEuac5MjDVWidTBX@gondor.apana.org.au>
Date:   Fri, 28 Apr 2023 18:05:39 +0800
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     Olivier Bacon <olivierb89@...il.com>
Cc:     linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
        Olivier Bacon <obacon@...etec.com>,
        Sylvain Ouellet <souellet@...etec.com>
Subject: Re: [PATCH] crypto: engine - fix crypto_queue backlog handling

On Thu, Apr 20, 2023 at 11:00:35AM -0400, Olivier Bacon wrote:
> CRYPTO_TFM_REQ_MAY_BACKLOG tells the crypto driver that it should
> internally backlog requests until the crypto hw's queue becomes
> full. At that point, crypto_engine backlogs the request and returns
> -EBUSY. Calling driver such as dm-crypt then waits until the
> complete() function is called with a status of -EINPROGRESS before
> sending a new request.
> 
> The problem lies in the call to complete() with a value of -EINPROGRESS
> that is made when a backlog item is present on the queue. The call is
> done before the successful execution of the crypto request. In the case
> that do_one_request() returns < 0 and the retry support is available,
> the request is put back in the queue. This leads upper drivers to send
> a new request even if the queue is still full.
> 
> The problem can be reproduced by doing a large dd into a crypto
> dm-crypt device. This is pretty easy to see when using
> Freescale CAAM crypto driver and SWIOTLB dma. Since the actual amount
> of requests that can be hold in the queue is unlimited we get IOs error
> and dma allocation.
> 
> The fix is to call complete with a value of -EINPROGRESS only if
> the request is not enqueued back in crypto_queue. This is done
> by calling complete() later in the code. In order to delay the decision,
> crypto_queue is modified to correctly set the backlog pointer
> when a request is enqueued back.
> 
> Fixes: 6a89f492f8e5 ("crypto: engine - support for parallel requests based on retry mechanism")
> Co-developed-by: Sylvain Ouellet <souellet@...etec.com>
> Signed-off-by: Sylvain Ouellet <souellet@...etec.com>
> Signed-off-by: Olivier Bacon <obacon@...etec.com>
> ---
>  crypto/algapi.c        | 3 +++
>  crypto/crypto_engine.c | 6 +++---
>  2 files changed, 6 insertions(+), 3 deletions(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt