Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

51–60 of 180 posts

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

#51

Post by SFjulie1 »

_qc3o wrote: post #11
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…

Because everything is a file in unix derivative land. That is a common accepted practice at least but optimizing for the common case here is the right thing to do. How often do people need to manage EFI things through the filesystem and how much of an inconvenience is it to have the initial mount be read-only? The answer is obvious to me because I know people run `rm -rf` often enough that having a safeguard in place…

A file maybe, a filesystem no.

You can't 'ls' your network connections.

And for tricky API that does not match the filesystem view we have the fnctls.

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

#52

Post by unethical_ban »

victorhugo31337 wrote: post #19
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…

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 believe that broad games support and GPU driver support in the past two years has made Linux more viable for a lot of the kind of people who might not install it. I have been running a linux-only household for a year now.

Offices most certainly could run linux only if they weren't chickenshit (I mostly kid, but after seeing how broken the desktop management model is now anyway, I don't see why Linux can't be used more in Corporate.)

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

#53

Post by Sanddancer »

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 has an efi library that's used in early boot to handle this instead. To be honest, with the structure of UEFI, exposing it as a filesystem is problematic at best. A filesystem just hides too much data from you -- errors, the reason a call to setting a variable failed, etc. Not everything is a file, and shoehorning things in to try to pretend just doesn't work.

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

#54

Post by rcxdude »

sjukfan wrote: post #30

I can't understand why people argue about this. Just put some safety measures on it already. Or at least change the rm option to "--brick-my-motherboard"

Honestly, I feel the issue is more rm -rf's default behaviour being to cross filesystems. This is almost always not what you want (and tends to result in deleting network drives, to give an example which has nothing to do with systemd), especially considering attempting to delete a mount point fails.

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

#55

Post by C0DEHERO »

Silhouette wrote: post #44
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…

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. I tend to think the Linux on the desktop thing is a bit of a diversion, but this issue and Poettering's response certainly lend weight to the concerns many have raised about systemd. What happened to defence in depth? Even if your users…

Well, I could see a problem occurring if Poettering decided not to represent efivars as files. Many people would claim that Systemd is trying to get rid of the Unix philosophy and force everyone to use the software if they want to keep up. After all, so many people are already complaining that Systemd uses a binary format to store logs.

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

#56

Post by andmarios »

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/firmware/efi/vars/dump-*` fixed it.

Some kind of protection would be nice, but the ability to see and use efi-vars as a filesystem is useful too. If we listen to security researchers too much, our computers will be no fun.

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

#57

Post by JoshTriplett »

Sanddancer wrote: post #33
JoshTriplett wrote: post #25

Earlier quoted context omitted.

The EFI standard specifically limits that to removable media. Windows installs itself via the EFI boot variable mechanism; Windows also installs itself to bootx64.efi, but even if you overwrite that, you can still boot Windows via its EFI boot entry. Having Linux systems install themselves only to bootx64.efi would produce a fragile installation (particularly in dual-boot configurations).

Okay, I read the standard and you're right, they are supposed to install to a vendor specific location, so my apologies. Boot's an additional place you can put it, but not the regular place. As an aside, goddamn is UEFI ugly. BIOS it was easy -- set the partition you want to boot as bootable, and away you go. here you have to copy the bootloader file, and then write to the firmware what file you want to boot, which f…

At least in theory, UEFI intended to avoid the current problem of OS bootloaders taking over (by writing to the MBR) and then needing to know how to boot other OSes. (Or, in practice, Linux bootloaders knowing how to boot everything and all other bootloaders only booting their own OS.) If you install your bootloader via the standard UEFI mechanism, you won't step on any other OS on the same system. And at boot time, you get a menu of OSes, with labels provided by those OSes.

The problem comes in with the small handful of UEFI firmware implementations that get EFI variables so horribly wrong that attempting to write to them in the standard way will cause the EFI firmware to overwrite itself or otherwise brick the machine. Linux does attempt to work around some of those systems through very careful handling of EFI variable writes.

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

#58

Post by _qc3o »

SFjulie1 wrote: post #51
_qc3o wrote: post #11

Earlier quoted context omitted.

Because everything is a file in unix derivative land. That is a common accepted practice at least but optimizing for the common case here is the right thing to do. How often do people need to manage EFI things through the filesystem and how much of an inconvenience is it to have the initial mount be read-only? The answer is obvious to me because I know people run `rm -rf` often enough that having a safeguard in place…

A file maybe, a filesystem no. You can't 'ls' your network connections. And for tricky API that does not match the filesystem view we have the fnctls.

With fuse you certainly can.

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

#59

Post by geggam »

sjukfan wrote: post #30

I can't understand why people argue about this. Just put some safety measures on it already. Or at least change the rm option to "--brick-my-motherboard"

I believe you hit the nail on the head. Many folk with experience have a different perspective than the folk writing this stuff. Ignoring their perspective dooms you to repeating their mistakes.

The Unix way isnt some holy grail holy shit perfect way. Its the simplest. Simple means its simpler to unfk. Because it will get fk'd.

Rendering someones hardware DOA is a really bad thing. Leaving that as a vector of attack is irresponsible at best.

If Redhat leaves this in expect legal issues.

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

#60

Post by magila »

CoconutPilot wrote: post #43

Unix has a long tradition of doing a `rm -rf /` before reinstalling a system. I don't agree with the people saying "don't do that". It worked safely before, it should still be safe to do. (yes I know about --no-preserve-root)

`rm -rf /` was never safe, even if reinstalling the system. If it worked for you then you were just lucky. In the context doing a reinstall you need to specify --one-file-system, but really you should just reformat the partition, it'll likely be much faster anyways.
Post reply on HN