Live data from Hacker News

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

github.com

71–80 of 180 posts

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

#71
post #67

Earlier quoted context omitted.

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.

Wow, that's some bad UI. Wells Fargo ATMs require you to take your card before it gives you the money.

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

#72
post #68
post #47

Earlier quoted context omitted.

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.

Isn't it already only writeable by root? The request is to make it not even writeable by root without taking some additional action to make it writeable first. If I understand correctly, that bit you quote just describes the current situation.

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

#73
post #42
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…

Nobody is saying root shouldn't be able to access such functionality but rather it just shouldn't be mounted rw by default. This is actually fairly uncomplicated.

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

#74
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…

Fixing every vendors implementation is an impossible task. Ensuring that the default configuration can't brick your motherboard is an easy one. So do the easy thing to ensure user safety WHILE working to solve the hard one to the extent feasible.

Robust systems must work in the real world not just in an ideal one.

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

#75
post #28

Earlier quoted context omitted.

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 derivatives rule the mobile space spo in essence it won really big. The desktop is not that impoortant. And so many of its paradigms are quite dated compared to the mobile experience.

The mobile experience is in a lot of ways absolute garbage designed by incompetents.

That the dominate platforms have any customers at all just illustrates how mediocre the entire software industry is.

If software were medicine we would still be leeching people and learning about the miasma theory of germs.

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

#76
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…

It is true that this is ultimately a hardware/firmware problem, but if the solution is waiting for motherboard manufacturers to not have bugs or stupid designs, then we will be waiting forever. Badly designed hardware will always exist.

If you look at how probing for hardware works in the Linux kernel, quite a few older drivers (and the occasional feature subtree) have auto-probing disabled by default because it tended to crash some types of hardware. You see this again in lm_sensors, where the auto-probe script specifically asks permission (with a default "no") before it tries certain probes that risk crashing the hardware.

We don't see this as much in recent years as hardware has gotten better - listing the device_ids/vendor_ids on a buss is much safer than poking ISA IO ports - but the problem remains. Some hardware needs special hand-holding, especially in the initial probe or initialize stages. Hence, tools that handle those stages are always going to have special cases and other annoyances.

> the amount of flack being received doesn't seem warranted

The flack against Pottering (and the rest of the systemd cabal) is because this isn't the first time his idealism has caused serious problems for others. Yes, it would be nice if we could just mount UEFI areas (or anything else). In reality, as this bug shows, this is dangerous behavior. It should have been made optional, or the entire idea of exposing those UEFI areas as a filesystem should have been reconsidered - a special purpose tool that handled bugged hardware might have been more appropriate.

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

#77
post #67

Earlier quoted context omitted.

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.

Wow, that's some bad UI. Wells Fargo ATMs require you to take your card before it gives you the money.

[deleted]

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

#78
post #42
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…

I agree with everything you wrote, but he did close the issue, which generally implies "I'm not going to do anything about it".

Maybe it's not his responsibility and distro creators need to protect it, I don't know.

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

#79

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…

> As an aside, goddamn is UEFI ugly.

I was installing a graphics card once and broke my EFI setup. Not because of the graphics card, but because I apparently bumped the CMOS battery enough to wipe settings.

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

#80
post #42
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…

He who play in root, kill tree.

-Slackware fortune file

Post reply on HN