Re: [PATCH 2/2] ath9k: disable RNG by default
Hi Jason, On 2016-08-10 21:24, Jason Cooper wrote: *gentle reminder: others are reading which may not be directly included in the conversation. Including the archives. Please avoid top posting. :) Thanks:) The fact is, barring userspace expectations of /dev/hwrng, hw_random is the appropriate place for it. It's not a devicetree blob, mac address, or pci config space. Which are things we feed in once for the heck of it. This is a *continuous* source or questionable quality. I'm seriously considering putting this and timeriomem-rng into a subdirectory under hw_random/, maybe environ/. Anything in there gets quality=0 for default, and *doesn't* contribute to /dev/hwrng. Regardless which path we take, I think we should include 'adc' in the name. I've heard countless times about "Atheros cards come with an rng on board". :-/ If I understand correctly, you want to bind the ADC source to /dev/hwrng, and then change rng-tools to set the entropy to zero in the ioctl call ? There are two major problems with that approach, 1) We already tried once before to bind our solution to /dev/hwrng, and got so much complaints. The conclusion was that maybe we know that the output of /dev/hwrng does not have perfect entropy, but a normal user does not know and will misuse it. You mentioned in https://www.kernel.org/doc/Documentation/hw_random.txt we have "This data is NOT CHECKED by any fitness tests, and could potentially be bogus (if the hardware is faulty or has been tampered with). Data is only output if the hardware "has-data" flag is set, but nevertheless a security-conscious person would run fitness tests on the data before assuming it is truly random." But this is not enough to convince upstream to switch to /dev/hwrng. I think the concern of users misusing the solution is a very valid concern. 2) If we set the entropy to zero in rng-tools, we cannot tolerate the load. Rng-tools is not a timer-based solution. Similar to our solution, it is based on /proc/sys/kernel/random/write_wakeup_threshold. If we do not increase the entropy counter, rng-tools keep writing into the pool, and both rng-tools and WiFi chip will be overloaded. Thanks, Miaoqing -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] ath9k: disable RNG by default
Hi Stephan, That is set as "optional but highly recommended" in the FIPS doc, plus the fact that we do not have a requirement to have a FIP-approved RNG in our case. Although FIPS might impose higher and stronger requirements on the source of entropy, but not passing those tests does not mean the source of entropy is of bad quality. As I mentioned earlier, we just need to evaluate the amount of entropy it provides correctly and use it accordingly. If we are dealing with a chip which has a HW RNG, we expect extremely high entropy close to full from our source, but this patch is for chips which do not have a dedicated HW RNG in place to improve the quality of random number generation on the platform. Thanks, Miaoqing -Original Message- From: Stephan Mueller [mailto:smuel...@chronox.de] Sent: Wednesday, August 10, 2016 3:27 PM To: Pan, Miaoqing <miaoq...@qti.qualcomm.com> Cc: Herbert Xu <herb...@gondor.apana.org.au>; Matt Mackall <m...@selenic.com>; miaoq...@codeaurora.org; Valo, Kalle <kv...@qca.qualcomm.com>; linux-wirel...@vger.kernel.org; ath9k-devel <ath9k-de...@qca.qualcomm.com>; linux-crypto@vger.kernel.org; ja...@lakedaemon.net; Sepehrdad, Pouyan <pouy...@qti.qualcomm.com> Subject: Re: [PATCH 2/2] ath9k: disable RNG by default Am Mittwoch, 10. August 2016, 07:15:49 CEST schrieb Pan, Miaoqing: Hi Miaoqing, > Hi Stephan, > > NIST SP 800-22-rev1a and NIST SP 800-90B are used together to evaluate > the amount of min entropy the source provides, and not to decide if > the source has passed the tests or failed. See > > https://github.com/usnistgov/SP800-90B_EntropyAssessment > > The goal is often to make sure the input entropy is more than the > entropy we expect from the output. You are correct on the SP800-90B tests (hence I did not refer to them for the binary decision). Yet, SP800-22 with the associated tool delivers a binary decision. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] ath9k: disable RNG by default
Hi Stephan, The problem with using the add_device_randomness is that we do not know when to call that API, and we have to make our solution either timer-based or interrupt based, which is not really the correct way of implementing this feature. Thanks, Miaoqing -Original Message- From: Pan, Miaoqing Sent: Wednesday, August 10, 2016 3:41 PM To: Stephan Mueller <smuel...@chronox.de> Cc: Herbert Xu <herb...@gondor.apana.org.au>; Matt Mackall <m...@selenic.com>; miaoq...@codeaurora.org; Valo, Kalle <kv...@qca.qualcomm.com>; linux-wirel...@vger.kernel.org; ath9k-devel <ath9k-de...@qca.qualcomm.com>; linux-crypto@vger.kernel.org; ja...@lakedaemon.net; Sepehrdad, Pouyan <pouy...@qti.qualcomm.com> Subject: RE: [PATCH 2/2] ath9k: disable RNG by default Hi Stephan, That is set as "optional but highly recommended" in the FIPS doc, plus the fact that we do not have a requirement to have a FIP-approved RNG in our case. Although FIPS might impose higher and stronger requirements on the source of entropy, but not passing those tests does not mean the source of entropy is of bad quality. As I mentioned earlier, we just need to evaluate the amount of entropy it provides correctly and use it accordingly. If we are dealing with a chip which has a HW RNG, we expect extremely high entropy close to full from our source, but this patch is for chips which do not have a dedicated HW RNG in place to improve the quality of random number generation on the platform. Thanks, Miaoqing -Original Message- From: Stephan Mueller [mailto:smuel...@chronox.de] Sent: Wednesday, August 10, 2016 3:27 PM To: Pan, Miaoqing <miaoq...@qti.qualcomm.com> Cc: Herbert Xu <herb...@gondor.apana.org.au>; Matt Mackall <m...@selenic.com>; miaoq...@codeaurora.org; Valo, Kalle <kv...@qca.qualcomm.com>; linux-wirel...@vger.kernel.org; ath9k-devel <ath9k-de...@qca.qualcomm.com>; linux-crypto@vger.kernel.org; ja...@lakedaemon.net; Sepehrdad, Pouyan <pouy...@qti.qualcomm.com> Subject: Re: [PATCH 2/2] ath9k: disable RNG by default Am Mittwoch, 10. August 2016, 07:15:49 CEST schrieb Pan, Miaoqing: Hi Miaoqing, > Hi Stephan, > > NIST SP 800-22-rev1a and NIST SP 800-90B are used together to evaluate > the amount of min entropy the source provides, and not to decide if > the source has passed the tests or failed. See > > https://github.com/usnistgov/SP800-90B_EntropyAssessment > > The goal is often to make sure the input entropy is more than the > entropy we expect from the output. You are correct on the SP800-90B tests (hence I did not refer to them for the binary decision). Yet, SP800-22 with the associated tool delivers a binary decision. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] ath9k: disable RNG by default
Hi Stephan, Would you please provide a recent NIST document which asks the entropy source to pass the NIST randomness tests ? Thanks, Miaoqing -Original Message- From: Stephan Mueller [mailto:smuel...@chronox.de] Sent: Wednesday, August 10, 2016 2:25 PM To: Pan, Miaoqing <miaoq...@qti.qualcomm.com> Cc: Herbert Xu <herb...@gondor.apana.org.au>; Matt Mackall <m...@selenic.com>; miaoq...@codeaurora.org; Valo, Kalle <kv...@qca.qualcomm.com>; linux-wirel...@vger.kernel.org; ath9k-devel <ath9k-de...@qca.qualcomm.com>; linux-crypto@vger.kernel.org; ja...@lakedaemon.net; Sepehrdad, Pouyan <pouy...@qti.qualcomm.com> Subject: Re: [PATCH 2/2] ath9k: disable RNG by default Am Mittwoch, 10. August 2016, 06:04:32 CEST schrieb Pan, Miaoqing: Hi Miaoqing, > Hi Stephan, > > FIPS RNG test is supposed to be run on the output of an RNG, and not > on the RNG entropy source. It is not surprising that the RNG input > fails the entropy tests from NIST. Check the following example. > > Imagine you have a perfectly random sequence, a_1, a_2, .., a_n, where > each a_i is a byte. And imagine, this sequence passes all randomness tests. > > Now, let's say I create a new sequence a_1, 0, a_2, 0, a_3, 0, ..., 0, > a_n, where each zero is a byte > > If you give this sequence (as an entropy source) to a randomness test, > it will fail most of the tests, if not all. This does not mean this > sequence is not appropriate as an entropy source, it just means we > need twice more bytes to gain the same amount of entropy. Agreed. But that is a very simplistic view. > > I can give this 2n byte sequence to an RNG as an entropy source and it > provides the same amount of security as if I give the n byte stream. Well, I am working with standards bodies like NIST and BSI on RNG assessments. They all require that the noise source (pre-whitening, of course) pass statistical tests like the AIS20 tests, SP800-22 and similar. If you fail, you better have a good argument. And the only argument that is kind of allowed is that you oversample your noise source to seed a DRNG from (i.e. have an entropy to data ratio of significantly below 1). And the argument for the oversampling rate is always a very interesting discussion. You apply 10/32. In private, I am wondering about that ratio, but this should not be discussed here as I hope you have a valid argument for that. As we are talking about the current rngd, we have to consider that it does *not* perform an oversampling (yet) as mentioned in the previous emails. Do not get me wrong on my initial patch: your RNG may provide some entropy. But there are quite some folks who want to understand and audit a noise source before using it. Your current implementation simply does not allow switching the noise source off to feed the input_pool with data that increases the entropy estimator (at runtime). Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] ath9k: disable RNG by default
Hi Stephan,
FIPS RNG test is supposed to be run on the output of an RNG, and not on the RNG
entropy source. It is not surprising that the RNG input fails the entropy tests
from NIST. Check the following example.
Imagine you have a perfectly random sequence, a_1, a_2, .., a_n, where each a_i
is a byte. And imagine, this sequence passes all randomness tests.
Now, let's say I create a new sequence a_1, 0, a_2, 0, a_3, 0, ..., 0, a_n,
where each zero is a byte
If you give this sequence (as an entropy source) to a randomness test, it will
fail most of the tests, if not all. This does not mean this sequence is not
appropriate as an entropy source, it just means we need twice more bytes to
gain the same amount of entropy.
I can give this 2n byte sequence to an RNG as an entropy source and it provides
the same amount of security as if I give the n byte stream.
Thanks,
Miaoqing
-Original Message-
From: Stephan Mueller [mailto:smuel...@chronox.de]
Sent: Wednesday, August 10, 2016 1:29 PM
To: Pan, Miaoqing <miaoq...@qti.qualcomm.com>
Cc: Herbert Xu <herb...@gondor.apana.org.au>; Matt Mackall <m...@selenic.com>;
miaoq...@codeaurora.org; Valo, Kalle <kv...@qca.qualcomm.com>;
linux-wirel...@vger.kernel.org; ath9k-devel <ath9k-de...@qca.qualcomm.com>;
linux-crypto@vger.kernel.org; ja...@lakedaemon.net; Sepehrdad, Pouyan
<pouy...@qti.qualcomm.com>
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default
Am Mittwoch, 10. August 2016, 02:35:04 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> For those less perfect noise source, can't pass the FIPS test.
>
> static int update_kernel_random(int random_step,
> unsigned char *buf, fips_ctx_t *fipsctx_in) {
> unsigned char *p;
> int fips;
>
> fips = fips_run_rng_test(fipsctx_in, buf);
> if (fips)
> return 1;
>
> for (p = buf; p + random_step <= [FIPS_RNG_BUFFER_SIZE];
> p += random_step) {
> random_add_entropy(p, random_step);
> random_sleep();
> }
> return 0;
> }
Not even the poor cheap AIS20 statistical tests from rngd pass?
I guess the only sensible solution is what Ted suggested to use
add_device_randomness.
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] ath9k: disable RNG by default
Hi Stephan, NIST SP 800-22-rev1a and NIST SP 800-90B are used together to evaluate the amount of min entropy the source provides, and not to decide if the source has passed the tests or failed. See https://github.com/usnistgov/SP800-90B_EntropyAssessment The goal is often to make sure the input entropy is more than the entropy we expect from the output. Thanks, Miaoqing -Original Message- From: Stephan Mueller [mailto:smuel...@chronox.de] Sent: Wednesday, August 10, 2016 2:52 PM To: Pan, Miaoqing <miaoq...@qti.qualcomm.com> Cc: Herbert Xu <herb...@gondor.apana.org.au>; Matt Mackall <m...@selenic.com>; miaoq...@codeaurora.org; Valo, Kalle <kv...@qca.qualcomm.com>; linux-wirel...@vger.kernel.org; ath9k-devel <ath9k-de...@qca.qualcomm.com>; linux-crypto@vger.kernel.org; ja...@lakedaemon.net; Sepehrdad, Pouyan <pouy...@qti.qualcomm.com> Subject: Re: [PATCH 2/2] ath9k: disable RNG by default Am Mittwoch, 10. August 2016, 06:46:31 CEST schrieb Pan, Miaoqing: Hi Miaoqing, > Hi Stephan, > > Would you please provide a recent NIST document which asks the entropy > source to pass the NIST randomness tests ? See FIPS 140-2 IG 7.15 which explicitly references SP800-22. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ath9k: disable RNG by default
Hi Stephan,
For those less perfect noise source, can't pass the FIPS test.
static int update_kernel_random(int random_step,
unsigned char *buf, fips_ctx_t *fipsctx_in)
{
unsigned char *p;
int fips;
fips = fips_run_rng_test(fipsctx_in, buf);
if (fips)
return 1;
for (p = buf; p + random_step <= [FIPS_RNG_BUFFER_SIZE];
p += random_step) {
random_add_entropy(p, random_step);
random_sleep();
}
return 0;
}
--
Miaoqing
From: Stephan Mueller <smuel...@chronox.de>
Sent: Tuesday, August 9, 2016 5:37 PM
To: Herbert Xu
Cc: Pan, Miaoqing; Matt Mackall; miaoq...@codeaurora.org; Valo, Kalle;
linux-wirel...@vger.kernel.org; ath9k-devel; linux-crypto@vger.kernel.org;
ja...@lakedaemon.net; Sepehrdad, Pouyan
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default
Am Dienstag, 9. August 2016, 17:17:55 CEST schrieb Herbert Xu:
Hi Herbert,
> On Tue, Aug 09, 2016 at 11:02:58AM +0200, Stephan Mueller wrote:
> > But shouldn't the default of the rngd then be adjusted a bit?
>
> Please elaborate.
in rngd_linux.c:random_add_entropy(void *buf, size_t size):
entropy.ent_count = size * 8;
entropy.size = size;
memcpy(entropy.data, buf, size);
if (ioctl(random_fd, RNDADDENTROPY, ) != 0) {
...
in rngd.c:do_loop():
retval = iter->xread(buf, sizeof buf, iter);
...
rc = update_kernel_random(random_step,
buf, iter->fipsctx);
where update_kernel_random simply invokes random_add_entropy in chunks.
Hence, the rngd reads some bytes from /dev/hwrand and injects it into /dev/
random with an entropy estimate that is equal to the read bytes.
With less than perfect noise sources, entropy.ent_count should be much
smaller.
>
> Thanks,
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ath9k: disable RNG by default
From: Miaoqing Pan <miaoq...@codeaurora.org> ath9k RNG will dominates all the noise sources from the real HW RNG, disable it by default. But we strongly recommand to enable it if the system without HW RNG, especially on embedded systems. Signed-off-by: Miaoqing Pan <miaoq...@codeaurora.org> --- drivers/net/wireless/ath/ath9k/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig index f68cb00..8f231c6 100644 --- a/drivers/net/wireless/ath/ath9k/Kconfig +++ b/drivers/net/wireless/ath/ath9k/Kconfig @@ -180,7 +180,7 @@ config ATH9K_HTC_DEBUGFS config ATH9K_HWRNG bool "Random number generator support" depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K) - default y + default n ---help--- This option incorporates the ADC register output as a source of randomness into Linux entropy pool (/dev/urandom and /dev/random) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ath9k: change entropy formula for easier understanding
From: Miaoqing Pan <miaoq...@codeaurora.org>
The quality of ADC entropy is 10 bits of min-entropy for
a 32-bit value, change '(((x) * 8 * 320) >> 10)' to
'(((x) * 8 * 10) >> 5)' for easier understanding.
Signed-off-by: Miaoqing Pan <miaoq...@codeaurora.org>
---
drivers/net/wireless/ath/ath9k/rng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/rng.c
b/drivers/net/wireless/ath/ath9k/rng.c
index d38e50f..568b1c6 100644
--- a/drivers/net/wireless/ath/ath9k/rng.c
+++ b/drivers/net/wireless/ath/ath9k/rng.c
@@ -22,7 +22,7 @@
#include "ar9003_phy.h"
#define ATH9K_RNG_BUF_SIZE 320
-#define ATH9K_RNG_ENTROPY(x) (((x) * 8 * 320) >> 10) /* quality: 320/1024 */
+#define ATH9K_RNG_ENTROPY(x) (((x) * 8 * 10) >> 5) /* quality: 10/32 */
static int ath9k_rng_data_read(struct ath_softc *sc, u32 *buf, u32 buf_size)
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
Hi Jason, Stephan, Agree with Jason's point, also understand Stephan's concern. The date rate can be roughly estimated by 'cat /dev/random |rngtest -c 1000', the average speed is .294Kibits/s. I will sent the patch to disable ath9k RNG by default. Thanks, Miaoqing -Original Message- From: Jason Cooper [mailto:ja...@lakedaemon.net] Sent: Tuesday, August 09, 2016 1:30 AM To: Stephan Mueller <smuel...@chronox.de> Cc: Pan, Miaoqing <miaoq...@qti.qualcomm.com>; Ted Tso <ty...@mit.edu>; Sepehrdad, Pouyan <pouy...@qti.qualcomm.com>; herb...@gondor.apana.org.au; linux-ker...@vger.kernel.org; linux-crypto@vger.kernel.org; ath9k-devel <ath9k-de...@qca.qualcomm.com>; linux-wirel...@vger.kernel.org; ath9k-de...@lists.ath9k.org; Kalle Valo <kv...@codeaurora.org> Subject: Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy Hi Stephan, Miaoqing Pan, On Mon, Aug 08, 2016 at 08:41:36AM +0200, Stephan Mueller wrote: > Am Montag, 8. August 2016, 02:03:36 CEST schrieb Pan, Miaoqing: > > The entropy was evaluated by crypto expert, the analysis report > > show the ADC with at least 10bits and up to 22 bits of min-entropy > > for a 32 bits value, we conservatively assume the min-entropy is 10 > > bits out of 32 bits, so that's why set entropy quality to 320/1024 = > > 10/32. Ok, so the relevant commit is: ed14dc0af7cce ath9k: feeding entropy in kernel from ADC capture Which refers to a previous commit: 6301566e0b2d ath9k: export HW random number generator > > Also we have explained in the commit message why can't use the HW > > RNG framework. >From ed14dc0af7cce: """ Since ADC was not designed to be a dedicated HW RNG, we do not want to bind it to /dev/hwrng framework directly. """ > Where is the description of the RNG, where is the test implementation? > > > > Otherwise, your patch will cause high CPU load, as continuously > > read ADC data if entropy bits under write_wakeup_threshold. > > The issue is that although you may have analyzed it, others are unable > to measure the quality of the RNG and assess the design as well as the > implementation of the RNG. This RNG is the only implementation of a > hardware RNG that per default and without being able to change it at > runtime injects data into the input_pool where the noise source cannot > be audited. Note, even other respected RNG noise sources like the > Intel RDRAND will not feed into / dev/random per default in a way that > dominates all other noise sources. > > I would like to be able to deactivate that noise source to the extent > that it does not cause /dev/random to unblock. The reason is that your > noise source starts to dominate all other noise sources. I think the short-term problem here is the config logic: config ATH9K_HWRNG bool "Random number generator support" depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K) default y If you have *any* hwrngs you want to use and you have an ath9k card (HW_RANDOM = y and ATH9K != n), you get the behavior Stephan is pointing out. Short term, we should just default no here. > If you think that this patch is a challenge because your driver starts > to spin, please help and offer another solution. Well, I don't buy the reasoning listed above for not using the hwrng framework. Interrupt timings were never designed to be a source of entropy either. We need to grab it where ever we can find it, especially on embedded systems. Documentation/hw_random.txt even says: """ This data is NOT CHECKED by any fitness tests, and could potentially be bogus (if the hardware is faulty or has been tampered with). """ I really don't think there's a problem with adding these sorts of sources under char/hw_random/. I think the only thing we would be concerned about, other than the already addressed entropy estimation, would be constraining the data rate. Is ath9k the only wireless card that exposes ADC registers? What about sound cards? thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
The entropy was evaluated by crypto expert, the analysis report show the ADC
with at least 10bits and up to 22 bits of min-entropy for a 32 bits value, we
conservatively assume the min-entropy is 10 bits out of 32 bits, so that's why
set entropy quality to 320/1024 = 10/32. Also we have explained in the
commit message why can't use the HW RNG framework.
Otherwise, your patch will cause high CPU load, as continuously read ADC data
if entropy bits under write_wakeup_threshold.
--
Miaoqing
-Original Message-
From: Stephan Mueller [mailto:smuel...@chronox.de]
Sent: Sunday, August 07, 2016 5:36 PM
To: Ted Tso <ty...@mit.edu>
Cc: herb...@gondor.apana.org.au; linux-ker...@vger.kernel.org;
linux-crypto@vger.kernel.org; ath9k-devel <ath9k-de...@qca.qualcomm.com>;
linux-wirel...@vger.kernel.org; ath9k-de...@lists.ath9k.org; Kalle Valo
<kv...@codeaurora.org>; Jason Cooper <ja...@lakedaemon.net>
Subject: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
The ATH9K driver implements an RNG which is completely bypassing the standard
Linux HW generator logic.
The RNG may or may not deliver entropy. Considering the conservative approach
in treating entropy with respect to non-auditable sources, this patch changes
the delivered entropy value to zero. The RNG still feeds data into the
input_pool but it is assumed to have no entropy.
When the ATH9K RNG changes to use the HW RNG framework, it may re-enable the
entropy estimation considering that a user can change that value at boot and
runtime.
Reviewed-by: Jason Cooper <ja...@lakedaemon.net>
Signed-off-by: Stephan Mueller <smuel...@chronox.de>
---
drivers/net/wireless/ath/ath9k/rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/rng.c
b/drivers/net/wireless/ath/ath9k/rng.c
index d38e50f..1ed8338 100644
--- a/drivers/net/wireless/ath/ath9k/rng.c
+++ b/drivers/net/wireless/ath/ath9k/rng.c
@@ -22,7 +22,6 @@
#include "ar9003_phy.h"
#define ATH9K_RNG_BUF_SIZE 320
-#define ATH9K_RNG_ENTROPY(x) (((x) * 8 * 320) >> 10) /* quality: 320/1024 */
static int ath9k_rng_data_read(struct ath_softc *sc, u32 *buf, u32 buf_size)
{ @@ -92,8 +91,7 @@ static int ath9k_rng_kthread(void *data)
fail_stats = 0;
/* sleep until entropy bits under write_wakeup_threshold */
- add_hwgenerator_randomness((void *)rng_buf, bytes_read,
- ATH9K_RNG_ENTROPY(bytes_read));
+ add_hwgenerator_randomness((void *)rng_buf, bytes_read, 0);
}
kfree(rng_buf);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] ath9k: export HW random number generator
+Pouyan David. -Original Message- From: Kalle Valo [mailto:kv...@codeaurora.org] Sent: Friday, July 31, 2015 3:09 PM To: Stephan Mueller Cc: Oleksij Rempel; Pan, Miaoqing; linvi...@tuxdriver.com; linux-wirel...@vger.kernel.org; Theodore Ts'o; linux-crypto@vger.kernel.org; nhor...@tuxdriver.com Subject: Re: [PATCH 2/2] ath9k: export HW random number generator Stephan Mueller smuel...@chronox.de writes: -rw-rw-r-- 1 lex lex 2564096 Jul 27 11:36 hwrng.out -rw-rw-r-- 1 lex lex 2468394 Jul 27 11:36 hwrng.out.bz2 Do i understand it correctly, in case of hwrng bzip was able to find enough pattern to compressed the data? Even with format overhead? I'm no an expert, help of an expert would be welcome, added some more people to CC This one does not look good for a claim that the RNG produces white noise. An RNG that is wired up to /dev/hwrng should produce white noise. Either by having an appropriate noise source or by conditioning the output of the noise source. When conditioning the output, you have to be careful about the entropy claim. For example, you cannot state that the data stream from your noise source has close to one bit of entropy for each obtained bit. Thus, the conditioner must ensure that the data from the noise source is collected and its entropy is maintained and accumulated. However, the hwrandom framework does not provide any conditioning logic. And I would say that such conditioner logic should not reside in a driver either. I would say that the discussed RNG does not seem fit for hooking it up with the hwrandom framework. Based on the discussion I'm going to revert this patch, at least for now. -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
