Page MenuHomeFreeBSD

random(4): Fortuna: Enable concurrent generation by default for 13
ClosedPublic

Authored by cem on Dec 19 2019, 8:28 PM.
Tags
None
Referenced Files
Unknown Object (File)
Oct 25 2024, 5:20 AM
Unknown Object (File)
Oct 25 2024, 2:04 AM
Unknown Object (File)
Oct 19 2024, 10:22 AM
Unknown Object (File)
Sep 21 2024, 3:51 PM
Unknown Object (File)
Sep 21 2024, 2:06 AM
Unknown Object (File)
Sep 20 2024, 9:22 PM
Unknown Object (File)
Sep 20 2024, 2:13 PM
Unknown Object (File)
Sep 20 2024, 1:28 PM
Subscribers

Details

Summary

Flip the knob added in r349154 to "enabled." The commit message from that
revision and associated code comment describe the rationale, implementation,
and motivation for the new default in detail. I have dog-fooded this
configuration on my own systems for six months, for what that's worth.

For end-users: the result is just as secure. The benefit is a faster, more
responsive system when processes produce significant demand on random(4).

As mentioned in the earlier commit, the prior behavior may be restored by
setting the kern.random.fortuna.concurrent_read="0" knob in loader.conf(5).

This scales the random generation side of random(4) somewhat, although there
is still a global mutex being shared by all cores and rand_harvestq; the
situation is generally much better than it was before on small CPU systems,
but do not expect miracles on 256-core systems running 256-thread full-rate
random(4) read. Work is ongoing to address both the generation-side (in
more depth) and the harvest-side scaling problems.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable