I disagree with Linus on this issue. It’s the situation where you’re sure you really *don’t need* secure random numbers that represents the special case. Put your API flag there. lore.kernel.org/lkml/CAHk-=wiG
44
157
497
Conversation
Replying to
One problem is that people started calling getrandom all over the place. The original name in OpenBSD, getentropy, is better - it's intended for uncommon use to seed userland RNGs (libc's arc4random and others) which would be the primary things used by consumers.
1
3
9
Is there some reason OpenBSD's can't be used to generate arbitrarily many random bytes? Because that seems like a real issue. Userland RNGs are too easy to screw up in the face of things like fork(). We should aim for security by default.
3
1
OpenBSD provides arc4random in libc. It provides a nicer, higher-level API that's harder to misuse and handles fork properly. The intention is that nearly everyone uses arc4random, not getentropy directly. It encourages using a CSPRNG by not forcing system call overhead for it.
Looking through github.com/openbsd/src/tr, it appears to be relying on pthread_atfork (which doesn't work in all cases according to comments) and PIDs which can wrap around. I could see a remote attacker being able to control or predict process spawning (and thus PIDs).
1
that's libressl fallback code for other OS which is best-effort only - OpenBSD's is in libc (github.com/openbsd/src/bl) and uses man.openbsd.org/minherit#MAP_I for fork safety. news.ycombinator.com/item?id=204632 has good comments (especially from notaplumber, ori_b, wahern) on OpenBSD's rng system.
1
3
Show replies