From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: question about checking for HW RNG support on apu4 appliance Date: Thu, 08 Sep 2022 20:31:59 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7069373268760496150==" List-Id: --===============7069373268760496150== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Robin, > On 8 Sep 2022, at 20:16, Robin Roevens wrote: >=20 > Hi all >=20 > 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. >=20 > 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.=20 >=20 > 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.=20 This is for an extended instruction set which was invented by Intel. This AMD processor doesn=E2=80=99t 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 ther= e, does not mean that it is being used. Then, there are other devices which usually emulate a character device that i= s to be found at /dev/hwrng. rngd has (had - see below) the job to copy any e= ntropy from that device into the kernel. So, the current status quo is that if /dev/hwrng exists, rngd should be runni= ng. > 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. Man= y systems do not have very good sources if any at all. How can we tell if a s= ource is good? We can=E2=80=99t. 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 happ= ens 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 fr= om 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 nee= ded based on that pool. The result will be mixed into the pool again and occa= sionally 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 t= hat 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 >=20 > Thanks >=20 > Robin >=20 > --=20 > Dit bericht is gescanned op virussen en andere gevaarlijke > inhoud door MailScanner en lijkt schoon te zijn. >=20 --===============7069373268760496150==--