From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robin Roevens To: development@lists.ipfire.org Subject: Re: question about checking for HW RNG support on apu4 appliance Date: Thu, 08 Sep 2022 23:37:42 +0200 Message-ID: <80348ce0e9da00045c74819916061e85d0aa75a9.camel@sicho.home> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5662668188724751350==" List-Id: --===============5662668188724751350== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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. > > > > -- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn. --===============5662668188724751350==--