Bug 12893 - CU169 Testing - Entropy shown very low after core update
Summary: CU169 Testing - Entropy shown very low after core update
Status: CLOSED FIXED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: all All
: Will affect all users Aesthetic Issue
Assignee: Peter Müller
QA Contact:
URL:
Keywords: 5MinuteJob
Depends on:
Blocks:
 
Reported: 2022-06-29 13:36 UTC by ChrisK
Modified: 2022-07-12 10:39 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ChrisK 2022-06-29 13:36:48 UTC
After updating to Core 169 Testing, the show system entropy is very low. Since this happens for a number of users idependently of different systems, it's possible a bug related to the core update process.

See https://community.ipfire.org/t/core-169-entropy-query/8157 for details.
Comment 1 A G 2022-06-29 13:48:17 UTC
Same issues as discribed in the thread https://community.ipfire.org/t/core-169-entropy-query/8157

Everyone appears to have 256bit as the top limit as far as I can tell from the graphs people have posted.
Comment 2 ChrisK 2022-06-29 14:10:47 UTC
It's not just a display but as reading the proc variable also output such a low value:

[root@ipfire ~]# cat /proc/sys/kernel/random/entropy_avail
256
Comment 3 ChrisK 2022-06-29 14:20:03 UTC
Some more testing:

System with Core 168:

[root@ipfire ~]# sysctl -a | grep entropy
kernel.random.entropy_avail = 3413

[root@ipfire ~]# sysctl -a | grep kernel.random.poolsize
kernel.random.poolsize = 4096


System with Core 169:

[root@ipfire ~]# sysctl -a | grep entropy
kernel.random.entropy_avail = 256

[root@ipfire ~]# sysctl -a | grep kernel.random.poolsize
kernel.random.poolsize = 256


Further, trying to set the poolside to 4096 on core 169 results in:

[root@ipfire ~]# sysctl kernel.random.poolsize=4096
sysctl: setting key "kernel.random.poolsize": Invalid argument

I think something's broken in here.
Comment 4 ChrisK 2022-06-29 14:25:26 UTC
Regarding this post, it's not a bug but a feature that came with kernel 5.10.119:
https://unix.stackexchange.com/questions/704737/kernel-5-10-119-caused-the-values-of-proc-sys-kernel-random-entropy-avail-and-p

Here's an explanation why the kernel devs have decided to do so:
https://lore.kernel.org/lkml/20220527084855.501642285@linuxfoundation.org/

@Michael: Is this still an issue for IPFire? Do we need a larger random pool like it was before?
Comment 5 Michael Tremer 2022-06-29 16:51:50 UTC
(In reply to ChrisK from comment #4)
> @Michael: Is this still an issue for IPFire? Do we need a larger random pool
> like it was before?

No, IPFire is nothing special in this regard. The changes in the Linux kernel make this graph entirely redundant which is why I would propose to drop it.
Comment 6 Michael Tremer 2022-06-29 18:37:49 UTC
> https://patchwork.ipfire.org/project/ipfire/patch/20220629183217.392626-1-michael.tremer@ipfire.org/

We can probably also afford loosing the stupid busy-loop script. This change probably needs some feedback from users on weaker hardware.
Comment 9 Paul Simmons 2022-07-03 03:53:02 UTC
If I may suggest, please consider adding the status of rgnd to "services.cgi".
Comment 10 Michael Tremer 2022-07-05 14:10:00 UTC
(In reply to Paul Simmons from comment #9)
> If I may suggest, please consider adding the status of rgnd to
> "services.cgi".

That is a good suggestion for the time being. However, I would like to investigate in what way rngd is useful these days. I would argue that it is not doing anything at all any more. However, I need to double-check that. Potentially we can remove it.
Comment 11 Paul Simmons 2022-07-05 16:18:36 UTC
Thank you for your consideration.

The instance of rngd on my production IPFire machine uses a hardware device (TrueRNGpro) to quickly supply additional entropy "on demand".  After the release of CU169, I'll be happy to provide any diagnostics or debugging to determine if the device still "works".
Comment 12 Peter Müller 2022-07-06 10:12:58 UTC
(In reply to Paul Simmons from comment #9)
> If I may suggest, please consider adding the status of rgnd to
> "services.cgi".

Ah yes, that was #11546. Sorry again for things stalling on this end...
Comment 13 Michael Tremer 2022-07-06 10:37:26 UTC
(In reply to Paul Simmons from comment #11)
> Thank you for your consideration.
> 
> The instance of rngd on my production IPFire machine uses a hardware device
> (TrueRNGpro) to quickly supply additional entropy "on demand".  After the
> release of CU169, I'll be happy to provide any diagnostics or debugging to
> determine if the device still "works".

I believe that you won't need rngd for this any more. The kernel should automatically try using the hwrng to add entropy to the pool. There is a kernel thread that is being launched here

> https://git.ipfire.org/?p=thirdparty/kernel/stable.git;a=blob;f=drivers/char/hw_random/core.c;hb=88084a3df1672e131ddc1b4e39eeacfd39864acf#l491

It will also be used to seed the kernel's CSRNG at boot time - among other sources if available.

For that reason, I believe there is no reason why we need to keep rngd. The kernel does that job by itself.
Comment 14 Paul Simmons 2022-07-08 20:17:08 UTC
It isn't clear to me how the kernel will recognize (and use) my RNG device.  It's not integral to the machine's CPU or motherboard.  It is connected via a USB port, and rng-tools (rngd) knows of it via a rule in /etc/udev/rules.d .
Comment 15 Peter Müller 2022-07-09 12:13:26 UTC
(In reply to Paul Simmons from comment #14)
> It isn't clear to me how the kernel will recognize (and use) my RNG device. 
> It's not integral to the machine's CPU or motherboard.  It is connected via
> a USB port, and rng-tools (rngd) knows of it via a rule in /etc/udev/rules.d
> .

This makes sense to me. To be honest, I have lost track of the entropy handling in the kernel. Can we reliably assume that it will - somehow - have sufficient entropy available on any machine, regardless whether they come with a built-in HWRNG or not?

If so, we could drop rng-tools and the correspondent udev rules entirely, as users will not gain any benefit from them anymore. If not, we will probably have to keep it in order not to impact RNG on systems without any HWRNG (or with USB-based external HWRNGs).

@Michael, Paul: What are your thoughts on this?
Comment 16 Paul Simmons 2022-07-10 07:57:47 UTC
Thank you for your contribution, Peter.

I want to understand how my HWRNG device can continue to provide entropy without rngd. I do not understand how the new kernel can recognize my device and provide entropy without my current enstanciation of support via rngd.
Comment 17 ChrisK 2022-07-10 10:35:35 UTC
(In reply to Paul Simmons from comment #16)
> Thank you for your contribution, Peter.
> 
> I want to understand how my HWRNG device can continue to provide entropy
> without rngd. I do not understand how the new kernel can recognize my device
> and provide entropy without my current enstanciation of support via rngd.

With the new kernel-based generation of entropy it shall no-longer be necessary to have a dedicated external random source like the usb-based device you have.
That's at least what I read from the link of the commit message I posted at comment #4.

We will see if that's really the case for all systems and all archicetures. But for the question of displaying a value that's now nailed to 256 on all systems, I go with Peter and Michael to remove that completely.
Comment 18 Peter Müller 2022-07-12 10:39:53 UTC
https://blog.ipfire.org/post/ipfire-2-27-core-update-169-released

Closing this as being fixed. The discussion on whether or not we can or should remove rng-tools will continue in #12900, to keep these two items separate.

Thank you all for your contributions!