Etienne Champetier <champetier.etie...@gmail.com> [2019-05-25 12:43:25]:
Hi, > I just want to be sure we don't make some devices worse / are not > missing something and I really appreciate that, the more eyes, the better. > > Exactly, that's why it's recommended[2] to save it during EVERY shutdown, > > so it's > > different EVERY boot. > > I know and I'm in favour of it, but proper shutdown is not always a > thing on router, that is why I went with getrandom() at the time Indeed, and I think, that it served us well. Now, that we've found out, that it's not helping that much as it was expected, and having proper source of randomness, we could simply stop using it in default install. Should you still need it, you can `opkg install` it back. > > I started experiments with kmod-crypto-rng package which already contains > > jitterentropy, drbg, krng and rng kernel modules, but it didn't improved the > > long booting times for me on ath79. Other reason was size of this kernel > > module(s) as they provide much more functionality of course. > > I think before anyone merge this (I'm not a core dev), This is just an RFC, so I'm not going to merge it anyway. I'm going to post another series of patches without the RFC and I plan to merge it myself if I get Acked-by from at least one additional core developer. I find this part of the system important enough, that I'm not going to push it myself. My current plan for the new series is following: * enable CONFIG_WARN_ALL_UNSEEDED_RANDOM by default in all kernels * add urngd as default package, because it's going to improve the overall system randomness * start urngd directly in procd to get rid of the following warnings: random: procd: uninitialized urandom read (4 bytes read) procd: - ubus - random: ubusd: uninitialized urandom read (4 bytes read) random: ubusd: uninitialized urandom read (4 bytes read) random: ubusd: uninitialized urandom read (4 bytes read) procd: - init - * create packages for urandom-seed, getrandom and remove those from the default images > we need to explain why your user space version and the kernel module > version behave differently Is the kernel module underestimating entropy ? > Is you user space version over estimating entropy ? I hope, that Stephan has already provided that answer in the other email to you. -- ynezz _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel