tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: rate to source random bits via rnd_add_data()

Frank Zerangue <> 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

Attachment: pgpl80_urFmZL.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index