Date: Wed, 06 Mar 2019 13:56:02 +0100 From: Florian Weimer <fweimer@...hat.com> To: Rich Felker <dalias@...c.org> Cc: musl@...ts.openwall.com Subject: Re: sigaltstack for implementation-internal signals? * 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? I think it is not clear whether a libc implementation may generate sporadic signals *at all* to support implementation needs. 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. The Boehm-Demers-Weiser garbage collector would probably benefit from that as well. Thanks, Florian
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.