On 6/18/2015 9:17 AM, Herbert Xu wrote:
>>> +static void init_gcm_job(struct aead_request *req,
>>> + struct aead_edesc *edesc,
>>> + bool all_contig, bool encrypt)
>>> +{
>>> + struct crypto_aead *aead = crypto_aead_reqtfm(req);
>>> + struct caam_ctx *ctx = crypto_aead_ctx(aead);
>>> + unsigned int ivsize = crypto_aead_ivsize(aead);
>>> + u32 *desc = edesc->hw_desc;
>>> + bool generic_gcm = (ivsize == 12);
>>> + unsigned int last;
>>> +
>>> + init_aead_job(req, edesc, all_contig, encrypt);
>>> +
>>> + /* BUG This should not be specific to generic GCM. */
>>
>> AFAICT, for non-generic GCM uses (RFC4106, RFC4543), cryptlen and/or
>> assoclen are always > 0. That's why the descriptors do not address these
>> cases.
>
> Of course. But with the algif_aead interface you need to at least
> ensure that you don't crash or do something silly should the user
> give you such an input. So my question is what happens when it is
> zero? Does the hardware simply emit an error and recover, or does it
> hang/lock up/do something worse?
To make sure, I've tried this case on HW (with modified tcrypt tests):
caam_jr ffe301000.jr: 4000101c: DECO: desc idx 16: DECO Watchdog timer
timeout error
alg: aead: encryption failed on test 1 for rfc4106-gcm-aes-caam:
ret=-1073745948
caam_jr ffe301000.jr: 4000111c: DECO: desc idx 17: DECO Watchdog timer
timeout error
alg: aead: encryption failed on test 1 for rfc4543-gcm-aes-caam:
ret=-1073746204
The errors are reported by HW and handled by the driver.
> BTW does this actually work on your hardware now?
tcrypt tests pass.
I'll run more tests (IPsec) on my side and report back if I encounter
any issue.
Thanks,
Horia
--
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
