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

41–50 of 180 posts

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

#41

Post by yuhong »

simoncion wrote: post #35
Sanddancer wrote: post #33

Earlier quoted context omitted.

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…

> As an aside, goddamn is UEFI ugly. You're goddamn right it is. Matthew Garrett [0] used to do UEFI stuff for -IIRC- RedHat. He has MANY blog posts about fucked-up parts of the spec, and horrifyingly fucked-up implementations of the same. Sadly, it looks like most (if not all) of his posts are now tagged "advogato, fedora", so I can't point you specifically to the UEFI gore posts. [0] http://mjg59.dreamwidth.org/

My personal favorite is how http://lkml.org/lkml/2013/11/11/653 is posted by @hp.com that also locked access to UEFI updates to paid customers not long after it was posted.

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

#42

Post by kbenson »

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 hose a system.

> But beyond that: root can do anything really.

This is a truism for Unix, and altering this is much more of a problem than the occasional bricked machine. This is free software, and the ability to use it to control our hardware to the fullest extent possible is part of that freedom. Root cannot and should not be restricted from doing what it needs. It can, have hurdles put in place to make it harder to accidentally do something it doesn't mean to do though.

So, agreement on the problem, and agreement that something needs to be done to fix it, and a caution that access can't be entirely closed off without consequences, so root needs access. What's so horrible about that?

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

#44

Post by Silhouette »

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 are all perfectly competent, with this sort of arrangement you're one vulnerability away from having bricked boxes, not just one vulnerability away from reimaging and restoring from backups.

What happened to making systems safe by default? There is no need to make this kind of system so fragile.

What happened to using the right tool for each job? The obsession with making everything look like a file that lives under the same global file system hierarchy causes endless problems, and it's never been entirely clear to me what benefits it's supposed to offer in return. It's interesting that Poettering remarked on exposing /dev/sda as root as well, because it's another excellent example of how broken this model is.

What happened to minimising trust? Of course it's crazy that any hardware/firmware actually allows itself to be permanently broken by a software error like this, but the software should not assume the hardware/firmware will take responsibility for providing any necessary safeguards.

Ultimately, this is just bad engineering and bad UI. It can result, and reportedly has resulted, in serious damage. No amount of dressing it up will change that, and the root cause of the problem should be fixed.

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

#45

Post by jerf »

JoshTriplett wrote: post #22
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…

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?

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

#46

Post by bootload »

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…

"Nobody sells a chainsaw with safeties disabled, remarking 'you can always attach the chain catcher'"

Last week after a storm I watched two blokes cut up some fallen wood. One held the chainsaw, the other ran the wood over the blade.

When you start using tools at a low enough level, there are some things you cannot guard against.

  Mounting efivarfs read/write by default 
  can lead to accidental deletion of the 
  EFI variables. -- laloch
At system level there no way this should happen. That is like having a chainsaw with a reversible saw motion.

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

#47

Post by mikeash »

kbenson wrote: post #36
mikeash wrote: post #14

Earlier quoted context omitted.

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.

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

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

#48

Post by chrisper »

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

Linux on the desktop is now a lot easier than it was 10 years ago. I just recently switched to Linux Desktop after having it used on servers for a lot longer.

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

#49

Post by Sanddancer »

cmiles74 wrote: post #37
avereveard wrote: post #15

Earlier quoted context omitted.

"let's make everything a filesystem so it's dead easy to hang yourself from userland tools"

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.

Except that the UEFI spec has a shitton of bits and pieces where the filesystem metaphor falls apart on. There are attributes that determine which parts of the boot process variables are visible in, variables that should require a guid in addition to data, etc. It's an ugly, messy protocol that really does require specialty tools.

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

#50

Post by ploxiln »

rando3826 wrote: post #21
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…

In linux, there is the immutable file attribute which won't let root rm the file without first changing it with chattr.

File attributes need to be implemented by the filesystem. efivars is a pseudo-filesystem which does not implement them. It could, but that is one of the more needlessly complicated solutions...
Post reply on HN