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>
 <00d759f3-8ea3-1f85-b623-225c372c0a04@linaro.org>
 <YByQpRG0SC0k0gYC@gmail.com>
From:   Thara Gopinath <thara.gopinath@linaro.org>
Message-ID: <ed714cc0-c3ca-88ca-f57f-e2a5ccf7ef16@linaro.org>
Date:   Fri, 5 Feb 2021 09:08:18 -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: <YByQpRG0SC0k0gYC@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 2/4/21 7:26 PM, Eric Biggers wrote:
> On Thu, Feb 04, 2021 at 07:09:53PM -0500, Thara Gopinath wrote:
>>>> @@ -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 ?

Ok. I will re-spin the series once more with this change..

> 
> Yes, there is nothing to do for empty inputs, so just return 0 (success).
> 
>>> 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 ?
> 
> Omitting support for certain inputs isn't allowed.  Anyone in the kernel who
> wants to use a particular algorithm could get this driver for it, and if they
> happen to use inputs which the driver decided not to support, things will break.

Ya sounds reasonable.

> 
> The way that drivers handle this is to use a fallback cipher for inputs they
> don't support.

Ok. So I will add this to my todo and make sure to have fallback ciphers 
for all the non-supported inputs. I will send this as a separate series 
and not this one.

In this case, though not supporting 0 length messages for encryption is 
valid. I don't think I have to have a fallback for this. I could have 
sworn that the test framework throws up an error for this. But I have 
been testing a lot and may be I am just confused. I will double check this.


> 
> - Eric
> 

-- 
Warm Regards
Thara