From: Thara Gopinath <thara.gopinath@linaro.org>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: herbert@gondor.apana.org.au, davem@davemloft.net,
ebiggers@google.com, ardb@kernel.org, sivaprak@codeaurora.org,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/7] crypto: qce: common: Add support for AEAD algorithms
Date: Sat, 17 Apr 2021 09:31:00 -0400 [thread overview]
Message-ID: <beab39e4-560b-b897-fa0e-c95a5f04a018@linaro.org> (raw)
In-Reply-To: <20210413230930.GU1538589@yoga>
On 4/13/21 7:09 PM, Bjorn Andersson wrote:
> On Tue 13 Apr 17:44 CDT 2021, Thara Gopinath wrote:
[..]
>
> Yes, given that you just typecast things as you do it should just work
> to move the typecast to the qce_cpu_to_be32p_array().
>
> But as I said, this would indicate that what is cpu_to_be32() should
> have been be32_to_cpu() (both performs the same swap, it's just a matter
> of what type goes in and what type goes out).
>
> Looking at the other uses of qce_cpu_to_be32p_array() I suspect that
> it's the same situation there, so perhaps introduce a new function
> qce_be32_to_cpu() in this patchset (that returns number of words
> converted) and then look into the existing users after that?
Hi!
I have sent out the v2 with the new function. To me, it does look
cleaner. So thanks!
>
> [..]
>>>>>> + if (IS_SHA_HMAC(rctx->flags)) {
>>>>>> + /* Write default authentication iv */
>>>>>> + if (IS_SHA1_HMAC(rctx->flags)) {
>>>>>> + auth_ivsize = SHA1_DIGEST_SIZE;
>>>>>> + memcpy(authiv, std_iv_sha1, auth_ivsize);
>>>>>> + } else if (IS_SHA256_HMAC(rctx->flags)) {
>>>>>> + auth_ivsize = SHA256_DIGEST_SIZE;
>>>>>> + memcpy(authiv, std_iv_sha256, auth_ivsize);
>>>>>> + }
>>>>>> + authiv_words = auth_ivsize / sizeof(u32);
>>>>>> + qce_write_array(qce, REG_AUTH_IV0, (u32 *)authiv, authiv_words);
>>>>>
>>>>> AUTH_IV0 is affected by the little endian configuration, does this imply
>>>>> that IS_SHA_HMAC() and IS_CCM() are exclusive bits of rctx->flags? If so
>>>>> I think it would be nice if you grouped the conditionals in a way that
>>>>> made that obvious when reading the function.
>>>>
>>>> So yes IS_SHA_HMAC() and IS_CCM() are exclusive bits of rctx->flags.
>>>> AUTH_IVn is 0 for ccm and has initial value for HMAC algorithms. I don't
>>>> understand the confusion here.
>>>>
>>>
>>> I'm just saying that writing is as below would have made it obvious to
>>> me that IS_SHA_HMAC() and IS_CCM() are exclusive:
>>
>> So regardless of the mode, it is a good idea to clear the IV registers
>> which happens above in
>>
>> qce_clear_array(qce, REG_AUTH_IV0, 16);
>>
>>
>> This is important becasue the size of IV varies between HMAC(SHA1) and
>> HMAC(SHA256) and we don't want any previous bits sticking around.
>> For CCM after the above step we don't do anything with AUTH_IV where as for
>> SHA_HMAC we have to go and program the registers. I can split it into
>> if (IS_SHA_HMAC(flags)) {
>> ...
>> } else {
>> ...
>> }
>>
>> but both snippets will have the above line code clearing the IV register and
>> the if part will have more stuff actually programming these registers.. Is
>> that what you are looking for ?
>
> I didn't find an answer quickly to the question if the two where
> mutually exclusive and couldn't determine from the code flow either. But
> my comment seems to stem from my misunderstanding that the little endian
> bit was dependent on IS_CCM().
>
> That said, if the logic really is "do this for IS_SHA_HMAC(), otherwise
> do that", then if else makes sense.
So, the logic is really. do "clearing of IV" in all cases. Do setting of
initial IV only for HMAC. I tried the if..else like you said. It did not
look correct to duplicate the code clearing the IV. So I have added
comments around this section hopefully making it clearer. Do take a look
and let me know. I can rework it further if you think so.
>
> Regards,
> Bjorn
>
--
Warm Regards
Thara
next prev parent reply other threads:[~2021-04-17 13:31 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-25 18:27 [PATCH 0/7] Add support for AEAD algorithms in Qualcomm Crypto Engine driver Thara Gopinath
2021-02-25 18:27 ` [PATCH 1/7] crypto: qce: common: Add MAC failed error checking Thara Gopinath
2021-04-05 17:36 ` Bjorn Andersson
2021-04-13 19:28 ` Thara Gopinath
2021-02-25 18:27 ` [PATCH 2/7] crypto: qce: common: Make result dump optional Thara Gopinath
2021-04-05 22:23 ` Bjorn Andersson
2021-02-25 18:27 ` [PATCH 3/7] crypto: qce: Add mode for rfc4309 Thara Gopinath
2021-04-05 22:32 ` Bjorn Andersson
2021-04-13 19:30 ` Thara Gopinath
2021-04-13 20:38 ` Bjorn Andersson
2021-02-25 18:27 ` [PATCH 4/7] crypto: qce: Add support for AEAD algorithms Thara Gopinath
2021-03-12 13:01 ` Herbert Xu
2021-03-17 2:09 ` Thara Gopinath
2021-02-25 18:27 ` [PATCH 5/7] crypto: qce: common: Clean up qce_auth_cfg Thara Gopinath
2021-02-25 18:27 ` [PATCH 6/7] crypto: qce: common: Add support for AEAD algorithms Thara Gopinath
2021-04-05 22:18 ` Bjorn Andersson
2021-04-13 21:31 ` Thara Gopinath
2021-04-13 22:20 ` Bjorn Andersson
2021-04-13 22:44 ` Thara Gopinath
2021-04-13 23:09 ` Bjorn Andersson
2021-04-17 13:31 ` Thara Gopinath [this message]
2021-04-13 22:27 ` Thara Gopinath
2021-04-13 22:33 ` Bjorn Andersson
2021-04-13 22:46 ` Thara Gopinath
2021-02-25 18:27 ` [PATCH 7/7] crypto: qce: aead: Schedule fallback algorithm Thara Gopinath
2021-03-04 5:30 ` [PATCH 0/7] Add support for AEAD algorithms in Qualcomm Crypto Engine driver Herbert Xu
2021-03-04 18:41 ` Thara Gopinath
2021-03-12 13:02 ` Herbert Xu
2021-03-17 2:08 ` 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=beab39e4-560b-b897-fa0e-c95a5f04a018@linaro.org \
--to=thara.gopinath@linaro.org \
--cc=ardb@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=davem@davemloft.net \
--cc=ebiggers@google.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).