←back to thread

279 points the_why_of_y | 1 comments | | HN request time: 0.206s | source
Show context
nkurz ◴[] No.11153467[source]
For context, this is in reference to a bug that was discussed a couple weeks ago: https://news.ycombinator.com/item?id=10999335

  Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm' 
Essentially, systemd defaulted to a configuration where the computer's motherboard could be permanently destroyed by removing a 'file' from the command line. The bug reporter argued that this was unduly dangerous, but the systemd developers thought that systemd was working as intended.

Here's a reasonably impartial discussion on a FreeBSD list that gives an overview: https://forums.freebsd.org/threads/54951/

And from that thread, here's a link to Matthew Garrett (the creator of efivarfs) saying that efivarfs is at fault here rather than systemd: https://twitter.com/mjg59/status/693494314941288448

replies(3): >>11153507 #>>11153589 #>>11153676 #
kbenson ◴[] No.11153507[source]
> but the developer's thought that it was working as intended

Really? Is that evidenced by Lennart's response to this, which stated "The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root."[1]? I think it implies the opposite.

1: https://github.com/systemd/systemd/issues/2402

replies(6): >>11153532 #>>11153561 #>>11153670 #>>11153711 #>>11153722 #>>11154994 #
loeg ◴[] No.11153532[source]
The firmware author(s) should not brick their hardware when EFI variables are deleted. That is an invalid behavior.
replies(4): >>11153582 #>>11153745 #>>11154035 #>>11155653 #
1. pyre ◴[] No.11153745[source]
The amount of software that requires write access to EFI variables (as root) is pretty small, so leaving it open all of the time in an environment where the firmware writer could have bugs that cause this seems like it's not necessarily the best course of action.