tree a59238c0f693077f53d3b6fe1048c3edabaa642a
parent e0c533aa237047bf419c776adc549d8863238981
author David Benjamin <davidben@google.com> 1558379472 -0400
committer CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> 1558380971 +0000

Sync aesp8-ppc.pl with upstream.

This pulls in the following commits from upstream:
5dcfd6c50a216f81bf43e1f21bc5f3fc517ba47a,
41013cd63c068e2f271fabc92702ee67d800f0cb,
83cf7abf8e9abbd4d0b68c63dc1cb43374aafe63, and
13f6857db107b1b6f68daa7fc4a6dd1293428bb1. Of these, the first fixes a bug:

commit 5dcfd6c50a216f81bf43e1f21bc5f3fc517ba47a
Author: Daniel Axtens <dja@axtens.net>
Date:   Mon Mar 18 10:22:44 2019 +1100

    PPC assembly pack: fix copy-paste error in CTR mode

    There are two copy-paste errors in handling CTR mode. When dealing
    with a 2 or 3 block tail, the code branches to the CBC decryption exit
    path, rather than to the CTR exit path.

    This can lead to data corruption: in the Linux kernel we have a copy
    of this file, and the bug leads to corruption of the IV, which leads
    to data corruption when we call the encryption function again later to
    encrypt subsequent blocks.

    Originally reported to the Linux kernel by Ondrej Mosnáček <omosnacek@gmail.com>

This bug does not appear to have practical impact the way the function is used
in BoringSSL/OpenSSL. Unlike the CBC functions, the CTR32 functions do not
update the IV, which is the only difference between their epilogs. However, all
the callers either use a temporary buffer for the IV or clobber the counter
portion of the IV with an updated value anyway. (Confirmed that
CipherTest.TestVectors hits this case with AES-GCM and that the clobbered IV
matches in all but the counter portion.)

Change-Id: I25b781152c578155e0bcb0ee1c6d967e9e8cea88
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36104
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>