Just for reference: https://bugzilla.ipfire.org/show_bug.cgi?id=12900 This is the current status of the discussion. > On 9 Sep 2022, at 09:26, Paul Simmons wrote: > > 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 ? We just rm them in the updater. Like this: https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=config/rootfiles/oldcore/169/update.sh;h=dc7a2a18abd65d464c862f5a71d6b1a85295865b;hb=HEAD#l89 >> 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. Ideally we want to keep all systems, whether freshly installed or upgraded, as similar as possible. This is never going to be 100% successful, but we can definitely delete files. -Michael >> >> >> 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