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: Fri, 09 Sep 2022 11:31:45 +0100 Message-ID: <8F5A1DEE-E294-40EB-9ECE-6F20C21AF73C@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7621508285361742105==" List-Id: --===============7621508285361742105== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Just for reference: https://bugzilla.ipfire.org/show_bug.cgi?id=3D12900 This is the current status of the discussion. > On 9 Sep 2022, at 09:26, Paul Simmons wrote: >=20 > On 9/8/22 16:37, Robin Roevens wrote: >> Hi Michael >>=20 >> 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=3Dipfire-2.x.git;a=3Dblob;f=3Dconfig/rootfiles/oldc= ore/169/update.sh;h=3Ddc7a2a18abd65d464c862f5a71d6b1a85295865b;hb=3DHEAD#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, a= s similar as possible. This is never going to be 100% successful, but we can definitely delete files. -Michael >>=20 >>=20 >> Regards >> Robin >>=20 >> Michael Tremer schreef op do 08-09-2022 om 20:31 [+0100]: >>> Hello Robin, >>>=20 >>>> 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. >>>=20 >>>> 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 >>>> 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. >>>=20 >>> This AMD processor doesn=E2=80=99t have it. >>>=20 >>>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> So, the current status quo is that if /dev/hwrng exists, rngd should >>> be running. >>>=20 >>>> 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. >>>=20 >>> 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=E2=80=99t. So why risk using = it? >>>=20 >>> Problems could be either broken implementations or backdoored RNGs. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> All systems will always have the same quality of randomness. >>>=20 >>> Hope this helps. >>>=20 >>> -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 >>>=20 > I have an external RNG device that performs VERY well, and object to the re= moval of rng-tools. >=20 > Paul >=20 > --=20 > It's just a willerwont - it will, or it won't. -- H D Guenther --===============7621508285361742105==--