Thanks for taking a look!
Thanks for the better fix. BTW, I still think these checks would be better to be rewritten as getting the real number and compare with 65535.
Totally agree, but I couldn't get clarity on whether or not the value could be static or how to compute it. I'll see if I can reverse engineer how sometime in the future (*files bug*).
We have single machine, that after automatic firmware upgrade fails to attache the driver:
So, it can be dangerous...
Sun, Apr 21
I think we can just use zero for the label if enough entropy is not available. A flow label of zero indicates no flow label "treatment" in the network.
I'm just thinking in terms of reducing binary size on normal builds. This doesn't have any uses on a normal system, does it?
Since this is just for development, should it be guarded by #ifdef INVARIANTS?
Sat, Apr 20
Is there a notification for when we are fully seeded the first time and entropy is available?
Fri, Apr 19
Hm, why isn't maclen of 16 an issue for encrypt?
No objection, although it's somewhat moot because the lists are shared (aesmodules, shamodules). Unless you plan to change that.
Let me make sure I understand the concern correctly.
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?
Remove arc misfire
Thu, Apr 18
Thanks Xin and Warner!
- Incorporate Ravi's suggested description wording
- Incorporate a SHA256 version of Xin's suggestion for fallback arc4random seeding for reasons mentioned in differential (open to discussion, just presenting a prototype)
Thanks markm and imp.
Yeah, moving the check into arc4rand helps.
Wed, Apr 17
At suggestion of rpokala@ and with help from np@, incorporate MD cyclecounter
in fako arc4random seeding when devrandom is bypassed unseeded.
I like that we can have a fallback seeding to RND devices, but Netflix requires a system to be bootable to userland no matter what goes on with the randomness in early boot. As such, we'd like a mode that can report that something screwed up in the early random stuff so we can decide if we care or not about that.
Tue, Apr 16
Thanks for taking a look!
Shuffle ordering of pure random source registration from late in autoconfig
(SI_SUB_DRIVERS) up to SI_SUB_RANDOM, and correctly invoke ra_pre_read in order
to actually transition an algorithm from !seeded to seeded (otherwise, all the
entropy in the world will not change that status).
Tinderbox passes. I'd appreciate expediency on this one, if possible.
Add CTASSERT that nitems(__stack_chk_guard) matches our expectations.
document in random.9 and add link
Ah, this deserves a manual page link to random.9 and random.9 update.
Rebase on WIP changes; no functional change.
I'm in favor of this change; please consider this as an explicit "accepted" if nobody objects in a week.
Mon, Apr 15
Sun, Apr 14
- Replace slpflags parameter to wait_until_seeded with boolean parameter. I still prefer a named parameter at consumers, so I made some file-local defines for true and false that show intent more clearly (I hope).
- Dropped panic() from !DEV_RANDOM empty read_random implementation. We will address !DEV_RANDOM separately.
- Added sysctl/tunable to enable testing of unavailability of random device throughout early boot, and documented it in random.4.
- Bumped .Dd on manual pages.