Commit Graph

5 Commits

Author SHA1 Message Date
Adam Langley
d75545600d Merge hwrand.c into rand.c.
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>
2015-09-25 22:07:42 +00:00
David Benjamin
b8a6c9e1e9 Fix CRYPTO_hwrand comment.
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>
2015-08-07 16:10:41 +00:00
David Benjamin
1be2ec6756 Fold CRYPTO_hwrand and CRYPTO_have_hwrand together.
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>
2015-08-07 02:02:24 +00:00
Adam Langley
2cac3506fa 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-23 20:56:33 +00:00
Adam Langley
310d4dd6b6 rand: new-style locking and support rdrand.
Pure /dev/urandom, no buffering (previous behaviour):
Did 2320000 RNG (16 bytes) operations in 3000082us (773312.2 ops/sec): 12.4 MB/s
Did 209000 RNG (256 bytes) operations in 3011984us (69389.5 ops/sec): 17.8 MB/s
Did 6851 RNG (8192 bytes) operations in 3052027us (2244.7 ops/sec): 18.4 MB/s

Pure rdrand speed:
Did 34930500 RNG (16 bytes) operations in 3000021us (11643418.5 ops/sec): 186.3 MB/s
Did 2444000 RNG (256 bytes) operations in 3000164us (814622.1 ops/sec): 208.5 MB/s
Did 80000 RNG (8192 bytes) operations in 3020968us (26481.6 ops/sec): 216.9 MB/s

rdrand + ChaCha (as in this change):
Did 19498000 RNG (16 bytes) operations in 3000086us (6499147.0 ops/sec): 104.0 MB/s
Did 1964000 RNG (256 bytes) operations in 3000566us (654543.2 ops/sec): 167.6 MB/s
Did 62000 RNG (8192 bytes) operations in 3034090us (20434.5 ops/sec): 167.4 MB/s

Change-Id: Ie17045650cfe75858e4498ac28dbc4dcf8338376
Reviewed-on: https://boringssl-review.googlesource.com/4328
Reviewed-by: Adam Langley <agl@google.com>
2015-04-14 20:13:42 +00:00