Re: question about checking for HW RNG support on apu4 appliance

[Robin Roevens <robin.roevens@disroot.org>]

[-- Attachment #1: Type: text/plain, Size: 3844 bytes --]

Hi Michael

Thanks for the clear explanation. I will remove the hw rng support and
rngd state checks from my template as those are then indeed quite
useless now.

Robin

Michael Tremer schreef op do 08-09-2022 om 20:31 [+0100]:
> Hello Robin,
> 
> > On 8 Sep 2022, at 20:16, Robin Roevens <robin.roevens(a)disroot.org>
> > 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.