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.
Tags
None
Referenced Files
F102554638: D19972.diff
Thu, Nov 14, 12:01 AM
Unknown Object (File)
Fri, Oct 25, 5:42 AM
Unknown Object (File)
Fri, Oct 25, 5:42 AM
Unknown Object (File)
Fri, Oct 25, 5:42 AM
Unknown Object (File)
Fri, Oct 25, 5:32 AM
Unknown Object (File)
Oct 4 2024, 11:25 PM
Unknown Object (File)
Oct 4 2024, 6:11 PM
Unknown Object (File)
Oct 3 2024, 7:47 AM
Subscribers
None

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 Passed
Unit
No Test Coverage
Build Status
Buildable 23774
Build 22722: arc lint + arc unit

Event Timeline

cem added inline comments.
sys/conf/kern.mk
64–66

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

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?

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.

Will pursue available initial seeding in another way.