This workaround was added in https://boringssl-review.googlesource.com/21664,
but the correct <openssl/hmac.h> include was added to NGINX over 5 years ago
in https://hg.nginx.org/nginx/rev/8076ba459f05, so this is no longer needed.

Change-Id: I30571871b336e1f68d385202bcc8836a621e0204
Signed-off-by: Piotr Sikora <piotr@aviatrix.com>
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56085
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
(cherry picked from commit 05b360d797353dd19842aa5a38dbccbf1c867f21)

This adds function to allow for issuing and redeeming tokens derived
from a particular message rather than a completely random nonce.

Change-Id: Ia29ae06ca419405ffff79ab6defadbed4f184b29
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55565
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
(cherry picked from commit fa4555a8b665b222e5d73d4cda3d4bbfa8518457)

Change-Id: I9abfef8d3d4d3ce0dabe29a5dc391fd4e0200d7f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56030
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
(cherry picked from commit 49e07914b396fabd7f372d872de23e583eb82cdc)

In the X.509 policy rewrite, I'll be using sorted stacks to keep the
overall algorithm subquadratic. Fix up sk_FOO_is_sorted in these edge
cases so the asserts work more smoothly.

Change-Id: I369f53543f0c2219df6f62a81aead630a9dbcd8d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56031
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
(cherry picked from commit ff23b7cb2c5bec11044d92dca8fa7d3ca0ec5fbc)

Constructing extensions from a config file should not modify the config
file or input certificates, so everything here should be const.

While I'm here, fix various missing sk_FOO_push malloc failure checks.

Change-Id: Ic29b21248a9d9243050c771fd0ce1e1d77f7ce7f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56027
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
(cherry picked from commit 44b3a283174cbfdf3c67ecd9cb515a4a8e029b60)

We've removed them in other files.

Change-Id: I14ea99c85fd3a21094beeac88cb669e7aa9e2763
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56028
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
(cherry picked from commit 974083f2afe32b54645cecee013092f531836027)

These APIs should not be used, but far too many callers use them. In the
meantime, at least test this behavior (so it can be rewritten) and write
down why it should not be used.

In doing so, I noticed that we actually broke some cases in the
ASN1_generate_v3 logic. I think it broke in
https://boringssl-review.googlesource.com/c/boringssl/+/48825. But since
no one's noticed, I've just kept it broken.

Bug: 430
Change-Id: I80ab1985964fc506c8aead579c769f15291b1384
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56029
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
(cherry picked from commit 7c81c5faec7730fc232f278c1ac9977338cdecc0)

This aligns with upstream OpenSSL, so it's hopefully more compatible.
Code search says no one outside of the project uses this function, so
it's unlikely to break anyone.

Whether it makes things better is a bit of a wash: OBJ_dup and
OPENSSL_strdup loose a pointless wrapper. X509_NAME_dup gains one, but
hopefully that can be resolved once we solve the X509_NAME
const-correctness problem. CRYPTO_BUFFER_up_ref gains one... really
FOO_up_ref should have type const T * -> T *, but OpenSSL decided it
returns int, so we've got to cast.

Change-Id: Ifa6eaf26777ac7239db6021fc1eafcaed98e42c4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56032
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
(cherry picked from commit df8a55bf622a495b2dd07f8ecf697d5642ee6be2)

They don't work because ASN1_mbstring_ncopy doesn't recognize them.

Change-Id: Id036252f4c6790714a73c5d0666149e13050fd4a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56105
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
(cherry picked from commit 0d9208e8896a8989af859d490d54c3be3f5174ca)

Change-Id: I88354719ccefbe8750bf02e069afbe8ab68b48fb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56033
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
(cherry picked from commit 1f2529d99d2dd7d569352ff4ef9b3ae295a47b4e)

