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

61–70 of 180 posts

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

#61

Post by mikeash »

rcxdude wrote: post #54
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.

I think there are at least three issues here.

One is efivarfs making it too easy to destroy stuff. It should probably identify problematic hardware and prohibit modifications that break that hardware. This is no fun, but hardware-specific workarounds are a fact of life for real-world OSes.

One is, as you say, bad default behavior with rm. Crossing filesystems by default is pretty weird. Preventing that unless it's explicitly requested would largely fix this problem and many others too.

And one is mounting efivarfs read-write by default. It's too dangerous to be that easy to modify.

I don't think it's too useful to try to pin one of these down as "the issue." They're all worth fixing.

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

#62

Post by threatofrain »

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 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 adequately competitive.

This will likely not be a server concern. Engineers probably won't be interested in a service that opaquely collects data and sends it off to remote locations just so that they can say, "Cortana, run the Ansible script to redeploy my API server." But desktop users would find value in saying, "Cortana, move all email from unknown entities to my todo list."

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

#63

Post by C0DEHERO »

Osiris wrote: post #5

> (note that you can remount it readonly at boot, simply by adding an entry for it into /etc/fstab, that is marked "ro") He's suggesting that not mounting it as read-only by default will break a few things like grub-install, but promptly suggested editing /etc/fstab to mount it read-only by default. So... his own solution to the problem is to mount it as read-only. The hard drive analogy is ridiculous because while y…

To be fair, you could make a distribution that works this way (or you could modify a current install). Simply make critical files belong to root, make files that are fairly important (config files) belong to a special user, and make user files belong to the user. This way, you can do day-to-day system administration with a more powerful but still limited user, while performing critical operations, such as installing a bootloader, as root. NixOS sort of does something similar, although not necessarily for the reason of preventing breakage. Any regular user can install packages for his/her own environment, which the daemon installs in the package directory that belongs to "nixos" You still need to use root for system configuration, unless the "configuration.nix" could also be chowned to the "nixos" user.

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

#64

Post by deathanatos »

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…

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 motherboard's manufacturer's stupidity, but the amount of flack being received doesn't seem warranted; has the same amount of outrage been directed towards the manufacturers?

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

#65

Post by ossreality »

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...

Man you people drive me nuts. Here I've been using Linux on the desktop for 6 years. Y'all spend more time being blowhards about Linux on the desktop than I've ever spent "fighting" anything in Linux.

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

#67

Post by billfor »

LoSboccacc wrote: post #40
cmiles74 wrote: post #37

Earlier quoted context omitted.

Let's make everything a filesystem... so that they are easy to access and modify. Anyone can "rm -rf" anything, that doesn't mean that they should.

that's a pretty weak argument. fault is in the firmware, but design of thing is important. it's why ATM gives the card back before the money. they don't just tell the user to suck it up. they implement good, safe best practices.

The new Citibank ATMs that take the chip card hold onto it until after you've taken your money. I already accidentally left my card in a machine after taking the cash.

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

#68

Post by kbenson »

mikeash wrote: post #47
kbenson wrote: post #36

Earlier quoted context omitted.

rm -rf / probably doesn't do what you think it does. The coreutils version of rm includes --preserve-root[1], which is the default[2]. It also supports --one-file-system, which would prevent this and a host of other problems as well. That said, I don't really see a problem with Lennart's response. It's basically, "we should take steps to make this hard to do, but root is capable of doing anything, so don't expect it…

Is there some response besides the one linked here? Because all I see here is basically saying, "We're not going to change anything, this is not a problem, remount it yourself if you don't like it."

He says "The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root." That looks like agreement that it needs something done to me. I took the followup comment to be a useful to on how to mitigate the problem until then.

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

#69

Post by pdkl95 »

enedil wrote: post #28
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...

Linux is important on dekstops to thrive. I've successfully transitioned my parents to Linux. What I got? Deser maintainance, more reliability, everything just works for them. And of course, sticking to proprietary solutions in a long run would be rather a sick idea.

> Linux is important on dekstops to thrive.

That's what distros are for. The "Linux" family of operating systems are used for a very wide variety of uses, some of which are orthogonal (and sometimes incompatible) with "desktop" features.

Something like "Year of the KDE desktop" or "Year of the Linux Mint desktop" would make much more sense than trying to shove all of Linux into one pigeon hole. In fact, even within "desktop" there is variation. While an easy to use, mostly automagic desktop is a good idea, that's not the only definition of "desktop".

Ultimately, this is the the biggest problem with the idea of "THE Linux desktop"[1]: one size never fits all. Fortunately, Linux distributions exist[2] allowing for great variety - including "everything just works" desktop distributions. Just remember that the Linux ecosystem is larger than one type of distro.

[1] and systemd, and 15+ years ago the "desktop environments" that insisted there should be only one GUI toolkit, etc

[2] This assumes distros decide to keep their own identity instead of continuing on the homogeneity bandwagon that many joined when they converted to systemd. Turning into a clone of Red Hat is the path to obsolescence.

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

#70

Post by toast0 »

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…

Iirc, bios just loads the first sector[1] of the disk into a specific place and jumps into it. Interpreting the partition table or not it's up to that code.

[1] or maybe the first 512 bytes, if a sector is bigger

Post reply on HN