BUG: p8_aes_ctr randomly returns wrong results

Hi,

FYI, the p8_aes_ctr crypto driver (drivers/crypto/vmx/aes_ctr.c) seems
to be seriously broken. When I do repeated encryption using libkcapi
multiple times in a row, I sometimes get a wrong result. This happens
more often with long messages (e.g. at 16 KiB it already happens very
frequently).

To reproduce:
1. Install or locally build libkcapi [1] (you will need the kcapi-enc
binary in PATH) on a ppc64le system.
2. Run the following in bash:
for i in {1..100}; do head -c $((16*1024)) /dev/zero | kcapi-enc -e -c
'ctr(aes)' -p test -s test --pbkdfiter 1 2>/dev/null | sha256sum; done
| sort -u

Expected result:
All invocations produce output with identical checksum.

Actual result:
Multiple different checksums are produced.

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.

[1] http://github.com/smuellerDD/libkcapi

Cheers,
Ondrej

st 13. 3. 2019 o 13:37 Ondrej Mosnáček [off-list ref] napísal(a):

Hi,

FYI, the p8_aes_ctr crypto driver (drivers/crypto/vmx/aes_ctr.c) seems
to be seriously broken. When I do repeated encryption using libkcapi
multiple times in a row, I sometimes get a wrong result. This happens
more often with long messages (e.g. at 16 KiB it already happens very
frequently).

To reproduce:
1. Install or locally build libkcapi [1] (you will need the kcapi-enc
binary in PATH) on a ppc64le system.
2. Run the following in bash:
for i in {1..100}; do head -c $((16*1024)) /dev/zero | kcapi-enc -e -c
'ctr(aes)' -p test -s test --pbkdfiter 1 2>/dev/null | sha256sum; done
| sort -u

Expected result:
All invocations produce output with identical checksum.

Actual result:
Multiple different checksums are produced.

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.

[1] http://github.com/smuellerDD/libkcapi

Cheers,
Ondrej

(Ah, forgot to compare email addresses with MAINTAINERS... let me try these)

Hi Ondrej,

I can confirm this on a ppc64le VM, at least as far back as 4.18, and am
investigating. Thanks for the reproducer.

Regards,
Daniel

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