Page MenuHomeFreeBSD

in_pcb_lport: Don't attempt to randomize if random(4) is unavailable
AbandonedPublic

Authored by cem on Apr 19 2019, 7:31 PM.

Details

Summary

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.

Diff Detail

Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 23775
Build 22723: arc lint + arc unit

Event Timeline

cem created this revision.Apr 19 2019, 7:31 PM
cem added inline comments.
sys/conf/kern.mk
64–66 ↗(On Diff #56401)

Please ignore this portion — arc misfire. It is not included in the actual git commit.

cem updated this revision to Diff 56402.Apr 19 2019, 7:35 PM

Remove arc misfire

jhb added a comment.Apr 19 2019, 8:33 PM

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?

cem added a comment.Apr 19 2019, 9:39 PM
In D19972#429343, @jhb wrote:

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?

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.

cem abandoned this revision.Aug 11 2019, 8:39 PM

Will pursue available initial seeding in another way.