On Thu, Aug 11, 2016 at 10:54:11AM +0800, miaoq...@codeaurora.org wrote: > On 2016-08-10 21:24, Jason Cooper wrote: > >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-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
