Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v5 05/11] crypto: qce: skcipher: Return error for zero
 length messages
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
References: <20210204214359.1993065-1-thara.gopinath@linaro.org>
 <20210204214359.1993065-6-thara.gopinath@linaro.org>
 <YBx5yWhKtT2EC2Ce@gmail.com>
From:   Thara Gopinath <thara.gopinath@linaro.org>
Message-ID: <00d759f3-8ea3-1f85-b623-225c372c0a04@linaro.org>
Date:   Thu, 4 Feb 2021 19:09:53 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <YBx5yWhKtT2EC2Ce@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

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