From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31684 invoked from network); 16 Aug 2020 03:58:16 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 16 Aug 2020 03:58:16 -0000 Received: (qmail 22496 invoked by uid 550); 16 Aug 2020 03:58:12 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 22478 invoked from network); 16 Aug 2020 03:58:11 -0000 Date: Sat, 15 Aug 2020 23:57:59 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200816035759.GW3265@brightrain.aerifal.cx> References: <20200814214136.GP3265@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200814214136.GP3265@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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