From e9f148c9356b18995298f37bafbf1836a3fce078 Mon Sep 17 00:00:00 2001 From: Daniel Axtens Date: Fri, 17 May 2019 10:59:40 +1000 Subject: [PATCH] ppc assembly pack: always increment CTR IV as quadword The kernel self-tests picked up an issue with CTR mode. The issue was detected with a test vector with an IV of FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD: after 3 increments it should wrap around to 0. 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. CLA: trivial Reviewed-by: Richard Levitte Reviewed-by: Paul Dale (Merged from https://github.com/openssl/openssl/pull/8942) --- crypto/aes/asm/aesp8-ppc.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crypto/aes/asm/aesp8-ppc.pl b/crypto/aes/asm/aesp8-ppc.pl index 44056e31aa..30ccecf7af 100755 --- a/crypto/aes/asm/aesp8-ppc.pl +++ b/crypto/aes/asm/aesp8-ppc.pl @@ -1331,7 +1331,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 -- 2.25.1