question about checking for HW RNG support on apu4 appliance

question about checking for HW RNG support on apu4 appliance

[Robin Roevens]

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

Hi all

If I understand it correctly, when HW RNG is supported, the Random
Number Generator Daemon (rngd) should be running ?

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

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?

Thanks

Robin

-- 
Dit bericht is gescanned op virussen en andere gevaarlijke
inhoud door MailScanner en lijkt schoon te zijn.

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

[Michael Tremer]

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

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

[Robin Roevens]

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

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

[Robin Roevens]

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

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

-- 
Dit bericht is gescanned op virussen en andere gevaarlijke
inhoud door MailScanner en lijkt schoon te zijn.

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

[Paul Simmons]

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

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

[Michael Tremer]

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

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

[Robin Roevens]

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

Hi

Michael Tremer schreef op vr 09-09-2022 om 11:31 [+0100]:
> Just for reference: https://bugzilla.ipfire.org/show_bug.cgi?id=12900
> 
> This is the current status of the discussion.

I see.. in that case I will leave it to professionals to figure out if
it is still needed :-)

> 
> > 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=dc7a2a18abd
> 65d464c862f5a71d6b1a85295865b;hb=HEAD#l89

Good to know for possible future work then. Thanks

Regards
Robin

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

-- 
Dit bericht is gescanned op virussen en andere gevaarlijke
inhoud door MailScanner en lijkt schoon te zijn.