Hi Ondrej,
> When I run 'rmmod vmx_crypto' before running the reproducer, I get
> only one (correct) checksum, so this is definitely a bug in the
> driver. Other ciphers (cbc(aes), xts(aes)) are not affected, even
> though the glue code is very similar. That leads me to believe the
> problem is somewhere in the assembly code.
It appears that under certain circumstances, aes_p8_ctr32_encrypt_blocks
changes walk.iv. If this is done when
while ((nbytes = walk.nbytes) >= AES_BLOCK_SIZE) {
is not in its final iteration, it will corrupt the future blocks.
I am not yet sure why this is. Clearly it's pretty late in the assembly
because it doesn't seem to affect the blocks being processed in that
call, only future calls.
Saving and restoring the IV makes the test case pass.
I'll have a look at the asm.
Regards,
Daniel
>
> [1] http://github.com/smuellerDD/libkcapi
>
> Cheers,
> Ondrej
