jitterentropy-rngd decreases available entropy on arm64

[Djhg2000]

Tested on Mobian Unstable (Debian Sid based distribution targeting phones), jitterentropy-rngd squashes the available entropy (read from /proc/sys/kernel/random/entropy_avail) to a single digit number (in one of my test runs down from 383 to 2). Output sample below:

$ sudo jitterentropy-rngd -vvvv
jitterentropy-rngd - Debug: Injected 64 bytes with an entropy count of 32 bytes of entropy
jitterentropy-rngd - Verbose: 64 bytes written to /dev/random
jitterentropy-rngd - Debug: Install termination signal handler
jitterentropy-rngd - Debug: Install alarm signal handler
jitterentropy-rngd - Debug: Polling /dev/random
jitterentropy-rngd - Verbose: Wakeup call for select on /dev/random
jitterentropy-rngd - Debug: Injected 64 bytes with an entropy count of 32 bytes of entropy
jitterentropy-rngd - Verbose: 64 bytes written to /dev/random
jitterentropy-rngd - Debug: Polling /dev/random
jitterentropy-rngd - Verbose: Wakeup call for select on /dev/random
jitterentropy-rngd - Debug: Injected 64 bytes with an entropy count of 32 bytes of entropy
jitterentropy-rngd - Verbose: 64 bytes written to /dev/random

Last 4 lines repeats very quickly and easily fills the entire console buffer in under a second. The issue is not repeatable on Debian Sid running on amd64.

Both systems are running version 1.2.1-1 from the official Debian repositories.

[smuellerDD]

Am Donnerstag, dem 11.03.2021 um 16:43 -0800 schrieb Djhg2000:

Tested on Mobian Unstable (Debian Sid based distribution targeting phones), `jitterentropy-rngd` squashes the available entropy (read from `/proc/sys/kernel/random/entropy_avail`) to a single digit number (in one of my test runs down from `383` to `2`). Output sample below:

I am wondering whether the rngd is the cuplrit here. It sounds more like that there is a user space component wanting data from /dev/random that commonly stalls as insufficient entropy is available . But with the rngd, you get sufficient entropy which may unblock this process sooner and thus pull random data that draws down the entropy counter.

``` $ sudo jitterentropy-rngd -vvvv jitterentropy-rngd - Debug: Injected 64 bytes with an entropy count of 32 bytes of entropy jitterentropy-rngd - Verbose: 64 bytes written to /dev/random jitterentropy-rngd - Debug: Install termination signal handler jitterentropy-rngd - Debug: Install alarm signal handler jitterentropy-rngd - Debug: Polling /dev/random jitterentropy-rngd - Verbose: Wakeup call for select on /dev/random jitterentropy-rngd - Debug: Injected 64 bytes with an entropy count of 32 bytes of entropy jitterentropy-rngd - Verbose: 64 bytes written to /dev/random jitterentropy-rngd - Debug: Polling /dev/random jitterentropy-rngd - Verbose: Wakeup call for select on /dev/random jitterentropy-rngd - Debug: Injected 64 bytes with an entropy count of 32 bytes of entropy jitterentropy-rngd - Verbose: 64 bytes written to /dev/random ``` Last 4 lines repeats very quickly and easily fills the entire console buffer in under a second.

This sounds very much like the scenario I describe above.

The issue is not repeatable on Debian Sid running on amd64.

I guess this is because the offending user space process does not exist there.

…

Both systems are running version `1.2.1-1` from the official Debian repositories.

[fortysixandtwo]

I'd just like to add from my own testing (on the pinephone):
If I kill jitterentropy-rngd the entropy does slowly start rising again (obviously faster if do f.e. touch the touchscreen a lot).
If I let it rise a bit (but below ~1300 or ~1400) and start jitterentropy-rngd in a second terminal all the available entropy is "sucked" to 0.
If I repeat the procedure but let it rise above ~1400 jitterentropy-rngd will be happy (aka not hogging one core at 100%) and the available entropy does not plummet to 0.

[smuellerDD]

Am Freitag, 12. März 2021, 18:40:23 CET schrieb fortysixandtwo: Hi fortysixandtwo, That is indeed an odd behavior. This sounds like what is discussed in issue #20. Can you try the debug hints stated there? When you say you start the jitterentropy-rngd in a second window, do you have then two rngd instances running? Which kernel do you use? My problem is that I cannot reproduce the issue and now we need to pinpoint the issue you see. Ciao Stephan

[smuellerDD]

Am Freitag, 12. März 2021, 01:43:15 CET schrieb Djhg2000: Hi Djhg2000, can you please try the latest code in the git repo to see whether this addresses the issue you see? Thanks Stephan

[Djhg2000]

It does indeed sound a lot like #20 , I'll give the latest git a try and report back.

[Djhg2000]

Latest git solves the issue on Mobian. Mobian Unstable is using Linux kernel 5.11.6 so I think it's safe to say this and #20 is a duplicate issue (we just didn't know it earlier).

[smuellerDD]

Am Montag, dem 15.03.2021 um 08:08 -0700 schrieb Djhg2000:

Latest git solves the issue on Mobian. Mobian Unstable is using Linux kernel 5.11.6 so I think it's safe to say this and #20 is a duplicate issue (we just didn't know it earlier).

Thank you - let me keep the issue open until a true release is published. Ciao Stephan

[smuellerDD]

The new code has been released