Received-SPF: pass (google.com: domain of linux-crypto+bounces-2690-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Fri, 15 Mar 2024 13:55:29 -0400
From: Ralph Siemsen <ralph.siemsen@linaro.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: [PATCH] crypto: af_alg - Disallow multiple in-flight AIO requests
Message-ID: <20240315175529.GA268782@maple.netwinder.org>
References: <ZWWkDZRR33ypncn7@gondor.apana.org.au>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <ZWWkDZRR33ypncn7@gondor.apana.org.au>

Hi Herbert,

I have found a regression in userspace behaviour after this patch was 
merged into the 4.19.y kernel. The fix seems to involve backporting a 
few more changes. Could you review details below and confirm if this is 
the right approach?

On Tue, Nov 28, 2023 at 04:25:49PM +0800, Herbert Xu wrote:
>Having multiple in-flight AIO requests results in unpredictable
>output because they all share the same IV.  Fix this by only allowing
>one request at a time.
>
>Fixes: 83094e5e9e49 ("crypto: af_alg - add async support to algif_aead")
>Fixes: a596999b7ddf ("crypto: algif - change algif_skcipher to be asynchronous")
>Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>---
> crypto/af_alg.c         | 14 +++++++++++++-
> include/crypto/if_alg.h |  3 +++
> 2 files changed, 16 insertions(+), 1 deletion(-)

This change got backported on the 4.19 kernel in January:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.19.y&id=19af0310c8767c993f2a5d5261e4df3f9f465ce1

Since then, I am seeing a regression in a simple openssl encoding test:

openssl enc -k mysecret -aes-256-cbc -in plain.txt -out cipher.txt -engine afalg

It fails intermittently with the message "error writing to file", but 
this error is a bit misleading, the actual problem is that the kernel 
returns -16 (EBUSY) on the encoding operation.

This happens only in 4.19, and not under 5.10. The patch seems correct, 
however it seems we are missing a couple of other patches on 4.19:

f3c802a1f3001 crypto: algif_aead - Only wake up when ctx->more is zero
21dfbcd1f5cbf crypto: algif_aead - fix uninitialized ctx->init

I was able to cherry-pick those into 4.19.y, with just a minor conflict 
in one case. With those applied, the openssl command no longer fails.

I suspect similar changes would be needed also in 5.4 kernel, however I 
neither checked that, nor have I run any tests on that version.

Regards,
-Ralph