Re: [RFC] Toward Shareable POSIX Signals

[Zack Weinberg <zackw at panix dot com>]

On Fri, Mar 9, 2018 at 3:25 PM, Rich Felker <dalias@libc.org> wrote:
> 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,

My point here is that a library author cannot assume there is no such
"rogue thread".

>> 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.

That is a problem for Breakpad _as it is today_, but it should not be
a problem for a hypothetical out-of-process ptrace monitor that the
kernel spawns after freezing the process that was about to take a
fatal sync signal.

You can almost fake this today by starting up the ptrace monitor with
the monitored child; the main issue I'm aware of is that the monitor
will get woken up every time the child takes any signal at all, which
makes signal handling even costlier than it already is, and figuring
out whether the child was about to be _killed_ by the signal is a
PITA.

zw