diff mbox series

hwrng: bcm2835: set quality to 1000

Message ID 20210220174741.23665-1-noltari@gmail.com (mailing list archive)
State New, archived
Headers show
Series hwrng: bcm2835: set quality to 1000 | expand

Commit Message

Álvaro Fernández Rojas Feb. 20, 2021, 5:47 p.m. UTC
This allows devices without a high precission timer to reduce boot from >100s
to <30s.

Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
---
 drivers/char/hw_random/bcm2835-rng.c | 1 +
 1 file changed, 1 insertion(+)

Comments

Andrew Lunn Feb. 20, 2021, 7:09 p.m. UTC | #1
On Sat, Feb 20, 2021 at 06:47:40PM +0100, Álvaro Fernández Rojas wrote:
> This allows devices without a high precission timer to reduce boot from >100s
> to <30s.
> diff --git a/drivers/char/hw_random/bcm2835-rng.c b/drivers/char/hw_random/bcm2835-rng.c
> index 1a7c43b43c6b..4b48cb7176b0 100644
> --- a/drivers/char/hw_random/bcm2835-rng.c
> +++ b/drivers/char/hw_random/bcm2835-rng.c
> @@ -163,6 +163,7 @@ static int bcm2835_rng_probe(struct platform_device *pdev)
>  	priv->rng.init = bcm2835_rng_init;
>  	priv->rng.read = bcm2835_rng_read;
>  	priv->rng.cleanup = bcm2835_rng_cleanup;
> +	priv->rng.quality = 1000;

Hi Alvero

 * @quality:		Estimation of true entropy in RNG's bitstream
 *			(in bits of entropy per 1024 bits of input;
 *			valid values: 1 to 1024, or 0 for unknown).

How did you determine this device produces 1000 bits of true entropy
per 1024?

    Andrew
Álvaro Fernández Rojas Feb. 20, 2021, 7:12 p.m. UTC | #2
Hi Andrew,

I ran rngtest and this is what I got:
root@OpenWrt:/# cat /dev/hwrng | rngtest -c 1000
rngtest 6.10
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: 20000032
rngtest: FIPS 140-2 successes: 996
rngtest: FIPS 140-2 failures: 4
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 1
rngtest: FIPS 140-2(2001-10-10) Long run: 3
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=146.002; avg=349.394; 
max=1302083.333)Kibits/s
rngtest: FIPS tests speed: (min=12.126; avg=22.750; max=23.432)Mibits/s
rngtest: Program run time: 56826982 microseconds

996 successes and 4 failures -> 99.6% success rate
1024 * 99.6% = 1019 (rounded down to 1000)

I'm not sure if I can rely on rngtest for that...

Best regards,
Álvaro.

El 20/02/2021 a las 20:09, Andrew Lunn escribió:
> On Sat, Feb 20, 2021 at 06:47:40PM +0100, Álvaro Fernández Rojas wrote:
>> This allows devices without a high precission timer to reduce boot from >100s
>> to <30s.
>> diff --git a/drivers/char/hw_random/bcm2835-rng.c b/drivers/char/hw_random/bcm2835-rng.c
>> index 1a7c43b43c6b..4b48cb7176b0 100644
>> --- a/drivers/char/hw_random/bcm2835-rng.c
>> +++ b/drivers/char/hw_random/bcm2835-rng.c
>> @@ -163,6 +163,7 @@ static int bcm2835_rng_probe(struct platform_device *pdev)
>>   	priv->rng.init = bcm2835_rng_init;
>>   	priv->rng.read = bcm2835_rng_read;
>>   	priv->rng.cleanup = bcm2835_rng_cleanup;
>> +	priv->rng.quality = 1000;
> 
> Hi Alvero
> 
>   * @quality:		Estimation of true entropy in RNG's bitstream
>   *			(in bits of entropy per 1024 bits of input;
>   *			valid values: 1 to 1024, or 0 for unknown).
> 
> How did you determine this device produces 1000 bits of true entropy
> per 1024?
> 
>      Andrew
>
Andrew Lunn Feb. 20, 2021, 7:40 p.m. UTC | #3
On Sat, Feb 20, 2021 at 08:12:45PM +0100, Álvaro Fernández Rojas wrote:
> Hi Andrew,
> 
> I ran rngtest and this is what I got:
> root@OpenWrt:/# cat /dev/hwrng | rngtest -c 1000
> rngtest 6.10
> 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: 20000032
> rngtest: FIPS 140-2 successes: 996
> rngtest: FIPS 140-2 failures: 4
> rngtest: FIPS 140-2(2001-10-10) Monobit: 0
> rngtest: FIPS 140-2(2001-10-10) Poker: 0
> rngtest: FIPS 140-2(2001-10-10) Runs: 1
> rngtest: FIPS 140-2(2001-10-10) Long run: 3
> rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> rngtest: input channel speed: (min=146.002; avg=349.394;
> max=1302083.333)Kibits/s
> rngtest: FIPS tests speed: (min=12.126; avg=22.750; max=23.432)Mibits/s
> rngtest: Program run time: 56826982 microseconds
> 
> 996 successes and 4 failures -> 99.6% success rate
> 1024 * 99.6% = 1019 (rounded down to 1000)
> 
> I'm not sure if I can rely on rngtest for that...

