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.
Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
71–80 of 180 posts
Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
#72Earlier 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.
Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
#73The 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…
Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
#74Earlier 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…
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'
#75Earlier 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.
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'
#76Earlier 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…
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'
#77Earlier 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.
Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'
#78The 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…
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'
#79Earlier 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…
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'
#80The 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…
-Slackware fortune file