Re: [musl] Restrictions on child context after multithreaded fork

[Rich Felker <dalias@libc.org>]

On Fri, Aug 14, 2020 at 05:41:38PM -0400, Rich Felker wrote:
> This is largely because glibc attempts to make the erroneous usage by
> these libraries work (more on that below).
> 
> [...]
> 
> In case we do want to follow a direction of trying to provide some
> degree of relaxation of restrictions on the child (taking the liberty
> of POSIX-future drop of fork's AS-safety requirement), I did a quick
> survey of libc-internal locks, and found:
> 
> - at_quick_exit
> - atexit
> - dlerror
> - gettext
> - malloc
> - pthread_atfork (already necessarily held at fork)
> - random
> - sem_open
> - stdio open file list (vs individual FILEs)
> - syslog
> - timezone
> 
> This list looks tractable. Aside from malloc, whose locks would need
> to be taken last since the others may call malloc, these don't seem to
> have any lock order dependencies between them, and each one's lock
> functions could be provided as strong overrides to weak no-op
> definitions in fork.c.

On some inspection, glibc does not actually attempt to make the child
environment unrestricted. The only things it does around fork are:

- obtain/release malloc locks (makes malloc work reliably in the
  child)

- obtain stdio file list lock in parent, release in parent, reset in
  child (probably makes fopen work in the child, but I see no reason
  why the child resets the lock rather than just unlocking it)

- reset FILE locks in child (necessarily leads to accessing
  inconsistent or corrupt state if they're ever used in the child)

- reset dynamic linker lock in child (AFAICT, necessarily leads to
  accessing inconsistent or corrupt state in child if any dynamic
  linker functions are ever used in the child, possibly including via
  the lazy resolver (!!))

So pretty much the *only* thing glibc attempts to make work
"correctly" in the MT-forked-child context is malloc. Everything else
is either ignored (see all of the above I found for musl, plus lots
more things that are glibc-specific) or actively broken by the special
handling at fork time.

In light of this, I think it's very reasonable that the new POSIX
direction is just allowing implementations that make fork non-AS-safe,
but not allowing the application to assume anything new. "It's
AS-unsafe, except malloc works" is a really weird and arbitrary
restriction. This reassures me that we really should be working to get
the broken application/library code here fixed, rather than trying to
accommodate it, unless there's a major change in direction where
multiple implementors want to agree to make this really work "right".

Rich