crypto: vmx - CTR: always increment IV as quadword
authorDaniel Axtens <dja@axtens.net>
Wed, 15 May 2019 10:24:50 +0000 (20:24 +1000)
committerHerbert Xu <herbert@gondor.apana.org.au>
Fri, 17 May 2019 05:36:54 +0000 (13:36 +0800)
The kernel self-tests picked up an issue with CTR mode:
alg: skcipher: p8_aes_ctr encryption test failed (wrong result) on test vector 3, cfg="uneven misaligned splits, may sleep"

Test vector 3 has an IV of FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD, so
after 3 increments it should wrap around to 0.

In the aesp8-ppc code from OpenSSL, there are two paths that
increment IVs: the bulk (8 at a time) path, and the individual
path which is used when there are fewer than 8 AES blocks to
process.

In the bulk path, the IV is incremented with vadduqm: "Vector
Add Unsigned Quadword Modulo", which does 128-bit addition.

In the individual path, however, the IV is incremented with
vadduwm: "Vector Add Unsigned Word Modulo", which instead
does 4 32-bit additions. Thus the IV would instead become
FFFFFFFFFFFFFFFFFFFFFFFF00000000, throwing off the result.

Use vadduqm.

This was probably a typo originally, what with q and w being
adjacent. It is a pretty narrow edge case: I am really
impressed by the quality of the kernel self-tests!

Fixes: 5c380d623ed3 ("crypto: vmx - Add support for VMS instructions by ASM")
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Axtens <dja@axtens.net>
Acked-by: Nayna Jain <nayna@linux.ibm.com>
Tested-by: Nayna Jain <nayna@linux.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
drivers/crypto/vmx/aesp8-ppc.pl

index de78282b8f4473d6884d66240c1fc31284599803..9c6b5c1d6a1a61c0408a55822a816516057a486f 100644 (file)
@@ -1357,7 +1357,7 @@ Loop_ctr32_enc:
        addi            $idx,$idx,16
        bdnz            Loop_ctr32_enc
 
-       vadduwm         $ivec,$ivec,$one
+       vadduqm         $ivec,$ivec,$one
         vmr            $dat,$inptail
         lvx            $inptail,0,$inp
         addi           $inp,$inp,16