7 ms·

It is not a systemd bug to mount efivars read/write. The efitools - efibootmgr et al - require write access to that table. By the spec, this should not brick co

by zanny 11y ago

It is not a systemd bug to mount efivars read/write. The efitools - efibootmgr et al - require write access to that table. By the spec, this should not brick computers. The problem is not systemd, its disastrous proprietary UEFI implementations that are shipping the most insecure and awful code in the world. The problem is we cannot fix this for 9233. MSI will absolutely refuse to disclose the firmware to his laptop so that he can make it so his replacement does not also brick itself. People have been treating coreboot / libreboot like a joke for a decade, but this is exactly why those projects matter and why the continued erosion and trend towards firmware blobs and proprietary bootloaders cripples individuals control of the hardware they supposedly own. Its the John Deere tractor problem, but until enough people care - I mean, enthusiasts and techies already don't care, and we would need a popular general consumer movement to care to inspire real change - it will only get worse. All the 802.11 AC wireless NICs in the Linux kernel use firmware blobs. As of Skylake, there is not a single GPU supported on x86 systems in Linux that does not use firmware blobs. Almost every Chromebook is shipping Coreboot with cancerous unauditable firmware blobs. Samsung SSDs have bricked themselves because of their proprietary firmware blobs. Its a constant endemic problem yet nobody cares to put their money where their mouth is.

Cartwright2 11y ago
I sympathize with you that the UEFI implementations are bad, but I don't agree that it's an excuse for everything on top of UEFI to be bad. I think the two competing ideas are: Either you make libraries that strictly conform to the spec and are "technically perfect", leaving any bugs that stem from non-compliance to the violating parties (i.e. the UEFI implementors) Or, you make libraries that conform to the spec and have some "dirty" handling to work around holes left by crappy UEFI implementations. The first options feels great to write as a developer, but the second option is what most users really need - it's the "it just works" factor that users care about. I know it hurts to code around shitty implementations, but there's no other alternative if reliability and idiot-proofing matters. The best I can suggest is to make the workarounds "pluggable" so that developers don't have to deal with the harsh realities unless they specifically go looking for the plugged-in workarounds.
- wtallis 11y ago
  Working around ACPI bugs has been a big part of platform support pretty much from the inception of ACPI. It's already been a fact of life that systems ship with firmware that only just barely manages to not completely break with the intended OS (Windows du jour, or OS X for Macs) while Linux needs piles of workarounds. But UEFI significantly expands the exposure surface of bad firmware and the situation truly is moving toward being untenable. The computer industry really needs to overhaul how system firmware is developed, tested, and deployed. Linux devs and users aren't the only ones feeling the pain; they're just the ones who are both skilled enough to trace the problem back to firmware, and inclined to rant about it publicly.
  - zanny 11y ago
    Its a cultural problem in a lot of these companies (Foxconn, Samsung, etc). The software is a cost center, the hardware is the product. So the developers who write the code are rarely best in class or treated well. They don't have any influence in their companies to cause change. The suits would rather have everything proprietary with a flashy gif riddled loud glossy UEFI graphical screen than actually working because it looks good in board meetings. We have seen this happen elsewhere, and seen how it turned out. Browser rendering engines used to be NIH proprietary behemoths and IE6 was the pinnacle of the failure of that model. Graphics APIs and hardware are another great example - game developers are writing broken shaders that driver developers need to work around because the API is broken and the hardware is undocumented proprietary bullshit. Then you end up with insanity like Nvidia having the de-facto standard OpenGL implementation in the industry such that a ton of OpenGL programs break on AMD drivers because they don't have nuances and breakages of the Nvidia one. But gradually people realize that its not a profit center to be a closed source broken douchebag. Either the industry goes through the pain of correcting the damage (gecko / webkit / blink / etc) or just abandons the insanity (Metal / Vulkan / DX12 / Mantle). The thing is we are not putting any financial pressure on motherboard makers to not be complete proprietary douchebags. Libreboot and Coreboot are at best infant hobbyist projects with extremely low penetration and they take half a decade to support products or just ship firmware blobs that were half the problem in the first place anyway (cough, Chromebooks). Network routers used to be that way, until the grassroots OpenWRT projects were so succesful manufacturers started making sure their routers were supported (TP-Link / Linksys) or even in the best scenario selling hardware running open source firmware (Buffalo). This needs to happen with x86 chipsets and motherboards desperately because UEFI is making the ACPI mess worse when the answer has been obvious this whole time - open documentation and specifications and working together rather than working in secret.
