All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: 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:41:22 +0100	[thread overview]
Message-ID: <Y45lguC4ZiniiWS/@zx2c4.com> (raw)
In-Reply-To: <Y45j/hd2MnnXzcAo@aurel32.net>

Hi Aurelien,

On Mon, Dec 05, 2022 at 10:34:54PM +0100, Aurelien Jarno wrote:
> 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.

That's the right principle. I just worry about estimating it like that
from looking at the output, rather than being derived from some
knowledge about the hardware. Maybe 50% (quality=512) is more
reasonable, so that it collects two bits for every one?

Jason

WARNING: multiple messages have this Message-ID (diff)
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: 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:41:22 +0100	[thread overview]
Message-ID: <Y45lguC4ZiniiWS/@zx2c4.com> (raw)
In-Reply-To: <Y45j/hd2MnnXzcAo@aurel32.net>

Hi Aurelien,

On Mon, Dec 05, 2022 at 10:34:54PM +0100, Aurelien Jarno wrote:
> 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.

That's the right principle. I just worry about estimating it like that
from looking at the output, rather than being derived from some
knowledge about the hardware. Maybe 50% (quality=512) is more
reasonable, so that it collects two bits for every one?

Jason

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: 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:41:22 +0100	[thread overview]
Message-ID: <Y45lguC4ZiniiWS/@zx2c4.com> (raw)
In-Reply-To: <Y45j/hd2MnnXzcAo@aurel32.net>

Hi Aurelien,

On Mon, Dec 05, 2022 at 10:34:54PM +0100, Aurelien Jarno wrote:
> 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.

That's the right principle. I just worry about estimating it like that
from looking at the output, rather than being derived from some
knowledge about the hardware. Maybe 50% (quality=512) is more
reasonable, so that it collects two bits for every one?

Jason

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-12-05 21:41 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-28 18:47 [PATCH v2 0/3] hwrng: add hwrng support for Rockchip RK3568 Aurelien Jarno
2022-11-28 18:47 ` Aurelien Jarno
2022-11-28 18:47 ` Aurelien Jarno
2022-11-28 18:47 ` [PATCH v2 1/3] dt-bindings: RNG: Add Rockchip RNG bindings Aurelien Jarno
2022-11-28 18:47   ` Aurelien Jarno
2022-11-28 18:47   ` Aurelien Jarno
2022-11-29  9:24   ` Krzysztof Kozlowski
2022-11-29  9:24     ` Krzysztof Kozlowski
2022-11-29  9:24     ` Krzysztof Kozlowski
2022-12-02 19:20     ` Aurelien Jarno
2022-12-02 19:20       ` Aurelien Jarno
2022-12-02 19:20       ` Aurelien Jarno
2022-12-03 10:21       ` Krzysztof Kozlowski
2022-12-03 10:21         ` Krzysztof Kozlowski
2022-12-03 10:21         ` Krzysztof Kozlowski
2022-11-28 18:47 ` [PATCH v2 2/3] hwrng: add Rockchip SoC hwrng driver Aurelien Jarno
2022-11-28 18:47   ` Aurelien Jarno
2022-11-28 18:47   ` Aurelien Jarno
2022-11-29  9:33   ` Krzysztof Kozlowski
2022-11-29  9:33     ` Krzysztof Kozlowski
2022-11-29  9:33     ` Krzysztof Kozlowski
2022-12-02 19:30     ` Aurelien Jarno
2022-12-02 19:30       ` Aurelien Jarno
2022-12-02 19:30       ` Aurelien Jarno
2022-12-05 13:13   ` Jason A. Donenfeld
2022-12-05 13:13     ` Jason A. Donenfeld
2022-12-05 13:13     ` Jason A. Donenfeld
2022-12-05 13:30     ` Jason A. Donenfeld
2022-12-05 13:30       ` Jason A. Donenfeld
2022-12-05 13:30       ` Jason A. Donenfeld
2022-12-05 21:34     ` Aurelien Jarno
2022-12-05 21:34       ` Aurelien Jarno
2022-12-05 21:34       ` Aurelien Jarno
2022-12-05 21:41       ` Jason A. Donenfeld [this message]
2022-12-05 21:41         ` Jason A. Donenfeld
2022-12-05 21:41         ` Jason A. Donenfeld
2022-11-28 18:47 ` [PATCH v2 3/3] arm64: dts: rockchip: add DT entry for RNG to RK356x Aurelien Jarno
2022-11-28 18:47   ` Aurelien Jarno
2022-11-28 18:47   ` Aurelien Jarno

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y45lguC4ZiniiWS/@zx2c4.com \
    --to=jason@zx2c4.com \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=herbert@gondor.apana.org.au \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=olivia@selenic.com \
    --cc=p.zabel@pengutronix.de \
    --cc=robh+dt@kernel.org \
    --cc=troy.lin@rock-chips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.