From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14292 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Conditional signal safety? Date: Sat, 29 Jun 2019 12:49:45 -0400 Message-ID: <20190629164945.GL1506@brightrain.aerifal.cx> References: <20190629055405.GA22788@voyager> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="77097"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14308-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jun 29 18:50:00 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hhGY4-000JxY-Lu for gllmg-musl@m.gmane.org; Sat, 29 Jun 2019 18:50:00 +0200 Original-Received: (qmail 9747 invoked by uid 550); 29 Jun 2019 16:49:58 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9722 invoked from network); 29 Jun 2019 16:49:57 -0000 Content-Disposition: inline In-Reply-To: <20190629055405.GA22788@voyager> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14292 Archived-At: On Sat, Jun 29, 2019 at 07:54:05AM +0200, Markus Wichmann wrote: > Hi all, > > at work yesterday I had to build an exception handler (a signal handler > for SIGSEGV, SIGBUS, SIGILL, and SIGFPE). For my purposes, it was really > convenient to just use dladdr() to find out at least what module and > function PC and LR were pointing to when the exception happened, so I > used that function. This is convenient for debugging, but I would strongly discourage its use in deployment. Attempts to intercept and introspectively report (or even worse, patch up and continue after) memory-safety UB almost always provide tools for an attacker to turn an unexploitable or difficult-to-exploit error into one they can exploit. This is inherent in continuing to run and make calls that might make use of compromised pointers. > Now, dladdr() is not on the list of signal safe functions, but then, > dladdr() is a GNU extension. I wondered if it is signal safe and noticed > that at least musl's implementation is, provided that dlopen() was not > the function that was pre-empted. That got me thinking: Is there such a > thing as "conditional signal safety"? There's not, because it requires too fine-grained constraint of implementation internals; my understanding is that this is the reason both on the standards side (where they're rightfully opposed to specifying anything about the interaction of internals) and on the musl implementation side (where we don't want to preclude interactions that have no obvious reason to exist but that are needed to fix subtle problems -- see for example the interaction between sigaction and abort). > dladdr() takes a rwlock in read mode. At the moment, this means it can > only block if the lock is write locked, which only dlopen() will ever > do. dladdr() does nothing else that would impede signal safety. But of > course, these are implementation details. What is actually defined about > the interface? Nothing further. Documenting the behavior of nonstandard extension functions musl supports is on the agenda, but I don't think documenting properties that are consequences of implementation internals would be part of it except possibly as part of a "hacking" document for use in debugging with tools that aren't stable interface guarantees. Rich