Increase Entropy in RHEL 9.1 VM – How to Increase Entropy in Azure Hardened by CIS

azureentropy-poolredhatrhel9solr

I am having trouble running Solr 9.2 on the above virtual machine (Rhel9.1 on Azure, image from CIS).

The problem is low entropy as seen in the logs below:

Started Apache Solr 9.
Java 17 detected. Enabled workaround for SOLR-16463
Warning: Available entropy is low. As a result, use of the UUIDField, SSL, or any other features that require
RNG might not work properly. To check for the amount of available entropy, use 'cat /proc/sys/kernel/random/entropy_avail'.

I have tried installing rng-tools and haveged but the problem still persists.
The ouput of cat /proc/sys/kernel/random/entropy_avail remains 256.

Below is the status of haveged service:

 Started Entropy Daemon based on the HAVEGE algorithm.
 haveged[14569]: haveged: command socket is listening at fd 3
 haveged[14569]: haveged: fills: 1, generated: 512 K bytes, RNDADDENTROPY: 256

and the status of rngd service:

 Started Hardware RNG Entropy Gatherer Daemon.
 rngd[14506]: Disabling 7: PKCS11 Entropy generator (pkcs11)
 rngd[14506]: Disabling 5: NIST Network Entropy Beacon (nist)
 rngd[14506]: Disabling 9: Qrypt quantum entropy beacon (qrypt)
 rngd[14506]: Initializing available sources
 rngd[14506]: [hwrng ]: Initialization Failed
 rngd[14506]: [rdrand]: Enabling RDSEED rng support
 rngd[14506]: [rdrand]: Initialized
 rngd[14506]: [jitter]: JITTER timeout set to 5 sec
 rngd[14506]: [jitter]: Initializing AES buffer

What am I missing?

Best Answer

Solr has a check that /proc/sys/kernel/random/entropy_avail < 300. Version control and SOLR-10352 SOLR-10338 suggests it was added circa Solr 7, around discussions of slow tests involving cryptography. This check serves no purpose on modern Linux, and I think should be removed by the developers.

I am not familiar with this application to know where it ultimately sources random bits, as in /dev/random or /dev/urandom or which flags on getrandom system calls. Solr never had to use a blocking source to get quantity random, but it may have been blocking in the past, by accident or design on the application's part.

man 7 random will explain that Linux random driver exists to initialize a cryptographically secure RNG (crng). Very recently the source code documentation got a long overdue update, char/random.c at 6.3 summarizes:

 * The high level overview is that there is one input pool, into which
 * various pieces of data are hashed. Prior to initialization, some of that
 * data is then "credited" as having a certain number of bits of entropy.
 * When enough bits of entropy are available, the hash is finalized and
 * handed as a key to a stream cipher that expands it indefinitely for
 * various consumers. This key is periodically refreshed as the various
 * entropy collectors, described below, add data to the input pool.

Note "expands it indefinitely". The algorithms here are sufficiently good that the blocking pool has been removed.

I believe that Linux's blocking pool has outlived its usefulness. Linux's CRNG generates output that is good enough to use even for key generation. The blocking pool is not stronger in any material way, and keeping it around requires a lot of infrastructure of dubious value.

I tested this lack of blocking, here is CentOS Stream 9 reading 20 billion bits from /dev/random. This is an enormous volume, given 256 bits is sufficient to seed any crypto key. Note this is just some idle test VM, and I shut down rngd. Despite these limitations, it has a decent showing on a test suite designed by NIST and implemented by the maintainers of rng-tools.

[root@novem ~]# pv < /dev/random |  rngtest --blockcount=1000000
rngtest 6.16
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000000032                                                                       ]
rngtest: FIPS 140-2 successes: 999166
rngtest: FIPS 140-2 failures: 834
rngtest: FIPS 140-2(2001-10-10) Monobit: 110
rngtest: FIPS 140-2(2001-10-10) Poker: 104
rngtest: FIPS 140-2(2001-10-10) Runs: 314
rngtest: FIPS 140-2(2001-10-10) Long run: 310
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=38.767; avg=1393.782; max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=21.052; avg=228.528; max=244.532)Mibits/s
rngtest: Program run time: 97270648 microseconds
2.33GiB 0:01:37 [24.5MiB/s] [   <=>                                                                                  ]
[root@novem ~]# uname -a
Linux novem 5.14.0-302.el9.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Apr 20 05:35:26 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Regarding why the warning triggers now in the EL 9 era, it is an implementation detail that the pool is this small. It does not affect the quality of output. The kernel maintainers are not going to return to the old 4096-bit LFSR pool. There's also a skepticism from the maintainers about putting much weight into it: "The general concept of entropy estimation to begin with is probably impossible to do robustly." Despite this, the sysctl API remains, for maximum transparency, and not to break user program assumptions.

Feel free to continue using programs to feed it more random bits. They'll get mixed in to the many other sources, and seed more output of the CRNG.

Further reading:

Related Topic