<div dir="ltr"><div>I'd be interested to know what kernel you were using on the Centos 7 machine - I think they only went up to something like 3.1.</div><div><br></div><div>I haven't gone digging into the current Linux behaviours in details for ages; but broadly speaking, the Linux kernel no longer operates the same way that it used to. Both /dev/random and /dev/urandom are operating from a CSPRNG, and there is a much reduced need for any external entropy after seeding has taken place; so much reduced that simple internal measurements of CPU jitter are more than sufficient to keep the system operating securely. The "entropy pool" is now only meaningfully measurable during initial boot, and even there it's going to be filled enough to start the system well before userland comes up.<br></div><div><br></div><div>So I expect your key is working just fine, sending data to rngd; and rngd is writing into /dev/random like it used to do - but the kernel is ignoring it, and the measurement you used to rely on is no longer meaningful. Much of the information published (& indexed) on the Internet still seems to be out-of-date, as the Arch documentation mentions: <a href="https://wiki.archlinux.org/title/Random_number_generation">https://wiki.archlinux.org/title/Random_number_generation</a></div><div><br></div><div>I'm pretty sure that this means hardware like OneRNG are no longer useful from a systems administration perspective.<br></div><div><div><br></div><div>-jim<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 13, 2024 at 11:35 PM Tom Yates <<a href="mailto:madhatter@teaparty.net">madhatter@teaparty.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I've got a D12 system, kernel 6.1.0-18, with an attached OneRNG. As far <br>
as I can tell, the OneRNG isn't filling up the entropy pool: cat<br>
/proc/sys/kernel/random/entropy_avail always returns 256 .<br>
<br>
The OneRNG is inside the system case, on a USB cable, and the case is in a <br>
colo about 50 miles away, so it's difficult for me to see the LED. But <br>
when the system is rebooted, onerng.sh starts up just fine; I see it in <br>
the process table:<br>
<br>
root 1215 0.0 0.0 2576 892 ? S 09:14 0:00 /bin/sh /sbin/onerng.sh feeder ttyACM0<br>
<br>
I see it sleep for 5 seconds:<br>
<br>
root 8033 0.0 0.0 2484 928 ? S 09:34 0:00 sleep 5<br>
<br>
then fire up and send a bunch of entropy to /dev/random via dd:<br>
<br>
root 8069 16.6 0.0 2532 924 ? R 09:34 0:00 dd if=/dev/ttyACM0 of=/dev/random bs=128 count=200<br>
<br>
at which point it goes back to sleep for 5 seconds. strace-ing the <br>
process shows the same pattern of events, which I think is what's expected <br>
of it.<br>
<br>
Just in case, I also read notes referred to in an earlier post on this <br>
list [1], manually killed the onerng.sh script, and manually started rngd <br>
with the appropriate flags:<br>
<br>
root@lory:~# rngd -r /dev/ttyACM0 -f<br>
rngd 2.2 starting up...<br>
entropy feed to the kernel ready<br>
<br>
but still, the entropy pool remains stubbornly 256 bytes deep. If I add <br>
"-S 60" to the daemon's flags, it logs once a minute along these lines:<br>
<br>
stats: bits received from HRNG source: 60064<br>
stats: bits sent to kernel pool: 7680<br>
stats: entropy added to kernel pool: 7680<br>
stats: FIPS 140-2 successes: 3<br>
stats: FIPS 140-2 failures: 0<br>
stats: FIPS 140-2(2001-10-10) Monobit: 0<br>
stats: FIPS 140-2(2001-10-10) Poker: 0<br>
stats: FIPS 140-2(2001-10-10) Runs: 0<br>
stats: FIPS 140-2(2001-10-10) Long run: 0<br>
stats: FIPS 140-2(2001-10-10) Continuous run: 0<br>
stats: HRNG source speed: (min=2.129; avg=3.330; max=5.304)Mibits/s<br>
stats: FIPS tests speed: (min=23.147; avg=40.524; max=66.925)Mibits/s<br>
stats: Lowest ready-buffers level: 2<br>
stats: Entropy starvations: 0<br>
stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us<br>
<br>
so it, too, seems to be getting entropy from the OneRNG and feeding it to <br>
the kernel, but again to no avail.<br>
<br>
I suppose it's possible that this system has enormous drains on its <br>
entropy pool, but it didn't have them last week (when it was running <br>
CentOS 7, also with the OneRNG inside) and the duty-cycle hasn't changed <br>
much.<br>
<br>
Does anyone have any thoughts about either (a) ways to hunt down an <br>
entropy sink, or (b) why my kernel seems to be ignoring entropy added to <br>
the pool?<br>
<br>
<br>
-- <br>
<br>
Tom Yates - <a href="https://www.teaparty.net" rel="noreferrer" target="_blank">https://www.teaparty.net</a><br>
<br>
<br>
[1] <a href="https://github.com/denis-beurive/onerng-notes?tab=readme-ov-file" rel="noreferrer" target="_blank">https://github.com/denis-beurive/onerng-notes?tab=readme-ov-file</a><br>
<br>
_______________________________________________<br>
Discuss mailing list<br>
<a href="mailto:Discuss@lists.onerng.info" target="_blank">Discuss@lists.onerng.info</a><br>
<a href="https://lists.ourshack.com/mailman/listinfo/discuss" rel="noreferrer" target="_blank">https://lists.ourshack.com/mailman/listinfo/discuss</a><br>
</blockquote></div>