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
