Change poolsize definition for recent Linux kernels?

[dermotbradley]

Recent Linux kernels have changed the entropy poolsize from 4096 to 256.

However rngd_linux.c contains: #define DEFAULT_WATERMARK_GUESS 4096 and rngd.8.in and rngd.c also refer to a poolsize of 4096.

Shouldn't this be changed, at least in rngd_linux.c, to be 256 instead?

[nhorman]

I argued that this should not have happened as they were completely breaking the ABI for rngd.

That said, yes, it should be changed. Do you want to submit a patch?

[dermotbradley]

I'm working on a patch.

Whilst testing the patch I found another issue, this code also has no effect in recent kernels. This is indicated in recent kernel docs:

"This file is writable for compatibility purposes, but writing to it has no effect on any RNG behavior."

This seems like the kernel PR (not sure which kernel versions this applies to) from March 2022 that made it read-only: torvalds/linux@77553cf

Testing even on the command line with echo and cat anything written to /proc/sys/kernel/random/write_wakeup_threshold has no effect, it still shows 256.

This renders the above rngd code, and also the --fill-watermark / -W option irrelevant.

As a side-note, when testing on Virtualbox x86_64 I notice that jitter gives the following error:

rngd: [jitter]: Unable to obtain AES key, disabling JITTER source

unless I set the (new to 6.16) "-O jitter:timeout" option to "20".

[nhorman]

yeah, I really hate how the kernel changed this interface. IMHO while they adhered to the "don't break the ABI" rule in the strictest sense, they completely broke rngd functionally with the changes they made. In truth, the kernel doesn't really accept exernal entropy in the way it used to (because they have an internal jitter source that attempts to reduce/prevent blocking in read from /dev/random.

I've thought about ways to keep rngd "working" with newer kernels, but doing so would be at the cost of potentially breaking older kernels that will still be around for some time.

You're welcome to propose a patch for it, but if the kernel doesn't want user space input to the random pool, so be it, rngd still has lots of use in monte-carlo testing, and other non-kernel use cases.

[dermotbradley]

In truth, the kernel doesn't really accept exernal entropy in the way it used to (because they have an internal jitter source that attempts to reduce/prevent blocking in read from /dev/random.

So are you saying that with recent kernels there is no real point in using rngd to improve /dev/random entropy?

For machines without a hwrng/TPM or CPU rdrand/darn/rndr instructions available for the kernel to directly use how does the kernel's current jitter code compare to rngd with jitterentropy library? Is there any benefit in using rngd + JITTER in such scenarios?

I assume rngd can still provide additional entropy to the kernel if the PKCS11 and/or RTLSDR sources are used.

[nhorman]

| So are you saying that with recent kernels there is no real point in using rngd to improve /dev/random entropy?
Yes. Specifically I'm saying that there isn't a good way to conditionally drive entropy into the kernel. It will still strictly speaking, accept entropy (by writing to /dev/random, or issuing the ADDENTROPY ioctl), but theres no longer any good way to tell when the kenrel needs entropy, so we're left with this condition in which rngd will either just chew cpu time adding entropy when its not needed, or it will have to guess at when to write (which is useless).

As for weather or not the kernel has any external requirement on entropy, I can't say for certain. I can say that reading /dev/random should no longer ever block, and I believe the kernel guys doing these updates have done the math to prove the relative security of that implementation, but if you are an individual that wants to say, add entropy of an external source, you're kind of out of luck

| For machines without a hwrng/TPM or CPU ...
Last time I looked they were pretty comparable in terms of performance, I think the kernel did some magic to avoid slow startups at the sacrifice of predictability, but it was a long time ago that I looked at that, you would have check to see recent updates.

As for advantages to using rngd + JITTER, its kind of a moot point because if you do the latter, it just doesn't work on recent kenrels.

| I assume rngd can still provide additional entropy to the kernel if the PKCS11 and/or RTLSDR sources are used.
rngd is still capable of providing entropy to the kernel from any configured source. The only issue is that, because of the behavioral changes to the wake threshold and entopy values in /proc, it never wakes up to do so, or (depending on how you configure it), will do so indifinately, chewing cpu time in the process.