There are still a ton of them, almost exclusively complaints that
function declaration and definitions have different parameter names. I
just fixed a few randomly.
Change-Id: I1072f3dba8f63372cda92425aa94f4aa9e3911fa
Reviewed-on: https://boringssl-review.googlesource.com/18706
Reviewed-by: Steven Valdez <svaldez@google.com>
The former is defined by the kernel and is a straightforward number. The
latter is defined by glibc as:
#define SYS_getrandom __NR_getrandom
which does not work when kernel headers are older than glibc headers.
Instead, use the kernel values.
Bug: chromium:742260
Change-Id: Id162f125db660643269e0b1329633437048575c4
Reviewed-on: https://boringssl-review.googlesource.com/17864
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>
This was specific to some old software on the test machine. Shrinking
the critical section to not cover getrandom is probably worthwhile
anyway though, so keep it around but make the comment less scary.
Change-Id: I8c17b6688ae93f6aef5d89c252900985d9e7bb52
Reviewed-on: https://boringssl-review.googlesource.com/16992
Reviewed-by: Adam Langley <agl@google.com>
POWER8 has hardware transactional memory, which glibc uses to implement
locks. In some cases, taking a lock begins a transaction, wrapping
arbitrary user code (!) until the lock is released. If the transaction
is aborted, everything rewinds and glibc tries again with some other
implementation.
The kernel will abort the transaction in a variety of cases. Notably, on
a syscall, the transaction aborts and the syscall *does not happen*.
https://www.kernel.org/doc/Documentation/powerpc/transactional_memory.txt
Yet, for some reason, although the relevant change does appear to be in
the kernel, the transaction is being rewound with getrandom happening
anyway. This does not work very well.
Instead, only guard the DRBG access with the lock, not CRYPTO_sysrand.
This lock is only used to protect the DRBG from the destructor that
zeros everything.
Change-Id: Ied8350f1e808a09300651de4200c7b0d07b3a158
Reviewed-on: https://boringssl-review.googlesource.com/16985
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>
Without this, trying to trigger the CRNGT on a system with RDRAND won't
work.
Change-Id: I0658a1f045620a2800df36277f67305bc0efff8b
Reviewed-on: https://boringssl-review.googlesource.com/16766
Reviewed-by: Adam Langley <agl@google.com>
FIPS requires that the CTR-DRBG state be zeroed on process exit, however
destructors for thread-local data aren't called when the process exits.
This change maintains a linked-list of thread-local state which is
walked on exit to zero each thread's PRNG state. Any concurrently
running threads block until the process finishes exiting.
Change-Id: Ie5dc18e1bb2941a569d8b309411cf20c9bdf52ef
Reviewed-on: https://boringssl-review.googlesource.com/16764
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>
Most importantly, this version of delocate works for ppc64le. It should
also work for x86-64, but will need significant testing to make sure
that it covers all the cases that the previous delocate.go covered.
It's less stringtastic than the old code, however the parser isn't as
nice as I would have liked. I thought that the reason we put up with
AT&T syntax with Intel is so that assembly syntax could be somewhat
consistent across platforms. At least for ppc64le, that does not appear
to be the case.
Change-Id: Ic7e3c6acc3803d19f2c3ff5620c5e39703d74212
Reviewed-on: https://boringssl-review.googlesource.com/16464
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>
Change-Id: Iab7a738a8981de7c56d1585050e78699cb876dab
Reviewed-on: https://boringssl-review.googlesource.com/16467
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This change causes FIPS mode to use RDRAND in preference to the kernel's
entropy pool. This prevents issues where the ioctl that we have to do
when getrandom isn't supported transiently reports that the pool is
“empty” and causes us to block.
Change-Id: Iad50e443d88b168bf0b85fe1e91e153d79ab3703
Reviewed-on: https://boringssl-review.googlesource.com/16466
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This is needed when unrandom.c is compiled on its own.
Change-Id: Ia46e06d267c097e5fa0296092a7270a4cd0b2044
Reviewed-on: https://boringssl-review.googlesource.com/16085
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>
Change-Id: Icf1d6ec9d3fb33a124a9f61c75d29248a2582680
Reviewed-on: https://boringssl-review.googlesource.com/15964
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>
This doesn't actually measure what we need(*) and, because of that, it's
way more noisy than expected.
(*) We want to know whether the pool has been initialised, not whether
it currently thinks it has a lot of bits, but we can't get what we want
without getrandom() support in the kernel.
Change-Id: I20accb99a592739c786a25c1656aeea050ae81a3
Reviewed-on: https://boringssl-review.googlesource.com/15624
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>
OPENSSL_ia32cap_addr avoids any relocations within the module, at the
cost of a runtime TEXTREL, which causes problems in some cases.
(Notably, if someone links us into a binary which uses the GCC "ifunc"
attribute, the loader crashes.)
Fix C references of OPENSSL_ia32cap_addr with a function. This is
analogous to the BSS getters. A follow-up commit will fix perlasm with a
different scheme which avoids calling into a function (clobbering
registers and complicating unwind directives.)
Change-Id: I09d6cda4cec35b693e16b5387611167da8c7a6de
Reviewed-on: https://boringssl-review.googlesource.com/15525
Reviewed-by: Adam Langley <agl@google.com>
Support for platforms that we don't support FIPS on doesn't need to be
in the module. Also, functions for dealing with whether fork-unsafe
buffering is enabled are left out because they aren't implementing any
cryptography and they use global r/w state, making their inclusion
painful.
Change-Id: I71a0123db6f5449e9dfc7ec7dea0944428e661aa
Reviewed-on: https://boringssl-review.googlesource.com/15084
Reviewed-by: Adam Langley <agl@google.com>
