Re: [PATCH 2/2] ath9k: disable RNG by default

[miaoqing@codeaurora.org]

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