Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   GROSSSCHARTNER Benjamin <benjamin.grossschartner@thalesgroup.com>
To:     "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>
CC:     "smueller@chronox.de" <smueller@chronox.de>
Subject: drbg using jitterentropy_rng causes huge latencies
Thread-Topic: drbg using jitterentropy_rng causes huge latencies
Thread-Index: AdjGf84ksYXiKWw4SWePZkEAIXXeuQ==
Date:   Mon, 12 Sep 2022 08:16:17 +0000
Message-ID: <a6aff0c118df4497b5e988c42586f4e4@thalesgroup.com>
Accept-Language: en-US, fr-FR
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: bulk

Hello!

On an embedded board based on ARM iMX6UL we observed latencies of over 60ms=
,
during tests using IPsec (strongSwan), that are caused by drbg using jitter=
entropy_rng.

These latencies cause various problems for our system (watchdog is not trig=
gered in time,
loss of synchronization of our communication system,...).

In the past, before commit https://github.com/torvalds/linux/commit/97f2650=
e504033376e8813691cb6eccf73151676
the Jitter RNG was only used if get_random_bytes() did not have sufficient =
entropy available.
Before updating our kernel from 5.4.180 to 5.4.205 (but behavior of current=
 kernel 6.0-rc4 seems to be the same)
we did not notice these latencies caused by the Jitter RNG, because it was =
never actually used by our
system (get_random_bytes() was always ready when seeding drbg).

We need to disable the Jitter RNG, which is not possible because the config=
 option
CRYPTO_JITTERENTROPY is selected by CRYPTO_DRBG. The usage of Jitter RNG in=
 drbg is only enforced in FIPS mode.
So I propose to decouple these config options, as drbg does not need/enforc=
e the usage of the Jitter RNG
if not in FIPS mode. This would enable slower systems to use drbg without t=
he latencies cause by Jitter RNG.

We maintain our own set of kernel patches specific to our needs, but I thin=
k that this change would also be
useful for others to be able to use drbg on slower systems without jitteren=
tropy_rng.

Would there be any chance to get such a patch merged?
Or could the Jitter RNG be optimized to not cause such latencies?

Thanks,
Benjamin