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

[Paul Simmons <mbatranch@gmail.com>]

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

On 9/8/22 16:37, Robin Roevens wrote:
> 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 <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.
>>>
>>
I have an external RNG device that performs VERY well, and object to the 
removal of rng-tools.

Paul

-- 
It's just a willerwont - it will, or it won't. -- H D Guenther