On Tue, 25 Feb 2020 13:13:16 -0500
Neil Horman <nhorman(a)redhat.com> 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.