Replace random() with arc4random(), this gives a bigger value of RANDOM_MAX.
It is likely the result will not be noticeable.
Details
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 28319 Build 26422: arc lint + arc unit
Event Timeline
sys/netinet/cc/cc_cdg.c | ||
---|---|---|
503 | Forwarding my comments from the earlier review: I am hesitant to make unrelated type changes like this. | |
515–516 | As I remarked before, this is now a different expression that is not purely a result of s/random/arc4random/. I don't really see any reason to try and expand this from 31 bits to 32 bits. I don't know if unpredictability is significant in this context. It may be significant that random(9) is actually the crappy rand(3) rather than the somewhat better (but still non-CSPRNG) random(3), for distribution purposes. If unpredictability doesn't matter, but distribution and speed does, a better solution might be to replace random(9) with random(3). Or another newish non-CS PRNG. Preferably dropping 'random' from the name. | |
sys/netinet/cc/cc_chd.c | ||
87–88 | As expressed before, I believe these function range definitions should live with the declarations in an appropriate header, rather than ad-hoc definitions in the .c file. |
Unpredictability is not important here, it is more the distribution. Any reason why the change has to happen?
Not really: when OpenBSD introduced arc4random(4), the idea there was to use it everywhere, and it seemed reasonable that we would follow the same principle so I had a much bigger patch replace random() everywhere in the kernel.
Part of the reasoning, although somewhat unscientific, is that feeding randomness to several different processes could have an effect of stripping the sequence for other processes so any stream will be even more unpredictable. I say the reasoning is unscientific because a good pseudo-random generator shouldn't have to rely on such tricks and striping some values in a biased manner may affect other properties of the random generator, but neither reasoning has been tested.
There is no hurry to commit this, I was just wondering if the replacement seems correct.
Abandon: it was not exactly right.
sys/netinet/cc/cc_cdg.c | ||
---|---|---|
503 | After some review, this change is fine somewhat unnecessary. backoff looks more like a boolean. | |
515–516 | Using the extra bit is a good idea: the return type is already unsigned. |