Re: [RFC] Toward Shareable POSIX Signals

[Rich Felker <dalias at libc dot org>]

On Fri, Mar 09, 2018 at 02:30:51PM -0500, Zack Weinberg wrote:
> > "Just use glib" is of course fundamentally unacceptable. But the
> > obvious solution is "just use threads" and I don't see why that's not
> > acceptable. The cost of a thread is miniscule compared to the cost of
> > a child process, and threads performing synchronous waitpid can
> > convert the result into whatever type of notification (poll wakeup,
> > cond var, synchronous handling, etc.) you like.
> 
> The main problem I see with this idea is, a thread waiting for _any_
> process can steal the event from a thread waiting for a specific
> process; this makes it nonviable for any situation where you don't

I never proposed using a thread that calls wait or waidpid with a
negative argument, rather one thread per child. As long as there is no
rogue thread in the program doing wait-any, the thread-per-child
approach lets you emulate pdfork pretty well; programs written around
this model can use pdfork as a drop-in replacement and eliminate the
cost of the thread.

> > On Fri, Mar 09, 2018 at 05:58:51PM +0100, Florian Weimer wrote:
> >> But [threads] only works for asynchronous signals.  It's reasonable
> >> for an application to want to catch synchronous signals (SIGBUS
> >> when dealing with file mappings, SIGFPE for arithmetic), and there
> >> is currently no thread-safe or library-safe way at all to do that.
> >
> > Yes, as I noted each use case needs to be considered separately to
> > determine if there's some other better/more-portable/whatnot way it
> > could be done already. The above applies only to SIGCHLD.
> >
> > FWIW I'm rather skeptical of many of the usage cases for synchronous
> > signals (most are dangerous papering-over of UB for dubious
> > performance reasons; never-taken "test reg,reg;jz" takes essentially 0
> > cycles on a modern uarch) but SIGBUS makes it hard to use mmap safely
> > to begin with. So there's still a lot of material to consider here.
> 
> If I remember correctly, GCJ tried to use signal handlers to generate
> NullPointerExceptions not for speed reasons, but for code-size and
> exception-precision reasons.  But it was never 100% reliable and it
> might have been better to go with "test reg,reg;jz" + lean harder on
> proving pointers couldn't be null.

This is my view. Null checks/proofs should be maximally hoisted and
explicitly emitted in the output rather than relying on traps.

> That's the only case I'm personally familiar with where a serious
> application tried to _recover from_ synchronous signals.  I've also
> dug into Breakpad a little, but that is a debugger at heart, and it
> would be well-served by a mechanism where the kernel would
> automatically spawn a ptrace supervisor instead of delivering a fatal
> signal.  (This would also allow us to kick core dump generation out of
> the kernel.)

This is a very bad idea. Introspective crash logging/reporting is a
huge gift to attackers. If an attacker has compromised a process in a
manner to cause it to segfault, they almost surely have enough control
over the process state to force the handler to perform code execution
for them. There have been real-world CVEs along these lines.

> > FYI Daniel proposed the ideas to me first before posting on libc-alpha
> > and I suggested bringing a proposal here. I'm rather split between
> > finding the proposal nice and finding signals irredeemably awful.
> 
> Yeah, I feel we collectively could have done a better job of not
> leaping at Daniel's throat just for bringing this up.

Absolutely. This needs to improve.

Rich