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

[cem]

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.

[cem]

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]

Remove arc misfire

[jhb]

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]

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]

Will pursue available initial seeding in another way.