←back to thread

279 points the_why_of_y | 1 comments | | HN request time: 0s | 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. kbenson ◴[] No.11153582[source]
Agreed, but that's almost a non-sequitur. The systemd developers are not the firmware developers. Additionally, while preferably we would have better firmware that couldn't be bricked in this way, we live in a world where this is often not the case, so the problem does need to be mitigated in some manner.