[systemd-devel] BUG: several bugs in core/main.c (v218)

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jan 29, 2015 at 12:17:08AM +0100, Tomasz Pawlak wrote:
> On Sun, 25.01.15 03:37, Tomasz Pawlak (tomazzi at wp.pl) wrote:
> --->
> I've replied in the 2nd part of this td - btw, can someone merge those parts?

That ship has already sailed. Your client did not set In-reply-to.

BTW., could you use standard quoting, the thing with arrows is very
unreadable.

> ---<
> 
> > 2. SIGSEGV should be catched by a handler running on a separate
> > stack (SA_ONSTACK) - otherwise it can cause segfault itself, when
> > the first SIGSEGV which triggered the handler is caused by stack
> > overflow.
> 
> I'd take a patch for this, but in general: the crash handler is
> nothing that is supposed to recover your system. All it does its close
> all fds, fork, and coredump in the child while freezing in the
> parent. That makes sure that all communication with PID 1 is severed
> (so that clients talking to it don't hang), we get a clean coredump,
> but the kernel doesn't oops immediately. That's really all there is to
> it.
> 
> So far we never ran into stack overflow issues, hence nobody was ever
> tempted to cover that case too, and set up a separate stack. In
> particular since doing this without testing it is pointless...
> 
> --->
> Actually, when the program is a critical part of the system, than ALL sig handlers should use separate stack (what in fact makes the life easier) - that's because it's completely unpredictable, whether there's enough stack space to execute the handler - i.e. each sig handler can cause segfault when it's executed at the bottom of the stack (where top/bootom is only a matter of naming convention)

IIUC, you are saying that we could trigger for example a FPE, and
then exhaust all the memory in the signal handler. Nah, we can ignore
this possibility.

> The only effect of SA_NODEFER is that sig mask is not automatically set for a signal which triggered the handler.
> This means nesting of signals, as the handler can be interrupted and another instance is started for a new signal context.  (and sig handlers are not signal-safe with SA_NODEFER, what means that they have to be fully re-entrant)
> This also means, that there's completely no warranty that the handler won't be interrupted with external signal -> mess.

Not really. systemd is single-threaded, so a signal could come only from two places:
the signal handler could cause a fault, or it could be delivered from another program.
The first is unlikely, stack handlers do a tiny amount of work, and the second is OK,
because killing PID 1 is only allowed for privileged processes, and if someone can
send arbitrary signals to PID 1, they can cause a failure in other ways.

Zbyszek