Re: jitterentropy vs. simulation

[Stephan Mueller <smueller@chronox.de>]

Am Freitag, 1. Dezember 2023, 19:35:11 CET schrieb Johannes Berg:

Hi Johannes,

> [I guess we should keep the CCs so other see it]
> 
> > Looking at the stuck check it will be bogus in simulations.
> 
> True.
> 
> > You might as well ifdef that instead.
> > 
> > If a simulation is running insert the entropy regardless and do not
> > compute the derivatives used in the check.
> Actually you mostly don't want anything inserted in that case, so it's
> not bad to skip it.
> 
> I was mostly thinking this might be better than adding a completely
> unrelated ifdef. Also I guess in real systems with a bad implementation
> of random_get_entropy(), the second/third derivates might be
> constant/zero for quite a while, so may be better to abort?
> 
> In any case, I couldn't figure out any way to not configure this into
> the kernel when any kind of crypto is also in ...

The reason for the Jitter RNG to be dragged in is the Kconfig select in 
CRYPTO_DRBG. Why does the DRBG require it?

The DRBG seeds from get_random_bytes || jitter rng output. It pulls an equal 
amount of data from each source where each source alone is able to provide all 
entropy that the DRBG needs. That said, the Jitter RNG can be designated as 
optional, because the code already can handle the situation where this Jitter 
RNG is not available. However, in FIPS mode, we must have the Jitter RNG 
source.

That said, I could fathom to change CRYPTO_DRBG to remove the select 
CRYPTO_JITTERENTROPY. But instead, add the select to CRYPTO_FIPS.

This change would entail a new log entry when a DRBG instance initializes:

pr_info("DRBG: Continuing without Jitter RNG\n");

I would assume that this change could help you to deselect the Jitter RNG in 
your environment.

Side note: do you have an idea how that Jitter RNG perhaps could still be 
selected by default when the DRBG is enabled, but allows it being deselected 
following the aforementioned suggestion?

Ciao
Stephan