Messages in this thread |  | | Subject | Re: [PATCH v5 05/11] crypto: qce: skcipher: Return error for zero length messages | From | Thara Gopinath <> | Date | Thu, 4 Feb 2021 19:09:53 -0500 |
| |
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
|  |