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

[Michael Tremer <michael.tremer@ipfire.org>]

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

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.
>