[v2,1/2] hwrng: iproc-rng200 - Set the quality value
diff mbox series

Message ID 20200519212552.11671-2-l.stelmach@samsung.com
State Not Applicable
Headers show
Series
  • Set the quality value for two HW RNGs
Related show

Commit Message

Łukasz Stelmach May 19, 2020, 9:25 p.m. UTC
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(+)

Comments

Stephan Mueller May 20, 2020, 6:23 a.m. UTC | #1
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
Kamil Konieczny May 20, 2020, 8:18 a.m. UTC | #2
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);
>
Łukasz Stelmach May 20, 2020, 9:10 a.m. UTC | #3
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,
Stephan Mueller May 20, 2020, 9:18 a.m. UTC | #4
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
Łukasz Stelmach May 20, 2020, 10:44 a.m. UTC | #5
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,
Stephan Mueller May 20, 2020, 11:53 a.m. UTC | #6
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
Krzysztof Kozlowski May 20, 2020, noon UTC | #7
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
Stephan Mueller May 20, 2020, 12:11 p.m. UTC | #8
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
Łukasz Stelmach May 20, 2020, 2:31 p.m. UTC | #9
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.
Stefan Wahren May 21, 2020, 11 a.m. UTC | #10
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);
Łukasz Stelmach May 21, 2020, 7:14 p.m. UTC | #11
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);
>
>
Stephan Mueller May 23, 2020, 6:46 p.m. UTC | #12
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

Patch
diff mbox series

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);