Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH 2/2] crypto: s5p - use correct block size of 1 for
 ctr(aes)
To:     Krzysztof Kozlowski <krzk@kernel.org>
Cc:     Ard Biesheuvel <ard.biesheuvel@linaro.org>,
        linux-crypto@vger.kernel.org, herbert@gondor.apana.org.au,
        Vladimir Zapolskiy <vz@mleia.com>,
        "linux-samsung-soc@vger.kernel.org" 
        <linux-samsung-soc@vger.kernel.org>
From:   Kamil Konieczny <k.konieczny@partner.samsung.com>
Message-ID: <f7f1babd-5c74-5561-4771-49809398da5f@partner.samsung.com>
Date:   Tue, 20 Aug 2019 14:28:03 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
        Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CAJKOXPfR_L4z=sE8ETUB3_6sVV=ab=vntqh-_KvNmsKacEa4qQ@mail.gmail.com>
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 201P
References: <20190819142226.1703-1-ard.biesheuvel@linaro.org>
        <20190819142226.1703-3-ard.biesheuvel@linaro.org>
        <CGME20190820102425epcas2p219b7cac45290fbc87bb62bf446fec345@epcas2p2.samsung.com>
        <CAJKOXPevJjBuRJjUX=6BfuMZSLUyqP3fpi7_eWDF170RfPvL+g@mail.gmail.com>
        <1f932022-0335-1d00-b651-83c82d77fa7a@partner.samsung.com>
        <CAJKOXPfR_L4z=sE8ETUB3_6sVV=ab=vntqh-_KvNmsKacEa4qQ@mail.gmail.com>
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On 20.08.2019 13:48, Krzysztof Kozlowski wrote:
> On Tue, 20 Aug 2019 at 13:39, Kamil Konieczny
> <k.konieczny@partner.samsung.com> wrote:
>>
>>
>>
>> On 20.08.2019 12:24, Krzysztof Kozlowski wrote:
>>> On Mon, 19 Aug 2019 at 16:24, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>>>
>>>> Align the s5p ctr(aes) implementation with other implementations
>>>> of the same mode, by setting the block size to 1.
>>>>
>>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>>> ---
>>>>  drivers/crypto/s5p-sss.c | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
>>>> index ef90c58edb1f..010f1bb20dad 100644
>>>> --- a/drivers/crypto/s5p-sss.c
>>>> +++ b/drivers/crypto/s5p-sss.c
>>>> @@ -2173,7 +2173,7 @@ static struct crypto_alg algs[] = {
>>>>                 .cra_flags              = CRYPTO_ALG_TYPE_ABLKCIPHER |
>>>>                                           CRYPTO_ALG_ASYNC |
>>>>                                           CRYPTO_ALG_KERN_DRIVER_ONLY,
>>>> -               .cra_blocksize          = AES_BLOCK_SIZE,
>>>> +               .cra_blocksize          = 1,
>>>
>>> This makes sense but I wonder how does it work later with
>>> s5p_aes_crypt() and its check for request length alignment
>>> (AES_BLOCK_SIZE). With block size of 1 byte, I understand that
>>> req->nbytes can be for example 4 bytes which is not AES block
>>> aligned... If my reasoning is correct, then the CTR mode in s5p-sss is
>>> not fully working.
>>
>> As I remember this case there are allocated buffers with len aligned up
>> AES_BLOCK_SIZE, source data copy to one buf, hw encrypts full block,
>> then nbytes are copy back.

to be precise, hw encrypts align_up(req->nbytes, AES_BLOCK_SIZE)

> Buffer alignment is different thing and it is defined in cra_alignmask.
> I am talking about req->nbytes which should be aligned according to
> s5p_aes_crypt(). But if blocksize is 1 byte, then what possible values
> for req->nbytes?

For AES-CTR, there are blocks of size multiply of AES_BLOCK_SIZE, with last
one which can be of any size

so for req->nbytes valid values are n*AES_BLOCK_SIZE + 0...AES_BLOCK_SIZE-1

-- 
Best regards,
Kamil Konieczny
Samsung R&D Institute Poland