diff options
| author | Daniel Axtens <dja@axtens.net> | 2019-05-17 10:59:40 +1000 |
|---|---|---|
| committer | Daniel Axtens <dja@axtens.net> | 2019-05-17 11:05:16 +1000 |
| commit | e9f148c9356b18995298f37bafbf1836a3fce078 (patch) | |
| tree | 3788ad01f80db23729d6ba0a8915b6be02e9df38 /crypto/aes | |
| parent | 3e4e43e609d6e9c36e5e526246d31802102cad4a (diff) | |
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 <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8942)
Diffstat (limited to 'crypto/aes')
| -rwxr-xr-x | crypto/aes/asm/aesp8-ppc.pl | 2 |
1 files changed, 1 insertions, 1 deletions
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 |