Hi Álvaro

You need some sort of justification for setting the quality
value. Please include what you have written above in the commit
message. It then becomes possible for reviewers to say if this
justification is valid or not.

	Andrew
Herbert Xu March 3, 2021, 9:20 a.m. UTC | #4
On Sat, Feb 20, 2021 at 08:12:45PM +0100, Álvaro Fernández Rojas wrote:
> 
> I ran rngtest and this is what I got:

This is meaningless except for sources that have not been whitened.

Your justification needs to be based on what the hardware does or
is documented to do.

Thanks,
Álvaro Fernández Rojas March 3, 2021, 9:29 a.m. UTC | #5
Hi Herbert,

> El 3 mar 2021, a las 10:20, Herbert Xu <herbert@gondor.apana.org.au> escribió:
> 
> On Sat, Feb 20, 2021 at 08:12:45PM +0100, Álvaro Fernández Rojas wrote:
>> 
>> I ran rngtest and this is what I got:
> 
> This is meaningless except for sources that have not been whitened.
> 
> Your justification needs to be based on what the hardware does or
> is documented to do.

Ok, so I guess that we’re never setting that value to anything since there’s no public documentation about that ¯\_(ツ)_/¯.

> 
> Thanks,
> -- 
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Best regards,
Álvaro.
Nicolas Saenz Julienne March 4, 2021, 3:11 p.m. UTC | #6
On Wed, 2021-03-03 at 10:29 +0100, Álvaro Fernández Rojas wrote:
> Hi Herbert,
> 
> > El 3 mar 2021, a las 10:20, Herbert Xu <herbert@gondor.apana.org.au> escribió:
> > 
> > On Sat, Feb 20, 2021 at 08:12:45PM +0100, Álvaro Fernández Rojas wrote:
> > > 
> > > I ran rngtest and this is what I got:
> > 
> > This is meaningless except for sources that have not been whitened.
> > 
> > Your justification needs to be based on what the hardware does or
> > is documented to do.
> 
> Ok, so I guess that we’re never setting that value to anything since there’s
> no public documentation about that ¯\_(ツ)_/¯.

@Florian, is there a way you might be able to get the official value?

Regards,
Nicolas
Florian Fainelli March 4, 2021, 10:28 p.m. UTC | #7
On 3/4/21 7:11 AM, Nicolas Saenz Julienne wrote:
> On Wed, 2021-03-03 at 10:29 +0100, Álvaro Fernández Rojas wrote:
>> Hi Herbert,
>>
>>> El 3 mar 2021, a las 10:20, Herbert Xu <herbert@gondor.apana.org.au> escribió:
>>>
>>> On Sat, Feb 20, 2021 at 08:12:45PM +0100, Álvaro Fernández Rojas wrote:
>>>>
>>>> I ran rngtest and this is what I got:
>>>
>>> This is meaningless except for sources that have not been whitened.
>>>
>>> Your justification needs to be based on what the hardware does or
>>> is documented to do.
>>
>> Ok, so I guess that we’re never setting that value to anything since there’s
>> no public documentation about that ¯\_(ツ)_/¯.
> 
> @Florian, is there a way you might be able to get the official value?