protomyth 11y ago
> It is not a systemd bug to mount efivars read/write. The efitools - efibootmgr et al - require write access to that table. By the spec, this should not brick computers. Why a filesystem and not a library? Write access doesn't require a filesystem mount.
- deleted 11y ago
  [deleted]
- pilif 11y ago
  Part of the UNIX philosophy is to expose as a file what can be exposed as a file. That way, open, read, write and close is all you need.
  - retrogradeorbit 11y ago
    Is it? I understand there are many things in UNIX that are exposed as file like objects, but is it part of the philosophy that this should be done with anything that it _can_ be done on? Can you cite me any sources?
    - protomyth 11y ago
      I've heard and read that for Plan 9, but I too would like the source for UNIX.
  - em3rgent0rdr 11y ago
    Everything a file, even the computer itself: https://media.giphy.com/media/P7PmvHY6kzAqY/giphy.gif https://media.giphy.com/media/P7PmvHY6kzAqY/giphy.gif
  - protomyth 11y ago
    That's not a real good reason given the damage and since we're talking about systemd.
    - ustolemyname 11y ago
ploxiln 11y ago
Yes, firmware blobs suck, no argument there. But forget about that aspect for a moment, and consider the firmware a mostly unchangeable part of the hardware. Hardware has bugs. A lot of hardware has had bugs for a long time. Linux has had tables of "quirks" for hardware pci ids / usb ids / etc. for a long time, for thousands of buggy hardware devices it needs work-arounds for. Some of those bugs are really in hardware, some are in the firmware loaded on the hardware, it doesn't really matter. This is a pervasive reality, and it can't just be demanded that the user get hardware which is not "shitty" by this metric ... it's all a trade-off. And finally, I've used linux on bios systems and efi systems, and I've never needed efivars mounted, I've always set up the bootloader some other way (which was simpler for me to control and manage as I prefer). My personal biggest complaint about systemd is how it automatically mounts and starts and uses all kinds of stuff that I don't need. I prefer to set up what I need and want, and not have anything else cluttering up my system, just waiting to cause serious reliability or security problems, and getting in my way when I'm debugging something else. So I'll be up-voting all stories about "systemd did something automatically and on some systems it was unfortunate" because yeah, UNFORTUNATE STUFF HAPPENS WHEN STUFF HAPPENS AUTOMATICALLY. This is why I left windows and OS X in the first place! So I had easy and convenient control over my computer! And now it takes extra effort to override and disable all the crap that systemd is doing automatically, and I resent it. (I actually already have a script on my systems that unmounts efivars and pstore and some other unneeded filesystems after boot.)
- oconnore 11y ago
  Not everyone who runs linux wants to learn what is necessary to spend hours doing whatever the opposite of "automatic" is.
  - ploxiln 11y ago
    I feel for those people, I do. But in this market, you can't get something which does the right thing, without hours doing the opposite of "automatic". Such an offering does not exist. You can live with a system that has various issues due to malware, or major updates breaking things you depended on, or get someone who did spend many many hours learning to spend a couple hours fixing your problems. OS X isn't too bad of an approximation though, if you don't sign into iCloud, turn off spotlight integration with internet services (see the recent story about people's macs crashing due to a malformed response from the server!) and don't link your iPhone to a mac (or don't have one). Finally, don't update to the next release until just before it's replaced by another, e.g. don't upgrade from 10.10 to 10.11 until just before 10.12 is released (but do install security updates of course). But then again ... you'd have to be a bit of an expert to know whether you could trust my advice, and if not, who to trust, especially since you'll definitely get contradicting advice from similarly-knowledgable-sounding people ... so you're ultimately on your own.
