This is the mail archive of the
mailing list for the glibc project.
Directions for arc4random
- From: Florian Weimer <fweimer at redhat dot com>
- To: libc-alpha at sourceware dot org
- Date: Mon, 22 Oct 2018 23:21:15 +0200
- Subject: Directions for arc4random
I would like to resubmit my arc4random patch.
Most of the code, and the difficult-to-review parts, are for providing
fork safety even if the process is forked by a system call, and not a
call to the glibc function fork.
Rich Felker said that he'd prefer to use a proper lock for this in musl:
This would make arc4random far less scalable if one global state is
used. But the implementation would be greatly simplified by this,
especially if we do not provide async-signal-safety for arc4random. (If
we always lock around arc4random invocations and the entire
cryptographic operations, then I think this would detect fork misuse due
to hangs on that lock.)
I would like to know if I should resubmit my last, very complex
approach, or if I should switch to the simple, lock-based approach.