Do not condition CRYPTO_is_RDRAND_capable on __RDRND__
On some AMD processors, we will act as if the hardware is
RDRAND-incapable, even it actually supports it, to workaround some bugs
where their RDRAND would return all ones. However, this works by
clearing the RDRAND bit, and the static capability check bypasses this.
That means, when compiling binaries for an RDRAND-capable baseline CPU,
we might end up disabling the workaround. Thanks to Brian Smith for
noticing this.
Fortunately, we believe this had no real impact and the workaround was
actually redundant with other parts of our PRNG logic. See
https://crbug.com/boringssl/675#c2 for a more detailed analysis.
Fixed: 675
Change-Id: I91d844cfaafb22eb29254f81fb6719588937a4a8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65267
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
diff --git a/crypto/internal.h b/crypto/internal.h
index e9da010..3164711 100644
--- a/crypto/internal.h
+++ b/crypto/internal.h
@@ -1407,13 +1407,10 @@
}
OPENSSL_INLINE int CRYPTO_is_RDRAND_capable(void) {
- // The GCC/Clang feature name and preprocessor symbol for RDRAND are "rdrnd"
- // and |__RDRND__|, respectively.
-#if defined(__RDRND__)
- return 1;
-#else
+ // We intentionally do not check |__RDRND__| here. On some AMD processors, we
+ // will act as if the hardware is RDRAND-incapable, even it actually supports
+ // it. See cpu_intel.c.
return (OPENSSL_get_ia32cap(1) & (1u << 30)) != 0;
-#endif
}
// See Intel manual, volume 2A, table 3-8.
