[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200816035759.GW3265@brightrain.aerifal.cx>
Date: Sat, 15 Aug 2020 23:57:59 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Restrictions on child context after multithreaded fork
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
