Remove support for RNDR/RNDRRS for aarch64 #32248

1. 
   laanwj commented at 6:17 am on April 11, 2025: member

   This hardware feature is

   • Rarely supported on SoCs (and broken on like half of the chips that support it in the first place) (#31817). It is not clear if, or how, the brokenness will be worked around in the kernel, but working around it in user space seems the wrong thing to do, this is not the place to maintain special workarounds for specific hardware (which despite that, was attempted in #31826, but had to be reverted in #31908 due to other problems).
   • Apparently not compiled into the release binary anymore (https://github.com/bitcoin/bitcoin/issues/31817#issuecomment-2795885962). Did check this at the time, but a build system change must have caused this, and went undetected.
   • Hard to test in CI (as well as manually), due to unavailability of hardware.

   Better to remove it.

   This reverts commit aee5404e02e203a256c1a97b629b9b107cc8bb07 from #26839.

   Closes #31817.

2. Remove support for RNDR/RNDRRS for aarch64 on Linux

   This hardware feature is
   
   - rarely supported on SoCs (and broken on like half of the chips that support it in the first place) (#31817)
   - apparently not compiled into the release binary (https://github.com/bitcoin/bitcoin/issues/31817#issuecomment-2795885962)
   - hard to test in CI, due to unavailable of hardware
   
   Better to remove it.
   
   This reverts commit aee5404e02e203a256c1a97b629b9b107cc8bb07.
   
   Closes #31817.

   7749d929a0
3. laanwj added the label Linux/Unix on Apr 11, 2025
4. laanwj added the label Utils/log/libs on Apr 11, 2025
5. 
   DrahtBot commented at 6:17 am on April 11, 2025: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Code Coverage & Benchmarks

   For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/32248.

   Reviews

   See the guideline for information on the review process.

   Type	Reviewers
   ACK	sipa, davidgumberg
   Concept ACK	hugohn, theStack

   If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

   Conflicts

   Reviewers, this pull request conflicts with the following ones:

   • #29641 (scripted-diff: Use LogInfo over LogPrintf [WIP, NOMERGE, DRAFT] by maflcko)

   If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

6. laanwj added the label Needs backport (29.x) on Apr 11, 2025
7. laanwj renamed this:
   Remove support for RNDR/RNDRRS for aarch64 on Linux
   Remove support for RNDR/RNDRRS for aarch64
   on Apr 11, 2025
8. 
   hugohn commented at 7:10 am on April 11, 2025: contributor

   ACK
9. 
   sipa commented at 11:47 am on April 11, 2025: member

   utACK 7749d929a0d9dfe71541a22e557ea41e01df28ce
10. 
    theStack commented at 7:15 pm on April 15, 2025: contributor

    Concept ACK
11. 
    davidgumberg commented at 0:57 am on April 16, 2025: contributor

    utACK https://github.com/bitcoin/bitcoin/commit/7749d929a0d9dfe71541a22e557ea41e01df28ce

    There are other sources of entropy in SeedStartup which is SeedHardwareSlow’s only caller.

    Without SeedHardwareFast() doing anything, the only remaining source of entropy in SeedFast is the timestamp, but this seems okay to me, since two of SeedFast’s users, SeedSlow and SeedPeriodic, have other entropy sources.

    The other place SeedFast() gets called is when ProcRand() is invoked with RNGLevel::Fast, the two places I see where that happens is in RandomInit()(only used by kernel and the wallet tool) and GetRandBytes(). GetRandBytes() is a little bit more all over the code base, but from what I can tell, nothing that uses it needs more entropy than the timestamp.

12. DrahtBot requested review from theStack on Apr 16, 2025
13. 
    laanwj commented at 3:03 am on April 16, 2025: member

    but from what I can tell, nothing that uses it needs more entropy than the timestamp.

    i wouldn’t say this is the ideal situation, clearly adding hardware randomness when available (and safe to use) is preferable, it’s just that it’s not, here.

14. maflcko added the label DrahtBot Guix build requested on Apr 16, 2025

Contributors
laanwj DrahtBot hugohn sipa theStack davidgumberg

Review Requested
theStack

Labels
Linux/Unix Utils/log/libs DrahtBot Guix build requested Needs backport (29.x)