ars 11y ago
> but until enough people care - I mean, enthusiasts and techies already don't care, and we would need a popular general consumer movement to care to inspire real change - it will only get worse. Create a virus that goes around messing with UEFI vars to brick the machine. Don't damage any user data, just the BIOS. It'll get fixed.
- yuhong 11y ago
  Not difficult to do it under Windows either BTW.
toast0 11y ago
> It is not a systemd bug to mount efivars read/write. The efitools - efibootmgr et al - require write access to that table. By the spec, this should not brick computers. How often do you need to run efitools though? Should it always be mounted read/write for the one or two times in the lifetime of the system that you need to adjust the boot variables? Wouldn't it be more reasonable for efitools to suggest you might need to remount it read/write while you're changing the variables?
userbinator 11y ago
MSI will absolutely refuse to disclose the firmware to his laptop so that he can make it so his replacement does not also brick itself The IBM PC, XT, and AT came with a physical copy of the complete source code for the BIOS, several hundred pages in a 3-ring binder. (You can get a digital copy of it here: https://archive.org/download/bitsavers_ibmpcat150ferenceMar84_26847525 https://archive.org/download/bitsavers_ibmpcat150ferenceMar8... ) IBM did this, despite the fact that they strongly recommended applications use the BIOS interfaces and not access the hardware directly. They could've saved so much paper if they just documented the API, but they didn't --- they released the whole thing. Yet 30 years later, in an era where it's easier than ever to distribute large amounts of information, companies regard such details as confidential and proprietary, hiding them even from their customers --- the real owners of their products. It costs next to nothing to distribute a DVD with each machine containing all the source code and documentation, or just put it up for download. Unfortunately the only recourse seems to be the occasional leak[1], and what's more disappointing is the overwhelming response that this is a "bad" and "insecure" thing, when it's really liberating what users should've received with their hardware. [1] http://adamcaudill.com/2013/04/04/security-done-wrong-leaky-ftp-server/ http://adamcaudill.com/2013/04/04/security-done-wrong-leaky-...
- yuhong 11y ago
  It wasn't useful for cloners either anyway, as it was copyrighted.
  - digi_owl 11y ago
    Well it could be used to write a spec sheet that then was used on clean room implement a clone. but i guess there was a risk that some terminology or similar could leak through.
    - umaxtu 11y ago
      Compaq managed it with their "Portable".
      - 11y ago

by zanny 11y ago

Cartwright2 11y ago

I sympathize with you that the UEFI implementations are bad, but I don't agree that it's an excuse for everything on top of UEFI to be bad. I think the two competing ideas are: Either you make libraries that strictly conform to the spec and are "technically perfect", leaving any bugs that stem from non-compliance to the violating parties (i.e. the UEFI implementors) Or, you make libraries that conform to the spec and have some "dirty" handling to work around holes left by crappy UEFI implementations. The first options feels great to write as a developer, but the second option is what most users really need - it's the "it just works" factor that users care about. I know it hurts to code around shitty implementations, but there's no other alternative if reliability and idiot-proofing matters. The best I can suggest is to make the workarounds "pluggable" so that developers don't have to deal with the harsh realities unless they specifically go looking for the plugged-in workarounds.

wtallis 11y ago
Working around ACPI bugs has been a big part of platform support pretty much from the inception of ACPI. It's already been a fact of life that systems ship with firmware that only just barely manages to not completely break with the intended OS (Windows du jour, or OS X for Macs) while Linux needs piles of workarounds. But UEFI significantly expands the exposure surface of bad firmware and the situation truly is moving toward being untenable. The computer industry really needs to overhaul how system firmware is developed, tested, and deployed. Linux devs and users aren't the only ones feeling the pain; they're just the ones who are both skilled enough to trace the problem back to firmware, and inclined to rant about it publicly.
- zanny 11y ago
  Its a cultural problem in a lot of these companies (Foxconn, Samsung, etc). The software is a cost center, the hardware is the product. So the developers who write the code are rarely best in class or treated well. They don't have any influence in their companies to cause change. The suits would rather have everything proprietary with a flashy gif riddled loud glossy UEFI graphical screen than actually working because it looks good in board meetings. We have seen this happen elsewhere, and seen how it turned out. Browser rendering engines used to be NIH proprietary behemoths and IE6 was the pinnacle of the failure of that model. Graphics APIs and hardware are another great example - game developers are writing broken shaders that driver developers need to work around because the API is broken and the hardware is undocumented proprietary bullshit. Then you end up with insanity like Nvidia having the de-facto standard OpenGL implementation in the industry such that a ton of OpenGL programs break on AMD drivers because they don't have nuances and breakages of the Nvidia one. But gradually people realize that its not a profit center to be a closed source broken douchebag. Either the industry goes through the pain of correcting the damage (gecko / webkit / blink / etc) or just abandons the insanity (Metal / Vulkan / DX12 / Mantle). The thing is we are not putting any financial pressure on motherboard makers to not be complete proprietary douchebags. Libreboot and Coreboot are at best infant hobbyist projects with extremely low penetration and they take half a decade to support products or just ship firmware blobs that were half the problem in the first place anyway (cough, Chromebooks). Network routers used to be that way, until the grassroots OpenWRT projects were so succesful manufacturers started making sure their routers were supported (TP-Link / Linksys) or even in the best scenario selling hardware running open source firmware (Buffalo). This needs to happen with x86 chipsets and motherboards desperately because UEFI is making the ACPI mess worse when the answer has been obvious this whole time - open documentation and specifications and working together rather than working in secret.

protomyth 11y ago

> It is not a systemd bug to mount efivars read/write. The efitools - efibootmgr et al - require write access to that table. By the spec, this should not brick computers. Why a filesystem and not a library? Write access doesn't require a filesystem mount.

deleted 11y ago
[deleted]
pilif 11y ago
Part of the UNIX philosophy is to expose as a file what can be exposed as a file. That way, open, read, write and close is all you need.
- retrogradeorbit 11y ago
  Is it? I understand there are many things in UNIX that are exposed as file like objects, but is it part of the philosophy that this should be done with anything that it _can_ be done on? Can you cite me any sources?
  - protomyth 11y ago
    I've heard and read that for Plan 9, but I too would like the source for UNIX.
- em3rgent0rdr 11y ago
  Everything a file, even the computer itself: https://media.giphy.com/media/P7PmvHY6kzAqY/giphy.gif https://media.giphy.com/media/P7PmvHY6kzAqY/giphy.gif
- protomyth 11y ago
  That's not a real good reason given the damage and since we're talking about systemd.
  - ustolemyname 11y ago

ploxiln 11y ago

Yes, firmware blobs suck, no argument there. But forget about that aspect for a moment, and consider the firmware a mostly unchangeable part of the hardware. Hardware has bugs. A lot of hardware has had bugs for a long time. Linux has had tables of "quirks" for hardware pci ids / usb ids / etc. for a long time, for thousands of buggy hardware devices it needs work-arounds for. Some of those bugs are really in hardware, some are in the firmware loaded on the hardware, it doesn't really matter. This is a pervasive reality, and it can't just be demanded that the user get hardware which is not "shitty" by this metric ... it's all a trade-off. And finally, I've used linux on bios systems and efi systems, and I've never needed efivars mounted, I've always set up the bootloader some other way (which was simpler for me to control and manage as I prefer). My personal biggest complaint about systemd is how it automatically mounts and starts and uses all kinds of stuff that I don't need. I prefer to set up what I need and want, and not have anything else cluttering up my system, just waiting to cause serious reliability or security problems, and getting in my way when I'm debugging something else. So I'll be up-voting all stories about "systemd did something automatically and on some systems it was unfortunate" because yeah, UNFORTUNATE STUFF HAPPENS WHEN STUFF HAPPENS AUTOMATICALLY. This is why I left windows and OS X in the first place! So I had easy and convenient control over my computer! And now it takes extra effort to override and disable all the crap that systemd is doing automatically, and I resent it. (I actually already have a script on my systems that unmounts efivars and pstore and some other unneeded filesystems after boot.)

oconnore 11y ago
Not everyone who runs linux wants to learn what is necessary to spend hours doing whatever the opposite of "automatic" is.
- ploxiln 11y ago
  I feel for those people, I do. But in this market, you can't get something which does the right thing, without hours doing the opposite of "automatic". Such an offering does not exist. You can live with a system that has various issues due to malware, or major updates breaking things you depended on, or get someone who did spend many many hours learning to spend a couple hours fixing your problems. OS X isn't too bad of an approximation though, if you don't sign into iCloud, turn off spotlight integration with internet services (see the recent story about people's macs crashing due to a malformed response from the server!) and don't link your iPhone to a mac (or don't have one). Finally, don't update to the next release until just before it's replaced by another, e.g. don't upgrade from 10.10 to 10.11 until just before 10.12 is released (but do install security updates of course). But then again ... you'd have to be a bit of an expert to know whether you could trust my advice, and if not, who to trust, especially since you'll definitely get contradicting advice from similarly-knowledgable-sounding people ... so you're ultimately on your own.

