[conspire] (forw) [DNG] Linux system can be brought down by sending SIGILL to Systemd

[Rick Moen]

You, too, can have an init with a built-in handler for the ILL signal.  ;->

----- Forwarded message from Martin Steigerwald <martin at lichtvoll.de> -----

Date: Fri, 24 May 2019 22:04:34 +0200
From: Martin Steigerwald <martin at lichtvoll.de>
To: DNG <dng at lists.dyne.org>
Subject: [DNG] Linux system can be brought down by sending SIGILL to Systemd

Hi!

Today in a Linux training a participant attempted to bring down Debian 
workstation with Systemd by sending signals to PID 1 as I invited them 
to try to bring down PID 1 while thinking for myself that this would not 
be possible from my past experiences about trying to bring down PID 1 – 
init – myself.

While sending SIGKILL to Systemd did not have any effect, sending SIGILL 
– illegal instruction – to it brought the machine to an halt. I 
reproduced it with

while true; do kill -ILL 1 ; echo -n "." ;  sleep 0.5 ; done

on my training workstation (Debian 9.9 with Systemd 232 and 4.9.0-9 
Debian Kernel with MDS mitigation).

The mouse pointer froze and the machine did not even respond to ping 
anymore! According to participants about 4 to 5 times sending the signal 
would be enough to bring down a workstation with Systemd as PID 1.

Despite all the bugs and issues I have seen or read about with Systemd I 
was very surprised about that result.

Curiously I attempted the same with the Debian on my laptop that I 
switched to SysVInit and elogind. As the elogind stuff mostly works I 
think I will switch it to Devuan once I come around to it.

I am able to run

while true; do kill -ILL 1 ; echo -n "." ; done

against SysVinit's "init" process without any issue for minutes (Debian 
Sid with sysvinit 2.93-8 and self-compiled 5.1.2 kernel, also with MDS 
mitigation). It is even running while I write this mail normally now.

Also the participants found in the manpage kill(2):

NOTES
       The  only  signals  that  can be sent to process ID 1, the init
       process, are those for which init has explicitly installed sig‐
       nal handlers.  This is done to assure the system is not brought
       down accidentally.

So if that is actually true, then it appears that Systemd initiates a 
signal handler for SIGILL for whatever reason.

I pondered about writing a bug report to Systemd developers, but 
honestly from my past experiences with upstream feedback about bug 
reports regarding Systemd I then decided not to bother about it. I am 
not willing to take in and deal with any more "this is by design, go 
away" or "this works as intended, go away" kind of responses. I am not 
interested in Systemd to a larger extent than teaching participants of 
my training what they need to know about it, when they have to deal with 
it due to distribution choices made at their employer. And yes, I also 
have a slide that summarizes critique about it, complete with links, so 
they can make up their own opinion. And no, for me it is not black and 
white, but my own decision is to go without Systemd.

This is another reason for me to start to provide Devuan VMs in the 
Proxmox VE environment I use to provide VMs of various distributions to 
the participants of my trainings. So participants can have a look at it 
and do exercises with it if they like. I already started to incorporate 
information about Devuan in some of my slides.

I share it here not to invite another bashing about Systemd, we really 
do not need to go there, but instead can focus on strengthening the 
alternatives. But I share it here to provide another reason to use a 
Systemd-free distribution like Devuan. I also share it as an example of 
the robustness of the SysVInit init process!

Thanks,
-- 
Martin


_______________________________________________
Dng mailing list
Dng at lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

----- End forwarded message -----