On Tue, 25 Feb 2020 13:13:16 -0500 Neil Horman <nhorman@xxxxxxxxxx> wrote: > Thats not my understanding. As I understand the changes, /dev/random > has been converted so that its no longer blocks (which is why the > removed the read_wakeup_threshold, since theres never a case where > /dev/random will block anymore). That doesn't prevent rngd from > feeding new entropy into the kernel though, via /dev/randoms > RNDADDTOENTCNT and RNDADDENTROPY ioctls (which is how we feed in more > entropy) If you are right, that is excellent. I've been hesitating with creating the patch because it is becoming like recreating more and more of random.c. I have to be really careful because the kernel expects the new interface, so I have to leave it, but I still have to add the obsolete interface back for my use. Doesn't the elimination of the shadow pool, and the removal of push_to_pool end the ability to push entropy? I'm going to have to bite the bullet and take the code apart until I can understand the new system. > I'm fine with gplv3, IIRC rngd was initially licensed as gplv2 or > later, so it should be good. Great! > Yeah, I just ordered an RTL2832U from amazon for a few bucks, seems > like a good cheap entropy source to make available. I'll try look > into bit-babbler as well, but at $100, that might not be as > worthwhile. Yeah, I was thinking of for server farm and cloud provider usage. > Usually network entropy is avoided because its subject to > manipulation from off system. You can hammer a target card enough > that you can do enough prediction of interrupt timing to predict what > the outcome will be. I'm thinking of a dedicated server that does nothing but provide entropy. A couple of different sources of entropy, and a private network address. The servers sign up as clients, and the entropy server sends them entropy updates on a periodic basis, which wakes the client and reseeds the crng. > As for radio sources, I'm not sure. $10 is actually a huge cost on a > BOM when you're building 1000's of systems, and crngs are cheaper, > especially when an OS adds them anyway to handle the 'no hardware > source' use case. Sure, individual entropy sources for each server is overkill and too expensive. But if it's spread across thousands of servers via a dedicated entropy server, it's just a few cents a server, or less. _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
