On 9/8/22 16:37, Robin Roevens wrote: > Hi Michael > > I was quickly looking into possibly submitting a patch for removing > rngd from IPFire; and I figured I could remove the rng-tools package, > initscript, udev rules etc.. from the source. But I wondered, do we > handle actually removing those files from the system during an update? > And if so, where/how do we do that ? > as keeping it installed on systems would possibly do more harm (with > crappy hwgenerator) than good, would never be updated anymore and could > possibly break on a future update. > > > Regards > Robin > > Michael Tremer schreef op do 08-09-2022 om 20:31 [+0100]: >> Hello Robin, >> >>> On 8 Sep 2022, at 20:16, Robin Roevens >>> wrote: >>> >>> Hi all >>> >>> If I understand it correctly, when HW RNG is supported, the Random >>> Number Generator Daemon (rngd) should be running ? >> No, not quite. >> >>> So in my Zabbix monitoring template for IPFire, I try to check if >>> HW >>> RNG is available and if so, I monitor the state of the rngd daemon. >>> >>> Previously I had no HW RNG support on the apu4 appliance until a >>> few >>> core updates ago where this was introduced with a firmware update. >>> So >>> now the rngd daemon is automatically started on the appliance. >>> >>> To know if HW RNG is supported, I currently check the contents of >>> /proc/cpuinfo for the occurrence of the string "rdrand" (which >>> seems a >>> correct check on x86_64 machines) but this string was and still is >>> not >>> present on the apu4 appliance. >> This is for an extended instruction set which was invented by Intel. >> >> This AMD processor doesn’t have it. >> >>> So I was wondering if anyone knows how to correctly check if HW RNG >>> support is available? So that this check works for all platforms. >> This is very hard - if possible at all. >> >> There are different kinds of sources for randomness. The first one is >> RDRAND as you pointed out and it is a processor instruction. Just >> because it is there, does not mean that it is being used. >> >> Then, there are other devices which usually emulate a character >> device that is to be found at /dev/hwrng. rngd has (had - see below) >> the job to copy any entropy from that device into the kernel. >> >> So, the current status quo is that if /dev/hwrng exists, rngd should >> be running. >> >>> Sidenote: This information (HW RNG support / rndg daemon state) was >>> previously also available on the entropy page of the IPFire GUI, >>> but it >>> seems this info is now gone together with the now obsolete entropy >>> graph. Was this intentional ? I assume that information is still >>> relevant even when with the entropy value gone? >> No, it is pretty much entirely irrelevant now. Even rngd is. >> >> The reason is that it has been changed how the kernel deals with >> entropy. Many systems do not have very good sources if any at all. >> How can we tell if a source is good? We can’t. So why risk using it? >> >> Problems could be either broken implementations or backdoored RNGs. >> >> So, the kernel is now seeding its pool of randomness once it boots. >> That happens with RDRAND or RDSEED if available, or with any other HW >> RNG and is being mixed together if there are multiple sources. >> Further sources are entropy from disk latency, keyboard strokes and >> so on. On servers, these are generally problematic sources. >> >> The kernel will then use Blake2 and ChaCha20 to generate random data >> when needed based on that pool. The result will be mixed into the >> pool again and occasionally it is being reseeded automatically in the >> same way it was initially seeded. >> >> So, I personally would prefer for us to drop rngd and just trust the >> kernel that it does its job right. This way seems to be the most >> sensical and allows us to ignore any dependencies on (crappy) HW >> RNGs. >> >> All systems will always have the same quality of randomness. >> >> Hope this helps. >> >> -Michael >> >>> Thanks >>> >>> Robin >>> >>> -- >>> Dit bericht is gescanned op virussen en andere gevaarlijke >>> inhoud door MailScanner en lijkt schoon te zijn. >>> >> I have an external RNG device that performs VERY well, and object to the removal of rng-tools. Paul -- It's just a willerwont - it will, or it won't. -- H D Guenther