Bug 12893

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.

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

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.

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?

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

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

https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=255873a5f9a564036092a20e4bec7f4965cbd149

https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=8000bc0a4375ee7afdc1d56023681b8ac9502c3d

If I may suggest, please consider adding the status of rgnd to "services.cgi".

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

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

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

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

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 .

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

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.

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

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!