I will be looking into the documentation this weekend and let you know
whether we can change the driver's quality accordingly.
Álvaro Fernández Rojas March 5, 2021, 6:26 a.m. UTC | #8
Hi Florian,

> El 4 mar 2021, a las 23:28, Florian Fainelli <f.fainelli@gmail.com> escribió:
> 
> On 3/4/21 7:11 AM, Nicolas Saenz Julienne wrote:
>> On Wed, 2021-03-03 at 10:29 +0100, Álvaro Fernández Rojas wrote:
>>> Hi Herbert,
>>> 
>>>> El 3 mar 2021, a las 10:20, Herbert Xu <herbert@gondor.apana.org.au> escribió:
>>>> 
>>>> On Sat, Feb 20, 2021 at 08:12:45PM +0100, Álvaro Fernández Rojas wrote:
>>>>> 
>>>>> I ran rngtest and this is what I got:
>>>> 
>>>> This is meaningless except for sources that have not been whitened.
>>>> 
>>>> Your justification needs to be based on what the hardware does or
>>>> is documented to do.
>>> 
>>> Ok, so I guess that we’re never setting that value to anything since there’s
>>> no public documentation about that ¯\_(ツ)_/¯.
>> 
>> @Florian, is there a way you might be able to get the official value?
> 
> I will be looking into the documentation this weekend and let you know
> whether we can change the driver's quality accordingly.

Could you do that for iproc-rng200.c too?

> -- 
> Florian

Best regards,
Álvaro.
Florian Fainelli March 12, 2021, 4:52 a.m. UTC | #9
On 3/4/2021 10:26 PM, Álvaro Fernández Rojas wrote:
> Hi Florian,
> 
>> El 4 mar 2021, a las 23:28, Florian Fainelli <f.fainelli@gmail.com> escribió:
>>
>> On 3/4/21 7:11 AM, Nicolas Saenz Julienne wrote:
>>> On Wed, 2021-03-03 at 10:29 +0100, Álvaro Fernández Rojas wrote:
>>>> Hi Herbert,
>>>>
>>>>> El 3 mar 2021, a las 10:20, Herbert Xu <herbert@gondor.apana.org.au> escribió:
>>>>>
>>>>> On Sat, Feb 20, 2021 at 08:12:45PM +0100, Álvaro Fernández Rojas wrote:
>>>>>>
>>>>>> I ran rngtest and this is what I got:
>>>>>
>>>>> This is meaningless except for sources that have not been whitened.
>>>>>
>>>>> Your justification needs to be based on what the hardware does or
>>>>> is documented to do.
>>>>
>>>> Ok, so I guess that we’re never setting that value to anything since there’s
>>>> no public documentation about that ¯\_(ツ)_/¯.
>>>
>>> @Florian, is there a way you might be able to get the official value?
>>
>> I will be looking into the documentation this weekend and let you know
>> whether we can change the driver's quality accordingly.
> 
> Could you do that for iproc-rng200.c too?

From looking at some documentation and the design of the 6368 RNG which
is supposedly the same as the Raspberry Pi 1/2/3 RNG, this appears to be
a random number generator that does not go through any post-processing
and just collects random bits into a FIFO.

The rbg200 is also similar except that it is integrated into a wrapper
called the rng200 which supposedly only accepts data that has passed
"NIST industry standard random data quality algorithm" without being
specific. So it seems to me you may be able to set the quality field for
bcm2835-rng, but not for iproc-rng200.

Stephan does that sound right?
diff mbox series

Patch

diff --git a/drivers/char/hw_random/bcm2835-rng.c b/drivers/char/hw_random/bcm2835-rng.c
index 1a7c43b43c6b..4b48cb7176b0 100644
--- a/drivers/char/hw_random/bcm2835-rng.c
+++ b/drivers/char/hw_random/bcm2835-rng.c
@@ -163,6 +163,7 @@  static int bcm2835_rng_probe(struct platform_device *pdev)
 	priv->rng.init = bcm2835_rng_init;
 	priv->rng.read = bcm2835_rng_read;
 	priv->rng.cleanup = bcm2835_rng_cleanup;
+	priv->rng.quality = 1000;
 
 	if (dev_of_node(dev)) {
 		rng_id = of_match_node(bcm2835_rng_of_match, dev->of_node);