On 12/7/2018 1:32 PM, Sascha Hauer wrote:
The crypto API wants the updated IV in req->info after decryption. The updated IV used to be copied correctly to req->info after running the decryption job. Since 115957bb3e59 this is done before running the job so instead of the updated IV only the unmodified input IV is given back to the crypto API.
Saving IV before running the decryption was done to address in-place cbc decryption - when the last block is overwritten with plaintext before having the chance to copy it.
Current IV update scheme is ok for cbc (IV <- last ciphertext block), however for ctr the counter should be saved instead; this has to be addressed, but IMHO is not the root cause for gcm failure.
This was observed running the gcm(aes) selftest which internally uses ctr(aes) implemented by the CAAM engine.
I don't see how this patch solves the gcm case you are mentioning, i.e. gcm_base(ctr-aes-caam,ghash-generic). The IV, updated by ctr(aes) CAAM implementation, doesn't seem to be used afterwards - in ghash from gcm SW implementation (crypto/gcm.c).
Considering lack of HW coherency on i.MX, I would rather check whether cacheline sharing is the culprit - see previous discussion: https://patchwork.kernel.org/patch/9801965/
Thanks, Horia