1. 23
  1.  

  2. 14

    It’s shit like this (and also EFI being bad) that makes me downright ashamed of being in this industry. Telling someone that they deserved having their laptop or motherboard turned into a paperweight because some jerk didn’t bother to make their software (systemd) mount efivarfs ro by default? The arrogance is as breathtaking as the sheer incompetence.

    Nothing prevents efivarfs from being mounted ro and requiring someone mount it as rw to mess with it. Many other systems have an NVRAM protection bit that needs to be explicitly flipped before being able to write to NVRAM, or even don’t write to NVRAM until you do an “nvram commit”. This isn’t groundbreaking or rocket science. Failing to write-protect NVRAM by default (as is usually done in other systems where NVRAM can affect boot) smacks of incompetence and laziness.

    (and no, bricking a motherboard isn’t even close to equivalent to hosing a filesystem through access with /dev/sda,

    1) you can simply restore from backup if you hose your fs, however not all of us have the dosh on hand needed to replace a laptop or motherboard

    2) merely rm'ing /dev/sda won’t hose your filesystem, you actually need to bother writing to it)

    1. 6

      Nah, they deserved to have their MB bricked for choosing to run Linux over OpenBSD. :)

      But for serious, OpenBSD has long prohibited even root from direct hardware access by defaulting to “securelevel” 1. This of course gets endlessly mocked because it’s not actually any more secure against a determined attacker. It does have the nice effect of preventing root from accidentally fucking things up too bad though.

      1. 2

        I referred to “securelevel” while explaining this efivarfs fiasco to a friend this morning and yeah, there’s definitely a place in production systems for features that help avoid accidentally clobbering things (especially if they’re rarely changed and very important) even if they aren’t super useful security-wise.

        1. 1

          I’m not super-knowledgeable about Darwin internals, but I think OSX does something vaguely like that too, using Mach I/O ports to proxy access to at least some kinds of hardware, instead of giving root direct access. For EFI NVRAM, they provide a userland tool, nvram(8), which root can use to read/write variables with some sanity checking. Of course you could bypass any checks in the tool itself by writing your own. But even then, if my read of the linked source is correct, the tool is going through some kind of Mach I/O port proxy, not getting direct access, so you’d still have that level of indirection. Presumably if you really own the machine there’s a way to bork things if you want, but they don’t seem to make it particularly easy.

          1. 1

            That source is so old I believe it’s for Power Macs, which used Open Firmware.

      2. 22

        I’m going to skip a whole giant rant currently scrolling through my head over this. I’ll limit myself to immaturely calling Lennart a pigheaded idiot and leave it at that.

        But more constructively, running software—at any level, including the kernel—should not be able to permanently brick hardware. (I mean, it’s partially unavoidable; you’ve been able to reflash your BIOS with nonsense thus destroying your motherboard for ages now. That’s fairly difficult to do accidentally, though, and more recently we’ve started seeing checksums, backup firmware, dual images and the like to make it even more durable.) EFI is not a well-designed system and the ability of hardware engineers to write outrageously terrible software is boundless, but allowing configuration of a set of variables that are meant to be configurable to brick it is truly atrocious. (For comparison, I can’t brick my BIOS no matter how incorrectly I set its configuration options.) This should be a recoverable problem.

        1. 6

          There’s a good response by Matthew Garrett in this twitter thread - the gist is “This is a kernel problem that needs to be fixed in the kernel”.

          1. 2

            It’s an issue where both sides are technically right on their own, but the best solution would require actually a sum of both approaches.

            Yes, the fact that you can brick your hardware sucks, but the fact that it runs non-replaceable blob of proprietary software that doesn’t even follow the basic spec it’s really supposed to sucks too.

            Best solution would actually require fixing both problems (or the just the hw one, so the issue does not appear in the first place.)

            I wonder whether this could be spun into some kind of… marketing leverage for open hardware and libreboot.

            1. 5

              Even if PC firmware (UEFI/ACPI and friends) weren’t insecure needlessly-complicated shit, it’d still be quite negligent for systemd/linux to mount EFI vars rw by default.

              Fussing with NVRAM boot config variables is both rare and could make a system unbootable – asking boot config software to flip a write-protect flag in /sys/ or to hold off writing to NVRAM until you explicitly ask the kernel to commit writes is reasonable.

              Almost every non-x86 platform that uses NVRAM for boot config has had some sort of mechanism like that (or even just a physical write-protect jumper!) to avoid accidentally clobbering NVRAM for decades.