Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm' • Hacker News Board

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#81

Post by clinta » Sat, Jan 30, 2016, 4:51 AM UTC

deathanatos wrote: post #64

kbenson wrote: post #42

Earlier quoted context omitted.

That is an extremely uncharitable reading of what he wrote, and I don't think it captures the essence of his intent at all. He said: > Well, there are tools that actually want to write it. It needs to be accessible in some manner. > The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root. Agreement it needs to be guarded, because it's a problem if it can hos…

Not only is root root, and should be permitted to access and modify the system as desired, it seems to me that the root of this problem is that motherboard manufacturers are shipping faulty boards. I shouldn't be able to brick my motherboard from my operating system, and that I can is a bug. You're telling me there isn't so much as a factory reset on these boards? Perhaps systemd could shield users from their motherb…

We've been living in a world where you couldn't brick the firmware from the OS for a long time, and it's been terrible. I'm perfectly happy to take the risk of being able to brick a board from the OS if it means I never again have to try boot to a dos disk and run a proprietary exe to update the BIOS.

Some boards do have something of a "factory reset" in the form of dual bios so that if one is bricked, the backup can still be booted. But it's not a bug that not every motherboard has this feature.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#82

Post by bsder » Sat, Jan 30, 2016, 5:01 AM UTC

This isn't a systemd problem. It's a kernel problem.

Allowing accidental access to a resource capable of doing permanent damage is dumb. Even embedded processors generally have an "unlock/lock" sequence when you want to write to their flash memory.

The fact that the kernel doesn't require you to write a "magic number" somewhere to gain access is foolhardy.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#83

Post by whydid » Sat, Jan 30, 2016, 5:37 AM UTC

Someone wrote: post #10

