We only need to generate about 8 bytes of entropy per second total for the spiking of the algorithms...

Given that there is trivially little if any entropy coming from mbufs is there a reason we're leaving this callsite at all? has anyone from secteam commented?

In D15526#330095, @jeff wrote:

Given that there is trivially little if any entropy coming from mbufs is there a reason we're leaving this callsite at all? has anyone from secteam commented?

That might be the right next step, or maybe it can be improved to be useful. I don't think we need to go that far in the first change.

In D15526#330054, @gallatin wrote:

If people want to use ethernet entropy harvesting, can we do something to make it more useful in a separate change? I was going to initially suggest the ether dst addr, but that's not very random either.

In any cases, I think these changes are a huge win. Especially moving the collection mask outside a cacheline that is written in the hot path.

as I have suggested, doing a sampling is a good choice for those that want/need it.. i.e. use 10 packets/second (or less). Use the previous second's pps to calculate the n for selecting every nth packet to use such that it comes out to something like 10pps. Then you use the entire packet, not just the header w/o packet data. Gives us good entropy, makes minimal impact on system overhead, and a huge improvement.

In D15526#330700, @jmg wrote:

as I have suggested, doing a sampling is a good choice for those that want/need it.. i.e. use 10 packets/second (or less). Use the previous second's pps to calculate the n for selecting every nth packet to use such that it comes out to something like 10pps.

Sure, this seems plausible. The existing pps primitive we have probably doesn't work well on many-core systems — I think it would ping pong around with many RX queues — but one can easily imagine enhancing it to be suitable for this goal.

Then you use the entire packet, not just the header w/o packet data.

random_harvest_queue() truncates to the first 8 bytes of input due to constraint on the size of a hc_entropy_ring entry (harvest_event::he_entropy[HARVESTSIZE]). We would have to change that behavior (with potentially wide-reaching implications), or add a new primitive that does not truncate, or pre-mix packet bytes together (simple xor probably fine).

And after all that work, I'm still not sure packet contents are an especially good source of random data. It's harmless to mix in crappy random data after Fortuna is seeded, but spamming the entropy pool with crappy entropy pre-seed may unblock random before it is truly unpredictable, since our unblock heuristic is basically just a byte count of seed data.

While certainly better than what we were doing, global pps accounting would not be efficient multi-core. I'd much rather have it collect the first 10 packets or so every second.

In D15526#330707, @mmacy wrote:

While certainly better than what we were doing, global pps accounting would not be efficient multi-core. I'd much rather have it collect the first 10 packets or so every second.

That is an implementation detail that I did not specify. If you have a 8 queue nic, maybe pick 1 or 2 packets per queue, or something.. or look at traffic per nic and balance it between each, etc. There are MANY solutions that will get you close to 10pps (or maybe even less) that are perfectly workable for efficient multi-core machines.

Collecting the first 10 packets or so every second is not a great idea. With things like tcp off-load which bursts packets, it's common for bursts of packets to be correlated.

Collecting the first 10 packets or so every second is not a great idea. With things like tcp off-load which bursts packets, it's common for bursts of packets to be correlated.

Yes. True. Nonetheless, I'm much more interested in the questions I raised in the review. All of these implementation details are secondary to those.

In D15526#330717, @mmacy wrote:

Collecting the first 10 packets or so every second is not a great idea. With things like tcp off-load which bursts packets, it's common for bursts of packets to be correlated.

Yes. True. Nonetheless, I'm much more interested in the questions I raised in the review. All of these implementation details are secondary to those.

I've written answers to most of those, or at least attempted to discuss it before. But short answers are:

• How much entropy does random actually need?

"None". Once a 256-bit seed has been generated at install time and no further entropy is needed. I'm fine w/ small amounts of additional entropy to prevent evil maid compromises (e.g. machine is powered off, maid clones hard drive, next boot, rng is "predictable"). Reference: https://blog.cr.yp.to/20140205-entropy.html

• How much is it actually getting from a given source?

Due to above, it doesn't/shouldn't mater. Depending upon kernel sources other than the keyboard for generating initial seed is likely to be very broken.

• Why aren't we using hardware entropy sources? When can we?

We are in a few cases. But there is also the case where people confuses PRNGs with TRNGs. Only the later are useful. RDRAND is now being used, I am working on setting up a lab (for everyone to access) that has various hardware so that drivers can be more easily be written and tested (no ETA though).

Oh, note that the above are my opinions, and they differ significantly from most of the rest of the FreeBSD team. Mainly why I haven't spent much time working on the rng system,

In D15526#330724, @jmg wrote:

Oh, note that the above are my opinions, and they differ significantly from most of the rest of the FreeBSD team. Mainly why I haven't spent much time working on the rng system,

That mostly looks reasonable to me — the big caveat is around initial seeding. Especially on embedded systems with readonly media, but also "evil maid" scenarios, as you point out. I'm not part of secteam, though.