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

Michael Eager eager at eagerm.com
Fri May 24 19:58:38 PDT 2019

What happened with the idea that if you are running as root you can 
break the system?  If you don't want it broken, don't do stupid shit.

On 5/24/19 2:04 PM, Rick Moen wrote:
> 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):
>         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,

Michael Eager    eager at eagerm.com
1960 Park Blvd., Palo Alto, CA 94306

More information about the svlug mailing list