ars 11y ago

> but until enough people care - I mean, enthusiasts and techies already don't care, and we would need a popular general consumer movement to care to inspire real change - it will only get worse. Create a virus that goes around messing with UEFI vars to brick the machine. Don't damage any user data, just the BIOS. It'll get fixed.

yuhong 11y ago
Not difficult to do it under Windows either BTW.

toast0 11y ago

> It is not a systemd bug to mount efivars read/write. The efitools - efibootmgr et al - require write access to that table. By the spec, this should not brick computers. How often do you need to run efitools though? Should it always be mounted read/write for the one or two times in the lifetime of the system that you need to adjust the boot variables? Wouldn't it be more reasonable for efitools to suggest you might need to remount it read/write while you're changing the variables?

userbinator 11y ago

MSI will absolutely refuse to disclose the firmware to his laptop so that he can make it so his replacement does not also brick itself The IBM PC, XT, and AT came with a physical copy of the complete source code for the BIOS, several hundred pages in a 3-ring binder. (You can get a digital copy of it here: https://archive.org/download/bitsavers_ibmpcat150ferenceMar84_26847525 https://archive.org/download/bitsavers_ibmpcat150ferenceMar8... ) IBM did this, despite the fact that they strongly recommended applications use the BIOS interfaces and not access the hardware directly. They could've saved so much paper if they just documented the API, but they didn't --- they released the whole thing. Yet 30 years later, in an era where it's easier than ever to distribute large amounts of information, companies regard such details as confidential and proprietary, hiding them even from their customers --- the real owners of their products. It costs next to nothing to distribute a DVD with each machine containing all the source code and documentation, or just put it up for download. Unfortunately the only recourse seems to be the occasional leak[1], and what's more disappointing is the overwhelming response that this is a "bad" and "insecure" thing, when it's really liberating what users should've received with their hardware. [1] http://adamcaudill.com/2013/04/04/security-done-wrong-leaky-ftp-server/ http://adamcaudill.com/2013/04/04/security-done-wrong-leaky-...

yuhong 11y ago
It wasn't useful for cloners either anyway, as it was copyrighted.
- digi_owl 11y ago
  Well it could be used to write a spec sheet that then was used on clean room implement a clone. but i guess there was a risk that some terminology or similar could leak through.
  - umaxtu 11y ago
    Compaq managed it with their "Portable".
    - 11y ago