6 ms·

There was that time it was bricking computers by erasing UEFI variables, but I'll allocate equal blame between systemd and UEFI

• chris_wot 8y ago
  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 / https://lwn.net/Articles/674940/ https://lwn.net/Articles/674940/
  • majewsky 8y ago
    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.
    • chris_wot 8y ago
      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/linux.git/commit/?id=0389075ecfb6231818de9b0225d3a5a21a661171 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
• voxadam 8y ago
  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.
• JdeBP 8y ago
  You shouldn't, because the maintainer of the kernel subsystem concerned told us all that systemd wasn't to blame for it. * https://news.ycombinator.com/item?id=15973577 https://news.ycombinator.com/item?id=15973577 * https://news.ycombinator.com/item?id=11152880 https://news.ycombinator.com/item?id=11152880