Cost: 6.3KiB, based on the size of the .o file. (The bssl tool size
doesn't really change, probably due to padding somewhere.)

This code originally came from ARM but David has merged the AES-128 and
AES-256 specific code into a function that works across AES sizes.

Speeds from an M1 Pro:

Did 16546000 AES-128-GCM (16 bytes) seal operations in 1000018us (16545702.2 ops/sec): 264.7 MB/s
Did 10450500 AES-128-GCM (256 bytes) seal operations in 1000011us (10450385.0 ops/sec): 2675.3 MB/s
Did 2822500 AES-128-GCM (1350 bytes) seal operations in 1000042us (2822381.5 ops/sec): 3810.2 MB/s
Did 547000 AES-128-GCM (8192 bytes) seal operations in 1000826us (546548.6 ops/sec): 4477.3 MB/s
Did 279000 AES-128-GCM (16384 bytes) seal operations in 1000411us (278885.4 ops/sec): 4569.3 MB/s
Did 16991250 AES-256-GCM (16 bytes) seal operations in 1000001us (16991233.0 ops/sec): 271.9 MB/s
Did 9257000 AES-256-GCM (256 bytes) seal operations in 1000072us (9256333.5 ops/sec): 2369.6 MB/s
Did 2398000 AES-256-GCM (1350 bytes) seal operations in 1000002us (2397995.2 ops/sec): 3237.3 MB/s
Did 465000 AES-256-GCM (8192 bytes) seal operations in 1001108us (464485.4 ops/sec): 3805.1 MB/s
Did 240000 AES-256-GCM (16384 bytes) seal operations in 1002704us (239352.8 ops/sec): 3921.6 MB/s

Did 16670000 AES-128-GCM (16 bytes) seal operations in 1000054us (16669099.9 ops/sec): 266.7 MB/s
Did 11450750 AES-128-GCM (256 bytes) seal operations in 1000014us (11450589.7 ops/sec): 2931.4 MB/s
Did 3830000 AES-128-GCM (1350 bytes) seal operations in 1000097us (3829628.5 ops/sec): 5170.0 MB/s
Did 790000 AES-128-GCM (8192 bytes) seal operations in 1000379us (789700.7 ops/sec): 6469.2 MB/s
Did 400000 AES-128-GCM (16384 bytes) seal operations in 1000980us (399608.4 ops/sec): 6547.2 MB/s
Did 16877000 AES-256-GCM (16 bytes) seal operations in 1000052us (16876122.4 ops/sec): 270.0 MB/s
Did 10438000 AES-256-GCM (256 bytes) seal operations in 1000067us (10437300.7 ops/sec): 2671.9 MB/s
Did 3419000 AES-256-GCM (1350 bytes) seal operations in 1000158us (3418459.9 ops/sec): 4614.9 MB/s
Did 698000 AES-256-GCM (8192 bytes) seal operations in 1000557us (697611.4 ops/sec): 5714.8 MB/s
Did 355000 AES-256-GCM (16384 bytes) seal operations in 1001900us (354326.8 ops/sec): 5805.3 MB/s

Change-Id: Id88f6e14482f09591fe95145bf4089de1ab68380
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55926
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
(cherry picked from commit c6e37807639a5ed33fc2bbd8695b104d915a589e)

Newer versions of clang figure out that copy_from_prebuf (used in builds
that aren't x86_64 with assembly optimizations) has a bunch of no-op
iterations and insert a branch. Add a value barrier to stop it. This was
caught by our valgrind-based constant-time validation.

As part of this, I noticed that OPENSSL_NO_ASM builds turn off value
barriers. This is because the value barriers use an empty inline asm
block. While this is technically correct, it's probably unnecessary.

The clang|gcc check means we know GCC-style inline assembly is
supported.  Disabling inline asm is used by sanitizers to shut off
unintrumentable code, but there's no uninstrumentable code in the empty
string. It's also used by consumers who haven't figured out how to
integrate an assembler into their build system, but that also doesn't
apply. So just remove the condition on the value barriers so
OPENSSL_NO_ASM also get mitigations.

Update-Note: It is possible the above is wrong and some OPENSSL_NO_ASM
relied on value barriers being disabled. If so, this will break that
build and we'll need to reconsider.

Change-Id: I6e3ea3ee705bef3afcf42d3532b17aaabbbcc60b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56827
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
(cherry picked from commit 53b876a4d15da0145495ec3a17521a2690fe5978)

bn/generic.c is used for functions like bn_add_words, when there is no
assembly implementation available. They're meant to be constant-time,
but are particularly dependent on the compiler in this. I ran our
valgrind-based tooling and found a couple issues in GCC:

First, the various mul_add and sqr_add macros end up branching in GCC.
Replacing the conditionals with expressions like c += (a < b) seems to
mitigate this.

Second, bn_sub_words produces branches in GCC. Replacing the expressions
with bit expressions involving the boolean comparisons seems to work for
now. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173 discusses
problems with GCC here, which seem to be as yet unresolved.

Clang already reliably avoided branches in all of these. (Though it
still spills the carry flag far more than would be ideal.)

I also checked in godbolt that the new versions didn't generate branches
in MSVC, but we don't have tooling to validate this as rigorously.

Change-Id: I739758a396fb5ee27fb88bee71bd13ae9cb92bd0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56967
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
(cherry picked from commit d4396e387c820198f509a6927facea84592cddd8)