Lennart is talking out of his ass, as the implication with CrowdStrike is that the Falcon module would have been running well for a while before the content update, and would only have fallen over once the agent looked for the new content update on system and tried to load it.
Any assessment systemd could have done would see failure to boot, and would either try to roll back to a kernel with an old agent module version, which would probably do the same thing, or go back to a kernel without the Crowd Strike Module at all if available.
Computers aren't magic. They don't know things. They can't bisect their own configuration or intuit what subcomponent caused what behavior. That's your job.
> The Boot Loader Specification describes how to annotate boot loader entries with a counter that specifies how many attempts should be made to boot it.
Which include kernel parameters. Which include the root. As a btrfs user, my system could take a snapshot before applying an update, & set that as the fall through loader entry, so that if boot fails I go back to that previous state.
I'm again finding myself 100% on Team Lennart here. Again this seems like the obvious right & true path, & like we obviously should be doing this.
> For EFI you could probably set BootNext to something else early on, in combination with some restarting watchdog. GRUB can store state between boots https://www.gnu.org/software/grub/manual/grub/html_node/Envi... and has "default" and "fallback" vars.
Ubuntu uses grub recordfail and has done so for years. Userspace records if the boot was successful and the bootloader can use this to change it's behaviour (eg. boot a previous kernel). I think by default it stops at the boot menu for user intervention but on a headless system you can configure it to automatically boot the previous kernel/initrd instead. I think Debian has the same but I'm not sure.
Ubuntu Core (eg. for the upcoming immutable desktop) also supports this kind of thing fully automatically.
So it's not just systemd and the alternatives are widely deployed already.
But anyway as others point out it won't mitigate risk on a system that injects bad code from outside of the boot process.
Ever since systemd landed in the distros I use (Debian & family), that project has been by far the single most common cause of breakage on the systems for which I am responsible.
However good or bad the intentions and ideas here might be, the project has demonstrated many times over that it is not capable of reliably filling the roles to which it aspires. I'm not interested in extending its reach even further.
Let's not also forget the "sshd" exploit some months ago was actually a libsystemd issue. An uncomfortable truth that was buried and not reported on at all. These do-it-all monoliths are the death of an ecosystem, and always seem to introduce more issues than they actually solve. If this is the future of Linux, then I'm making preparations to abandon ship.
9 comments
[ 4.8 ms ] story [ 28.4 ms ] threadAny assessment systemd could have done would see failure to boot, and would either try to roll back to a kernel with an old agent module version, which would probably do the same thing, or go back to a kernel without the Crowd Strike Module at all if available.
Computers aren't magic. They don't know things. They can't bisect their own configuration or intuit what subcomponent caused what behavior. That's your job.
But if you click in, what's being tried monitored & reverted is boot loader entries. From the second sentence in https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/ :
> The Boot Loader Specification describes how to annotate boot loader entries with a counter that specifies how many attempts should be made to boot it.
Which include kernel parameters. Which include the root. As a btrfs user, my system could take a snapshot before applying an update, & set that as the fall through loader entry, so that if boot fails I go back to that previous state.
I'm again finding myself 100% on Team Lennart here. Again this seems like the obvious right & true path, & like we obviously should be doing this.
systemd.io/AUTOMATIC_BOOT_ASSESSMENT/ : https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/
From https://news.ycombinator.com/item?id=29995566 :
> Which distro has the best out-of-the-box output for:?
> Is there a tool like `audit2allow` for systemd units?And also automatic variance in boot sequences with timeouts.
Where does it explain that a systemd service unit is always failing at boot?
> For EFI you could probably set BootNext to something else early on, in combination with some restarting watchdog. GRUB can store state between boots https://www.gnu.org/software/grub/manual/grub/html_node/Envi... and has "default" and "fallback" vars.
It's probably the worse thing to do to give the key to the boot kingdom to systemd, doing random things to your configuration when it feels so...
Ubuntu Core (eg. for the upcoming immutable desktop) also supports this kind of thing fully automatically.
So it's not just systemd and the alternatives are widely deployed already.
But anyway as others point out it won't mitigate risk on a system that injects bad code from outside of the boot process.
However good or bad the intentions and ideas here might be, the project has demonstrated many times over that it is not capable of reliably filling the roles to which it aspires. I'm not interested in extending its reach even further.
In short, no thanks.