4 ms·

For context, this is in reference to a bug that was discussed a couple weeks ago: https://news.ycombinator.com/item?id=10999335 https://news.ycombinator.com/ite

• kbenson 11y ago
  > but the developer's thought that it was working as intended Really? Is that evidenced by Lennart's response to this, which stated "The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root."[1]? I think it implies the opposite. 1: https://github.com/systemd/systemd/issues/2402 https://github.com/systemd/systemd/issues/2402
  • loeg 11y ago
    The firmware author(s) should not brick their hardware when EFI variables are deleted. That is an invalid behavior.
    • kbenson 11y ago
      Agreed, but that's almost a non-sequitur. The systemd developers are not the firmware developers. Additionally, while preferably we would have better firmware that couldn't be bricked in this way, we live in a world where this is often not the case, so the problem does need to be mitigated in some manner.
    • pyre 11y ago
      The amount of software that requires write access to EFI variables (as root) is pretty small, so leaving it open all of the time in an environment where the firmware writer could have bugs that cause this seems like it's not necessarily the best course of action.
    • vacri 11y ago
      We should also live in a world without kernel panics and BSODs, too.
    • snuxoll 11y ago
      Bingo! While preventing a user from accidentally hosing their system due to a bad firmware implementation this still does nothing to address potential malware, it's good to have a patch that helps but I think any blame directed at systemd or the kernel devs really needs to be redirected at poor firmware engineering efforts. Mounting efivars as ro is a bandaid, this patch is a bandaid - the real damage is yet to be done!
  • burke 11y ago
    Root is certainly capable, traditionally, of completely hosing all levels of the software stack. Usually it's the OS's job to protect even root from being able to hose hardware/firmware, especially by easy-to-make mistake.
    • kbenson 11y ago
      Yes, which is what we have here. My point is that I don't think there was ever any indication that the systemd developers thought there wasn't a problem to be fixed. That the fix was pushed farther up-stack so it was more comprehensive is not a bad thing in my eyes. Put another way, systemd mounting efivarfs read-only doesn't necessarily prevent you from bricking your machine by deleting files within that file system, it protects only those using systemd. The problem stems from the nature of efivarfs, and that it was implemented as a file system and not some other interface. Making it default to something more sane is a better (but by no means the best) solution, and that ideally would happen within the source, which is the kernel.
      • burke 11y ago
        I don't disagree with this, but I still think it's irresponsible of systemd to claim it's a kernel problem but not take steps to help people not brick their systems before it's fixed upstream.
        • kbenson 11y ago
          What, like his second comment (which was just a few minutes after his first, IIRC), which in it's entirely is '(note that you can remount it readonly at boot, simply by adding an entry for it into /etc/fstab, that is marked "ro")'? Keep in mind we've had a single month since this bug was submitted. Systemd had a release 11 days ago according to their repo[1], but if that wasn't expected to be picked up and used by distros (which it might not, depending on the distro and what changes have been implemented since the distro shipped/updated systemd), then the appropriate places to fix this are in the kernel and/or as a patch to the distro package for systemd. Really, I think the two appropriate places for this fix are the kernel, and if that's not expected to be rolled out soon, as a patch to systemd to mount it read-only by the distro shipping systemd. Systemd shipping the fix would only really help the small group of people that install systemd from source during the short window from 11 days ago until the next kernel is available (or that choose to run an older kernel), and makes the whole efivarfs situation a bit more confusing by leaving it read-only and immutable for the future. 1: https://github.com/systemd/systemd/releases/tag/v229 https://github.com/systemd/systemd/releases/tag/v229
  • nkurz 11y ago
    I was going from memory, and didn't reread Lennart's responses in the thread. But looking at it again now, I still think it's an accurate summary. Lennart's line after you quoted is "But beyond that: root can do anything really." I read this as Lennart saying that when root issues an 'rm' in efivarfs, the variable should be removed even if this renders the motherboard unusable without physical repairs. What's your interpretation? I've edited to fix my terrible punctuation, and to make it clear that 'it' refers to 'systemd', and to add a link to MJG's response on Twitter. I can edit further if you have a way to make it clearer.
    • kbenson 11y ago
      My interpretation, stemming from his statement that it is a problem to brick machines and his statement that some programs need write access, is that something needs to be put in place, but we can't unilaterally restrict root (which would be very un-Unixy to do). I think he was fairly ambigous in details on how to fix it (possibly because he wasn't sure the best path to take), and included with some fairly blanket statements about policy/belief that allowed people to interpret his statements however they were inclined. Unfortunately due to the polarizing effect of systemd (and Lennart's prior projects, and possibly Lennart himself), there are plenty of people inclined to believe he doesn't care.
  • Sanddancer 11y ago
    It shouldn't be mounted rw, and only exposed at root. It shouldn't be mounted by default. It shouldn't even be a bloody filesystem. EFI variables have so much metadata and other information attached to them that trying to wedge them into the filesystem is just asking for problems like this. Were the maintainers smart, they'd dump the file system all together, because it's a nonsensical way of presenting this data.
    • wfunction 11y ago
      I was saying the same thing a while ago but nobody takes it seriously.
    • mjg59 11y ago
      > It shouldn't be mounted rw It should be mounted rw because existing userspace expects it to be rw. > It shouldn't be mounted by default. It should be mounted by default because it's information that's relevant to various pieces of userspace. > It shouldn't even be a bloody filesystem. With hindsight, it should absolutely not have been a filesystem. There's very little metadata associated with EFI variables and the convenience of exposing this in a way that can be handled using read and write is huge, but real-world firmware turns out to be fragile enough that this was a mistake. But, in the absence of a time machine, there's very little I can do to fix that now.
      • Sanddancer 11y ago
        Start pushing for its deprecation. Devfs existed before it was replaced by udev. Keeping a broken system around just makes it harder to fix it. Interfaces on other systems, like the BSDs' sysctl show that you don't need to make everything a pseudofilesystem to make variables possible to change. If someone really really wants their efi variables as a filesystem, they could always write a fuse driver or the like.
      • thinkpad20 11y ago
        > It should be mounted rw because existing userspace expects it to be rw. Can you explain this a bit? I'm not familiar with the particulars of firmware, but I'm having a hard time imagining why any userspace program would expect a firmware partition to be writable. Even if there are any, certainly I'd have a hard time believing that they would need it to be mounted and writable all the time.
  • pyre 11y ago
    You're missing the end of that quote: > But beyond that: root can do anything really. ... so running "rm -rf /" as root should brick your motherboard because it's the responsibility of the motherboard manufacturer to protect against this. That's all fine and dandy in an idealized world, but in the "real world" there are going to be motherboard manufacturers that play fast and loose with these things.
    • mozumder 11y ago
      It's firmware. It's supposed to brick your system if you ruin it. Firmware is basically hardware. It's not a multi-user protected-mode operating system. It's the responsibility of the OS to make sure it doesn't ruin firmware.
      • wtallis 11y ago
        This wasn't removing firmware as in the actual boot code for the motherboard. It was just clearing the list of what drives to attempt to load an OS from. That list is explicitly intended to be accessible to and modifiable by operating systems, to provide a better user experience than the old method of the user having to manually change BIOS settings. The standard practice for PCs has always been that firmware configuration settings can be cleared (through a jumper or by pulling the battery) to reset the system to its factory state, forcing it to fall back to its conservative and safe defaults. Some systems have apparently forgotten to have defaults. Their firmware is already broken and afflicted with a major bug even if you avoid triggering it in this particular manner.
      • LordKano 11y ago
        It shouldn't be possible to brick hardware by running 'rm'.
        • mozumder 11y ago
          Right, but it should be possible to brick hardware through firmware updates. Again, this is the OS's fault.
  • datenwolf 11y ago
    It happens rarely, but actually I totally agree with Lennart on this one. Maybe not for the very same ultimate reasons, but nevertheless, I agree. Being able to brick hardware through a very oftenly used action (unliking a filesystem entry) throws us back into the times where one could damage display devices beyone repair by feeding them scan frequencies outside their operational range or by destroying hard disks by smashing the heads into a parking position outside of the mechanical range. We left those days behind us some 20 years ago: Devices got smart enough to detect potentially dangerous inputs and execute failsafe behaviour. It's just reasonable to expect this from system firmware. When talking about (U)EFI variables we're not talking about firmware updates, which are kind of a special action (and even for firmware updates its unacceptible that a corrupted update bricks a system¹). Manipulating (U)EFI variables is considered a perfectly normal day-to-day operation and the OS should not have to care about sanity checks and validity at boot time. (U)EFI is the owner and interpreter of these variables, so it is absolutely reasonable to expect the firmware to have safeguards and failsafe values in place. IMHO (U)EFI is a big mess, a bloated mishap of system boostrap loader. And I'm totally against trying to workaround all the br0kenness in higher levels. The more and often systems brick due to the very fundamentals of (U)EFI being so misguided, the sooner we'll move on to something that's not verengineered. ---- ¹: Just to make the point: When we developed the bootstrap loader for our swept laser product we implemented several safeguards to make it unbrickable. It's perfectly fine to cut the power or reset the device in the middle of a firmware upgrade. It safely recovers from that. Heck, the firmware in flash memory could become damaged by cosmic radiation, the bootloader would detect it and reinstall it from a backup copy in secondary storage.
    • lostphilosopher 11y ago
      Aside: I misread "swept laser" as "sweet laser" and was really bummed you didn't include a link to the Kick Starter for whatever project that would have been.
    • rjzzleep 11y ago
      I completely disagree. I looked at the patch above. I personally don't like. mounting efivars rw is akin to mounting boot rw by default. A sane linux distro will mount it ro and switch to rw whenever need. Defaulting to rw efivars is, excuse the language stupid. I've done a fair share of efi debugging even removing some of the variables that the kernel will now protect you from breaking. If the issue is that users should be able to remount efivars as rw whenever needed then that should be addressed, not prevent you from doing stuff to it because there is a rogue init system doing crazy stuff. EDIT: BTW, i don't think systemd does anything besides write to the various Boot* variables, but I may be wrong. I don't see why that can't be addressed with a remount. If you replace the boot.efi you still have to remount the efi partition anyway. While Matthew may be right that there is an issue that needs to be addressed, but in one of his tweets he basically says the kernel should fix it because tooling isn't and bioses suck. Well, maybe tooling should be forced to fix it. or from the issue: Matthew-Jemielity commented 24 days ago What needs efivars mounted at all anyway? So far I've seen: grub systemctl --firmware-setup reboot efibootmgr Since those likely need superuser, couldn't they handle (un)mounting it themselves? @annejan annejan commented 23 days ago As long as distribution that are aimed at consumers remount it ro and on updating kernels wrap grub with remount this is a complete non-issue.
• pavanky 11y ago
  That is not impartial at all.. It's a bunch of people enjoying the schadenfraude.
• eeZi 11y ago
  If you mount to r/o, a bunch of userspace applications break. Mounting it r/w is correct.
  • captainmuon 11y ago
    I'm curious, what kind of userspace application needs r/w access to EFI vars? I would think a) this are mostly system tools like boot managers and b) these tools need root (or setuid root) anyway, so why can't they just mount it themselves temporarily? Edit: It seems it is mostly grub-install, efibootmgr, and `systemctl reboot --firmware` that need this mounted rw. The first two aren't something that a casual user uses very often, and if someone does, a "Filesystem is mounted read-only" message will point them in the right direction. The latter is part of systemd and could easily be changed to mount efivarfs itself, no third party involved.
    • sandGorgon 11y ago
      Each time boot variables need to be written, etc.
    • mjg59 11y ago
      They could remount it read-write, but they don't. If systemd had made a unilateral change that broke existing userspace people would have been unhappy for a different reason. Doing this in-kernel means that the issue could be fixed without breaking existing userspace, so it's clearly the better solution.
    • zanny 11y ago
      The EFI spec is a horrible disastrous mess, but in theory you could be reading and writing EFIvars at runtime to dynamically configure boots - ie, "reboot to safe mode" would set the evifar next boot parameter to your initram-fs fallback. It would not be complicated to implement pam / polkit support for unprivlidged users to set such things without authenticating root. It does not change the fact the fault lies with shitty proprietary UEFI implementations, and nobody writing free software is at fault here.
    • EmanueleAina 11y ago