* [PATCH 0/2] Set the quality value for two HW RNGs [not found] <CGME20200514190737eucas1p18ccdddb185ea7611683a6859e17bc721@eucas1p1.samsung.com> @ 2020-05-14 19:07 ` Łukasz Stelmach [not found] ` <CGME20200514190738eucas1p2695c0d8af064ee702209ca03696ef438@eucas1p2.samsung.com> ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: Łukasz Stelmach @ 2020-05-14 19:07 UTC (permalink / raw) To: Matt Mackall, Herbert Xu, Arnd Bergmann, Greg Kroah-Hartman, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Kukjin Kim, Krzysztof Kozlowski, Florian Fainelli, Markus Elfring, Matthias Brugger, Stefan Wahren, linux-crypto, linux-arm-kernel, linux-kernel, linux-samsung-soc Cc: Łukasz Stelmach, Bartlomiej Zolnierkiewicz The rng structure contains the quality field which tells how many bits of entropy can be obtained from 1024 bits read from a device. With the quality value set the hw_random framework starts a kernel thread to feed the entropy pool in the CRNG, which helps to initialize it quickly especially during boot. Łukasz Stelmach (2): hwrng: iproc-rng200 - Set the quality value hwrng: exynos - Set the quality value drivers/char/hw_random/exynos-trng.c | 1 + drivers/char/hw_random/iproc-rng200.c | 1 + 2 files changed, 2 insertions(+) -- 2.25.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <CGME20200514190738eucas1p2695c0d8af064ee702209ca03696ef438@eucas1p2.samsung.com>]
* [PATCH 1/2] hwrng: iproc-rng200 - Set the quality value [not found] ` <CGME20200514190738eucas1p2695c0d8af064ee702209ca03696ef438@eucas1p2.samsung.com> @ 2020-05-14 19:07 ` Łukasz Stelmach 2020-05-14 20:20 ` Stephan Mueller 0 siblings, 1 reply; 26+ messages in thread From: Łukasz Stelmach @ 2020-05-14 19:07 UTC (permalink / raw) To: Matt Mackall, Herbert Xu, Arnd Bergmann, Greg Kroah-Hartman, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Kukjin Kim, Krzysztof Kozlowski, Florian Fainelli, Markus Elfring, Matthias Brugger, Stefan Wahren, linux-crypto, linux-arm-kernel, linux-kernel, linux-samsung-soc Cc: Łukasz Stelmach, Bartlomiej Zolnierkiewicz The value has been estimaded by obtainig 1024 chunks of data 128 bytes (1024 bits) each from the generator and finding chunk with minimal entropy using the ent(1) tool. The value was 6.327820 bits of entropy in each 8 bits of data. Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com> --- drivers/char/hw_random/iproc-rng200.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/char/hw_random/iproc-rng200.c b/drivers/char/hw_random/iproc-rng200.c index 32d9fe61a225..7eb02a23f744 100644 --- a/drivers/char/hw_random/iproc-rng200.c +++ b/drivers/char/hw_random/iproc-rng200.c @@ -199,6 +199,7 @@ static int iproc_rng200_probe(struct platform_device *pdev) priv->rng.read = iproc_rng200_read, priv->rng.init = iproc_rng200_init, priv->rng.cleanup = iproc_rng200_cleanup, + priv->rng.quality = 800, /* Register driver */ ret = devm_hwrng_register(dev, &priv->rng); -- 2.25.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: [PATCH 1/2] hwrng: iproc-rng200 - Set the quality value 2020-05-14 19:07 ` [PATCH 1/2] hwrng: iproc-rng200 - Set the quality value Łukasz Stelmach @ 2020-05-14 20:20 ` Stephan Mueller [not found] ` <CGME20200514221852eucas1p2bea169d0b4467b0ec9e195c6ac58a08a@eucas1p2.samsung.com> 0 siblings, 1 reply; 26+ messages in thread From: Stephan Mueller @ 2020-05-14 20:20 UTC (permalink / raw) To: Łukasz Stelmach Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger, Greg Kroah-Hartman, Matt Mackall, linux-kernel, Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz, Kukjin Kim, Arnd Bergmann, Stefan Wahren, Ray Jui, bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel, linux-crypto Am Donnerstag, 14. Mai 2020, 21:07:33 CEST schrieb Łukasz Stelmach: Hi Łukasz, > The value has been estimaded by obtainig 1024 chunks of data 128 bytes > (1024 bits) each from the generator and finding chunk with minimal > entropy using the ent(1) tool. The value was 6.327820 bits of entropy > in each 8 bits of data. I am not sure we should use the ent tool to define the entropy level. Ent seems to use a very coarse entropy estimation. I would feel more comfortable when using other measures like SP800-90B which even provides a tool for the analysis. I understand that entropy estimates, well, are estimates. But the ent data is commonly not very conservative. [1] https://github.com/usnistgov/SP800-90B_EntropyAssessment Ciao Stephan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <CGME20200514221852eucas1p2bea169d0b4467b0ec9e195c6ac58a08a@eucas1p2.samsung.com>]
* Re: [PATCH 1/2] hwrng: iproc-rng200 - Set the quality value [not found] ` <CGME20200514221852eucas1p2bea169d0b4467b0ec9e195c6ac58a08a@eucas1p2.samsung.com> @ 2020-05-14 22:18 ` Lukasz Stelmach 2020-05-15 8:32 ` Stephan Mueller [not found] ` <CGME20200515090158eucas1p1b653fc50f1ad4f0f6c92525ab3188d45@eucas1p1.samsung.com> 0 siblings, 2 replies; 26+ messages in thread From: Lukasz Stelmach @ 2020-05-14 22:18 UTC (permalink / raw) To: Stephan Mueller Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger, Greg Kroah-Hartman, Matt Mackall, linux-kernel, Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz, Kukjin Kim, Arnd Bergmann, Stefan Wahren, Ray Jui, bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel, linux-crypto [-- Attachment #1.1: Type: text/plain, Size: 2351 bytes --] It was <2020-05-14 czw 22:20>, when Stephan Mueller wrote: > Am Donnerstag, 14. Mai 2020, 21:07:33 CEST schrieb Łukasz Stelmach: > > Hi Łukasz, > >> The value has been estimaded by obtainig 1024 chunks of data 128 bytes >> (1024 bits) each from the generator and finding chunk with minimal >> entropy using the ent(1) tool. The value was 6.327820 bits of entropy >> in each 8 bits of data. > > I am not sure we should use the ent tool to define the entropy > level. Ent seems to use a very coarse entropy estimation. > > I would feel more comfortable when using other measures like SP800-90B > which even provides a tool for the analysis. > > I understand that entropy estimates, well, are estimates. But the ent > data is commonly not very conservative. > > [1] https://github.com/usnistgov/SP800-90B_EntropyAssessment Thank you for pointing this out. I am running tests using SP800-90B tools and the first issue I can see is the warning that samples contain less than 1e6 bytes of data. I know little about maths behind random number generators, but I have noticed that the bigger chunk of data from an RNG I feed into either ent or ea_iid the higher entropy they report. That is why I divided the data into 1024 bit chunks in the first place. To get worse results. With ea_iid they get even worse (128 bytes of random data) Calculating baseline statistics... H_original: 4.107376 H_bitstring: 0.795122 min(H_original, 8 X H_bitstring): 4.107376 but I don't know how much I can trust it, when I get such warning *** Warning: data contains less than 1000000 samples *** ea_non_iid refuses to run tests with less than 4096 bytes of input. I may suspect that lack of any warnings from ent doesn't make its results any more reliable. Anyway. I collected 1024 files 1024 bits each once again and ran the following tests for f in exynos-trng/random*; do ./ea_iid "$f" | grep ^min; done | sort | head -1 for f in rng200/random*; do ./ea_iid "$f" | grep ^min; done | sort | head -1 For both RNGs I got the same min(H_original, 8 X H_bitstring): 3.393082 which, if I understand correctly, means I should set quality to no more than 434. Do you think 400 is OK? Kind regards, -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 1/2] hwrng: iproc-rng200 - Set the quality value 2020-05-14 22:18 ` Lukasz Stelmach @ 2020-05-15 8:32 ` Stephan Mueller [not found] ` <CGME20200515090647eucas1p21018edfd835730c9a68dcb186349ee74@eucas1p2.samsung.com> [not found] ` <CGME20200515090158eucas1p1b653fc50f1ad4f0f6c92525ab3188d45@eucas1p1.samsung.com> 1 sibling, 1 reply; 26+ messages in thread From: Stephan Mueller @ 2020-05-15 8:32 UTC (permalink / raw) To: Lukasz Stelmach Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger, Greg Kroah-Hartman, Matt Mackall, linux-kernel, Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz, Kukjin Kim, Arnd Bergmann, Stefan Wahren, Ray Jui, bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel, linux-crypto Am Freitag, 15. Mai 2020, 00:18:41 CEST schrieb Lukasz Stelmach: Hi Lukasz, > > I am running tests using SP800-90B tools and the first issue I can see > is the warning that samples contain less than 1e6 bytes of data. I know > little about maths behind random number generators, but I have noticed > that the bigger chunk of data from an RNG I feed into either ent or ea_iid > the higher entropy they report. That is why I divided the data into 1024 > bit chunks in the first place. To get worse results. With ea_iid they > get even worse (128 bytes of random data) I read that you seem to just take the output data from the RNG. If this is correct, I think we can stop right here. The output of an RNG is usually after post-processing commonly provided by a cryptographic function. Thus, when processing the output of the RNG all what we measure here is the quality of the cryptographic post-processing and not the entropy that may be present in the data. What we need is to access the noise source and analyze this with the given tool set. And yes, the analysis may require adjusting the data to a format that can be consumed and analyzed by the statistical tests. Ciao Stephan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <CGME20200515090647eucas1p21018edfd835730c9a68dcb186349ee74@eucas1p2.samsung.com>]
* Re: [PATCH 1/2] hwrng: iproc-rng200 - Set the quality value [not found] ` <CGME20200515090647eucas1p21018edfd835730c9a68dcb186349ee74@eucas1p2.samsung.com> @ 2020-05-15 9:06 ` Lukasz Stelmach 0 siblings, 0 replies; 26+ messages in thread From: Lukasz Stelmach @ 2020-05-15 9:06 UTC (permalink / raw) To: Stephan Mueller Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger, Greg Kroah-Hartman, Matt Mackall, linux-kernel, Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz, Kukjin Kim, Arnd Bergmann, Stefan Wahren, Ray Jui, bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel, linux-crypto [-- Attachment #1.1: Type: text/plain, Size: 1483 bytes --] It was <2020-05-15 pią 10:32>, when Stephan Mueller wrote: > Am Freitag, 15. Mai 2020, 00:18:41 CEST schrieb Lukasz Stelmach: > >> I am running tests using SP800-90B tools and the first issue I can see >> is the warning that samples contain less than 1e6 bytes of data. I know >> little about maths behind random number generators, but I have noticed >> that the bigger chunk of data from an RNG I feed into either ent or ea_iid >> the higher entropy they report. That is why I divided the data into 1024 >> bit chunks in the first place. To get worse results. With ea_iid they >> get even worse (128 bytes of random data) > > I read that you seem to just take the output data from the RNG. If this is > correct, I think we can stop right here. The output of an RNG is usually after > post-processing commonly provided by a cryptographic function. > > Thus, when processing the output of the RNG all what we measure here is the > quality of the cryptographic post-processing and not the entropy that may be > present in the data. > > What we need is to access the noise source and analyze this with the given > tool set. And yes, the analysis may require adjusting the data to a format > that can be consumed and analyzed by the statistical tests. I took data from /dev/hwrng which is directly connected to the hardware. See rng_dev_read() in drivers/char/hw_random/core.c. -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <CGME20200515090158eucas1p1b653fc50f1ad4f0f6c92525ab3188d45@eucas1p1.samsung.com>]
* Re: [PATCH 1/2] hwrng: iproc-rng200 - Set the quality value [not found] ` <CGME20200515090158eucas1p1b653fc50f1ad4f0f6c92525ab3188d45@eucas1p1.samsung.com> @ 2020-05-15 9:01 ` Lukasz Stelmach 2020-05-15 9:10 ` Stephan Mueller 0 siblings, 1 reply; 26+ messages in thread From: Lukasz Stelmach @ 2020-05-15 9:01 UTC (permalink / raw) To: Stephan Mueller Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger, Greg Kroah-Hartman, Matt Mackall, linux-kernel, Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz, Kukjin Kim, Arnd Bergmann, Stefan Wahren, Ray Jui, bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel, linux-crypto [-- Attachment #1.1: Type: text/plain, Size: 1999 bytes --] It was <2020-05-15 pią 00:18>, when Lukasz Stelmach wrote: > It was <2020-05-14 czw 22:20>, when Stephan Mueller wrote: >> Am Donnerstag, 14. Mai 2020, 21:07:33 CEST schrieb Łukasz Stelmach: >> >> Hi Łukasz, >> >>> The value has been estimaded by obtainig 1024 chunks of data 128 bytes >>> (1024 bits) each from the generator and finding chunk with minimal >>> entropy using the ent(1) tool. The value was 6.327820 bits of entropy >>> in each 8 bits of data. >> >> I am not sure we should use the ent tool to define the entropy >> level. Ent seems to use a very coarse entropy estimation. >> >> I would feel more comfortable when using other measures like SP800-90B >> which even provides a tool for the analysis. >> >> I understand that entropy estimates, well, are estimates. But the ent >> data is commonly not very conservative. >> >> [1] https://github.com/usnistgov/SP800-90B_EntropyAssessment [...] > Anyway. I collected 1024 files 1024 bits each once again and ran the > following tests > > for f in exynos-trng/random*; do ./ea_iid "$f" | grep ^min; done | sort | head -1 > for f in rng200/random*; do ./ea_iid "$f" | grep ^min; done | sort | head -1 > > For both RNGs I got the same > > min(H_original, 8 X H_bitstring): 3.393082 Oddly enough I've got the same number for other random sources on my x86 | Source | ea_iid -i | ea_iid -c (h') | ent | |--------------+-----------+----------------+----------| | /dev/random | 3.393082 | 0.768654 | 6.300399 | | /dev/urandom | 3.393082 | 0.759161 | 6.348562 | | tpm-rng | 3.393082 | 0.735722 | 6.323990 | | exynos-trng | 3.393082 | 0.687825 | 6.327820 | | rng200 | 3.393082 | 0.740376 | 6.291959 | I suspect 1024 bits is too little for ea_iid to give a meaningfull result. BTW ent results also seem a little oddly low for crng. Any thoughs? -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 1/2] hwrng: iproc-rng200 - Set the quality value 2020-05-15 9:01 ` Lukasz Stelmach @ 2020-05-15 9:10 ` Stephan Mueller [not found] ` <CGME20200515110002eucas1p136759396d9b61f214d1f14856c009501@eucas1p1.samsung.com> 0 siblings, 1 reply; 26+ messages in thread From: Stephan Mueller @ 2020-05-15 9:10 UTC (permalink / raw) To: Lukasz Stelmach Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger, Greg Kroah-Hartman, Matt Mackall, linux-kernel, Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz, Kukjin Kim, Arnd Bergmann, Stefan Wahren, Ray Jui, bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel, linux-crypto Am Freitag, 15. Mai 2020, 11:01:48 CEST schrieb Lukasz Stelmach: Hi Lukasz, As I mentioned, all that is or seems to be analyzed here is the quality of the cryptographic post-processing. Thus none of the data can be used for getting an idea of the entropy content. That said, the ent value indeed looks too low which seems to be an issue in the tool itself. Note, for an entropy assessment commonly at least 1 million traces from the raw noise source are needed. See for examples on how such entropy assessments are conducted in the LRNG documentation [1] or the Linux /dev/random implementation in [2] [1] appendix C of https://www.chronox.de/lrng/doc/lrng.pdf [2] chapter 6 of https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/ Publications/Studies/LinuxRNG/LinuxRNG_EN.pdf Ciao Stephan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <CGME20200515110002eucas1p136759396d9b61f214d1f14856c009501@eucas1p1.samsung.com>]
* Re: [PATCH 1/2] hwrng: iproc-rng200 - Set the quality value [not found] ` <CGME20200515110002eucas1p136759396d9b61f214d1f14856c009501@eucas1p1.samsung.com> @ 2020-05-15 10:59 ` Lukasz Stelmach 0 siblings, 0 replies; 26+ messages in thread From: Lukasz Stelmach @ 2020-05-15 10:59 UTC (permalink / raw) To: Stephan Mueller Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger, Greg Kroah-Hartman, Matt Mackall, linux-kernel, Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz, Kukjin Kim, Arnd Bergmann, Stefan Wahren, Ray Jui, bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel, linux-crypto [-- Attachment #1.1: Type: text/plain, Size: 1410 bytes --] It was <2020-05-15 pią 11:10>, when Stephan Mueller wrote: > As I mentioned, all that is or seems to be analyzed here is the > quality of the cryptographic post-processing. Thus none of the data > can be used for getting an idea of the entropy content. > > That said, the ent value indeed looks too low which seems to be an > issue in the tool itself. > > Note, for an entropy assessment commonly at least 1 million traces > from the raw noise source are needed. I've got 1MiB from each source. Of course I used raw data from /dev/hwrng for tpm, exynos and rng200. | Source | ea_iid -i | ea_iid -c (h') | ent | |--------------+-----------+----------------+----------| | /dev/random | 7.875064 | 0.998166 | 7.999801 | | /dev/urandom | 7.879351 | 0.998373 | 7.999821 | | tpm-rng | 7.880012 | 0.998118 | 7.999828 | | exynos-trng | 7.435701 | 0.947574 | 7.991820 | | rng200 | 7.883320 | 0.998592 | 7.999824 | > See for examples on how such entropy assessments are conducted in the LRNG > documentation [1] or the Linux /dev/random implementation in [2] Thanks a lot, I am reading. I will try to write somthing clever as soon as I parse and understand these documents (and do other stuff too). Thank you very much for your help. Kind regards, -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <CGME20200514190740eucas1p293129b2ef3ba706652a9327e55db9649@eucas1p2.samsung.com>]
* [PATCH 2/2] hwrng: exynos - Set the quality value [not found] ` <CGME20200514190740eucas1p293129b2ef3ba706652a9327e55db9649@eucas1p2.samsung.com> @ 2020-05-14 19:07 ` Łukasz Stelmach 2020-05-14 20:20 ` Stephan Mueller 0 siblings, 1 reply; 26+ messages in thread From: Łukasz Stelmach @ 2020-05-14 19:07 UTC (permalink / raw) To: Matt Mackall, Herbert Xu, Arnd Bergmann, Greg Kroah-Hartman, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Kukjin Kim, Krzysztof Kozlowski, Florian Fainelli, Markus Elfring, Matthias Brugger, Stefan Wahren, linux-crypto, linux-arm-kernel, linux-kernel, linux-samsung-soc Cc: Łukasz Stelmach, Bartlomiej Zolnierkiewicz The value has been estimaded by obtainig 1024 chunks of data 128 bytes (1024 bits) each from the generator and finding chunk with minimal entropy using the ent(1) tool. The value was 6.332937 bits of entropy in each 8 bits of data. Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com> --- drivers/char/hw_random/exynos-trng.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/char/hw_random/exynos-trng.c b/drivers/char/hw_random/exynos-trng.c index 8e1fe3f8dd2d..ff6739272bf5 100644 --- a/drivers/char/hw_random/exynos-trng.c +++ b/drivers/char/hw_random/exynos-trng.c @@ -123,6 +123,7 @@ static int exynos_trng_probe(struct platform_device *pdev) trng->rng.init = exynos_trng_init; trng->rng.read = exynos_trng_do_read; trng->rng.priv = (unsigned long) trng; + trng->rng.quality = 800; platform_set_drvdata(pdev, trng); trng->dev = &pdev->dev; -- 2.25.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: [PATCH 2/2] hwrng: exynos - Set the quality value 2020-05-14 19:07 ` [PATCH 2/2] hwrng: exynos " Łukasz Stelmach @ 2020-05-14 20:20 ` Stephan Mueller 0 siblings, 0 replies; 26+ messages in thread From: Stephan Mueller @ 2020-05-14 20:20 UTC (permalink / raw) To: Łukasz Stelmach Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger, Greg Kroah-Hartman, Matt Mackall, linux-kernel, Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz, Kukjin Kim, Arnd Bergmann, Stefan Wahren, Ray Jui, bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel, linux-crypto Am Donnerstag, 14. Mai 2020, 21:07:34 CEST schrieb Łukasz Stelmach: Hi Łukasz, > The value has been estimaded by obtainig 1024 chunks of data 128 bytes > (1024 bits) each from the generator and finding chunk with minimal > entropy using the ent(1) tool. The value was 6.332937 bits of entropy > in each 8 bits of data. Dto - see the other comment. Ciao Stephan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <CGME20200519212617eucas1p1b6e7af0ecb894896b165601fafd6abe8@eucas1p1.samsung.com>]
* [PATCH v2 0/2] Set the quality value for two HW RNGs [not found] ` <CGME20200519212617eucas1p1b6e7af0ecb894896b165601fafd6abe8@eucas1p1.samsung.com> @ 2020-05-19 21:25 ` Łukasz Stelmach [not found] ` <CGME20200519212619eucas1p22fa5d3db2521096dc4b79f6e53016d17@eucas1p2.samsung.com> [not found] ` <CGME20200519212621eucas1p13279db41d930b69e115972463c994a37@eucas1p1.samsung.com> 0 siblings, 2 replies; 26+ messages in thread From: Łukasz Stelmach @ 2020-05-19 21:25 UTC (permalink / raw) To: Matt Mackall, Herbert Xu, Arnd Bergmann, Greg Kroah-Hartman, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Kukjin Kim, Krzysztof Kozlowski, Florian Fainelli, Markus Elfring, Matthias Brugger, Stefan Wahren, linux-crypto, linux-arm-kernel, linux-kernel, linux-samsung-soc, Stephan Mueller Cc: Łukasz Stelmach, Bartlomiej Zolnierkiewicz The rng structure contains the quality field which tells how many bits of entropy can be obtained from 1024 bits read from a device. With the quality value set the hw_random framework starts a kernel thread to feed the entropy pool in the CRNG, which helps to initialize it quickly especially during boot. Łukasz Stelmach (2): hwrng: iproc-rng200 - Set the quality value hwrng: exynos - Set the quality value drivers/char/hw_random/exynos-trng.c | 1 + drivers/char/hw_random/iproc-rng200.c | 1 + 2 files changed, 2 insertions(+) v2: - recalculated values using the SP800-90B_EntropyAssessment package -- 2.25.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <CGME20200519212619eucas1p22fa5d3db2521096dc4b79f6e53016d17@eucas1p2.samsung.com>]
* [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value [not found] ` <CGME20200519212619eucas1p22fa5d3db2521096dc4b79f6e53016d17@eucas1p2.samsung.com> @ 2020-05-19 21:25 ` Łukasz Stelmach 2020-05-20 6:23 ` Stephan Mueller ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: Łukasz Stelmach @ 2020-05-19 21:25 UTC (permalink / raw) To: Matt Mackall, Herbert Xu, Arnd Bergmann, Greg Kroah-Hartman, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Kukjin Kim, Krzysztof Kozlowski, Florian Fainelli, Markus Elfring, Matthias Brugger, Stefan Wahren, linux-crypto, linux-arm-kernel, linux-kernel, linux-samsung-soc, Stephan Mueller Cc: Łukasz Stelmach, Bartlomiej Zolnierkiewicz The value was estimaded with ea_iid[1] using on 10485760 bytes read from the RNG via /dev/hwrng. The min-entropy value calculated using the most common value estimate (NIST SP 800-90P[2], section 6.3.1) was 7.964464. [1] https://github.com/usnistgov/SP800-90B_EntropyAssessment [2] https://csrc.nist.gov/publications/detail/sp/800-90b/final Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com> --- drivers/char/hw_random/iproc-rng200.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/char/hw_random/iproc-rng200.c b/drivers/char/hw_random/iproc-rng200.c index 32d9fe61a225..95669ece050f 100644 --- a/drivers/char/hw_random/iproc-rng200.c +++ b/drivers/char/hw_random/iproc-rng200.c @@ -199,6 +199,7 @@ static int iproc_rng200_probe(struct platform_device *pdev) priv->rng.read = iproc_rng200_read, priv->rng.init = iproc_rng200_init, priv->rng.cleanup = iproc_rng200_cleanup, + priv->rng.quality = 1000, /* Register driver */ ret = devm_hwrng_register(dev, &priv->rng); -- 2.26.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value 2020-05-19 21:25 ` [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value Łukasz Stelmach @ 2020-05-20 6:23 ` Stephan Mueller [not found] ` <CGME20200520091043eucas1p15ecae108007382a95b01e42241cc7a26@eucas1p1.samsung.com> 2020-05-20 8:18 ` Kamil Konieczny 2020-05-21 11:00 ` Stefan Wahren 2 siblings, 1 reply; 26+ messages in thread From: Stephan Mueller @ 2020-05-20 6:23 UTC (permalink / raw) To: Łukasz Stelmach Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger, Greg Kroah-Hartman, Matt Mackall, linux-kernel, Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz, Kukjin Kim, Arnd Bergmann, Stefan Wahren, Ray Jui, bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel, linux-crypto Am Dienstag, 19. Mai 2020, 23:25:51 CEST schrieb Łukasz Stelmach: Hi Łukasz, > The value was estimaded with ea_iid[1] using on 10485760 bytes read from > the RNG via /dev/hwrng. The min-entropy value calculated using the most > common value estimate (NIST SP 800-90P[2], section 6.3.1) was 7.964464. I am sorry, but I think I did not make myself clear: testing random numbers post-processing with the statistical tools does NOT give any idea about the entropy rate. Thus, all that was calculated is the proper implementation of the post-processing operation and not the actual noise source. What needs to happen is that we need access to raw, unconditioned data from the noise source that is analyzed with the statistical methods. Ciao Stephan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <CGME20200520091043eucas1p15ecae108007382a95b01e42241cc7a26@eucas1p1.samsung.com>]
* Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value [not found] ` <CGME20200520091043eucas1p15ecae108007382a95b01e42241cc7a26@eucas1p1.samsung.com> @ 2020-05-20 9:10 ` Lukasz Stelmach 2020-05-20 9:18 ` Stephan Mueller 0 siblings, 1 reply; 26+ messages in thread From: Lukasz Stelmach @ 2020-05-20 9:10 UTC (permalink / raw) To: Stephan Mueller Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger, Greg Kroah-Hartman, Matt Mackall, linux-kernel, Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz, Kukjin Kim, Arnd Bergmann, Stefan Wahren, Ray Jui, bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel, linux-crypto [-- Attachment #1.1: Type: text/plain, Size: 1476 bytes --] It was <2020-05-20 śro 08:23>, when Stephan Mueller wrote: > Am Dienstag, 19. Mai 2020, 23:25:51 CEST schrieb Łukasz Stelmach: > >> The value was estimaded with ea_iid[1] using on 10485760 bytes read from >> the RNG via /dev/hwrng. The min-entropy value calculated using the most >> common value estimate (NIST SP 800-90P[2], section 6.3.1) was 7.964464. > > I am sorry, but I think I did not make myself clear: testing random numbers > post-processing with the statistical tools does NOT give any idea about the > entropy rate. Thus, all that was calculated is the proper implementation of > the post-processing operation and not the actual noise source. > > What needs to happen is that we need access to raw, unconditioned data from > the noise source that is analyzed with the statistical methods. I did understand you and I assure you the data I tested were obtained directly from RNGs. As I pointed before[1], that is how /dev/hwrng works[2]. If I am wrong, do show me the code that processes the data from a HW RNG before copying them to user provided buffer[3]. [1] https://lkml.org/lkml/2020/5/15/252 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/hw_random.rst?h=v5.6 [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/hw_random/core.c?h=v5.6#n251 Kind regards, -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value 2020-05-20 9:10 ` Lukasz Stelmach @ 2020-05-20 9:18 ` Stephan Mueller [not found] ` <CGME20200520104448eucas1p122e9a8ed84d5276a1b796e10ef5e1964@eucas1p1.samsung.com> 0 siblings, 1 reply; 26+ messages in thread From: Stephan Mueller @ 2020-05-20 9:18 UTC (permalink / raw) To: Lukasz Stelmach Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger, Greg Kroah-Hartman, Matt Mackall, linux-kernel, Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz, Kukjin Kim, Arnd Bergmann, Stefan Wahren, Ray Jui, bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel, linux-crypto Am Mittwoch, 20. Mai 2020, 11:10:32 CEST schrieb Lukasz Stelmach: Hi Lukasz, > It was <2020-05-20 śro 08:23>, when Stephan Mueller wrote: > > Am Dienstag, 19. Mai 2020, 23:25:51 CEST schrieb Łukasz Stelmach: > >> The value was estimaded with ea_iid[1] using on 10485760 bytes read from > >> the RNG via /dev/hwrng. The min-entropy value calculated using the most > >> common value estimate (NIST SP 800-90P[2], section 6.3.1) was 7.964464. > > > > I am sorry, but I think I did not make myself clear: testing random > > numbers > > post-processing with the statistical tools does NOT give any idea about > > the > > entropy rate. Thus, all that was calculated is the proper implementation > > of > > the post-processing operation and not the actual noise source. > > > > What needs to happen is that we need access to raw, unconditioned data > > from > > the noise source that is analyzed with the statistical methods. > > I did understand you and I assure you the data I tested were obtained > directly from RNGs. As I pointed before[1], that is how /dev/hwrng > works[2]. I understand that /dev/hwrng pulls the data straight from the hardware. But the data from the hardware usually is not obtained straight from the noise source. Typically you have a noise source (e.g. a ring oscillator) whose data is digitized then fed into a compression function like an LFSR or a hash. Then a cryptographic operation like a CBC-MAC, hash or even a DRBG is applied to that data when the caller wants to have random numbers. In order to estimate entropy, we need the raw unconditioned data from the, say, ring oscillator and not from the (cryptographic) output operation. That said, the illustrated example is typical for hardware RNGs. Yet it is never guaranteed to work that way. Thus, if you can point to architecture documentation of your specific hardware RNGs showing that the data read from the hardware is pure unconditioned noise data, then I have no objections to the patch. > > If I am wrong, do show me the code that processes the data from a HW RNG > before copying them to user provided buffer[3]. I am not talking about any software post-processing. I am talking about post- processing within the hardware. > > [1] https://lkml.org/lkml/2020/5/15/252 > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Doc > umentation/admin-guide/hw_random.rst?h=v5.6 [3] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri > vers/char/hw_random/core.c?h=v5.6#n251 > > Kind regards, Ciao Stephan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <CGME20200520104448eucas1p122e9a8ed84d5276a1b796e10ef5e1964@eucas1p1.samsung.com>]
* Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value [not found] ` <CGME20200520104448eucas1p122e9a8ed84d5276a1b796e10ef5e1964@eucas1p1.samsung.com> @ 2020-05-20 10:44 ` Lukasz Stelmach 2020-05-20 11:53 ` Stephan Mueller 0 siblings, 1 reply; 26+ messages in thread From: Lukasz Stelmach @ 2020-05-20 10:44 UTC (permalink / raw) To: Stephan Mueller Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger, Greg Kroah-Hartman, Matt Mackall, linux-kernel, Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz, Kukjin Kim, Arnd Bergmann, Stefan Wahren, Ray Jui, bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel, linux-crypto [-- Attachment #1.1: Type: text/plain, Size: 3231 bytes --] It was <2020-05-20 śro 11:18>, when Stephan Mueller wrote: > Am Mittwoch, 20. Mai 2020, 11:10:32 CEST schrieb Lukasz Stelmach: >> It was <2020-05-20 śro 08:23>, when Stephan Mueller wrote: >>> Am Dienstag, 19. Mai 2020, 23:25:51 CEST schrieb Łukasz Stelmach: >>>> The value was estimaded with ea_iid[1] using on 10485760 bytes read >>>> from the RNG via /dev/hwrng. The min-entropy value calculated using >>>> the most common value estimate (NIST SP 800-90P[2], section 6.3.1) >>>> was 7.964464. >>> >>> I am sorry, but I think I did not make myself clear: testing random >>> numbers post-processing with the statistical tools does NOT give any >>> idea about the entropy rate. Thus, all that was calculated is the >>> proper implementation of the post-processing operation and not the >>> actual noise source. >>> >>> What needs to happen is that we need access to raw, unconditioned >>> data from the noise source that is analyzed with the statistical >>> methods. >> >> I did understand you and I assure you the data I tested were obtained >> directly from RNGs. As I pointed before[1], that is how /dev/hwrng >> works[2]. > > I understand that /dev/hwrng pulls the data straight from the > hardware. But the data from the hardware usually is not obtained > straight from the noise source. > > Typically you have a noise source (e.g. a ring oscillator) whose data > is digitized then fed into a compression function like an LFSR or a > hash. Then a cryptographic operation like a CBC-MAC, hash or even a > DRBG is applied to that data when the caller wants to have random > numbers. I do understand your point (but not entirely, see below). [opinion] However, I am really not sure that this is a "typical" setting for a HW RNG, at least not among RNGs supported by Linux. Otherwise there would be no hw_random framework and no rngd(8) which are suppsed to post-process imperfectly random data from HW. [/opinion] > In order to estimate entropy, we need the raw unconditioned data from > the, say, ring oscillator and not from the (cryptographic) output > operation. Can you tell, why it matters in this case? If I understand correctly, the quality field describes not the randomness created by the noise generator but the one delivered by the driver to other software components. > That said, the illustrated example is typical for hardware RNGs. Yet > it is never guaranteed to work that way. Thus, if you can point to > architecture documentation of your specific hardware RNGs showing that > the data read from the hardware is pure unconditioned noise data, then > I have no objections to the patch. I can tell for sure that this is the case for exynos-trng[1]. There is a post-processor which I have forgotten about since writing the driver, because from the very beginning I didn't intend to use it. I knew there is the software framework for post-processing and simply didn't bother. With regards to iproc-rng200 I cannot be sure. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/hw_random/exynos-trng.c?h=v5.6#n100 Kind regards, -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value 2020-05-20 10:44 ` Lukasz Stelmach @ 2020-05-20 11:53 ` Stephan Mueller 2020-05-20 12:00 ` Krzysztof Kozlowski [not found] ` <CGME20200520143211eucas1p21bd93be5c62726aa715db05bb6e7119b@eucas1p2.samsung.com> 0 siblings, 2 replies; 26+ messages in thread From: Stephan Mueller @ 2020-05-20 11:53 UTC (permalink / raw) To: Lukasz Stelmach Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger, Greg Kroah-Hartman, Matt Mackall, linux-kernel, Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz, Kukjin Kim, Arnd Bergmann, Stefan Wahren, Ray Jui, bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel, linux-crypto Am Mittwoch, 20. Mai 2020, 12:44:33 CEST schrieb Lukasz Stelmach: Hi Lukasz, > It was <2020-05-20 śro 11:18>, when Stephan Mueller wrote: > > Am Mittwoch, 20. Mai 2020, 11:10:32 CEST schrieb Lukasz Stelmach: > >> It was <2020-05-20 śro 08:23>, when Stephan Mueller wrote: > >>> Am Dienstag, 19. Mai 2020, 23:25:51 CEST schrieb Łukasz Stelmach: > >>>> The value was estimaded with ea_iid[1] using on 10485760 bytes read > >>>> from the RNG via /dev/hwrng. The min-entropy value calculated using > >>>> the most common value estimate (NIST SP 800-90P[2], section 6.3.1) > >>>> was 7.964464. > >>> > >>> I am sorry, but I think I did not make myself clear: testing random > >>> numbers post-processing with the statistical tools does NOT give any > >>> idea about the entropy rate. Thus, all that was calculated is the > >>> proper implementation of the post-processing operation and not the > >>> actual noise source. > >>> > >>> What needs to happen is that we need access to raw, unconditioned > >>> data from the noise source that is analyzed with the statistical > >>> methods. > >> > >> I did understand you and I assure you the data I tested were obtained > >> directly from RNGs. As I pointed before[1], that is how /dev/hwrng > >> works[2]. > > > > I understand that /dev/hwrng pulls the data straight from the > > hardware. But the data from the hardware usually is not obtained > > straight from the noise source. > > > > Typically you have a noise source (e.g. a ring oscillator) whose data > > is digitized then fed into a compression function like an LFSR or a > > hash. Then a cryptographic operation like a CBC-MAC, hash or even a > > DRBG is applied to that data when the caller wants to have random > > numbers. > > I do understand your point (but not entirely, see below). [opinion] > However, I am really not sure that this is a "typical" setting for a HW > RNG, at least not among RNGs supported by Linux. Otherwise there would > be no hw_random framework and no rngd(8) which are suppsed to > post-process imperfectly random data from HW. [/opinion] The hw_random framework only makes these hardware RNG accessible for in-kernel as well as user space use. > > > In order to estimate entropy, we need the raw unconditioned data from > > the, say, ring oscillator and not from the (cryptographic) output > > operation. > > Can you tell, why it matters in this case? If I understand correctly, > the quality field describes not the randomness created by the noise > generator but the one delivered by the driver to other software > components. The quality field is used by add_hwgenerator_randomness to increase the Linux RNG entropy estimator accordingly. This is the issue. And giving an entropy rate based on post-processed data is meaningless. The concern is, for example, that you use a DRBG that you seeded with, say, a zero buffer. You get perfect random data from it that no statistical test can disprove. Yet we know this data stream has zero entropy. Thus, we need to get to the source and assess its entropy. > > > That said, the illustrated example is typical for hardware RNGs. Yet > > it is never guaranteed to work that way. Thus, if you can point to > > architecture documentation of your specific hardware RNGs showing that > > the data read from the hardware is pure unconditioned noise data, then > > I have no objections to the patch. > > I can tell for sure that this is the case for exynos-trng[1]. So you are saying that the output for the exynos-trng is straight from a ring oscillator without any post-processing of any kind? If this is the case, I would like to suggest you add that statement to the git commit message with that reference. If so, then I would withdraw my objection. > There is a > post-processor which I have forgotten about since writing the driver, > because from the very beginning I didn't intend to use it. I knew there > is the software framework for post-processing and simply didn't bother. > > With regards to iproc-rng200 I cannot be sure. > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri > vers/char/hw_random/exynos-trng.c?h=v5.6#n100 > > Kind regards, Ciao Stephan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value 2020-05-20 11:53 ` Stephan Mueller @ 2020-05-20 12:00 ` Krzysztof Kozlowski 2020-05-20 12:11 ` Stephan Mueller [not found] ` <CGME20200520143211eucas1p21bd93be5c62726aa715db05bb6e7119b@eucas1p2.samsung.com> 1 sibling, 1 reply; 26+ messages in thread From: Krzysztof Kozlowski @ 2020-05-20 12:00 UTC (permalink / raw) To: Stephan Mueller Cc: Florian Fainelli, Herbert Xu, Arnd Bergmann, Matthias Brugger, Greg Kroah-Hartman, Matt Mackall, Lukasz Stelmach, Scott Branden, linux-kernel, linux-samsung-soc, Bartlomiej Zolnierkiewicz, Kukjin Kim, bcm-kernel-feedback-list, Stefan Wahren, Ray Jui, Markus Elfring, linux-arm-kernel, linux-crypto On Wed, 20 May 2020 at 13:53, Stephan Mueller <smueller@chronox.de> wrote: > > > That said, the illustrated example is typical for hardware RNGs. Yet > > > it is never guaranteed to work that way. Thus, if you can point to > > > architecture documentation of your specific hardware RNGs showing that > > > the data read from the hardware is pure unconditioned noise data, then > > > I have no objections to the patch. > > > > I can tell for sure that this is the case for exynos-trng[1]. > > So you are saying that the output for the exynos-trng is straight from a ring > oscillator without any post-processing of any kind? Hi, I think we will never be able to state this because the manual is quite limited in sharing internals. What the driver does and probably Lukasz wanted to say is that there is "post processing" block and feature which can be disabled. The manual is saying the TRNG block generates random data from thermal noise but not how much in a direct way. There could be some simple post-processing or not (except the one able to on/off). Also manual says this post processing block is there to remove statistical weakness from the TRNG block. To me it does not prove enough that raw data is really raw... Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value 2020-05-20 12:00 ` Krzysztof Kozlowski @ 2020-05-20 12:11 ` Stephan Mueller 0 siblings, 0 replies; 26+ messages in thread From: Stephan Mueller @ 2020-05-20 12:11 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Florian Fainelli, Herbert Xu, Arnd Bergmann, Matthias Brugger, Greg Kroah-Hartman, Matt Mackall, Lukasz Stelmach, Scott Branden, linux-kernel, linux-samsung-soc, Bartlomiej Zolnierkiewicz, Kukjin Kim, bcm-kernel-feedback-list, Stefan Wahren, Ray Jui, Markus Elfring, linux-arm-kernel, linux-crypto Am Mittwoch, 20. Mai 2020, 14:00:01 CEST schrieb Krzysztof Kozlowski: Hi Krzysztof, > On Wed, 20 May 2020 at 13:53, Stephan Mueller <smueller@chronox.de> wrote: > > > > That said, the illustrated example is typical for hardware RNGs. Yet > > > > it is never guaranteed to work that way. Thus, if you can point to > > > > architecture documentation of your specific hardware RNGs showing that > > > > the data read from the hardware is pure unconditioned noise data, then > > > > I have no objections to the patch. > > > > > > I can tell for sure that this is the case for exynos-trng[1]. > > > > So you are saying that the output for the exynos-trng is straight from a > > ring oscillator without any post-processing of any kind? > > Hi, > > I think we will never be able to state this because the manual is > quite limited in sharing internals. What the driver does and probably > Lukasz wanted to say is that there is "post processing" block and > feature which can be disabled. The manual is saying the TRNG block > generates random data from thermal noise but not how much in a direct > way. There could be some simple post-processing or not (except the one > able to on/off). Also manual says this post processing block is there > to remove statistical weakness from the TRNG block. To me it does not > prove enough that raw data is really raw... Unterstood, but can't that statement be added to the commit message? > > Best regards, > Krzysztof Ciao Stephan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <CGME20200520143211eucas1p21bd93be5c62726aa715db05bb6e7119b@eucas1p2.samsung.com>]
* Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value [not found] ` <CGME20200520143211eucas1p21bd93be5c62726aa715db05bb6e7119b@eucas1p2.samsung.com> @ 2020-05-20 14:31 ` Lukasz Stelmach 0 siblings, 0 replies; 26+ messages in thread From: Lukasz Stelmach @ 2020-05-20 14:31 UTC (permalink / raw) To: Stephan Mueller Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger, Greg Kroah-Hartman, Matt Mackall, linux-kernel, Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz, Kukjin Kim, Arnd Bergmann, Stefan Wahren, Ray Jui, bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel, linux-crypto [-- Attachment #1.1: Type: text/plain, Size: 3719 bytes --] It was <2020-05-20 śro 13:53>, when Stephan Mueller wrote: > Am Mittwoch, 20. Mai 2020, 12:44:33 CEST schrieb Lukasz Stelmach: >> It was <2020-05-20 śro 11:18>, when Stephan Mueller wrote: >>> Am Mittwoch, 20. Mai 2020, 11:10:32 CEST schrieb Lukasz Stelmach: >>>> It was <2020-05-20 śro 08:23>, when Stephan Mueller wrote: >>>>> Am Dienstag, 19. Mai 2020, 23:25:51 CEST schrieb Łukasz Stelmach: >>>>> >>>>>> The value was estimaded with ea_iid[1] using on 10485760 bytes >>>>>> read from the RNG via /dev/hwrng. The min-entropy value >>>>>> calculated using the most common value estimate (NIST SP >>>>>> 800-90P[2], section 6.3.1) was 7.964464. >>>>> >>>>> I am sorry, but I think I did not make myself clear: testing >>>>> random numbers post-processing with the statistical tools does NOT >>>>> give any idea about the entropy rate. Thus, all that was >>>>> calculated is the proper implementation of the post-processing >>>>> operation and not the actual noise source. >>>>> >>>>> What needs to happen is that we need access to raw, unconditioned >>>>> data from the noise source that is analyzed with the statistical >>>>> methods. >>>> >>>> I did understand you and I assure you the data I tested were >>>> obtained directly from RNGs. As I pointed before[1], that is how >>>> /dev/hwrng works[2]. >>> >>> I understand that /dev/hwrng pulls the data straight from the >>> hardware. But the data from the hardware usually is not obtained >>> straight from the noise source. >>> >>> Typically you have a noise source (e.g. a ring oscillator) whose data >>> is digitized then fed into a compression function like an LFSR or a >>> hash. Then a cryptographic operation like a CBC-MAC, hash or even a >>> DRBG is applied to that data when the caller wants to have random >>> numbers. [...] >>> In order to estimate entropy, we need the raw unconditioned data from >>> the, say, ring oscillator and not from the (cryptographic) output >>> operation. >> >> Can you tell, why it matters in this case? If I understand correctly, >> the quality field describes not the randomness created by the noise >> generator but the one delivered by the driver to other software >> components. > > The quality field is used by add_hwgenerator_randomness to increase > the Linux RNG entropy estimator accordingly. This is the issue. > > And giving an entropy rate based on post-processed data is > meaningless. > > The concern is, for example, that you use a DRBG that you seeded with, > say, a zero buffer. You get perfect random data from it that no > statistical test can disprove. Yet we know this data stream has zero > entropy. Thus, we need to get to the source and assess its entropy. Of course, this makes sense. >>> That said, the illustrated example is typical for hardware RNGs. Yet >>> it is never guaranteed to work that way. Thus, if you can point to >>> architecture documentation of your specific hardware RNGs showing >>> that the data read from the hardware is pure unconditioned noise >>> data, then I have no objections to the patch. >> >> I can tell for sure that this is the case for exynos-trng[1]. > > So you are saying that the output for the exynos-trng is straight from > a ring oscillator without any post-processing of any kind? > > If this is the case, I would like to suggest you add that statement to > the git commit message with that reference. If so, then I would > withdraw my objection. Done. I will do some reaserch on iproc-rng200 and I will send v3 with the altered commit message. Thank you *very* much for your patience. -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value 2020-05-19 21:25 ` [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value Łukasz Stelmach 2020-05-20 6:23 ` Stephan Mueller @ 2020-05-20 8:18 ` Kamil Konieczny 2020-05-21 11:00 ` Stefan Wahren 2 siblings, 0 replies; 26+ messages in thread From: Kamil Konieczny @ 2020-05-20 8:18 UTC (permalink / raw) To: Łukasz Stelmach, Matt Mackall, Herbert Xu, Arnd Bergmann, Greg Kroah-Hartman, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Kukjin Kim, Krzysztof Kozlowski, Florian Fainelli, Markus Elfring, Matthias Brugger, Stefan Wahren, linux-crypto, linux-arm-kernel, linux-kernel, linux-samsung-soc, Stephan Mueller Cc: Bartlomiej Zolnierkiewicz Hi, On 19.05.2020 23:25, Łukasz Stelmach wrote: > The value was estimaded with ea_iid[1] using on 10485760 bytes read from > the RNG via /dev/hwrng. The min-entropy value calculated using the most > common value estimate (NIST SP 800-90P[2], section 6.3.1) was 7.964464. > > [1] https://protect2.fireeye.com/url?k=316f3d79-6cf9840e-316eb636-0cc47a312ab0-5f119f729b3ddc11&q=1&u=https%3A%2F%2Fgithub.com%2Fusnistgov%2FSP800-90B_EntropyAssessment This link looks ugly and do not protect anything. Can you just cut out that "protect2" thing and put proper direct link to github ? > [2] https://csrc.nist.gov/publications/detail/sp/800-90b/final > > Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com> > --- > drivers/char/hw_random/iproc-rng200.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/char/hw_random/iproc-rng200.c b/drivers/char/hw_random/iproc-rng200.c > index 32d9fe61a225..95669ece050f 100644 > --- a/drivers/char/hw_random/iproc-rng200.c > +++ b/drivers/char/hw_random/iproc-rng200.c > @@ -199,6 +199,7 @@ static int iproc_rng200_probe(struct platform_device *pdev) > priv->rng.read = iproc_rng200_read, > priv->rng.init = iproc_rng200_init, > priv->rng.cleanup = iproc_rng200_cleanup, > + priv->rng.quality = 1000, > > /* Register driver */ > ret = devm_hwrng_register(dev, &priv->rng); > -- Best regards, Kamil Konieczny Samsung R&D Institute Poland _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value 2020-05-19 21:25 ` [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value Łukasz Stelmach 2020-05-20 6:23 ` Stephan Mueller 2020-05-20 8:18 ` Kamil Konieczny @ 2020-05-21 11:00 ` Stefan Wahren [not found] ` <CGME20200521191415eucas1p2d112a86171b23dcf255e7da53a56f4f3@eucas1p2.samsung.com> 2 siblings, 1 reply; 26+ messages in thread From: Stefan Wahren @ 2020-05-21 11:00 UTC (permalink / raw) To: Łukasz Stelmach, Matt Mackall, Herbert Xu, Arnd Bergmann, Greg Kroah-Hartman, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Kukjin Kim, Krzysztof Kozlowski, Florian Fainelli, Markus Elfring, Matthias Brugger, linux-crypto, linux-arm-kernel, linux-kernel, linux-samsung-soc, Stephan Mueller Cc: Bartlomiej Zolnierkiewicz Hi Lukasz, Am 19.05.20 um 23:25 schrieb Łukasz Stelmach: > The value was estimaded with ea_iid[1] using on 10485760 bytes read from > the RNG via /dev/hwrng. The min-entropy value calculated using the most > common value estimate (NIST SP 800-90P[2], section 6.3.1) was 7.964464. could you please mention in the commit the used hardware implementation(s) of iproc-rng200 to get this quality? AFAIK there is still no public register description at least for the bcm2711. So is it safe to assume that the suggested quality applies to all possible configurations? Thanks Stefan > > [1] https://github.com/usnistgov/SP800-90B_EntropyAssessment > [2] https://csrc.nist.gov/publications/detail/sp/800-90b/final > > Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com> > --- > drivers/char/hw_random/iproc-rng200.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/char/hw_random/iproc-rng200.c b/drivers/char/hw_random/iproc-rng200.c > index 32d9fe61a225..95669ece050f 100644 > --- a/drivers/char/hw_random/iproc-rng200.c > +++ b/drivers/char/hw_random/iproc-rng200.c > @@ -199,6 +199,7 @@ static int iproc_rng200_probe(struct platform_device *pdev) > priv->rng.read = iproc_rng200_read, > priv->rng.init = iproc_rng200_init, > priv->rng.cleanup = iproc_rng200_cleanup, > + priv->rng.quality = 1000, > > /* Register driver */ > ret = devm_hwrng_register(dev, &priv->rng); _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <CGME20200521191415eucas1p2d112a86171b23dcf255e7da53a56f4f3@eucas1p2.samsung.com>]
* Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value [not found] ` <CGME20200521191415eucas1p2d112a86171b23dcf255e7da53a56f4f3@eucas1p2.samsung.com> @ 2020-05-21 19:14 ` Lukasz Stelmach 2020-05-23 18:46 ` Stephan Müller 0 siblings, 1 reply; 26+ messages in thread From: Lukasz Stelmach @ 2020-05-21 19:14 UTC (permalink / raw) To: Stefan Wahren Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger, Stephan Mueller, Greg Kroah-Hartman, Matt Mackall, linux-kernel, Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz, Kukjin Kim, Arnd Bergmann, linux-crypto, Ray Jui, bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel [-- Attachment #1.1: Type: text/plain, Size: 2205 bytes --] It was <2020-05-21 czw 13:00>, when Stefan Wahren wrote: > Hi Lukasz, > > Am 19.05.20 um 23:25 schrieb Łukasz Stelmach: >> The value was estimaded with ea_iid[1] using on 10485760 bytes read from >> the RNG via /dev/hwrng. The min-entropy value calculated using the most >> common value estimate (NIST SP 800-90P[2], section 6.3.1) was 7.964464. > > could you please mention in the commit the used hardware > implementation(s) of iproc-rng200 to get this quality? > > AFAIK there is still no public register description at least for the > bcm2711. So is it safe to assume that the suggested quality applies to > all possible configurations? I've learnt that there is a post-processing unit in RNG200 that tests the output of the noise generator and fills FIFO only with data that passes FIPS tests. Unlike simmilar unit in Exynos, it cannot be disabled or bypassed. Therefore, after Stephan Mueller's thorough explanations I am considering dropping this patch in v3. However, I stil am still not 100% convinced that it is impossible to assign the quality a reasonable non-zero value in such case. > Thanks > Stefan > >> >> [1] https://protect2.fireeye.com/url?k=da4735b2-87d99b28-da46befd-0cc47a336fae-e1c21080bc6ab1e4&q=1&u=https%3A%2F%2Fgithub.com%2Fusnistgov%2FSP800-90B_EntropyAssessment >> [2] https://csrc.nist.gov/publications/detail/sp/800-90b/final >> >> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com> >> --- >> drivers/char/hw_random/iproc-rng200.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/char/hw_random/iproc-rng200.c b/drivers/char/hw_random/iproc-rng200.c >> index 32d9fe61a225..95669ece050f 100644 >> --- a/drivers/char/hw_random/iproc-rng200.c >> +++ b/drivers/char/hw_random/iproc-rng200.c >> @@ -199,6 +199,7 @@ static int iproc_rng200_probe(struct platform_device *pdev) >> priv->rng.read = iproc_rng200_read, >> priv->rng.init = iproc_rng200_init, >> priv->rng.cleanup = iproc_rng200_cleanup, >> + priv->rng.quality = 1000, >> >> /* Register driver */ >> ret = devm_hwrng_register(dev, &priv->rng); > > -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value 2020-05-21 19:14 ` Lukasz Stelmach @ 2020-05-23 18:46 ` Stephan Müller 0 siblings, 0 replies; 26+ messages in thread From: Stephan Müller @ 2020-05-23 18:46 UTC (permalink / raw) To: Stefan Wahren, Lukasz Stelmach Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger, Greg Kroah-Hartman, Matt Mackall, linux-kernel, Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz, Kukjin Kim, Arnd Bergmann, linux-crypto, Ray Jui, bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel Am Donnerstag, 21. Mai 2020, 21:14:02 CEST schrieb Lukasz Stelmach: Hi Lukasz, > It was <2020-05-21 czw 13:00>, when Stefan Wahren wrote: > > Hi Lukasz, > > > > Am 19.05.20 um 23:25 schrieb Łukasz Stelmach: > >> The value was estimaded with ea_iid[1] using on 10485760 bytes read from > >> the RNG via /dev/hwrng. The min-entropy value calculated using the most > >> common value estimate (NIST SP 800-90P[2], section 6.3.1) was 7.964464. > > > > could you please mention in the commit the used hardware > > implementation(s) of iproc-rng200 to get this quality? > > > > AFAIK there is still no public register description at least for the > > bcm2711. So is it safe to assume that the suggested quality applies to > > all possible configurations? > > I've learnt that there is a post-processing unit in RNG200 that tests > the output of the noise generator and fills FIFO only with data that > passes FIPS tests. Unlike simmilar unit in Exynos, it cannot be disabled > or bypassed. Therefore, after Stephan Mueller's thorough explanations I > am considering dropping this patch in v3. If you would be more clear what that FIPS test is all about, we may be able to identify whether it affects the entropy behavior or not. E.g. if it is the SP800-90B health test following SP880-90B section 4.4, this does not affect entropy and you could apply your calculation. > > However, I stil am still not 100% convinced that it is impossible to > assign the quality a reasonable non-zero value in such case. > > > Thanks > > Stefan > > > >> [1] > >> https://protect2.fireeye.com/url?k=da4735b2-87d99b28-da46befd-0cc47a336f > >> ae-e1c21080bc6ab1e4&q=1&u=https%3A%2F%2Fgithub.com%2Fusnistgov%2FSP800-90 > >> B_EntropyAssessment [2] > >> https://csrc.nist.gov/publications/detail/sp/800-90b/final > >> > >> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com> > >> --- > >> > >> drivers/char/hw_random/iproc-rng200.c | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/drivers/char/hw_random/iproc-rng200.c > >> b/drivers/char/hw_random/iproc-rng200.c index 32d9fe61a225..95669ece050f > >> 100644 > >> --- a/drivers/char/hw_random/iproc-rng200.c > >> +++ b/drivers/char/hw_random/iproc-rng200.c > >> @@ -199,6 +199,7 @@ static int iproc_rng200_probe(struct platform_device > >> *pdev)>> > >> priv->rng.read = iproc_rng200_read, > >> priv->rng.init = iproc_rng200_init, > >> priv->rng.cleanup = iproc_rng200_cleanup, > >> > >> + priv->rng.quality = 1000, > >> > >> /* Register driver */ > >> ret = devm_hwrng_register(dev, &priv->rng); Ciao Stephan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <CGME20200519212621eucas1p13279db41d930b69e115972463c994a37@eucas1p1.samsung.com>]
* [PATCH v2 2/2] hwrng: exynos - Set the quality value [not found] ` <CGME20200519212621eucas1p13279db41d930b69e115972463c994a37@eucas1p1.samsung.com> @ 2020-05-19 21:25 ` Łukasz Stelmach 0 siblings, 0 replies; 26+ messages in thread From: Łukasz Stelmach @ 2020-05-19 21:25 UTC (permalink / raw) To: Matt Mackall, Herbert Xu, Arnd Bergmann, Greg Kroah-Hartman, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Kukjin Kim, Krzysztof Kozlowski, Florian Fainelli, Markus Elfring, Matthias Brugger, Stefan Wahren, linux-crypto, linux-arm-kernel, linux-kernel, linux-samsung-soc, Stephan Mueller Cc: Łukasz Stelmach, Bartlomiej Zolnierkiewicz The value was estimaded with ea_iid[1] using on 10485760 bytes read from the RNG via /dev/hwrng. The min-entropy value calculated using the most common value estimate (NIST SP 800-90P[2], section 6.3.1) was 7.489627. [1] https://github.com/usnistgov/SP800-90B_EntropyAssessment [2] https://csrc.nist.gov/publications/detail/sp/800-90b/final Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com> --- drivers/char/hw_random/exynos-trng.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/char/hw_random/exynos-trng.c b/drivers/char/hw_random/exynos-trng.c index 8e1fe3f8dd2d..2a5896122001 100644 --- a/drivers/char/hw_random/exynos-trng.c +++ b/drivers/char/hw_random/exynos-trng.c @@ -123,6 +123,7 @@ static int exynos_trng_probe(struct platform_device *pdev) trng->rng.init = exynos_trng_init; trng->rng.read = exynos_trng_do_read; trng->rng.priv = (unsigned long) trng; + trng->rng.quality = 900; platform_set_drvdata(pdev, trng); trng->dev = &pdev->dev; -- 2.26.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 26+ messages in thread
end of thread, other threads:[~2020-05-23 18:46 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CGME20200514190737eucas1p18ccdddb185ea7611683a6859e17bc721@eucas1p1.samsung.com> 2020-05-14 19:07 ` [PATCH 0/2] Set the quality value for two HW RNGs Łukasz Stelmach [not found] ` <CGME20200514190738eucas1p2695c0d8af064ee702209ca03696ef438@eucas1p2.samsung.com> 2020-05-14 19:07 ` [PATCH 1/2] hwrng: iproc-rng200 - Set the quality value Łukasz Stelmach 2020-05-14 20:20 ` Stephan Mueller [not found] ` <CGME20200514221852eucas1p2bea169d0b4467b0ec9e195c6ac58a08a@eucas1p2.samsung.com> 2020-05-14 22:18 ` Lukasz Stelmach 2020-05-15 8:32 ` Stephan Mueller [not found] ` <CGME20200515090647eucas1p21018edfd835730c9a68dcb186349ee74@eucas1p2.samsung.com> 2020-05-15 9:06 ` Lukasz Stelmach [not found] ` <CGME20200515090158eucas1p1b653fc50f1ad4f0f6c92525ab3188d45@eucas1p1.samsung.com> 2020-05-15 9:01 ` Lukasz Stelmach 2020-05-15 9:10 ` Stephan Mueller [not found] ` <CGME20200515110002eucas1p136759396d9b61f214d1f14856c009501@eucas1p1.samsung.com> 2020-05-15 10:59 ` Lukasz Stelmach [not found] ` <CGME20200514190740eucas1p293129b2ef3ba706652a9327e55db9649@eucas1p2.samsung.com> 2020-05-14 19:07 ` [PATCH 2/2] hwrng: exynos " Łukasz Stelmach 2020-05-14 20:20 ` Stephan Mueller [not found] ` <CGME20200519212617eucas1p1b6e7af0ecb894896b165601fafd6abe8@eucas1p1.samsung.com> 2020-05-19 21:25 ` [PATCH v2 0/2] Set the quality value for two HW RNGs Łukasz Stelmach [not found] ` <CGME20200519212619eucas1p22fa5d3db2521096dc4b79f6e53016d17@eucas1p2.samsung.com> 2020-05-19 21:25 ` [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value Łukasz Stelmach 2020-05-20 6:23 ` Stephan Mueller [not found] ` <CGME20200520091043eucas1p15ecae108007382a95b01e42241cc7a26@eucas1p1.samsung.com> 2020-05-20 9:10 ` Lukasz Stelmach 2020-05-20 9:18 ` Stephan Mueller [not found] ` <CGME20200520104448eucas1p122e9a8ed84d5276a1b796e10ef5e1964@eucas1p1.samsung.com> 2020-05-20 10:44 ` Lukasz Stelmach 2020-05-20 11:53 ` Stephan Mueller 2020-05-20 12:00 ` Krzysztof Kozlowski 2020-05-20 12:11 ` Stephan Mueller [not found] ` <CGME20200520143211eucas1p21bd93be5c62726aa715db05bb6e7119b@eucas1p2.samsung.com> 2020-05-20 14:31 ` Lukasz Stelmach 2020-05-20 8:18 ` Kamil Konieczny 2020-05-21 11:00 ` Stefan Wahren [not found] ` <CGME20200521191415eucas1p2d112a86171b23dcf255e7da53a56f4f3@eucas1p2.samsung.com> 2020-05-21 19:14 ` Lukasz Stelmach 2020-05-23 18:46 ` Stephan Müller [not found] ` <CGME20200519212621eucas1p13279db41d930b69e115972463c994a37@eucas1p1.samsung.com> 2020-05-19 21:25 ` [PATCH v2 2/2] hwrng: exynos " Łukasz Stelmach
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).