The changes to delocate.go are needed because modes/ does things like
return the address of a module function. Both of these need to be
changed from referencing the GOT to using local symbols.
Rather than testing whether |ghash| is |gcm_ghash_avx|, we can just keep
that information in a flag.
The test for |aesni_ctr32_encrypt_blocks| is more problematic, but I
believe that it's superfluous and can be dropped: if you passed in a
stream function that was semantically different from
|aesni_ctr32_encrypt_blocks| you would already have a bug because
|CRYPTO_gcm128_[en|de]crypt_ctr32| will handle a block at the end
themselves, and assume a big-endian, 32-bit counter anyway.
Change-Id: I68a84ebdab6c6006e11e9467e3362d7585461385
Reviewed-on: https://boringssl-review.googlesource.com/15064
Reviewed-by: Adam Langley <agl@google.com>
FIPS requires that the output of the entropy source be checked to ensure
that no two n-bit blocks are equal.
Change-Id: Ia086ca5c888770e0fd71ee052278f77b544b9983
Reviewed-on: https://boringssl-review.googlesource.com/14926
Reviewed-by: Adam Langley <agl@google.com>
We already do this in the case that getrandom is supported. This change
adds a polling loop for the case where we are using /dev/urandom.
This makes FIPS imply Linux, which I think is fine for the time being.
Change-Id: I9bf5c0f51a908621655cbcc47fc86b0366168b97
Reviewed-on: https://boringssl-review.googlesource.com/14925
Reviewed-by: Adam Langley <agl@google.com>
Fork-unsafe buffering was a mode that could be enabled by applications
that were sure that they didn't need to worry about state duplication.
It saved reads to urandom.
Since everything is now going through the CTR-DRBG, we can get the same
effect by simply not reading additional data from urandom in this case.
This change drops the buffering from urandom.c and, instead, implements
fork-unsafe buffering as a mode that skips reading additional data from
urandom, which only happened when RDRAND wasn't available anyway.
Since we expect the power-on self-tests to call into the PRNG, this
change also makes the flag capable of changing at any point by using a
mutex rather than a once. This is split into a separate file so that it
doesn't have to go into the FIPS module—since it uses r/w data that
would be a pain.
Change-Id: I5fd0ead0422e770e35758f080bb1cffa70d0c8da
Reviewed-on: https://boringssl-review.googlesource.com/14924
Reviewed-by: Adam Langley <agl@google.com>
This isn't actually used yet, but implements CTR-DRBG from SP 800-90Ar1.
Specifically, it always uses AES-256 and no derivation function.
Change-Id: Ie82b829590226addd7c165eac410a5d584858bfd
Reviewed-on: https://boringssl-review.googlesource.com/14891
Reviewed-by: Adam Langley <agl@google.com>
This isn't something we need to fix, just an explanatory comment.
Change-Id: I284e6580d176f981c6b161e9951f367fef1b1be6
Reviewed-on: https://boringssl-review.googlesource.com/14264
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
It is hard to control what flags consumers may try to build us with.
Account for someone adding _GNU_SOURCE to the build line.
Change-Id: I4c931da70a9dccc89382ce9100c228c29d28d4bf
Reviewed-on: https://boringssl-review.googlesource.com/13621
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Fuchsia uses crypto/rand/fuchsia.c for CRYPTO_sysrand, and so must be
excluded from the Linux/Apple/POSIX variant.
Change-Id: Ide9f0aa2547d52ce0579cd0a1882b2cdcc7b95c6
Reviewed-on: https://boringssl-review.googlesource.com/13141
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This change adds the OS-specific routines to get random bytes when using
BoringSSL on Fuchsia. Fuchsia uses the Magenta kernel, which provides
random bytes via a syscall rather than via a file or library function.
Change-Id: I32f858246425309d643d142214c7b8de0c62250a
Reviewed-on: https://boringssl-review.googlesource.com/13140
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: If565a5fdfa0f314422aa26c2e8f869965ca08c1b
Reviewed-on: https://boringssl-review.googlesource.com/12969
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <alangley@gmail.com>
Most C standard library functions are undefined if passed NULL, even
when the corresponding length is zero. This gives them (and, in turn,
all functions which call them) surprising behavior on empty arrays.
Some compilers will miscompile code due to this rule. See also
https://www.imperialviolet.org/2016/06/26/nonnull.html
Add OPENSSL_memcpy, etc., wrappers which avoid this problem.
BUG=23
Change-Id: I95f42b23e92945af0e681264fffaf578e7f8465e
Reviewed-on: https://boringssl-review.googlesource.com/12928
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
MSAN doesn't hook |syscall| and thus doesn't know that the kernel has
filled the output buffer when |getrandom| is called.
This change tells MSAN to trust that the memory that |getrandom| writes
to has been initialised. This should avoid false-positives when code
operates on |RAND_bytes| output.
Change-Id: I0a74ebb21bcd1de1f28eda69558ee27f82db807a
Reviewed-on: https://boringssl-review.googlesource.com/12903
Reviewed-by: Adam Langley <alangley@gmail.com>
Commit-Queue: Adam Langley <alangley@gmail.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This reverts commit 97db926cf7,
effectively unreverting the two changes that it contained. A subsequent
change will fix this code for MSAN.
Change-Id: I54a82b667b7a4208c7a960aa28b01cb246bc78c7
Reviewed-on: https://boringssl-review.googlesource.com/12902
Commit-Queue: Adam Langley <alangley@gmail.com>
Reviewed-by: David Benjamin <davidben@google.com>
This reverts commits 36ca21415a and
7b668a873e. We believe that we need to
update ASAN to be aware of getrandom before we can use it. Otherwise it
believes that the memory with the entropy from this syscall is
uninitialised.
Change-Id: I1ea1c4d3038b3b2cd080be23d7d8b60fc0c83df2
Reviewed-on: https://boringssl-review.googlesource.com/12901
Reviewed-by: Adam Langley <alangley@gmail.com>
Commit-Queue: Adam Langley <alangley@gmail.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This change will cause getrandom to be used in preference to
/dev/urandom when supported by the kernel.
This will also cause BoringSSL-using processes to block until the
entropy pool is initialised on systems that support getrandom(2).
Change-Id: I2d3a17891502c85884c77138ef0f3a719d7ecfe6
Reviewed-on: https://boringssl-review.googlesource.com/12421
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Fuzzer mode explores the handshake, but at the cost of losing coverage
on the record layer. Add a separate build flag and client/server
corpora for this mode.
Note this requires tweaks in consumers' fuzzer build definitions.
BUG=111
Change-Id: I1026dc7301645e165a761068a1daad6eedc9271e
Reviewed-on: https://boringssl-review.googlesource.com/12108
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This patch changes the urandom PRNG to read one byte from the
getrandom(2) Linux syscall on initialization in order to find any
unexpected behavior.
Change-Id: I8ef676854dc361e4f77527b53d1a14fd14d449a8
Reviewed-on: https://boringssl-review.googlesource.com/8681
Reviewed-by: Adam Langley <alangley@gmail.com>
Commit-Queue: Adam Langley <alangley@gmail.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This is very far from all of it, but I did some easy ones before I got
bored. Snapshot the progress until someone else wants to continue this.
BUG=22
Change-Id: I2609e9766d883a273e53e01a75a4b1d4700e2436
Reviewed-on: https://boringssl-review.googlesource.com/9132
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
There's a __pragma expression which allows this. Android builds us Windows with
MinGW for some reason, so we actually do have to tolerate non-MSVC-compatible
Windows compilers. (Clang for Windows is much more sensible than MinGW and
intentionally mimicks MSVC.)
MinGW doesn't understand MSVC's pragmas and warns a lot. #pragma warning is
safe to suppress, so wrap those to shush them. This also lets us do away with a
few ifdefs.
Change-Id: I1f5a8bec4940d4b2d947c4c1cc9341bc15ec4972
Reviewed-on: https://boringssl-review.googlesource.com/8236
Reviewed-by: Adam Langley <agl@google.com>
Windows SRWLOCK requires you call different functions here. Split
them up in preparation for switching Windows from CRITICAL_SECTION.
BUG=37
Change-Id: I7b5c6a98eab9ae5bb0734b805cfa1ff334918f35
Reviewed-on: https://boringssl-review.googlesource.com/8080
Reviewed-by: Adam Langley <agl@google.com>
If running the stack through a fuzzer, we would like execution to be
completely deterministic. This is gated on a
BORINGSSL_UNSAFE_FUZZER_MODE #ifdef.
For now, this just uses the zero ChaCha20 key and a global counter. As
needed, we can extend this to a thread-local counter and a separate
ChaCha20 stream and counter per input length.
Change-Id: Ic6c9d8a25e70d68e5dc6804e2c234faf48e51395
Reviewed-on: https://boringssl-review.googlesource.com/7286
Reviewed-by: Adam Langley <agl@google.com>
With these stubs, cURL should not need any BoringSSL #ifdefs at all,
except for their OCSP #ifdefs (which can switch to the more generally
useful OPENSSL_NO_OCSP) and the workaround for wincrypt.h macro
collisions. That we intentionally leave to the consumer rather than add
a partial hack that makes the build sensitive to include order.
(I'll send them a patch upstream once this cycles in.)
Change-Id: I815fe67e51e80e9aafa9b91ae68867ca1ff1d623
Reviewed-on: https://boringssl-review.googlesource.com/6980
Reviewed-by: Adam Langley <agl@google.com>
Native Client doesn't support fcntl natively and its default
implemention just returns ENOSYS.
Change-Id: Id8615e2f6f0a75a1140f8efd75afde471ccdf466
Reviewed-on: https://boringssl-review.googlesource.com/6721
Reviewed-by: Adam Langley <agl@google.com>
OpenSSH calls |RAND_seed| before jailing in the expectation that that
will be sufficient to ensure that later RAND calls are successful.
See internal bug 25695426.
Change-Id: I9d3f5665249af6610328ac767cb83059bb2953dd
Reviewed-on: https://boringssl-review.googlesource.com/6494
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
The new function |CRYPTO_chacha_96_bit_nonce_from_64_bit_nonce| can be
used to adapt code from that uses 64 bit nonces, in a way that is
compatible with the old semantics.
Change-Id: I83d5b2d482e006e82982f58c9f981e8078c3e1b0
Reviewed-on: https://boringssl-review.googlesource.com/6100
Reviewed-by: Adam Langley <alangley@gmail.com>
This compiled, so I guess everything we care about can do C++-style
comments, but better be uniform.
Change-Id: I9950c2df93cd81bb2bddb3a1e14e2de02c7e4807
Reviewed-on: https://boringssl-review.googlesource.com/6304
Reviewed-by: Adam Langley <alangley@gmail.com>
By doing this the compiler can notice that much of the code is unused in
the case that we know that we can't have a hardware RNG (i.e. ARM).
Change-Id: I72d364a30080364d700f855640e0164c2c62f0de
Reviewed-on: https://boringssl-review.googlesource.com/6001
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
It didn't do too much and I didn't notice that CRYPTO_sysrand wasn't
OPENSSL_EXPORTed, which makes the test impossible on shared-library
builds.
Change-Id: I38986572aa34fa9c0f30075d562b8ee4e1a0c8b8
Callers that lack hardware random may obtain a speed improvement by
calling |RAND_enable_fork_unsafe_buffering|, which enables a
thread-local buffer around reads from /dev/urandom.
Change-Id: I46e675d1679b20434dd520c58ece0f888f38a241
Reviewed-on: https://boringssl-review.googlesource.com/5792
Reviewed-by: Adam Langley <agl@google.com>
arm_arch.h is included from ARM asm files, but lives in crypto/, not
openssl/include/. Since the asm files are often built from a different
location than their position in the source tree, relative include paths
are unlikely to work so, rather than having crypto/ be a de-facto,
second global include path, this change moves arm_arch.h to
include/openssl/.
It also removes entries from many include paths because they should be
needed as relative includes are always based on the locations of the
source file.
Change-Id: I638ff43d641ca043a4fc06c0d901b11c6ff73542
Reviewed-on: https://boringssl-review.googlesource.com/5746
Reviewed-by: Adam Langley <agl@google.com>
Missed a mention of CRYPTO_have_hwrand.
Change-Id: I9756d80105c2fcee487a7badbf4d82f375b5652d
Reviewed-on: https://boringssl-review.googlesource.com/5640
Reviewed-by: Adam Langley <agl@google.com>
Since the caller must check for CRYPTO_hwrand failures anyway, there's not much
point in doing the CRYPTO_have_hwrand check externally.
(As a bonus, CRYPTO_hwrand no longer compiles to abort() on ARM, so linker
deduplicating won't confuse Chrome's crash reporter...)
Change-Id: I2191d835fbda5b70812f14cd9a873a5e35c30c6d
Reviewed-on: https://boringssl-review.googlesource.com/5630
Reviewed-by: Adam Langley <agl@google.com>
This means e.g. that a caller can say:
RAND_SSLEay()->bytes(...)
and so on. But in exchange for this convenience, I've changed the
signatures to be more BoringSSL-ish (|size_t| instead of |int|).
That's fine; |RAND_set_rand_method(SSLEay())| still works. And by
works I mean "does nothing".
Change-Id: I35479b5efb759da910ce46e22298168b78c9edcf
Reviewed-on: https://boringssl-review.googlesource.com/5472
Reviewed-by: Adam Langley <agl@google.com>
Less chance of problems should the prototype ever change. This doesn't
make it any more or less a circular dependency. (It actually isn't;
crypto/chacha doesn't use crypto/rand and CMakeLists.txt actually puts
rand above chacha anyway.)
Change-Id: Ia80289f801f76551737233f158755aac99ddd74a
Reviewed-on: https://boringssl-review.googlesource.com/5262
Reviewed-by: Adam Langley <agl@google.com>
Chromium uses a zygote process and a sandbox on Linux. In order for RAND_bytes
to be functional and guaranteed fork-safe inside the renderers, /dev/urandom
must be prewarmed. Calling RAND_bytes initializes a thread-local ChaCha20 key
when rdrand is available. So that key is fork-safe and to avoid tempting any
dragons by touching pthreads APIs before a non-exec fork, add a
RAND_set_urandom_fd API. It allows the consumer to supply the /dev/urandom fd
and promises to be fork-safe, both in initializing key material and use of
pthreads.
This doesn't affect any current shipping versions of Chrome.
BUG=462040
Change-Id: I1037e21e525918971380e4ea1371703c8237a0b0
Reviewed-on: https://boringssl-review.googlesource.com/5302
Reviewed-by: Adam Langley <agl@google.com>
I mistakenly believed that only RDSEED could fail. However, the Intel
manuals state that RDRAND can fail too.
I can't actually observe it failing, even with all cores running RDRAND in a
tight loop. In any case, the ChaCha20 masking means that it wouldn't be
a big deal anyway.
Still, this change tests the carry flag after RDRAND and the code falls
back to |CRYPTO_sysrand| if RDRAND has a hiccup. (The Intel manuals
suggest[1] calling RDRAND in a loop, ten times, before considering it to
have failed. But a single failure appears to be such a rare event that
the complexity in the asm code doesn't seem worth it.)
This change also adds an asm function to fill a buffer with random data.
Otherwise the overhead of calling |CRYPTO_rdrand|, and bouncing the data
in and out of memory starts to add up.
Thanks to W. Mark Kubacki, who may have reported this. (There's some
confusion in the bug report.)
Before:
Did 6148000 RNG (16 bytes) operations in 1000080us: 98.4 MB/s
Did 649000 RNG (256 bytes) operations in 1000281us: 166.1 MB/s
Did 22000 RNG (8192 bytes) operations in 1033538us: 174.4 MB/s
After:
Did 6573000 RNG (16 bytes) operations in 1000002us: 105.2 MB/s
Did 693000 RNG (256 bytes) operations in 1000127us: 177.4 MB/s
Did 24000 RNG (8192 bytes) operations in 1028466us: 191.2 MB/s
[1] Intel Reference Manual, section 7.3.17.1.
Change-Id: Iba7f82e844ebacef535472a31f2dd749aad1190a
Reviewed-on: https://boringssl-review.googlesource.com/5180
Reviewed-by: Adam Langley <agl@google.com>
When cross-compiling for Windows on a Linux system, the filesystem is
case sensitive and so #includes with uppercase characters cause errors.
Change-Id: I6fe6d677887ce84ba8b2c3136cf2c70998d96e81
Reviewed-on: https://boringssl-review.googlesource.com/5060
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
We can't actually catch this with MSan because it requires all code be
instrumented, so it needs a NO_ASM build which no disables that code. valgrind
doesn't notice either, possibly because there's some computation being done on
it. Still, we shouldn't use uninitialized memory.
Also get us closer to being instrumentable by MSan, but the runner tests will
need to build against an instrumented STL and I haven't tried that yet.
Change-Id: I2d65697a3269b5b022899f361730a85c51ecaa12
Reviewed-on: https://boringssl-review.googlesource.com/4760
Reviewed-by: Adam Langley <agl@google.com>
MSVC doesn't like |const size_t len| in a function definition where the
declaration was just |size_t len| without the |const|. Also, MSVC needs
declarations of parameterless functions to have a |void| parameter list.
Change-Id: I91e01a12aca657b2ee1d653926f09cc52da2faed
Reviewed-on: https://boringssl-review.googlesource.com/4329
Reviewed-by: Adam Langley <agl@google.com>
OpenSSH, especially, does some terrible things that mean that it needs
the EVP_CIPHER structure to be exposed ☹. Damian is open to a better API
to replace this, but only if OpenSSL agree too. Either way, it won't be
happening soon.
Change-Id: I393b7a6af6694d4d2fe9ebcccd40286eff4029bd
Reviewed-on: https://boringssl-review.googlesource.com/4330
Reviewed-by: Adam Langley <agl@google.com>
