From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 4251B1F4B4 for ; Thu, 1 Oct 2020 14:39:24 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4390D398B82E; Thu, 1 Oct 2020 14:39:23 +0000 (GMT) Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [216.12.86.13]) by sourceware.org (Postfix) with ESMTPS id 1F0A6398B474 for ; Thu, 1 Oct 2020 14:39:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1F0A6398B474 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dalias@libc.org Date: Thu, 1 Oct 2020 10:39:19 -0400 From: Rich Felker To: Florian Weimer Subject: Re: [musl] Re: [PATCH] Make abort() AS-safe (Bug 26275). Message-ID: <20201001143918.GN17637@brightrain.aerifal.cx> References: <20200927141952.121047-1-carlos@redhat.com> <871rinm1fx.fsf@mid.deneb.enyo.de> <20200928234833.GC17637@brightrain.aerifal.cx> <87d025jcn0.fsf@mid.deneb.enyo.de> <20200929144207.GD17637@brightrain.aerifal.cx> <20201001023018.GL17637@brightrain.aerifal.cx> <87o8lmeaw7.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87o8lmeaw7.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: musl@lists.openwall.com, Carlos O'Donell via Libc-alpha Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On Thu, Oct 01, 2020 at 08:08:24AM +0200, Florian Weimer wrote: > * Rich Felker: > > > Even without fork, execve and posix_spawn can also see the SIGABRT > > disposition change made by abort(), passing it on to a process that > > should have started with a disposition of SIG_IGN if you hit exactly > > the wrong spot in the race. > > My feeling is that it's not worth bothering with this kind of leakage. > We've had this bug forever in glibc, and no one has complained about > it. > > Carlos is investigating removal of the abort lock from glibc, I think. I don't think that's a good solution. The lock is really important in that it protects against serious wrong behavior *within the process* like an application-installed signal handler for SIGABRT getting called more than once. The worst outcome of the exec issue discussed here (and similar for fork) is simply the wrong disposition (SIG_DFL rather than SIG_IGN) getting passed on to the new process image -- and it's very rare to actually want SIG_IGN to be inherited. Undoing an important fix for wrong code execution just because it's an incomplete fix for wrong disposition inheritance would be bad. If we want to solve this without relying on broadcast/seizure of all threads, it looks like it may be a tradeoff between the subtly wrong behavior for inheritance of SIG_IGN, and subtle wrongness with respect to POSIX requirements on termination status from abort. It's possible to just probe whether the old status was SIG_IGN; if not, there's no issue with the current approach of changing it to SIG_DFL. But if it was SIG_IGN, you can sacrifice the desired SIGABRT termination and get termination by SIGSEGV or SIGILL or SIGBUS (still abnormal status, still generating a core, just not the right signal number) just by leaving signals masked and executing an instruction that will fault in one of these ways. FWIW musl "already does this" (attempting to terminate via a_crash() with signals still masked) if the SIGABRT after resetting its disposition somehow fails to terminate the process. It then falls back to raising SIGKILL, SYS_exit_group, SYS_exit, and for(;;), so we'd get this behavior automatically just by skipping the sigaction if the old disposition was SIG_IGN. Rich