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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
