Re:Systemd as tragedy
by 65a on Tuesday January 29, 2019 @01:45AM
(#19024333)
There was that time it was bricking computers by erasing UEFI variables, but I'll allocate equal blame between systemd and UEFI
[ Parent
| on HN ]
Personally, I lay the blame for this issue squarely at the feet of various UEFI implementations which fail to boot when the system's EFI variables are, for whatever reason, wiped clean. The UEFI spec explicitly states that clearing all of the variables on a system must not result in an unbootable system.
You shouldn't, because the maintainer of the kernel subsystem concerned told us all that systemd wasn't to blame for it.
Actually, that was nothing to do with systemd. That was definitely a UEFI implementation issue. And systemd didn't delete anything, the user did - they ran:
rm -rf --no-preserve-root /
The bug was in the kernel (it should not have allowed userspace to write arbitrary UEFI variables), but AFAIR it was exposed by systemd because it eagerly mounted the UEFI variable filesystem provided by the kernel into /sys/something/efivars.
Indeed, but again that was a firmware issue. systemd didn't delete the variables. And systemd was setting EFI variables, so consequently it needed it to be mounted as read/write.
The configuration files should have set that to read only after boot.
The kernel patch where this was fixed can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...