From: Thara Gopinath <thara.gopinath@linaro.org>
To: Eric Biggers <ebiggers@kernel.org>
Cc: herbert@gondor.apana.org.au, davem@davemloft.net,
bjorn.andersson@linaro.org, ardb@kernel.org,
sivaprak@codeaurora.org, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 05/11] crypto: qce: skcipher: Return error for zero length messages
Date: Thu, 4 Feb 2021 19:09:53 -0500 [thread overview]
Message-ID: <00d759f3-8ea3-1f85-b623-225c372c0a04@linaro.org> (raw)
In-Reply-To: <YBx5yWhKtT2EC2Ce@gmail.com>
Hi Eric,
On 2/4/21 5:48 PM, Eric Biggers wrote:
> On Thu, Feb 04, 2021 at 04:43:53PM -0500, Thara Gopinath wrote:
>> Crypto engine BAM dma does not support 0 length data. Return unsupported
>> if zero length messages are passed for transformation.
>>
>> Signed-off-by: Thara Gopinath <thara.gopinath@linaro.org>
>> ---
>> drivers/crypto/qce/skcipher.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/crypto/qce/skcipher.c b/drivers/crypto/qce/skcipher.c
>> index de1f37ed4ee6..331b3c3a5b59 100644
>> --- a/drivers/crypto/qce/skcipher.c
>> +++ b/drivers/crypto/qce/skcipher.c
>> @@ -8,6 +8,7 @@
>> #include <linux/interrupt.h>
>> #include <linux/moduleparam.h>
>> #include <linux/types.h>
>> +#include <linux/errno.h>
>> #include <crypto/aes.h>
>> #include <crypto/internal/des.h>
>> #include <crypto/internal/skcipher.h>
>> @@ -260,6 +261,10 @@ static int qce_skcipher_crypt(struct skcipher_request *req, int encrypt)
>> rctx->flags |= encrypt ? QCE_ENCRYPT : QCE_DECRYPT;
>> keylen = IS_XTS(rctx->flags) ? ctx->enc_keylen >> 1 : ctx->enc_keylen;
>>
>> + /* CE does not handle 0 length messages */
>> + if (!req->cryptlen)
>> + return -EOPNOTSUPP;
>> +
>
> For the algorithms in question, the correct behavior is to return 0.
What do you mean? The driver should return a 0 ?
>
> Aren't the tests catching that difference?
I was anyways planning on sending an email to the list with these
queries. But since you asked, these are my observations with fuzz
testing which I have been doing quite a bit now (I am also working on
adding a few qualcomm AEAD algorithms support in mainline).
- if the generic algorithm supports 0 length messages and the
transformation I am testing does not, the test framework throws an error
and stops.
- key support mismatch between the generic algorithm vs my algorithm
/engine also does the same thing.For eg, Qualcomm CE engine does not
support any three keys being same for triple des algorithms. Where as a
two key 3des is a valid scenario for generic algorithm(k1=k3). Another
example is hardware engine not supporting AES192.
How are these scenarios usually handled ? Why not allow the test
framework to proceed with the testing if the algorithm does not support
a particular scenario ?
>
> - Eric
>
--
Warm Regards
Thara
next prev parent reply other threads:[~2021-02-05 0:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-04 21:43 [PATCH v5 00/11] Regression fixes/clean ups in the Qualcomm crypto engine driver Thara Gopinath
2021-02-04 21:43 ` [PATCH v5 01/11] crypto: qce: sha: Restore/save ahash state with custom struct in export/import Thara Gopinath
2021-02-04 21:43 ` [PATCH v5 02/11] crypto: qce: sha: Hold back a block of data to be transferred as part of final Thara Gopinath
2021-02-04 21:43 ` [PATCH v5 03/11] crypto: qce: skcipher: Return unsupported if key1 and key 2 are same for AES XTS algorithm Thara Gopinath
2021-02-04 21:43 ` [PATCH v5 04/11] crypto: qce: skcipher: Return unsupported if any three keys are same for DES3 algorithms Thara Gopinath
2021-02-04 21:43 ` [PATCH v5 05/11] crypto: qce: skcipher: Return error for zero length messages Thara Gopinath
2021-02-04 22:48 ` Eric Biggers
2021-02-05 0:09 ` Thara Gopinath [this message]
2021-02-05 0:26 ` Eric Biggers
2021-02-05 14:08 ` Thara Gopinath
2021-02-04 21:43 ` [PATCH v5 06/11] crypto: qce: skcipher: Return error for non-blocksize data(ECB/CBC algorithms) Thara Gopinath
2021-02-04 22:50 ` Eric Biggers
2021-02-05 0:24 ` Thara Gopinath
2021-02-04 21:43 ` [PATCH v5 07/11] crypto: qce: skcipher: Set ivsize to 0 for ecb(aes) Thara Gopinath
2021-02-04 21:43 ` [PATCH v5 08/11] crypto: qce: skcipher: Improve the conditions for requesting AES fallback cipher Thara Gopinath
2021-02-04 21:43 ` [PATCH v5 09/11] crypto: qce: common: Set data unit size to message length for AES XTS transformation Thara Gopinath
2021-02-04 21:43 ` [PATCH v5 10/11] crypto: qce: Remover src_tbl from qce_cipher_reqctx Thara Gopinath
2021-02-04 21:43 ` [PATCH v5 11/11] crypto: qce: Remove totallen and offset in qce_start Thara Gopinath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=00d759f3-8ea3-1f85-b623-225c372c0a04@linaro.org \
--to=thara.gopinath@linaro.org \
--cc=ardb@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=davem@davemloft.net \
--cc=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sivaprak@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.