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

I'm going to have to seriously consider not using systemd.

SteveT

On Fri, 24 May 2019 14:04:17 -0700
Rick Moen <[email protected]> wrote:

> You, too, can have an init with a built-in handler for the ILL
> signal.  ;->
> 
> ----- Forwarded message from Martin Steigerwald <[email protected]>
> -----
> 
> Date: Fri, 24 May 2019 22:04:34 +0200
> From: Martin Steigerwald <[email protected]>
> To: DNG <[email protected]>
> 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,


_______________________________________________
svlug mailing list
[email protected]
http://lists.svlug.org/lists/listinfo/svlug