If kern.random.initial_seeding.bypass_before_seeding is disabled,
arc4rand(9) may block if/until the the random(4) device is initially
seeded. Probably we want to be able to create sockets in that case,
even if we cannot yet randomize the port, rather than blocking
indefinitely.
Details
Details
Diff Detail
Diff Detail
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 23774 Build 22722: arc lint + arc unit
Event Timeline
sys/conf/kern.mk | ||
---|---|---|
64–66 | Please ignore this portion — arc misfire. It is not included in the actual git commit. |
Comment Actions
Is this a case where 'not very random' PRNG output is still better than "sequential port assignment"? That is, if we had a variant of arc4random() that would fail to "weak output" rather than blocking?
Comment Actions
The hope is that after a few packets are exchanged, we will have gathered sufficient entropy that random will be seeded (and that state persists forever). I'm not sure how pernicious sequential port assignment is perceived to be. Note that ipport_tick can force us to drop to sequential port assignment after a certain number of random assignments in a given window, so there is some precedent for using sequential ports when it is convenient.