Frank Zerangue <frank.zerangue%gmail.com@localhost> writes: > Rnd.h specifies a pool size of 128. Should the high water mark in your > opinion be somewhere in the 80% range of this? First: are you adding entropy from a driver in the kernel? From rnd(4), that's the only way to add bits while increasing the entropy estimate. You said rnd_add_data, so presumably you are. on one box, rndctl -s reports 4094 bits in the pool out of 4096 max at the moment, which is 128*32, and then lots bits discarded due to a full pool. So I suspect that disk/net/etc. adds bits when it has them, and often they are discarded. For a hardware device, the challenge is to avoid spending too much cpu time adding entropy that is just discarded. So it seems to me that the rnd(9) public interface needs a call to find out how many bits of entropy are not present in the pool (max-current), and then the read-hw-add code can be run periodically, stopping when that hits the max, or is close. The next step would be to have the random code invoke a callback when the entropy estimate gets low. There is hardware rng for some chipsets. So I would suggest reading that code to see what existing practice is. E.f., hifn(4), ubsec(4), and probably others. recursive grep for rnd_add_data is probably useful.
Attachment:
pgpl80_urFmZL.pgp
Description: PGP signature