From mboxrd@z Thu Jan 1 00:00:00 1970 From: Date: Sat, 19 Nov 2016 18:31:33 -0000 Subject: No subject Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org """ 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?=20 > >=20 > > Otherwise, your patch will cause high CPU load, as continuously=20 > > read ADC data if entropy bits under write_wakeup_threshold. >=20 > The issue is that although you may have analyzed it, others are unable=20 > to measure the quality of the RNG and assess the design as well as the=20 > implementation of the RNG. This RNG is the only implementation of a=20 > hardware RNG that per default and without being able to change it at=20 > runtime injects data into the input_pool where the noise source cannot=20 > be audited. Note, even other respected RNG noise sources like the=20 > Intel RDRAND will not feed into / dev/random per default in a way that do= minates all other noise sources. >=20 > I would like to be able to deactivate that noise source to the extent=20 > that it does not cause /dev/random to unblock. The reason is that your=20 > 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 =3D y || HW_RANDOM =3D ATH9K) default y If you have *any* hwrngs you want to use and you have an ath9k card (HW_RAN= DOM =3D y and ATH9K !=3D 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=20 > to spin, please help and offer another solution. Well, I don't buy the reasoning listed above for not using the hwrng framew= ork. Interrupt timings were never designed to be a source of entropy eithe= r. We need to grab it where ever we can find it, especially on embedded sy= stems. Documentation/hw_random.txt even says: """ This data is NOT CHECKED by any fitness tests, and could potentially be bog= us (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 u= nder 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 sou= nd cards? thx, Jason.