| commit | d84cb4d163d0df7ff6b703fbd180b14137c2f8f4 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Mon May 20 15:11:12 2019 -0400 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Mon May 20 19:36:11 2019 +0000 |
| tree | a59238c0f693077f53d3b6fe1048c3edabaa642a | |
| parent | e0c533aa237047bf419c776adc549d8863238981 [diff] |
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>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
There are other files in this directory which might be helpful: