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

11–20 of 180 posts

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

#11

Post by _qc3o »

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 is the right thing to do.

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

#12

Post by mikeash »

ajross wrote: post #3

To be fair, userspace access to these variables is required in order to manage EFI boot. Having them there to be deleted (by root!) accidentally is probably bad, but this isn't a meaningful security fix. The real crisis here is that modern firmware is developed in an environment so fragile and isolated that it's simply unable to recover from configuration that is "wrong". I had a laptop that I bricked about two years…

I don't think this is meant to be a security fix, it's just meant to make it so you can't accidentally break your hardware with what seems like an unrelated filesystem command.

I agree that the stupid firmware is ultimately to blame, and mounting this stuff read-write is a fairly reasonable initial decision. But given the existence of this stupid firmware, the resistance to implementing an easy mitigation by mounting it read-only is insane. I can't understand why there are any responses besides "oh shit, we'd better change this."

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

#14

Post by mikeash »

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.

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

#15

Post by avereveard »

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…

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

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

#17

Post by Sanddancer »

Unless you're doing something super screwy, GRUB, the excuse for this backwards default, doesn't even need access to UEFI. UEFI booting looks for a file in a FAT-formatted partition of a hard disk with a specific ID -- C12A7328-F81F-11D2-BA4B-00A0C93EC93B for GPT disks and 0xEF for MBR disks. All EFI does is to look for a file BOOTX64.EFI on that partition. There's no need to muck around the UEFI settings for this, it Just Fucking Works.

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

#18

Post by gh02t »

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 don't think he's kicking the can down the road, at least not all the way to end users. I think he is implying that it's something distros should do, presumably after installing as part of their post-install config.

Either way is going to break things and I'm sure there'd be people lining up to complain about them making it ro by default or adding some sort of safety layer in. Might as well leave it as it is and let the various distros do what they want with it. I do think though that someone should do something and this sort of thing shouldn't be possible, but I can understand the stance of leaving it up to the distros to decide as a reasonable compromise.

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

#19

Post by victorhugo31337 »

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

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

#20

Post by JoshTriplett »

Sanddancer wrote: post #17

Unless you're doing something super screwy, GRUB, the excuse for this backwards default, doesn't even need access to UEFI. UEFI booting looks for a file in a FAT-formatted partition of a hard disk with a specific ID -- C12A7328-F81F-11D2-BA4B-00A0C93EC93B for GPT disks and 0xEF for MBR disks. All EFI does is to look for a file BOOTX64.EFI on that partition. There's no need to muck around the UEFI settings for this, i…

Only removable disks use bootx64.efi, though some (but not all) BIOSes will look for that on fixed disks too. efibootmgr needs access to efivarsfs to configure an EFI boot entry for Linux on a fixed disk. Relying exclusively on bootx64.efi on the EFI system partition will break on some devices, and will overwrite the Windows bootloader (and conversely, Windows doing so will render Linux unbootable).
Post reply on HN