Re: [PATCH v2 2/3] hwrng: add Rockchip SoC hwrng driver

From: Aurelien Jarno <aurelien@aurel32.net>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Olivia Mackall <olivia@selenic.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Heiko Stuebner <heiko@sntech.de>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Lin Jinhan <troy.lin@rock-chips.com>,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
	<linux-crypto@vger.kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	"moderated list:ARM/Rockchip SoC support" 
	<linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC support" 
	<linux-rockchip@lists.infradead.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/3] hwrng: add Rockchip SoC hwrng driver
Date: Mon, 5 Dec 2022 22:34:54 +0100	[thread overview]
Message-ID: <Y45j/hd2MnnXzcAo@aurel32.net> (raw)
In-Reply-To: <Y43uiVo41vljLsZM@zx2c4.com>

Hi,

On 2022-12-05 14:13, Jason A. Donenfeld wrote:
> On Mon, Nov 28, 2022 at 07:47:17PM +0100, Aurelien Jarno wrote:
> > The TRNG device does not seem to have a signal conditionner and the FIPS
> > 140-2 test returns a lot of failures. They can be reduced by increasing
> > RK_RNG_SAMPLE_CNT, in a tradeoff between quality and speed. This value
> > has been adjusted to get ~90% of successes and the quality value has
> > been set accordingly.
> 
> Can't you reduce it even more to get 100%? All we need is 32 bytes every
> once in a while.

From what I understood, we get the raw stream of the TRNG, there is no
conditionner and the TRNG is not FIPS compliant. So even with the
slowest speed, you don't reach 100% and you only get a very small
increase in the quality while it's way more slower.

> > +	rk_rng->rng.quality = 900;
> 
> If your intention is "90%", this should be 921 or 922, because the
> quality knob is out of 1024, not 1000.

Well I am not sure it really matters. 90% is actually conservative, it's
the worst case I have seen, rounded down. However I often get much
better quality, see for instance the following run:

| 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: entropy source drained
| rngtest: bits received from input: 16777216
| rngtest: FIPS 140-2 successes: 819
| rngtest: FIPS 140-2 failures: 19
| rngtest: FIPS 140-2(2001-10-10) Monobit: 17
| rngtest: FIPS 140-2(2001-10-10) Poker: 0
| rngtest: FIPS 140-2(2001-10-10) Runs: 2
| rngtest: FIPS 140-2(2001-10-10) Long run: 2
| rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
| rngtest: input channel speed: (min=132.138; avg=137.848; max=147.308)Kibits/s
| rngtest: FIPS tests speed: (min=16.924; avg=20.272; max=20.823)Mibits/s
| rngtest: Program run time: 119647459 microseconds

Does the exact value has an importance there? I thought it was just
important to not overestimate the quality.

Regards
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net