The comments by Lennart Poettering, IMO, are a prime example of the schism between what is needed for reaching "the year of Linux on the desktop" and what some hackers think is best. Nobody sells a chainsaw with safeties disabled, remarking "you can always attach the chain catcher" if people report a couple of accidents, but Lennart thinks requiring almost every user to change the default install ( (note that you can…

Yeah, it's called empathy for your users.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#84

Post by GhotiFish » Sat, Jan 30, 2016, 5:50 AM UTC

mikeash wrote: post #14

mmastrac wrote: post #4

These threads are never productive. Running rm -rf / is going to offer multiple interesting ways to make your life miserable, eg: a mounted FUSE filesystem, an NFS folder pointed somewhere important, Samba mounts from your network automatically connected from your desktop, etc. I wouldn't be surprised if you could nuke firmware off a device by deleting the appropriate file in /sys/. Systemd hate is en vogue these day…

Sometimes people run rm -rf / just for fun before reformatting a system, just to see what happens. Given that its purpose in life is to delete files, it stands to reason that running this command on a system which contains no important data is OK. A default configuration which makes this command destroy hardware is not reasonable.

It's funny you mentioned that rm's purpose in life is to delete files. I'm reminded of a common saying in the unix world.

Everything is a file.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#85

Post by Sanddancer » Sat, Jan 30, 2016, 6:05 AM UTC

kbenson wrote: post #42

Someone wrote: post #10

The comments by Lennart Poettering, IMO, are a prime example of the schism between what is needed for reaching "the year of Linux on the desktop" and what some hackers think is best. Nobody sells a chainsaw with safeties disabled, remarking "you can always attach the chain catcher" if people report a couple of accidents, but Lennart thinks requiring almost every user to change the default install ( (note that you can…

That is an extremely uncharitable reading of what he wrote, and I don't think it captures the essence of his intent at all. He said: > Well, there are tools that actually want to write it. It needs to be accessible in some manner. > The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root. Agreement it needs to be guarded, because it's a problem if it can hos…

Root needs access, but creating a pseudo-filesystem to access an area of the system with metadata, etc that doesn't map well to a filesystem, especially given the number of very buggy implementations of UEFI out there is just asking for trouble. There are properties that have settings to be visible only certain times during the boot process, there are settings that involve changing guids, etc. Access is better served through tools that better understand UEFI's confusing properties, not hammered at with general filesystem-level tools.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#86

Post by uxcn » Sat, Jan 30, 2016, 6:20 AM UTC

threatofrain wrote: post #62

victorhugo31337 wrote: post #19

Earlier quoted context omitted.

I think the "Year of Linux on the desktop" thing is BS and needs to stop. It's been the year of Linux on the desktop for 15 years now. Can't GNU/Linux just be a solid server platform? Not trying to be a troll, but if someone says "the year of Linux on the desktop" one more time...

I also think that desktop vs server are two different domains. The desktop / personal user domain is looking like it's in the early stages of transformation, with mass data collection to support voice search and user intent prediction. While there's something to be said for privacy, I don't think consumers will care enough, and I don't think desktop linux systems outside of whatever Google may make is going to be ade…

Linux is just source for a kernel that the userland for the various distributions are built on though. It's already largely on people's phones with Android. In fact, Chrome OS is based on Linux.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#87

Post by eeZi » Sat, Jan 30, 2016, 6:21 AM UTC

kbenson wrote: post #42

Someone wrote: post #10

The comments by Lennart Poettering, IMO, are a prime example of the schism between what is needed for reaching "the year of Linux on the desktop" and what some hackers think is best. Nobody sells a chainsaw with safeties disabled, remarking "you can always attach the chain catcher" if people report a couple of accidents, but Lennart thinks requiring almost every user to change the default install ( (note that you can…

That is an extremely uncharitable reading of what he wrote, and I don't think it captures the essence of his intent at all. He said: > Well, there are tools that actually want to write it. It needs to be accessible in some manner. > The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root. Agreement it needs to be guarded, because it's a problem if it can hos…

If they changed it to "ro" by default, people would complain as well if it breaks something.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#88

Post by eeZi » Sat, Jan 30, 2016, 6:25 AM UTC

JulianMorrison wrote: post #27

Why not just turn off recognition of "rm" in the efivarfs? That is, the response to "unlink" of a file that represents a system abstraction of firmware should be something drastic only to the unlinker. SIGSEGV or something. "Go away, don't do that."

Well there are use cases where you'd want to remove an EFI variable.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#89

Post by milkey_mouse » Sat, Jan 30, 2016, 6:31 AM UTC

andmarios wrote: post #56

One day I broke my laptop's boot list, so I went to add a new efi boot entry. I couldn't and thought it was due to my inability to find a proper usb bootable media with efi support since you can't access efi-vars if you boot from bios. Turns out linux used to store crash-dumps inside efi-vars, so mine were full and new entries couldn't be written. Good thing /sys/firmware/efi/vars/ was mounted rw, thus a `rm -rf /sys…

Breaking your laptop's boot list will happen more often with it mounted RW anyway. So it's good it fixed it for you, but I doubt the number of cases it's fixed something/been useful outnumbers the cases where someone bricks their system using what is probably the most repeated Linux command on the internet: rm -rf /.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#90

Post by gtrubetskoy » Sat, Jan 30, 2016, 6:35 AM UTC

jerf wrote: post #45

JoshTriplett wrote: post #22

Earlier quoted context omitted.

If you mount efivarsfs read-only, efibootmgr can't make your system bootable. So at a minimum, you can't just remount the filesystem read-only; you need distribution integration so efibootmgr can still write to it. There's no point in mounting efivarsfs read-only; you might as well not mount it at all.

(Honest question, I lack hardware to check this on myself:) What do non-systemd systems do about this?

FreeBSD generally avoids system calls via filesystem - it's cute because you can change kernel parameters with echo and cat, but it's generally not efficient and prone to unexpected problems such as what this whole thread is about. You can just use appropriate commands which in turn use the appropriate system calls to accomplish the same thing.