Upcoming NIST rule changes are expected to effectively require us to
pass in larger entropy inputs to the DRBG, which requires us to use the
"derivation function" option from 800-90A.
This change implements the derivation function and splits the entropy
and nonce arguments out, as needed for this style of DRBG.
Since we have external users of the existing CTR-DRBG mode, that is
still supported, but all internal uses will now use a derivation
function.
Change-Id: I8079e9f4c6238e91c68fef1e40189211f4142555
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/79768
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Historically, sha.h included both SHA-1 and SHA-2 functions. But SHA-1
functions mostly shouldn't be used now, and it's useful to be able to
audit at the level of header names in some contexts.
Therefore move SHA-2 things into a new sha2.h. In order not to break
everything, sha.h now includes sha2.h so no changes are needed in
existing callers.
Change-Id: I68d5e991f58a1c74ca377ba017caaff356acc870
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/80327
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Instead of having a pair of bespoke build definitions use the standard
FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION toggle. We actually originated
the idea of a fuzzing-specific build toggle, and then libFuzzer
standardized a toggle when we talked to them about what we were doing.
The problem is our fuzzer mode toggle substantially changed the TLS
stack behavior, such that downstream code would likely go haywire. So we
couldn't easily fold into the standard one, and all of BoringSSL's
downstream fuzzer builds were messy.
Instead, make a few changes:
1. Switch BORINGSSL_UNSAFE_DETERMINISTIC_MODE to
FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION. That flag is not expected
to cause downstream issues as it just makes the PRNG deterministic.
2. Replace BORINGSSL_UNSAFE_FUZZER_MODE with a runtime toggle that is
only available when building with
FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION.
3. Instead of the no_fuzzer_mode fuzzers being special corpora for the
client and server fuzzers, they're now just separate fuzzerrs and
follow the usual naming conventions between fuzzers and their
corpora.
Update-Note: Downstream fuzzer builds can now be simplified. If the
fuzzing infrastructure already builds with
FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION, the separate boringssl_fuzz
(or whatever) target can be removed.
Bug: 42290128
Change-Id: Ia1e479777f366908951e15067c96c9767c229f0a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/77749
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
When we have both crypto/foo/internal.h and
crypto/fipsmodule/foo/internal.h, it's important that we put FIPSMODULE
into the header guard.
At that point, we probably should just put CRYPTO in there too, and
indeed we have been putting it in a few places. Go ahead and rewrite
them all with some clever shell scripting.
Change-Id: If61586f1d49ed477023530c36e9ed74373d4d1e6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/77727
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We use the standard Apache 2.0 file header, described in "APPENDIX: How
to apply the Apache License to your work."
This was primarily automated by running:
git ls-tree -r --name-only HEAD | xargs go run ./util/relicense.go
See go/boringssl-relicensing-triage for the results of triaging the
output of the tool.
As part of this, switch from taking fiat-crypto under MIT license to
Apache 2.0. (It is licensed under MIT OR Apache-2.0 OR BSD-1-Clause.)
The copyright_summary tool can also be used to confirm we didn't
accidentally drop any copyright lines:
# Run before the CL
git grep -l Copyright | xargs go run ./util/copyright_summary.go -out /tmp/old.json
# Run after the CL
git grep -l Copyright | xargs go run ./util/copyright_summary.go -compare /tmp/old.json
Bug: 364634028
Change-Id: I17c50e761e9d077a1f92e25969e50ed35e320c59
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75852
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Except for our public headers, our files no longer need to be consumed
by C. That means inline can just be inline, and with C++17,
OPENSSL_UNUSED can be [[maybe_unused]].
Bug: 42290600
Change-Id: Ibdb309bc413660e10d075fbb71d4d1dd87101c6d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74489
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The referenced bug notes some ODR warnings in an unspecified
configuration. (Which I can't get AppleClang or GCC 14 to reproduce, at
least.) This is likely due to us switching to C++. The ODR rules in C++
are a little different, but also perhaps the detection is only kicking
in for C++.
Either way, structs in .cc files are generally not intended to leave
that compilation unit. (Unless it's an opaque struct listed in base.h.)
There's no such thing as `static struct` so this change wraps many
structs in .cc files in `namespace {`. There are also lots of structs in
test file. Those are less concerning, but test files should mostly
entirely be in a namespace so this change does that where possible for
test files containing structs.
Bug: 384186552
Change-Id: I6ccf715fbcdc3ea6260b5d5d05f305182b1a9450
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74407
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
AES_KEY was separate from GCM128_KEY because crypto/modes was originally
written as if there were non-AES 128-bit block ciphers to worry about.
This has long since stopped being the case for BoringSSL. This avoids
some duplicate key setup logic in EVP_CIPHER and EVP_AEAD.
GCM128_KEY was embedded into GCM128_CONTEXT because OpenSSL assembly
once relied on the exact order of a bunch of the fields, some of which
we per-operation and some of which were per-key. See
https://boringssl-review.googlesource.com/c/boringssl/+/13122
This assumption has since been removed. See
https://boringssl-review.googlesource.com/c/boringssl/+/59526
Now that that is done, we can pull it out and instead pass it in as a
separate pointer, like how AES_KEY used to. (I made the key the first
argument because key than op seems more natural to me than op than key.
Also I didn't noticed I'd flipped them until I was done with the CL.) By
pulling it out, we avoid a pointless 500-ish byte memcpy before every
AES-GCM operation, which actually speeds up shorter inputs
non-trivially. See below. A nice bonus to cleaner code.
This doesn't do all the things in crbug.com/382503563, but gets us
partway towards it. It also gets the GCM128_* functions slightly closer
to being a self-contained abstraction.
As part of this, move aes_ctr_set_key into crypto/fipsmodule/aes instead
of crypto/fipsmodule/cipher. It was previously in cipher because it
depended on modes and modes already depends on aes, but now the GCM
dependency is moved out, I think aes makes more sense for it.
On an Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz
Before:
Did 22847000 AES-128-GCM (16 bytes) seal operations in 2000070us (182.8 MB/sec)
Did 13704000 AES-128-GCM (256 bytes) seal operations in 2000025us (1754.1 MB/sec)
Did 5856000 AES-128-GCM (1350 bytes) seal operations in 2000107us (3952.6 MB/sec)
Did 1323000 AES-128-GCM (8192 bytes) seal operations in 2001392us (5415.2 MB/sec)
Did 683000 AES-128-GCM (16384 bytes) seal operations in 2000266us (5594.4 MB/sec)
Did 20866750 AES-256-GCM (16 bytes) seal operations in 2000005us (166.9 MB/sec)
Did 12114000 AES-256-GCM (256 bytes) seal operations in 2000109us (1550.5 MB/sec)
Did 4572000 AES-256-GCM (1350 bytes) seal operations in 2000142us (3085.9 MB/sec)
Did 972000 AES-256-GCM (8192 bytes) seal operations in 2000988us (3979.3 MB/sec)
Did 497000 AES-256-GCM (16384 bytes) seal operations in 2000832us (4069.7 MB/sec)
After:
Did 25786000 AES-128-GCM (16 bytes) seal operations in 2000050us (206.3 MB/sec) [+12.9%]
Did 14489000 AES-128-GCM (256 bytes) seal operations in 2000004us (1854.6 MB/sec) [+5.7%]
Did 5927000 AES-128-GCM (1350 bytes) seal operations in 2000248us (4000.2 MB/sec) [+1.2%]
Did 1316000 AES-128-GCM (8192 bytes) seal operations in 2000236us (5389.7 MB/sec) [-0.5%]
Did 679000 AES-128-GCM (16384 bytes) seal operations in 2001792us (5557.4 MB/sec) [-0.7%]
Did 23180500 AES-256-GCM (16 bytes) seal operations in 2000016us (185.4 MB/sec) [+11.1%]
Did 12703000 AES-256-GCM (256 bytes) seal operations in 2000070us (1625.9 MB/sec) [+4.9%]
Did 4668000 AES-256-GCM (1350 bytes) seal operations in 2000238us (3150.5 MB/sec) [+2.1%]
Did 976000 AES-256-GCM (8192 bytes) seal operations in 2000115us (3997.5 MB/sec) [+0.5%]
Did 500000 AES-256-GCM (16384 bytes) seal operations in 2001380us (4093.2 MB/sec) [+0.6%]
The difference is even more pronounced on GCC:
Before:
Did 19500000 AES-128-GCM (16 bytes) seal operations in 2000077us (156.0 MB/sec)
Did 12833000 AES-128-GCM (256 bytes) seal operations in 2000040us (1642.6 MB/sec)
Did 5544000 AES-128-GCM (1350 bytes) seal operations in 2000325us (3741.6 MB/sec)
Did 1305000 AES-128-GCM (8192 bytes) seal operations in 2000029us (5345.2 MB/sec)
Did 677000 AES-128-GCM (16384 bytes) seal operations in 2002554us (5538.9 MB/sec)
Did 18222000 AES-256-GCM (16 bytes) seal operations in 2000026us (145.8 MB/sec)
Did 11351750 AES-256-GCM (256 bytes) seal operations in 2000036us (1453.0 MB/sec)
Did 4431000 AES-256-GCM (1350 bytes) seal operations in 2000278us (2990.5 MB/sec)
Did 965000 AES-256-GCM (8192 bytes) seal operations in 2000617us (3951.4 MB/sec)
Did 497000 AES-256-GCM (16384 bytes) seal operations in 2003070us (4065.2 MB/sec)
After:
Did 25878000 AES-128-GCM (16 bytes) seal operations in 2000001us (207.0 MB/sec) [+32.7%]
Did 14510250 AES-128-GCM (256 bytes) seal operations in 2000034us (1857.3 MB/sec) [+13.1%]
Did 5936000 AES-128-GCM (1350 bytes) seal operations in 2000273us (4006.3 MB/sec) [+7.1%]
Did 1314000 AES-128-GCM (8192 bytes) seal operations in 2000033us (5382.1 MB/sec) [+0.7%]
Did 677000 AES-128-GCM (16384 bytes) seal operations in 2002827us (5538.2 MB/sec) [-0.0%]
Did 23281000 AES-256-GCM (16 bytes) seal operations in 2000048us (186.2 MB/sec) [+27.8%]
Did 12750000 AES-256-GCM (256 bytes) seal operations in 2000008us (1632.0 MB/sec) [+12.3%]
Did 4685000 AES-256-GCM (1350 bytes) seal operations in 2000205us (3162.1 MB/sec) [+5.7%]
Did 977000 AES-256-GCM (8192 bytes) seal operations in 2001842us (3998.1 MB/sec) [+1.2%]
Did 501000 AES-256-GCM (16384 bytes) seal operations in 2003419us (4097.2 MB/sec) [+0.8%]
Bug: 382503563, 42290602
Change-Id: I4690b79212242084cbcde49aa59979344012e5f6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74268
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
There were two places where the ctr32_encrypt_blocks function could be
missing:
1. In the AES-CTR EVP_CIPHER, with aes_nohw, we forgot to fill it in but
we actually provide it. We don't care enough about AES-CTR to
benchmark it, but I expect this to be a significant perf win because
aes_nohw is bitsliced.
2. The 32-bit x86 vpaes implementation did not have a
ctr32_encrypt_blocks. Just implement it in C.
This allows us to delete a ton of code for a broadly unreachable
codepath.
32-bit x86 is not a particularly important target in 2024, but just to
confirm, here is the impact on AES-GCM on an Intel(R) Xeon(R) Gold 6154
CPU @ 3.00GHz, running in 32-bit mode and with
OPENSSL_ia32cap='~0x200000000000000'
Before:
Did 5587000 AES-128-GCM (16 bytes) seal operations in 1000098us (5586452.5 ops/sec): 89.4 MB/s
Did 1063000 AES-128-GCM (256 bytes) seal operations in 1000036us (1062961.7 ops/sec): 272.1 MB/s
Did 225000 AES-128-GCM (1350 bytes) seal operations in 1001725us (224612.5 ops/sec): 303.2 MB/s
Did 39000 AES-128-GCM (8192 bytes) seal operations in 1014011us (38461.1 ops/sec): 315.1 MB/s
Did 19127 AES-128-GCM (16384 bytes) seal operations in 1009808us (18941.2 ops/sec): 310.3 MB/s
Did 4742000 AES-256-GCM (16 bytes) seal operations in 1000051us (4741758.2 ops/sec): 75.9 MB/s
Did 820000 AES-256-GCM (256 bytes) seal operations in 1000199us (819836.9 ops/sec): 209.9 MB/s
Did 171000 AES-256-GCM (1350 bytes) seal operations in 1000656us (170887.9 ops/sec): 230.7 MB/s
Did 30000 AES-256-GCM (8192 bytes) seal operations in 1034187us (29008.3 ops/sec): 237.6 MB/s
Did 15000 AES-256-GCM (16384 bytes) seal operations in 1031233us (14545.7 ops/sec): 238.3 MB/s
After:
Did 5314000 AES-128-GCM (16 bytes) seal operations in 1000040us (5313787.4 ops/sec): 85.0 MB/s
Did 1035000 AES-128-GCM (256 bytes) seal operations in 1000919us (1034049.7 ops/sec): 264.7 MB/s
Did 220000 AES-128-GCM (1350 bytes) seal operations in 1001498us (219670.9 ops/sec): 296.6 MB/s
Did 37000 AES-128-GCM (8192 bytes) seal operations in 1009332us (36657.9 ops/sec): 300.3 MB/s
Did 19000 AES-128-GCM (16384 bytes) seal operations in 1018435us (18656.1 ops/sec): 305.7 MB/s
Did 4512250 AES-256-GCM (16 bytes) seal operations in 1000047us (4512037.9 ops/sec): 72.2 MB/s
Did 803000 AES-256-GCM (256 bytes) seal operations in 1000917us (802264.3 ops/sec): 205.4 MB/s
Did 168000 AES-256-GCM (1350 bytes) seal operations in 1002181us (167634.4 ops/sec): 226.3 MB/s
Did 29000 AES-256-GCM (8192 bytes) seal operations in 1033945us (28047.9 ops/sec): 229.8 MB/s
Did 15000 AES-256-GCM (16384 bytes) seal operations in 1055312us (14213.8 ops/sec): 232.9 MB/s
It's a bit slower, but comparable. Any affected device should really be
served ChaCha20-Poly1305 anyway. (Of course, this is entirely
unscientific because this code would never run on anything remotely like
this CPU.)
Fixed: 383994657
Change-Id: Ifca6a6195b20497dc7053d736c61b9000d3074f9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74267
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Following the guidance in
https://opensource.google/documentation/reference/releasing/authors,
start maintaining an AUTHORS file.
Update all existing Google copyright lines to 'The BoringSSL Authors'
per the document. This CL also changes the styling to match the new
guidance: removed the '(c)' and the comma.
All other existing copyright lines are left unmodified. Going forward,
our preference will be that new contributions to BoringSSL use 'The
BoringSSL Authors', optionally adding to the AUTHORS file if the
contributor desires.
To avoid being presumptuous, this CL does *not* proactively list every
past contributor in the BoringSSL half of the AUTHORS file. Past
contributors are welcome to send us a patch to be added, or request that
we add you. (Listed or not, the commit log continues to be a more
accurate record, and any existing non-Google copyright lines were left
unmodified.)
The OpenSSL half of the AUTHORS file is seeded with the contents of the
current OpenSSL AUTHORS file, as of writing. The current contents in the
latest revision of the 1.1.1 branch
(b372b1f76450acdfed1e2301a39810146e28b02c) and master
(d992e8729ee38b082482dc010e090bb20d1c7bd5) are identical, just formatted
in text vs Markdown.
Note when reviewing: CONTRIBUTING.md and AUTHORS contain non-mechanical
changes.
Bug: 364634028
Change-Id: I319d0ee63ec021ad85e248e8e3304b9cf9566681
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74149
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This change switches nearly all of BoringSSL to use C++. The public
functions still use the C ABI, and so code written in C can still use
BoringSSL. Also the use of the C++ standard library is minimal and no
run-time requirement for it is intended.
Change-Id: I902d2f51a3c8d6bd0dc4aabe1b192a15d7b788e8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/72747
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Having the files named .c but included causes a ton of problems with
build systems. Many of our build systems care about three categories of
files:
- public headers, available to downstream targets
- source files, each of which is compiled as a compilation unit
- internal headers, not available to downstream targets
There is usually a check, in Bazel called layering_check that enforces
source files only include headers that are declared somewhere
appropriate. The bcm.c fragments, under this classification, are
internal headers.
However, in both GN and Bazel, internal headers and sources
both go in the source list. They are distinguished only by file
extension. When FIPS fragments have a .c file extension, they are
misinterpreted as source files, and many things break.
Rename them. Either .h and .inc would be sufficient. Because we had to
disable Bazel's parse_headers feature, there is no difference (AFAICT)
in their handling. Also, these files actually pass the parse_headers
feature, even though they don't have an include guard. Still, the tech
of the style guide suggests that .inc is probably the better file
extension.
https://google.github.io/styleguide/cppguide.html#Self_contained_Headers
I used .c.inc rather than plain .inc so that we can easily
rename them back to .c when we solve https://crbug.com/362530616.
Note that, as .inc is not as common of a file extension, people working
on BoringSSL may need to reconfigure their editors to map .inc to C/C++.
Update-Note: Some downstream builds have been working around this by
building the fragments individually and excluding bcm.c. This change
will break those workarounds but also remove the need for it. It should
now be consistently possible to build BoringSSL without modifying the
file list.
Bug: 362664827
Change-Id: I933115c37843317a066e24a1092728c9afce35f5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70689
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This moves fork detection itself back into libcrypto.
BCM itself retains only the API to access the generation number
to know if stiring in more entropy is needed because a fork
happened.
Bug: 723
Change-Id: I9b38440e7243119de97f9c4653f0e91d71107501
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68967
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
BCM uses only passive entropy, in that from BCM's
point of view, entropy is requested and obtained
from an external source, and fed to BCM's CTR_DRBG
as required. With this change entropy is always gathered
in an OS specific manner outside of BCM by libcrypto,
while the CTR_DRBG remains in BCM using that entropy.
BCM functions (but not yet the tests!) now no longer
use the public RAND_bytes function, but instead use
BCM_rand_bytes which uses the BCM module CTR_DRBG.
BCM_rand_bytes is in turn used by libcrypto to implement
the public RAND_bytes function. All public RAND_
functions are now implemented in rand_extra.
As part of this two new headers are introduced to
start defining the interface boundary between libcrypto
and BCM.
crypto/bcm_support.h <- Functions implemented by libcrypto
and used by bcm
fipsmodule/bcm_interface.h <- Functions implemented by
bcm and used by libcrypto.
Bug: 723
Change-Id: I6b618dfe4df257f67971e88cbd79126c837e21d6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68147
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Strictly speaking this does not change any of the bcm/fipsmodule
code, it moves the tests out into libcrypto so that once we move
to an api boundary where bcm does not call libcrypto functions
directly, these tests still can do so.
Bug: 722
Change-Id: I9defc70a9e523e52dda2d53ab4bd155a4b44fc02
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68787
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Zephyr and CrOS EC targets embedded devices without MMU unit (no virtual
memory). It means that they don't support any address space duplication
like fork() or clone().
BUG=b/321092852
Change-Id: Icdf8be888ba87cd164cffb35f1accbc14f1a6887
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67807
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
If BORINGSSL_FIPS is defined, then rand_thread_state_free will attempt to manage the next and prev
pointers. These will be set to undefined values in the case of CRYPTO_set_thread_local calling rand_thread_state_free,
as theese pointers are not initalized until later on.
Change-Id: Ie7712e7eb4acec7cca6890cfabc2030f18ab5244
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63885
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This provides an alternative way for fork detection that can
be used if we are certain the platform does not have other ways
of cloning an address space in use that are not noticed by
pthread_atfork.
This supports using pthread_atfork for fork detection on
macOS, iOS, OpenBSD and FreeBSD. Linux continues to use MADVISE
for the generation number and fork detection.
Change-Id: I79fd7769477dc90bfe37229d2ff2e8c16898dff7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59906
Reviewed-by: David Benjamin <davidben@google.com>
Auto-Submit: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Add a rand_extra file for trusty, bump the BORINGSSL_API_VERION
and mark both trusty and windows as non-forking so we do not
require fork detection support.
Update-Note:
Prior to API version 24, Trusty maintained their own CRYPTO_sysrand
implementations outside of the BoringSSL tree. With this change
they are not expected to provide CRYPTO_sysrand, it is maintained
inside the BoringSSL tree.
Change-Id: Iabcef024ff85bd767e2869a6ff27a64236322325
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61465
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This allows operating systems to insist on IBT
enforcement as an exploit mitigation mechanism without
needing to make an exception for anything using a
bundled boringssl, such as chrome, mono, and qtwebengine.
Change-Id: Iac28dd3d2af177b89ffde10ae97bce23739feb94
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60625
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This changes the order of things so that by default your
system is expected to provide us with a getentropy() in
<unistd.h> for integrators that are not explicitly
supported.
We preserve the getrandom/urandom dance for Linux and Android
for now.
Linux has had getentropy() in libc's since 2017
macOS, and all the BSD's have had it for any versions we
care about.
iOS hides it from us - so we use CommonCrypto CCRandomGenerateBytes
Update-Note: Non-macOS Apple platforms now use CCRandomGenerateBytes
instead of /dev/urandom. Linux behavior remains unchanged. Platforms
which were not explicitly supported with a different codepath will also
switch from /dev/urandom to getentropy. If your platform specifically
requires /dev/urandom, let us know.know
Bug: 287
Change-Id: I0c2b8c594c473e4395379f50b0c4e6713c0a4c02
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61325
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
OPENSSL_WINDOWS doesn't *quite* imply that crypto/rand_extra/windows.c
is used, thanks to fuzzer mode.
The sea of ifdefs here is becoming quite a mess, so I've added
OPENSSL_RAND_* resolve the dispatch in one place. Perhaps later we
should also we can also simplify this by just including
CRYPTO_init_sysrand and CRYPTO_sysrand_if_available in all the C files.
But that'll be easier to do when Trusty's RNG is moved in tree.
While I'm here, fold some of the ifdefs in windows.c together.
Change-Id: Ic9c21c5c943a409ebb1d77f27daea1eeb9422e9d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61085
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
The Windows system RNG[1] lives in bcryptprimitives.dll which exports
the function ProcessPrng[2] to supply random bytes from its internal
generators. These are seeded and reseeded from the operating
system using a device connection to \\Device\CNG which is opened
when bcryptprimitives.dll is first loaded.
After this CL boringssl calls ProcessPrng() directly.
Before this CL boringssl got its system randomness (on non-UWP
desktop Windows) from calls to RtlGenRandom[3].
This function is undocumented and unsupported, but has always been
available by linking to SystemFunction036 in advadpi32.dll. In
Windows 10 and later, this export simply forwards to
cryptbase.dll!SystemFunction036 which calls ProcessPrng()
directly.
cryptbase!SystemFunction036 decompiled:
```
BOOLEAN SystemFunction036(PVOID RandomBuffer,ULONG RandomBufferLength)
{
BOOL retval;
retval = ProcessPrng(RandomBuffer,RandomBufferLength);
return retval != 0;
}
```
Loading cryptbase.dll has the side effect of opening a device handle
to \\Device\KsecDD which is not used by boringssl's random number
wrappers. Calling ProcessPrng() directly allows sandboxed programs
such as Chromium to avoid having this handle if they do not need it.
ProcessPrng() also takes a size_t length rather than a u32 length,
allowing some simplification of the calling code.
After this CL we require bcryptprimitives to be loaded before the
first call to CRYPTO_srand(). Applications using the library should
either load the module themselves or call CRYPTO_pre_sandbox_init().
Before this CL boringssl required that advapi32, cryptbase and
bcryptprimitives were all loaded so this should not represent a
breaking change.
[1] https://learn.microsoft.com/en-us/windows/win32/seccng/processprng
[2] https://download.microsoft.com/download/1/c/9/1c9813b8-089c-4fef-b2ad-ad80e79403ba/Whitepaper%20-%20The%20Windows%2010%20random%20number%20generation%20infrastructure.pdf
[3] https://docs.google.com/document/d/13n1t5ak0yofzcadQCF7Ew5TewSUkNfQ3n-IYodjeRYc/edit
Bug: chromium:74242
Change-Id: Ifb1d6ef1a4539ff6e9a2c36cc119b7700ca2be8f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60825
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
We no longer need to define CRYPTO_MUTEX in public headers. This
simplifies a pile of things. First, we can now use pthread_rwlock_t
without any fuss, rather than trying to guess the size on glibc.
As a result, CRYPTO_MUTEX and CRYPTO_STATIC_MUTEX can be merged into one
type. We can almost do this to CRYPTO_refcount_t too. BIO is the one
straggler remaining.
Fixed: 325
Change-Id: Ie93c9f553c0f02ce594b959c041b00fc15ba51d2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60611
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
If a process calls fork(), then the child process never forks again, the
child may wish to call RAND_enable_fork_unsafe_buffering(). However,
doing so exposes a bug: we assume that, if the flag is set, we don't
need to worry about fork-safety. But it is possible that the PRNG state
was cloned from another process which does not work.
Concretely, consider a zygote process, e.g. Chromium's. A zygote process
would retain fork-safety, but pass along its PRNG state to each of its
children. If the children never fork, they might disable fork-safety,
hitting this bug. (Chromium does not call this API. This is just a
hypothetical scenario.)
Fix this by reseeding whenever the fork-safety bit changes. This fix
does not strictly depend on the atomics work, but it causes us to
unconditionally sample rand_fork_unsafe_buffering_enabled(). This no
longer causes contention because it's just another atomic load.
This only affects systems without MADV_WIPEONFORK and without fast
RDRAND. If RDRAND is fast, we're always fork-safe and MADV_WIPEONFORK
allows us to efficiently detect forks.
Cq-Include-Trybots: luci.boringssl.try:linux_clang_rel_tsan
Change-Id: I6d0c471c62c951254faf85420a7dc3f4a9d65ee0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59850
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We don't take write locks in the PRNG, steady state, but we do take some
read locks: computing fork generation, reading the fork-unsafe buffering
flag, and a FIPS-only artifact of some global state clearing mess. That
last one is completely useless, but it's a consequence of FIPS's
understanding of process exit being comically inconsistent with reality.
Taking read locks is, in principle, parallel, but the cacheline write
causes some contention, even in newer glibcs with faster read locks. Fix
these:
- Use atomic reads to check the fork generation. We only need to lock
when we observe a fork.
- Replace the fork-unsafe buffering flag with an atomic altogether.
- Split state_clear_all_lock into a per-rand_thread_state lock. We still
need a read lock, but a completely uncontended one until process exit.
With many threads, this gives a significant perf boost.
x86_64, non-FIPS, Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz, 30 threads:
Before:
Did 45131875 RNG (16 bytes) operations in 300039649us (150419.7 ops/sec): 2.4 MB/s
Did 44089000 RNG (32 bytes) operations in 300053237us (146937.3 ops/sec): 4.7 MB/s
Did 43328000 RNG (256 bytes) operations in 300058423us (144398.5 ops/sec): 37.0 MB/s
Did 45857000 RNG (1350 bytes) operations in 300095943us (152807.8 ops/sec): 206.3 MB/s
Did 43249000 RNG (8192 bytes) operations in 300102698us (144114.0 ops/sec): 1180.6 MB/s
After:
Did 296204000 RNG (16 bytes) operations in 300009524us (987315.3 ops/sec): 15.8 MB/s
Did 311347000 RNG (32 bytes) operations in 300014396us (1037773.5 ops/sec): 33.2 MB/s
Did 295104000 RNG (256 bytes) operations in 300012657us (983638.5 ops/sec): 251.8 MB/s
Did 255721000 RNG (1350 bytes) operations in 300016481us (852356.5 ops/sec): 1150.7 MB/s
Did 103339000 RNG (8192 bytes) operations in 300040059us (344417.3 ops/sec): 2821.5 MB/s
(Smaller PRNG draws are more impacted because they spend less time in the
DRBG. But they're also more likely because you rarely need to pull 8K of
data out at once.)
x86_64, FIPS, Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz, 30 threads:
Before:
Did 29060000 RNG (16 bytes) operations in 300081190us (96840.5 ops/sec): 1.5 MB/s
Did 31882000 RNG (32 bytes) operations in 300118031us (106231.5 ops/sec): 3.4 MB/s
Did 30925000 RNG (256 bytes) operations in 300113646us (103044.3 ops/sec): 26.4 MB/s
Did 31969000 RNG (1350 bytes) operations in 300096688us (106529.0 ops/sec): 143.8 MB/s
Did 33434000 RNG (8192 bytes) operations in 300093240us (111412.0 ops/sec): 912.7 MB/s
After:
Did 299013000 RNG (16 bytes) operations in 300012167us (996669.6 ops/sec): 15.9 MB/s
Did 289788000 RNG (32 bytes) operations in 300014611us (965913.0 ops/sec): 30.9 MB/s
Did 298699000 RNG (256 bytes) operations in 300013443us (995618.7 ops/sec): 254.9 MB/s
Did 247061000 RNG (1350 bytes) operations in 300018215us (823486.7 ops/sec): 1111.7 MB/s
Did 100479000 RNG (8192 bytes) operations in 300037708us (334887.9 ops/sec): 2743.4 MB/s
On an M1 Pro, it's mostly a wash by default (fewer threads because this chip has fewer cores)
aarch64, M1 Pro, 8 threads:
Before:
Did 23218000 RNG (16 bytes) operations in 80009131us (290191.9 ops/sec): 4.6 MB/s
Did 23021000 RNG (256 bytes) operations in 80007544us (287735.4 ops/sec): 73.7 MB/s
Did 22853000 RNG (1350 bytes) operations in 80013184us (285615.4 ops/sec): 385.6 MB/s
Did 25407000 RNG (8192 bytes) operations in 80008371us (317554.3 ops/sec): 2601.4 MB/s
Did 22128000 RNG (16384 bytes) operations in 80013269us (276554.1 ops/sec): 4531.1 MB/s
After:
Did 23303000 RNG (16 bytes) operations in 80011433us (291245.9 ops/sec): 4.7 MB/s
Did 23072000 RNG (256 bytes) operations in 80008755us (288368.4 ops/sec): 73.8 MB/s
Did 22807000 RNG (1350 bytes) operations in 80013355us (285039.9 ops/sec): 384.8 MB/s
Did 23759000 RNG (8192 bytes) operations in 80010212us (296949.6 ops/sec): 2432.6 MB/s
Did 23193000 RNG (16384 bytes) operations in 80011537us (289870.7 ops/sec): 4749.2 MB/s
This is likely because, without RDRAND or MADV_WIPEONFORK, we draw from
the OS on every call. We're likely bottlenecked by getentropy, whether
it's some internal synchronization or syscall overherad. With
fork-unsafe buffering enabled, this change shows even more significant
wins on the M1 Pro.
aarch64, fork-unsafe buffering, M1 Pro, 8 threads:
Before:
Did 25727000 RNG (16 bytes) operations in 80010579us (321545.0 ops/sec): 5.1 MB/s
Did 25776000 RNG (32 bytes) operations in 80008587us (322165.4 ops/sec): 10.3 MB/s
Did 25780000 RNG (256 bytes) operations in 80006127us (322225.3 ops/sec): 82.5 MB/s
Did 33171250 RNG (1350 bytes) operations in 80002532us (414627.5 ops/sec): 559.7 MB/s
Did 54784000 RNG (8192 bytes) operations in 80005706us (684751.2 ops/sec): 5609.5 MB/s
After:
Did 573826000 RNG (16 bytes) operations in 80000668us (7172765.1 ops/sec): 114.8 MB/s
Did 571329000 RNG (32 bytes) operations in 80000423us (7141574.7 ops/sec): 228.5 MB/s
Did 435043750 RNG (256 bytes) operations in 80000214us (5438032.3 ops/sec): 1392.1 MB/s
Did 229536000 RNG (1350 bytes) operations in 80001888us (2869132.3 ops/sec): 3873.3 MB/s
Did 57253000 RNG (8192 bytes) operations in 80004974us (715618.0 ops/sec): 5862.3 MB/s
Note that, on hardware with RDRAND, the read lock in
rand_fork_unsafe_buffering_enabled() doesn't do much. But without
RDRAND, we hit that on every RAND_bytes call. More importantly, the
subsequent CL will fix a bug that will require us to hit it more
frequently.
I've removed the volatile on g_fork_detect_addr because I think we
didn't need it and this avoids thinking about the interaction between
volatile and atomics. The pointer is passed into madvise, so the
compiler knows the pointer escapes. For it to be invalid, the compiler
would need to go out of its way to model madvise as not remembering the
pointer, which would be incorrect of it for MADV_WIPEONFORK.
Bug: 570
Cq-Include-Trybots: luci.boringssl.try:linux_clang_rel_tsan
Change-Id: Ie6977acd1b8e7639aaa419cf6f4f5f0645bde9d1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59849
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This test could simulate the lack of MADV_WIPEONFORK on systems with it,
but couldn't simulate having it if the kernel didn't support it.
This change makes the presence / absence of
BORINGSSL_IGNORE_MADV_WIPEONFORK control whether MADV_WIPEONFORK is
"supported" in the test environment or not, and corrects the test for
the case where it's missing.
Change-Id: I23876788a0e0a4fd2a148f98b6b94e40880b6fc9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57745
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Setting the first argument to -1 works, but changing the syscall number
is more straightforward. It's doable on aarch64 too, if we use a
different regset.
Cq-Include-Trybots: luci.boringssl.try:android_aarch64
Change-Id: I6c3c2d3dc67c06a44b181f9086cb5c9d343d51bc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57587
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
At least on the devices we have on CI, PTRACE_SETREGS seems to break
things when passing in a slightly smaller structure. I'm guessing the
other registers get set to zero, so we SIGILL.
Cq-Include-Trybots: luci.boringssl.try:android_aarch64
Change-Id: I09da595dba2b6b70805c9a79c71c797c0f6635c0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57585
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This reverts commit 8ce0e1c14e.
The original commit didn't work on Android because:
a) urandom_test didn't handle the fact that Android requires
getrandom() and will never fall back to /dev/urandom.
b) Android may open files in /dev/__properties__ which
confused urandom_test.
The original change is patchset 1 so the differences build on that.
Change-Id: Ib840ec20d60cb28d126d3d09271b18fbd9ec1371
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53705
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: Adam Langley <agl@google.com>
We no longer have a need to support ppc64le, nor do we have any testing
story for the assembly we previously had. Remove all ppc64le-specific
assembly.
This CL stops short of removing it from base.h. That'll be done in a
follow-up CL, just to separate which removals are for the assembly and
which removals remove all support.
Update-Note: After this change, ppc64le builds drop assembly
optimizations and will fallback to a generic C-based AES implementation.
Change-Id: Ic8075638085761d66cebc276eb16c4770ce03920
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56388
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
It is now 2022. See if we can assume getrandom in this configuration.
Update-Note: The /dev/urandom fallback is no longer available in FIPS
builds. This fallback relied on RNGGETENTCNT and was quite flaky.
Change-Id: Icf6d29f6d5952fb6c5656c9039a4cfaf1de2d724
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54127
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
For various reasons, our FIPS mode build will sometimes seed from RDRAND
instead of the OS. (And, when
https://boringssl-review.googlesource.com/c/boringssl/+/52527 relands,
there'll be another non-OS source.)
To help with this,
https://boringssl-review.googlesource.com/c/boringssl/+/37664 made the
FIPS mode rand_get_seed opportunistically incorporate OS entropy when
available. Originally, it just XORed into the original entropy.
Then https://boringssl-review.googlesource.com/c/boringssl/+/44305
rearranged this so that rand_get_seed had an out_used_cpu (since renamed
to out_want_additional input) output, with the caller mixing the entropy
in instead, into the personalization input to CTR_DRBG_init.
In doing so, that change lost the OS entropy in the CTR_DRBG_reseed
calls. Add it back in, using the additional_data parameter. As part of
this, move the CRYPTO_sysrand_if_available call back to rand_get_seed,
this time as a second output which the caller is responsible for passing
into CTR_DRBG_{init,reseed} alongside the main output.
Change-Id: Ie3335c74e940c760031a28de932d6fedfe355ea0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54126
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Adam Langley