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

On Thu, Aug 11, 2016 at 10:54:11AM +0800, miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org wrote:

On 2016-08-10 21:24, Jason Cooper wrote:

quoted

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,

Nope.  I want to leverage the hwrng framework to facilitate feeding the
*kernel* entropy pools like all the other hwrngs do currently.  The
difference for *environmental* sources is that when userspace read()s
from /dev/hwrng, they will *not* contribute.

If the environmental sources are the only sources, then no /dev/hwrng
should appear.

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.

Agreed.

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.

That's why I propose a change to the hwrng framework to permit noise
sources while not wiring them up to feed /dev/hwrng.  timeriomem-rng
should have the same problem ath9k-rng does.

Basically, if it wasn't designed to be an rng, it shouldn't be wired up
to /dev/hwrng.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html