From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13934 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: sigaltstack for implementation-internal signals? Date: Wed, 6 Mar 2019 17:07:40 +0100 Message-ID: <20190306160740.GF28106@voyager> References: <20190305155719.GO23599@brightrain.aerifal.cx> <87tvggb1r1.fsf@oldenburg2.str.redhat.com> 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="261051"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-13950-gllmg-musl=m.gmane.org@lists.openwall.com Wed Mar 06 17:09:01 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 1h1Z6L-0015mz-PD for gllmg-musl@m.gmane.org; Wed, 06 Mar 2019 17:09:01 +0100 Original-Received: (qmail 11910 invoked by uid 550); 6 Mar 2019 16:08:59 -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 11865 invoked from network); 6 Mar 2019 16:08:59 -0000 Content-Disposition: inline In-Reply-To: <87tvggb1r1.fsf@oldenburg2.str.redhat.com> X-Provags-ID: V03:K1:daUzj3+QQIIrMSeh7R+Ib9LVDUbJeddMwSjLEMYRs9HpILzSIdy GR+pv+rkvcXzJaeTJVGRFNCDnnD8XhNMNUiitBwIEKFijBe3b0+nc3v6MGRmpdjl5402EV/ isp+xxeA+D5Y0QF0/uHxaAaMfXJHt9zedTMsWgAe0y4ErRv5XZgDsX4D1b3RpczXc2z/pX9 z+6Wsuj1JMibUg0QU6s9w== X-UI-Out-Filterresults: notjunk:1;V03:K0:Wv6wZbAEcRs=:Nfz6c5IRWZbxLY+mBEGQmy ky22s8a0F9WHakhhyylNswpOpjcNTcRirSKrvVCdskB2JIg9RRTaYQpFuHbB3PRpdY5/1Dbzl 9DwKr83TImDtBNYmDCS7X2sRWh961+dGm4840wYyWHQVL27nXGjHN/xZQnMyxNPCQFhcm/5Wf F7fD182P6SeAwfwlziacAwEwSLCjcJ0mffSgGUx67B0XYyT8opJj9B7jSc7h1dniCOoTQcH8B cK6gYiuI0879egRnYMCPwnmNR8aiDFzvMfWg79oGpDNL6YLVBgN33H0CzziAXw007BuGZRBWS jB+A9eQpNSgVtMx0viUB8NcFX/RqeVRy0ksEJt4gXB942pUka+eVPkWrsF0rl7i5pEaY16RLr ej6EjSeGEFcEJxelRs5UqVCs0/2KyW+ejYX5QLScCgUWijF8igjc1CIBo7uw7/b1zBzmIuAdd uCn7W1VQYjaU5qsDeCn9KZ825hBlrU2uCNhWpzqzQnNDPOQT/QV+s5CNcHIr9vomFxIkaqgJl ui6RRdkDtCHfaU6vBf/8uvbxmrgeeVvR/WLX2r+HLPk2tnIVmWPFYMNumkSgHUqCZk9MoJroP IlBjPVbLm3cjuAUQBHreohTjlp8H5zkBUJCzpFfCnlXkWzqlta1MVXvR7rkfdm/n0F+kcAGJM YdsMhU/PFmno4VucLItyh+wUYY+VUfe38ldPv1bNgmjeWm6kwCbgdMV/SfsGV7uzDhCG2obhm qnAC9oUDqLTEKzitErRfBNhbsak1/Dw+5bmsKlQjtjPjXnXV+z+ECT22Dcoo79cMo5m3Webf Xref: news.gmane.org gmane.linux.lib.musl.general:13934 Archived-At: On Wed, Mar 06, 2019 at 01:56:02PM +0100, Florian Weimer wrote: > * Rich Felker: > > > If we add unblockable, implementation-internal signals that are > > flagged SA_ONSTACK, however, this breaks; now even if an application > > has taken the "proper precautions", they can be delivered in a state > > where the alt stack is nonempty but the stack pointer doesn't point > > into it, thereby causing it to get clobbered. > > There's also the matter of applications which do not use signal handlers > at all (and thus never invoke sigaltstack) and have really small stacks, > or use the stack pointer register for something else. Is either of that > supported? > If you or any library you use install signal handlers, your code is constantly at an interface boundary, since a signal can appear at any time. libc uses signal handlers. And you use libc. Connect the dots... > I think it is not clear whether a libc implementation may generate > sporadic signals *at all* to support implementation needs. > Well, then we're at an impasse, as POSIX requires certain semantics and the kernel provides different ones, and we need the signals as a go-between. Alright, what implementation-internal signals are there? SIGTIMER: That one is needed in timer_create() to be able to spawn a thread if someone creates a timer with SIGEV_THREAD. Since the handling thread is spawned immediately, the signal is taken only on the stack of the internal thread. And the handler itself does nothing. BTW, is there a reason that handler is installed with SA_SIGINFO if it does nothing with the extra info? Anyway, this signal has no impact on application stacks. SIGCANCEL: The cancelled thread will take this signal. Wanting to cancel a thread without signalling it is like wanting to be washed without being made wet; it simply makes no sense. Applications can trivially prevent the generation of this signal by simply foregoing the use of pthread_cancel(). SIGSYNCCALL: This is going to be the sticking point, isn't it? This signal really does appear in each thread, even application threads, without warning. It is currently used to implement setrlimit(), setegid(), seteuid(), setgid(), setuid(), setregid(), setreuid(), setresgid() and setresuid(). Except for setrlimit(), I would not expect applications with tiny stacks and lots of threads to call any of these. Much less often enough to cause an issue. So setrlimit() is probably the only call that will cause problems in the kind of applications you speak of. Thus the entire problem could be solved if the kernel allowed setting rlimits for the entire process, or at least for other threads. Seems like the smaller change to me. > Does musl use asynchronous implementation signals? For glibc, we would > prefer synchronous delivery, that is, the handler runs before the > signal-generating system call returns. This makes me wonder if we > should try to get the kernel to provide us a system call which allows us > to run code on a different thread, with signals disabled, but with the > caller's stack (from the original thread). I think this would address > issues caused by strange stack pointer values in the target thread. > Hmmm... if the kernel supported remote sigaltstack() (i.e. setting a signal stack for another thread), then this would all be done. But alas, no such luck. > Thanks, > Florian Ciao, Markus