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 24628 invoked from network); 1 Oct 2020 14:55:48 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 1 Oct 2020 14:55:48 -0000 Received: (qmail 19506 invoked by uid 550); 1 Oct 2020 14:55:47 -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 19486 invoked from network); 1 Oct 2020 14:55:46 -0000 Date: Thu, 1 Oct 2020 10:55:34 -0400 From: Rich Felker To: Carlos O'Donell Cc: Florian Weimer , musl@lists.openwall.com, Carlos O'Donell via Libc-alpha Message-ID: <20201001145533.GO17637@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: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Re: [PATCH] Make abort() AS-safe (Bug 26275). On Thu, Oct 01, 2020 at 10:49:42AM -0400, Carlos O'Donell wrote: > On 10/1/20 2:08 AM, 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 am investigating the removal, but I think the replacement solution > might be needing to have a helper thread carry out specific tasks. I'm confused what a helper thread could achieve here. The underlying problem is that the kernel forces CLONE_SIGHAND on threads (EINVAL without it) so that the disposition can't be changed in a thread-local manner. Any new thread would have that same issue. It also would not be something you could reliably create at abort time (especially since abort is most often used on resource exhaustion and other unexpected failures). Rich