Hi,
On Wed, Nov 23, 2011 at 9:44 AM, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
> Kasatkin, Dmitry <dmitry.kasatkin@xxxxxxxxx> wrote:
>> Hi,
>>
>> I have noticed very odd behavior with hmac calculation on my dual
>> core, 4 HTs PC.
>> I am using async hash API to to calculate hmac over the page.
>> I am using "hmac(sha1)" and the same key to calculate different pages.
>>
>> I have a work queue, which calculates the hmac like...
>>
>> int()
>> {
>> tfm = crypto_alloc_ahash(...);
>> }
>>
>> work_task()
>> {
>> crypto_ahash_setkey(tfm, key, keylen);
>> crypto_ahash_digest(req);
>> }
>>
>> HMAC result "sometimes" is incorrect.
>
> Is your tfm shared by multiple instances of work_task? The key
> is a property of the tfm, so you cannot have multiple users of a
> tfm all changing keys at the same time.
Yes. I know that....
Work queue also uses WQ_NON_REENTRANT, so it should not be any races,
and it should be possible to call crypto_ahash_setkey() without any problems.
This problem happens on 64 bit kernel.
It does not happen on my QEMU 32 bit kernel,
I will do some more tests...
>
> The correct usage model allowing parallel use is to dedicate a
> tfm to each key.
>
Sure.
Thanks...
> Cheers,
> --
> Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
