Hi, guys! So, the kernel has supported this for a long time, but there's no way to select it in the build configuration. Is there any specific reason for it (@jow, @nbd)? I vaguely recall reading somewhere it could cause instability with certain specific SoC/configurations, but it seemed kind of handwaving.
Anyway, I'm hacking support for it (I have both an AR9344 and a QCA9563 to test). If it works, would a patch for it be acceptable? Thanks in advance!
… And it's alive! Up and running on QCA9563 (Archer C6 v2), for 28 minutes. 
This works on my devices already...unless I'm missing something?
Does it? I seriously doubt it, I had to make quite a few changes in the mac80211 backports kconfig and also enable kernel support for hardware random number generators.
Anyway, it's simple to test: just disable any jitter entropy collectors you may have (urngd or haveged) and cat /dev/random. If it blocks waiting for entropy, it's not working. Obviously, it will never work if you don't have a recent enough ath9k controller (AR93xx+, IIRC).
There has been an Openwrt-specific patch for that since 2013:
https://github.com/openwrt/openwrt/blob/master/package/kernel/mac80211/patches/ath/543-ath9k_entropy_from_adc.patch
(original SVN commit:
ath9k: gather entropy from raw ADC I/Q samples (use the least significant bit only)
https://git.openwrt.org/?p=openwrt/svn-archive/archive.git;a=commitdiff;h=953d5892724736ad6fbd27091ee13fab7180fd1d;hp=e0897ef26b9d65ad32acce18676ff0f6d5d7af01
Old discussion about ath9k and entropy can be found in
https://dev.archive.openwrt.org/ticket/9631
1 Like
I was honestly asking you...I have not looked in-depth at any code related to it.
I have experienced exactly the opposite what you describe. So long as the WiFi is enabled, I get entropy from noise...unless I've utterly mistaken.
I have some threads on the forum about entropy and using an ath9k devices. I discovered it on a Meraki MX60W with rngd and WiFi disabled.
Yep. We do. And the more traffic the wifi client devices have, the more we do get entropy. At least with my old ar71xx WNDR3800 
Ps. the worst wifi driver regarding entropy is mwlwifi. I bought a chaoskey, a hardware random gen for USB, for my WRT3200ACM.
1 Like
Have you done the test I told @lleachii? Because I'm pretty sure the status quo doesn't work on a lot of otherwise mainline supported devices (case in point, both my Archer C6 v2 and TL-WDR3600).
Indeed, and that patch is exactly the reason why I started digging into this issue. Because it sure as hell isn't feeding /dev/random.
noone should be using /dev/random though. provided your device gets at least say 256 bits of entropy at some point before you are using it /dev/urandom is the right choice.
There is no such thing as depleting entropy. This is a concept invented by kernel programmers, not by cryptographers.
1 Like
What do you mean? The only driver I know which supports collecting entropy from the ADC is ath9k, and only for a subset of all supported devices. Nevertheless, I just asked a friend with a WRT1200AC to do the same test, just to be sure.
It feeds the kernel entropy pool, but not at the pace that you can really fulfill the requirements of continuous non-stop /dev/random reading via cat.
Here is a kernel entropy pool stats from WNDR3700v2 with ath9k (with urngd still on, so the entropy pool floor is at 1000).
- Router is idle all the time, no connected wired devices (except the main router).
- First 20 minutes with wifi on and entropy pool being at 2600-3000 bits,
- then I turned wifi off, used "cat /dev/random" to empty pool, urngd filled it to 1000, but it does not go up from there.
- Then 15 minutes waiting, wifi still off.
- Then wifi on, and the pool starts to fill again toward 3000 bits, thanks to ath9k.
Those stats measure the pool at /proc/sys/kernel/random/entropy_avail
Mwlwifi:
Regarding mwlwifi, there was a wifi driver update in 2017 that reduced the entropy dramatically. That prompted me to buy Chaoskey and to introduce its drivers into OpenWrt.
Discussion at https://github.com/kaloz/mwlwifi/issues/150
1 Like
That's definitely not the mainline ath9k kernel driver behaviour. (Edit: by mainline, I mean 4.19.x, since I'm writing the patch against OpenWrt 19.07, which backports the wireless drivers from Linux 4.19.x.)
the entropy pool depletion is a figment of a fevered imagination. /dev/random does the same kind of calculation as /dev/urandom, it just blocks when some counter reaches zero. does this counter mean anything? during the initial stages of boot, yes, once the counter has hit say 256 bits, urandom output is cryptographically safe for essentially infinite bits.
1 Like
And yet here we are. Because you can't change the whole userspace, even if it misbehaves. In that case, if you get a better behaviour from /dev/random, why not doing it?
You never get better userspace behavior from /dev/random it was essentially a programming mistake. To compensate for this they invented "getrandom" http://man7.org/linux/man-pages/man2/getrandom.2.html
But do you actually have any userspace stuff that blocks on /dev/random?
Look, I'm well aware of this. Actually, it's being discussed, as we write, the possibility of removing the blocking behaviour from /dev/random. But do you have any idea when this is going to hit OpenWrt? We're talking about a Linux 5.7-5.8 timeframe.
But I reiterate (and maybe I wasn't very successful at making my point come across): is there any technical reason to make use of a hacky patch instead of the proper upstream infrastructure? If so, I'd like to understand why. If not, I'll prepare a patch for it. It's that simple.
I don't think there's any reason to use a hacky patch instead of upstream infrastructure. So, go for it!
I guess my question is how much does any of this matter? Do people experience blocking behavior on routers in typical usage?
I think because of the communications issue surrounding this people get afraid that they'll experience some security problems if they don't keep their entropy high enough. But that's not the case, the problem will be just that a piece of software which is poorly written would block on /dev/random and essentially freeze up. Entropy "depleting" doesn't cause a security problem really, except to some extent a denial of service.
1 Like
Probably not much (apart from the rather theoretical DoS issue you mentioned), but the less we deviate from upstream, the more maintainable the code base is. And since it seems to boil down to a couple of Kconfig changes and a deleted patch, I'd say the result is quite nice. 
Yes, I agree the less special patches the better! For that reason alone it's well worth it.
2 Likes