aboutsummaryrefslogtreecommitdiff
path: root/src/randomenv.cpp
AgeCommit message (Collapse)Author
2022-05-01tidy: add readability-redundant-declarationfanquake
2022-04-26Don't use zero as null pointer constant (-Wzero-as-null-pointer-constant)practicalswift
2021-12-30scripted-diff: Bump copyright headersHennadii Stepanov
-BEGIN VERIFY SCRIPT- ./contrib/devtools/copyright_header.py update ./ -END VERIFY SCRIPT- Commits of previous years: * 2020: fa0074e2d82928016a43ca408717154a1c70a4db * 2019: aaaaad6ac95b402fe18d019d67897ced6b316ee0
2021-09-24build: remove support for weak linking getauxval()fanquake
It was [pointed out in #23030](https://github.com/bitcoin/bitcoin/pull/23030#issuecomment-922893367) that we might be able to get rid of our weak linking of [`getauxval()`](https://man7.org/linux/man-pages/man3/getauxval.3.html) (`HAVE_WEAK_GETAUXVAL`) entirely, with only Android being a potential holdout: > I wonder if it's time to get rid of HAVE_WEAK_GETAUXVAL. I think it's confusing. Either we build against a C library that has this functionality, or not. We don't do this weak linking thing for any other symbols and recently got rid of the other glibc backwards compatibility stuff. > Unless there is still a current platform that really needs it (Android?), I'd prefer to remove it from the build system, it has caused enough issues. After looking at Android further, it would seem that given we are moving to using `std::filesystem`, which [requires NDK version 22 and later](https://github.com/android/ndk/wiki/Changelog-r22), and `getauxval` has been available in the since [API version 18](https://developer.android.com/ndk/guides/cpu-features#features_using_libcs_getauxval3), that shouldn't really be an issue. Support for API levels < 19 will be dropped with the NDK 24 release, and according to [one website](https://apilevels.com/), supporting API level 18+ will cover ~99% of devices. Note that in the CI we currently build with NDK version 22 and API level 28. The other change in this PR is removing the include of headers for ARM intrinsics, from the check for strong `getauxval()` support in configure, as they shouldn't be needed. Including these headers also meant that the check would basically only succeed when building for ARM. This would be an issue if we remove weak linking, as we wouldn't detect `getauxval()` as supported on other platforms. Note that we also use `getauxval()` in our RNG when it's available. I've checked that with these changes we detect support for strong `getauxval()` on Alpine (muslibc). On Linux, previously we'd be detecting support for weak getauxval(), now we detect strong support. Note that we already require glibc 2.17, and `getauxval()` was introduced in `2.16`. This is an alternative / supersedes #23030.
2021-03-29rand: only try and use freeifaddrs if availablefanquake
2020-12-08util: Allow use of C++14 chrono literalsMarcoFalke
2020-11-09src/randomenv.cpp: fix build on uclibcFabrice Fontaine
Check for HAVE_STRONG_GETAUXVAL or HAVE_WEAK_GETAUXVAL before using getauxval to avoid a build failure on uclibc Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
2020-10-07random: fixes read buffer resizing in RandAddSeedPerfmonEthan Heilman
+ Replaces std::max with std::min to resize buffer in RandAddSeedPerfmon + Documents behavior of RandAddSeedPerfmon
2020-04-16scripted-diff: Bump copyright headersMarcoFalke
-BEGIN VERIFY SCRIPT- ./contrib/devtools/copyright_header.py update ./ -END VERIFY SCRIPT-
2020-02-28Drop unused mach time headersBen Woosley
Now that we're no longer special-casing clock usage for MacOS, we're not referencing anything defined in these headers.
2020-02-06random: don't special case clock usage on macOSfanquake
clock_gettime(), CLOCK_MONOTONIC and CLOCK_REALTIME are all available for use on macOS (now that we require macOS >=10.12). Use them rather than the deprecated mach_timespec_t time API. master: 2019-12-23T20:49:43Z Feeding 216 bytes of dynamic environment data into RNG 2019-12-23T20:50:43Z Feeding 216 bytes of dynamic environment data into RNG this commit: 2019-12-23T20:32:41Z Feeding 232 bytes of dynamic environment data into RNG 2019-12-23T20:33:42Z Feeding 232 bytes of dynamic environment data into RNG
2019-11-20Put bounds on the number of CPUID leaves exploredPieter Wuille
2019-11-19Fix CPUID subleaf iterationPieter Wuille
2019-11-18random: stop retrieving random bytes from OpenSSLfanquake
On the ::SLOW path we would use OpenSSL as an additional source of random bytes. This commit removes that functionality. Note that this was always only an additional source, and that we never checked the return value RAND_bytes(): https://www.openssl.org/docs/manmaster/man3/RAND_bytes.html RAND_bytes() puts num cryptographically strong pseudo-random bytes into buf.
2019-11-12Use thread-safe atomic in perfmon seederPieter Wuille
Also switch to chrono based types.
2019-11-12Add information gathered through getauxval()Pieter Wuille
Suggested by Wladimir van der Laan.
2019-11-12Feed CPUID data into RNGPieter Wuille
2019-11-12Use sysctl for seeding on MacOS/BSDPieter Wuille
2019-11-12Gather additional entropy from the environmentPieter Wuille
This based on code by Gregory Maxwell.
2019-11-12Seed randomness with process id / thread id / various clocksPieter Wuille
This sort of data is also used by OpenSSL.
2019-11-12[MOVEONLY] Move perfmon data gathering to new randomenv modulePieter Wuille