This is the mail archive of the
mailing list for the glibc project.
Re: Directions for arc4random
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: libc-alpha at sourceware dot org
- Date: Thu, 25 Oct 2018 15:36:33 -0300
- Subject: Re: Directions for arc4random
- References: <firstname.lastname@example.org>
On 22/10/2018 18:21, Florian Weimer wrote:
> 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.
It was my backlog list for some time. The first problem I see is the
the huge size which makes reviewing quite complicate.
The first step to try simplify patch submission is remove all x86
optimizations for AES-NI/SSE2 as you already indicate in your initial
Another thing is I tend to agree with Rich, the lock-free fork/clone
detection is quite complicated and possible troublesome for maintainability.
Since we have a long-standing issue of a no async-signal-safe fork
implementation (BZ#4737) and fork implementation still contain some
lock contention on multithread fork (due atfork list handling, libio
internal list, and malloc) I think such lock-free complexity would not
yield much gain.
So I would prefer Rich suggestion of using simpler locks, albeit with
less scalability. As you already described in your path, current kernel
support of MADV_WIPEONFORK already provides a proper way to handle it.
Also, the lock-free optimization is also a future option is current
lock seems to be a problem in real-world usage.
I also think it would profitable to discuss how to properly handle BZ#4737
if fork scalability is an issue. You recently brought if there is a way
to detect if the current function has been called (directly or indirectly)
from a signal handler , not sure if were your idea to handle BZ#4737 or
something else (with a proper way we could fix the atfork list scalability