I got infinity of this error because my perl script forked a lot of children all with the same PRNG seed so all of them tried to create the same sequence of 1000 temp file names 😭😭
Conversation
Replying to
Yeah the way fork() interacts with randomness is pretty forking bad. But it also allows for a fun attack on stack cookies that I enjoy explaining, so it's not all bad.
3
13
Replying to
it's one of those things where if *I* was using the prng I might possibly think of this, but library functions?
I guess the answer is maybe that all randomness that isn't perf-sensitive or intended to be deterministic should come from /dev/urandom?
4
3
Should be getrandom, not /dev/urandom, so that it makes sure the CSPRNG is initialized in early boot and is always available even if the /dev device nodes are missing which often happens within a chroot or mount namespace sandbox.
It's pretty high performance overhead though.
1
1
libc should really have arc4random like OpenBSD and Bionic which deals with the fork issue. Ideally, it'd have a tiny thread-local cache like the Rust version rather than a global lock.
hardened_malloc needs a custom one for perf:
github.com/GrapheneOS/har
github.com/GrapheneOS/har
1
2
It avoids needing extra locking by having a CSPRNG for each slab allocator. ChaCha8 is very fast, although it'd be nice to speed it up more.
Initially cached getrandom output but that was far too slow and needed to cache way too much to reduce overall syscall/locking overhead.
Already has to deal with forking to avoid deadlocking when multi-threaded processes fork and call malloc in the child so it just gets dealt with it as part of that:
github.com/GrapheneOS/har
Note every lock (region allocator, per-arena per-size-class slab allocator) has a CSPRNG.
1