←back to thread

Linux 4.5-rc5: efivarfs fixed to avoid “rm -rf /” bricking UEFI

(git.kernel.org)
279 points the_why_of_y | 4 comments | 22 Feb 16 18:08 UTC | HN request time: 0.001s | source
Show context
Mic92 ◴[22 Feb 16 19:16 UTC] No.11153454[source]▶
Instead of flaming systemd developers for mounting efivars read/write, the kernel is the right place to fix the problem for everybody!
replies(1): >>11153544 #
ajross ◴[22 Feb 16 19:28 UTC] No.11153544[source]▶
No, the firmware is the right place to fix the problem. A BIOS that bricks itself because of within-specification deletion of variables via a standard API is just plain broken.

But in the real world no one ever fixes firmware bugs, so this is the best we can do.

replies(3): >>11153652 #>>11153744 #>>11153940 #
kbenson ◴[22 Feb 16 19:43 UTC] No.11153652[source]▶
I think we can all compromise on "The firmware is the right place to fix the problem, the kernel is the right place to mitigate the problem."
replies(2): >>11153705 #>>11153827 #
1. ktRolster ◴[22 Feb 16 19:50 UTC] No.11153705[source]▶
Not really. Systemd could have fixed it, but it would have been a lot of work and a hack. The Linux kernel team could have fixed it, but it would have been a lot of work and a hack. The hardware manufacturers should have fixed it, but they don't care.

The Kernel team showed they are professionals by stepping up and doing the work.

replies(3): >>11153967 #>>11154782 #>>11156334 #
2. ambrice ◴[22 Feb 16 20:21 UTC] No.11153967[source]▶
What you mean is: systemd could have fixed it, but it would have been a lot of work and a hack that wouldn't help you when efivarfs gets mounted on a sysv/upstart/openrc system. The kernel was the best place for the fix.
3. GhotiFish ◴[22 Feb 16 22:20 UTC] No.11154782[source]▶
disagree. It's not just systemd that could mount efivars as read/write, anyone could. So anyone that does will fall prey to this. It's firmware, and failing that, the kernel protecting you is a good second.
4. cbd1984 ◴[23 Feb 16 03:41 UTC] No.11156334[source]▶
systemd couldn't have fixed it, because removing the offending code from systemd wouldn't have prevented any other program from, innocently or maliciously, triggering the same bug.

The kernel is where the buck stops when it comes to protecting hardware and, therefore, protecting software from misdesigned and/or buggy hardware. That's been true for longer than most of us have been alive.