boringssl/crypto/rand/hwrand.c

66 lines
1.7 KiB
C
Raw Normal View History

/* Copyright (c) 2015, Google Inc.
*
* Permission to use, copy, modify, and/or distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
* SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
* OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */
#include <openssl/rand.h>
Handle RDRAND failures. 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>
2015-06-19 19:06:28 +01:00
#include <assert.h>
#include <string.h>
#include <openssl/cpu.h>
#include "internal.h"
#if defined(OPENSSL_X86_64) && !defined(OPENSSL_NO_ASM)
Handle RDRAND failures. 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>
2015-06-19 19:06:28 +01:00
/* These functions are defined in asm/rdrand-x86_64.pl */
extern int CRYPTO_rdrand(uint8_t out[8]);
extern int CRYPTO_rdrand_multiple8_buf(uint8_t *buf, size_t len);
static int have_rdrand(void) {
return (OPENSSL_ia32cap_P[1] & (1u << 30)) != 0;
}
Handle RDRAND failures. 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>
2015-06-19 19:06:28 +01:00
int CRYPTO_hwrand(uint8_t *buf, size_t len) {
if (!have_rdrand()) {
return 0;
}
Handle RDRAND failures. 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>
2015-06-19 19:06:28 +01:00
const size_t len_multiple8 = len & ~7;
if (!CRYPTO_rdrand_multiple8_buf(buf, len_multiple8)) {
return 0;
}
Handle RDRAND failures. 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>
2015-06-19 19:06:28 +01:00
len -= len_multiple8;
if (len != 0) {
assert(len < 8);
Handle RDRAND failures. 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>
2015-06-19 19:06:28 +01:00
uint8_t rand_buf[8];
if (!CRYPTO_rdrand(rand_buf)) {
return 0;
}
memcpy(buf + len_multiple8, rand_buf, len);
}
Handle RDRAND failures. 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>
2015-06-19 19:06:28 +01:00
return 1;
}
#else
int CRYPTO_hwrand(uint8_t *buf, size_t len) {
return 0;
}
#endif