This introduces support for autodetecting and using the RdSeed instruction on x86/x86_64 systems.
In addition:
random.cpp: isn’t the std::move on L562 without any effect? Could be removed?
MixExtract intentionally takes an rvalue reference, so that callers must either pass in a temporary, or use std::move explicitly (as the hasher object becomes useless after the call).
132+#ifdef __i386__
133+ uint32_t r1, r2;
134+ __asm__ volatile (".byte 0x0f, 0xc7, 0xf0, 0x0f, 0xc7, 0xf2; setc %2" : "=a"(r1), "=d"(r2), "=q"(ok) :: "cc"); // rdrand %eax; rdrand %edx
135+ assert(ok);
136+ return (((uint64_t)r2) << 32) | r1;
137+#else
223+ uint64_t out1 = GetRdRand(), out2 = GetRdRand(), out3 = GetRdRand(), out4 = GetRdRand();
224+ WriteLE64(ent32, out1);
225+ WriteLE64(ent32 + 8, out2);
226+ WriteLE64(ent32 + 16, out3);
227+ WriteLE64(ent32 + 24, out4);
228 return true;
Maybe we should ignore it for the less critical runtime use, but pedantically:
“After invoking the RDRAND instruction, the caller must examine the carry flag (CF) to determine whether a random value was available at the time the RDRAND instruction was executed. As Table 3 shows, a value of 1 indicates that a random value was available and placed in the destination register provided in the invocation. A value of 0 indicates that a random value was not available. In current architectures the destination register will also be zeroed as a side effect of this condition.” … “It is recommended that applications attempt 10 retries in a tight loop in the unlikely event that the RDRAND instruction does not return a random number. This number is based on a binomial probability argument: given the design margins of the DRNG, the odds of ten failures in a row are astronomically small and would in fact be an indication of a larger CPU issue.”
This one might also want to consider:
“There are two approaches to structuring RDRAND invocations such that DRBG reseeding can be guaranteed:
Iteratively execute RDRAND beyond the DRBG upper bound by executing more than 1022 64-bit RDRANDs"215+ uint64_t out1 = GetRdSeed(), out2 = GetRdSeed(), out3 = GetRdSeed(), out4 = GetRdSeed();
216+ WriteLE64(ent32, out1);
217+ WriteLE64(ent32 + 8, out2);
218+ WriteLE64(ent32 + 16, out3);
219+ WriteLE64(ent32 + 24, out4);
220+ return true;
“After invoking the RDSEED instruction, the caller must examine the carry flag (CF) to determine whether a random seed was available at the time the RDSEED instruction was executed. As shown in Table 5, a value of 1 indicates that a random seed was available and placed in the destination register provided in the invocation.” “Unlike the RDRAND instruction, the seed values come directly from the entropy conditioner, and it is possible for callers to invoke RDSEED faster than those values are generated. This means that applications must be designed robustly and be prepared for calls to RDSEED to fail because seeds are not available (CF=0).
If only one thread is calling RDSEED infrequently, it is very unlikely that a random seed will not be available. Only during periods of heavy demand, such as when one thread is calling RDSEED in rapid succession or multiple threads are calling RDSEED simultaneously, are underflows likely to occur. Because the RDSEED instruction does not have a fairness mechanism built into it, however, there are no guarantees as to how often a thread should retry the instruction, or how many retries might be needed, in order to obtain a random seed. In practice, this depends on the number of hardware threads on the CPU and how aggressively they are calling RDSEED.” “5.3.1.1 Synchronous applications
If the application is not latency-sensitive, then it can simply retry the RDSEED instruction indefinitely, though it is recommended that a PAUSE instruction be placed in the retry loop. In the worst-case scenario, where multiple threads are invoking RDSEED continually, the delays can be long, but the longer the delay, the more likely (with an exponentially increasing probability) that the instruction will return a result.”
87+static void inline GetCPUID(uint32_t leaf, uint32_t subleaf, uint32_t& a, uint32_t& b, uint32_t& c, uint32_t& d)
88+{
89+#ifdef __GNUC__
90+ __cpuid_count(leaf, subleaf, a, b, c, d);
91+#else
92+ __asm__ ("cpuid" : "=a"(a), "=b"(b), "=c"(c), "=d"(d) : "0"(leaf), "2"(subleaf));
82+static bool g_rdrand_supported = false;
83+static bool g_rdseed_supported = false;
84 static constexpr uint32_t CPUID_F1_ECX_RDRAND = 0x40000000;
85+static constexpr uint32_t CPUID_F7_EBX_RDSEED = 0x00040000;
86+
87+static void inline GetCPUID(uint32_t leaf, uint32_t subleaf, uint32_t& a, uint32_t& b, uint32_t& c, uint32_t& d)
Maybe I’m mistaken, but I think we can use __get_cpuid here, e.g.:
https://github.com/linuxkit/linuxkit/blob/c5b3f24de6ba2238c5465025960f16920a731124/pkg/rngd/cmd/rngd/rng_linux_amd64.go#L11-L23
If not, how about a comment ala, or extracting a common method: https://github.com/bitcoin/bitcoin/blob/4d661baf1aca4226d1c4ec89fe7e44c1f93f04da/src/crypto/sha256.cpp#L552
77@@ -78,25 +78,112 @@ static inline int64_t GetPerformanceCounter() noexcept
78 }
79
80 #if defined(__x86_64__) || defined(__amd64__) || defined(__i386__)
81-static bool rdrand_supported = false;
82+static bool g_rdrand_supported = false;
83+static bool g_rdseed_supported = false;
84 static constexpr uint32_t CPUID_F1_ECX_RDRAND = 0x40000000;
85+static constexpr uint32_t CPUID_F7_EBX_RDSEED = 0x00040000;
static_assert against cpuid.h’s definition of bit_RDRND, bit_RDSEED if available?
102+ if (ecx & CPUID_F1_ECX_RDRAND) {
103+ g_rdrand_supported = true;
104+ GetCPUID(7, 0, eax, ebx, ecx, edx);
105+ if (ebx & CPUID_F7_EBX_RDSEED) {
106+ g_rdseed_supported = true;
107+ }
244+ }
245+ return true;
246+ }
247+ // When falling back to RdRand, XOR the result of 1024 results.
248+ // This guarantees a reseeding occurs between each.
249+ if (g_rdrand_supported) {
g_rdseed_supported case is, given the dependent detection logic. else if?
138+ }
139+ for (int i = 0; i < 10; ++i) {
140+ __asm__ volatile (".byte 0x0f, 0xc7, 0xf0; setc %1" : "=a"(r2), "=q"(ok) :: "cc"); // rdrand %eax
141+ if (ok) break;
142+ }
143+ return (((uint64_t)r2) << 32) | r1;
If you put two 64-bit values with additive prediction resistance togehter, the prediction resistance of the resulting value is only 65 bits (264 + 264 = 265). https://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdrand-and-rdseed
Assume this is addressed via the XOR rounds?
231+ }
232 #endif
233+ return false;
234+}
235+
236+static bool SeedHardwareSlow(CSHA512& hasher) noexcept {
bool that no one reacts to. Drop or log?
bool then please consider NODISCARD.
193@@ -107,36 +194,36 @@ static void InitHardwareRand() {}
194 static void ReportHardwareRand() {}
195 #endif
196
197-static bool GetHardwareRand(unsigned char* ent32) noexcept {
198+static bool SeedHardwareFast(CSHA512& hasher) noexcept {
bool that no one reacts to. Drop or log?
bool then please consider NODISCARD.
bool is gone.
This introduces support for autodetecting and using the RdSeed instruction.
In addition:
* In SeedFast, only 64 bits of entropy are generated through RdRand (256 was relatively slow).
* In SeedStartup, 256 bits of entropy are generated, using RdSeed (preferably) or RdRand (otherwise).
RDRAND or RDSEED instruction to generate vulberable private keys?
@laanwj Not trivially, at least. The output of the rdrand/rdseed is mixed with other entropy using SHA512 to produce output and the new state.
In theory a backdoored CPU could try to infer what variable is going to store entropy, and try to control that directly.
Thanks!
In theory a backdoored CPU could try to infer what variable is going to store entropy, and try to control that directly.
Sure—I meant when say, only those instructions were made to return a fixed value, not anything more advanced/complex. Like a bugdoor with plausible deniability.
/proc/cpuinfo will show the rdrand and/or rdseed under flags)
ACK 1435fab on macOS x86_64 on Intel Core i7-7920HQ CPU @ 3.10GHz (has RDRAND & RDSEED).
2019-02-13T19:22:30Z Using the 'sse4(1way),sse41(4way),avx2(8way)' SHA256 implementation2019-02-13T19:22:30Z Using RdSeed as additional entropy source2019-02-13T19:22:30Z Using RdRand as an additional entropy source
Functional and unit tests pass.
bitcoind runs fine, and reports only “Using RdRand as an additional entropy source”.
@laanwj To expand on Pieter’s response. Our mixing construction is designed to be secure against adversarial inputs generated by an attacker that can also inspect the entire process state unless the attacker can attack SHA512 in a very serious way (e.g. construct a suffix to a message being hashed that causes a specific hash value).
There are various standards for combining entropy sources that just xor the sources. The construction we’re using is obviously stronger than those. If we had just xored the state then a malicious rdrand could inspect and return the current state (perhaps xored with a constant) in order to override it, and even plausibly do so as a bugdoor (e.g. oops we accidentally failed to update the register). I just mention this to point out that what we’re doing is stronger than something other people think is acceptable…
Linux debian 4.9.0-8-686-pae [#1](/bitcoin-bitcoin/1/) SMP Debian 4.9.130-2 (2018-10-27) i686 GNU/Linux
2019-02-14T21:30:29Z Using RdSeed as additional entropy source
2019-02-14T21:30:29Z Using RdRand as an additional entropy source
Labels
Utils/log/libs
Milestone
0.18.0