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)
Thu, Apr 25, 12:55 PM
Unknown Object (File)
Mon, Apr 22, 2:00 PM
Unknown Object (File)
Sat, Apr 20, 12:04 PM
Unknown Object (File)
Sun, Apr 7, 3:04 AM
Unknown Object (File)
Mar 22 2024, 3:49 AM
Unknown Object (File)
Mar 3 2024, 4:02 AM
Unknown Object (File)
Feb 8 2024, 6:52 PM
Unknown Object (File)
Feb 3 2024, 6:59 AM
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

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 28233
Build 26357: arc lint + arc unit