[PATCH] random.c: add SP800-90B RCT/APT health tests before crediting sources
From: Robert Viragh
Date: Wed Sep 16 2026 - 17:14:16 EST
Hi Jason and maintainer team,
I'm very impressed with random.c, it is a huge and clever application of ChaCha20 with rekeying. I was reading it to see if there are failure modes from hardware errors. (I wanted to know if entropy sources that were stuck high such as due to a wiring fault could cause an infinite loop freeze if non-dyadic (not a power of two denominator) random value ranges are chosen, since the usual algorithm rejects the excess, for example if one of three values are needed with uniform randomness then it could read two bits, assign 00, 01, and 10 to the three values and discard 11 and try again - so getting stuck on 11 could freeze a system.)
I'm very impressed with random.c, it is a huge and clever application of ChaCha20 with rekeying. I was reading it to see if there are failure modes from hardware errors. (I wanted to know if entropy sources that were stuck high such as due to a wiring fault could cause an infinite loop freeze if non-dyadic (not a power of two denominator) random value ranges are chosen, since the usual algorithm rejects the excess, for example if one of three values are needed with uniform randomness then it could read two bits, assign 00, 01, and 10 to the three values and discard 11 and try again - so getting stuck on 11 could freeze a system.)
Along the way I learned that there are some NIST recommendations for testing against just such problems (stuck entropy sources), these are here:
under Health Tests in Section 4 starting on page 22 of the document (page 30 of the PDF file.), the reasoning/discussion is provided on page 6 under General Discussion.
These seem like really good recommendations.
I asked Grok to take a shot at proposing the changes, it produced the attached patch. I asked it to try to encapsulate this guard behavior correctly (so it doesn't repeat the code) and while respecting the layout and architecture of the code. I've read the diff and it seems to make sense, it has also run some tests on it, but since this code is also used in high security applications, I would submit it for a review process to see if it is correct. I don't know the details of the IRQ and other entropy sources.
I think it would be nice to add this compliance with SP 800-90B which is a thoughtful and good standard, though I don't know if it would really guard code that much. It's hard to see how these tests could ever fail, since there are so many entropy sources in the pool. But if they did fail, I guess people would want to know!
Let me know what you think, and I hope you will consider carefully reviewing and potentially adding the code below or a version of it.
Grok's notes are below.
Robert Viragh
Grok's notes:
This adds SP800-90B 4.3-4.4 startup (1024-sample discard) and continuous
RCT/APT on the raw symbols of credited sources only:
add_interrupt_randomness
add_timer_randomness (input + disk)
add_hwgenerator_randomness
Not on add_device_randomness / add_vmfork_randomness / bootloader seed.
A failed source is still mixed, but not credited. Other sources still
credit. getrandom(2) is unchanged.
Helper was unit-tested in userspace (startup discard, RCT C=31, APT
C=325, no credit after fail). Not booted in a kernel.
add_interrupt_randomness
add_timer_randomness (input + disk)
add_hwgenerator_randomness
Not on add_device_randomness / add_vmfork_randomness / bootloader seed.
A failed source is still mixed, but not credited. Other sources still
credit. getrandom(2) is unchanged.
Helper was unit-tested in userspace (startup discard, RCT C=31, APT
C=325, no credit after fail). Not booted in a kernel.
Attachment:
0001-random-add-SP800-90B-RCT-APT-health-tests.patch
Description: Binary data