kris/boringssl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Work around an apparent Linux or glibc bug on ppc64le in FIPS mode.

Browse Source 
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>
This commit is contained in:
David Benjamin 2017-06-07 15:30:11 -04:00 committed by CQ bot account: commit-bot@chromium.org
parent d91e1efd83
commit 17ce286e07
1 changed files with 36 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

61
crypto/fipsmodule/rand/rand.c
View File

@ -238,6 +238,27 @@ void RAND_bytes_with_additional_data(uint8_t *out, size_t out_len,
return;
}
/* Additional data is mixed into every CTR-DRBG call to protect, as best we
* can, against forks & VM clones. We do not over-read this information and
* don't reseed with it so, from the point of view of FIPS, this doesn't
* provide “prediction resistance”. But, in practice, it does. */
uint8_t additional_data[32];
if (!hwrand(additional_data, sizeof(additional_data))) {
/* Without a hardware RNG to save us from address-space duplication, the OS
* entropy is used. This can be expensive (one read per |RAND_bytes| call)
* and so can be disabled by applications that we have ensured don't fork
* and aren't at risk of VM cloning. */
if (!rand_fork_unsafe_buffering_enabled()) {
CRYPTO_sysrand(additional_data, sizeof(additional_data));
} else {
OPENSSL_memset(additional_data, 0, sizeof(additional_data));
}
}
for (size_t i = 0; i < sizeof(additional_data); i++) {
additional_data[i] ^= user_additional_data[i];
}
struct rand_thread_state stack_state;
struct rand_thread_state *state =
CRYPTO_get_thread_local(OPENSSL_THREAD_LOCAL_RAND);
@ -275,38 +296,28 @@ void RAND_bytes_with_additional_data(uint8_t *out, size_t out_len,
#endif
}
#if defined(BORINGSSL_FIPS)
CRYPTO_STATIC_MUTEX_lock_read(thread_states_list_lock_bss_get());
#endif
if (state->calls >= kReseedInterval) {
uint8_t seed[CTR_DRBG_ENTROPY_LEN];
rand_get_seed(state, seed);
#if defined(BORINGSSL_FIPS)
/* Take a read lock around accesses to |state->drbg|. This is needed to
* avoid returning bad entropy if we race with
* |rand_thread_state_clear_all|.
*
* This lock must be taken after any calls to |CRYPTO_sysrand| to avoid a
* bug on ppc64le. glibc may implement locks by wrapping the critical
* section in a hardware transaction. This appears to sometimes break
* |getrandom|. */
CRYPTO_STATIC_MUTEX_lock_read(thread_states_list_lock_bss_get());
#endif
if (!CTR_DRBG_reseed(&state->drbg, seed, NULL, 0)) {
abort();
}
state->calls = 0;
}
/* Additional data is mixed into every CTR-DRBG call to protect, as best we
* can, against forks & VM clones. We do not over-read this information and
* don't reseed with it so, from the point of view of FIPS, this doesn't
* provide “prediction resistance”. But, in practice, it does. */
uint8_t additional_data[32];
if (!hwrand(additional_data, sizeof(additional_data))) {
/* Without a hardware RNG to save us from address-space duplication, the OS
* entropy is used. This can be expensive (one read per |RAND_bytes| call)
* and so can be disabled by applications that we have ensured don't fork
* and aren't at risk of VM cloning. */
if (!rand_fork_unsafe_buffering_enabled()) {
CRYPTO_sysrand(additional_data, sizeof(additional_data));
} else {
OPENSSL_memset(additional_data, 0, sizeof(additional_data));
}
}
for (size_t i = 0; i < sizeof(additional_data); i++) {
additional_data[i] ^= user_additional_data[i];
} else {
#if defined(BORINGSSL_FIPS)
CRYPTO_STATIC_MUTEX_lock_read(thread_states_list_lock_bss_get());
#endif
}
int first_call = 1;