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

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

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

Just for reference: https://bugzilla.ipfire.org/show_bug.cgi?id=12900

This is the current status of the discussion.

> On 9 Sep 2022, at 09:26, Paul Simmons <mbatranch(a)gmail.com> wrote:
> 
> 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 ?

We just rm them in the updater. Like this:

https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=config/rootfiles/oldcore/169/update.sh;h=dc7a2a18abd65d464c862f5a71d6b1a85295865b;hb=HEAD#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, as similar as possible.

This is never going to be 100% successful, but we can definitely delete files.

-Michael

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