back to article Little warning: Deleting the wrong files may brick your Linux PC

Here's a friendly warning from El Reg: don't wipe the wrong directory from your Linux system, or you may end up bricking the computer. This has happened to people, we're told. The directory in question is /sys/firmware/efi/efivars which is a special filesystem that presents the configuration settings for the computer's …

Page:

  1. Anonymous Coward
    Anonymous Coward

    I'm going to go out on a limb here but don't most people disable UEFI anyway when installing Linux?

    I know I do.

    1. wolfetone Silver badge

      I always found I've had to disable UEFI to install Linux properly. I spent an evening with my new laptop installing Fedora, trying to work out why it wouldn't boot properly. Eventually I worked out how to disable UEFI, and it eventually sprang in to life.

      I still view UEFI as poison and it adds no real value to Linux users. It's just something Microshite asked the vendors to put on the machines to "secure the computer" - translated, means "secure our profits".

      1. petur

        My T450s dual-boots Windows and Debian testing with the bios set to UEFI and legacy off

        Guess that means it works....

        1. Anonymous Coward
          Mushroom

          petur...

          Until MS roll an update to change the UEFI... oh, lost your Linux? MS will consider that an upgrade.

          1. pmartin66

            Re: petur...

            http://www.uefi.org/faq

            go educate yourself.

      2. Anonymous Coward
        Anonymous Coward

        So you think PCs should have stuck with a BIOS architecture that dates back all the way to the twin floppy IBM PC? And FYI it wasn't 'Microshite' who initiated the change, 'AppleShite' implemented EFI on Macs way before it was put on PCs. And it wasn't developed by Microshite, IntelShite developed it and it is now managed by the UEFIShite consortium. So I'm sorry if it upsets your Linuxshite but tough. But anyway, Linuxshite is supposed to be so efficient it doesn't need modern hardware to run like the proverbial shite of a shovel. So stick to old pre UEFI shite motherboards and your shite will be fine ;))

        1. Anonymous Coward
          Anonymous Coward

          "So you think PCs should have stuck with a BIOS architecture that dates back all the way to the twin floppy IBM PC?"

          Well, PCs are still using a binary number system that's hundreds of years old. And transistors that were developed 50+ years ago. Not to mention capacitors, resistors, chokes, etc from a century or more ago. And, eh, well, how long has electricity been around?

          Just stirring the pot...

          1. John Brown (no body) Silver badge
            Joke

            "And, eh, well, how long has electricity been around?"

            Are you still using that old fashioned analogue electricity ;round your way? Still waiting for the upgrade to the new, faster and more efficient digital electricity?

            1. Roland6 Silver badge

              Still waiting for the upgrade to the new, faster and more efficient digital electricity

              We're still on analogue electricity round here, but looking forward to when HD electricity becomes available.

              1. Captain DaFt

                "We're still on analogue electricity round here, but looking forward to when HD electricity becomes available."

                And then, two years later, have the shocking revelation that your old HD electricity is obsolete, and now have to rewire your whole house to upgrade to 4K.

                1. Roland6 Silver badge
                  Pint

                  "And then, two years later, have the shocking revelation that your old HD electricity is obsolete, and now have to rewire your whole house to upgrade to 4K."

                  What!! you mean all the time my daughter has spent learning about the care of magical creatures isn't going to get her a nice job for life with the electricity company!

            2. jelabarre59

              > Are you still using that old fashioned analogue electricity ;round your way? Still waiting for the upgrade to the new, faster and more efficient digital electricity?

              .

              "digital electricity", that must be what Dyson is using in all those "digital motors". (as in "WTF is a 'digital motor'?"

        2. Anonymous Coward
          Anonymous Coward

          OBF would have been preferable

          As in the title.

        3. Tac Eht Xilef

          "And FYI it wasn't 'Microshite' who initiated the change, 'AppleShite' implemented EFI on Macs way before it was put on PCs."

          Err, wrong. Gateway were the first to use it (on one of their media center PCs) in 2003/2004, several years before Apple even started using Intel processors.

          (Yeah, yeah, Open Firmware / OpenBoot is essentially the same thing done differently. So why aren't you blaming Sun?)

          1. Colin Tree

            difference of gold and lead

            Done very differently !

            open firmware / boot is an interactive programming language, allowing interactive testing or writing drivers or hardware diagnostics and it resides in just a few k-bytes of firmware.

            based on ANS Forth.

            Sun's boot was BSD license.

            PCI code was compiled Fcode which would run on any open-boot machine, platform independent !

            very small amount of assembler under Fcode to move to a different platform !

            efficiently run up new hardware !

            take a day and learn Forth, it's simple and has been implemented on most platforms.

            Ok

      3. AdamWill

        UEFI != Secure Boot

        UEFI is not Secure Boot. UEFI existed for many years before Secure Boot. Secure Boot is an effectively optional part of the UEFI spec that was added in later revisions, and really isn't particularly tied to it; the desire for a cryptographically secured boot chain has existed for a long time and would have existed if UEFI had never been created. If UEFI hadn't been around, the same idea would just have been attached to some other firmware format (you could build something like Secure Boot on top of BIOS, if you really wanted to).

        UEFI is a development of EFI, which was created by Intel, not Microsoft. It's maintained by a consortium of pretty much every significant company in personal computing, including Microsoft but also everyone else.

    2. Anonymous Coward
      Anonymous Coward

      on't most people disable UEFI anyway when installing Linux?

      Given that UEFI shows all the signs of having been specifically and deliberately engineered to stop the installation of Linux that seems logical. I have as yet to discover any credible reason for this abomination other than to enable Microsoft to make installing Linux much harder.

      1. dajames

        ... UEFI shows all the signs of having been specifically and deliberately engineered to stop the installation of Linux ...

        No, UEFI was specifically and deliberately engineered to allow Itanium systems to benefit from the vast number of expansion cards being made for x86 systems. As Itanium is all but dead there is no longer any point in it.

        Sure, we need pre-boot firmware that doesn't rely on the processor supporting legacy 16-bit x86 real mode and we need support for boot volumes bigger than 2.1TB* -- but we don't need UEFI for those things.

        I'm not even sure that it's the case that UEFI was specifically or deliberately subverted by Microsoft when they got every OEM to ship their own (Microsoft's) keys for Secure Boot ... World+Dog would have preferred the UEFI consortium to take responsibility for issuing keys to OEMs and OS vendors, but they were too busy loading useless and unnecessary features into the spec so Microsoft took responsibility for keys onto their own shoulders. They've actually been pretty good, so far, when it comes to signing boot images for other OS vendors.

        *or will do one day, the current tendency seems to be for SSD boot volumes well below 2.1TB together with much larger HDD storage volumes where necessary.

    3. davidp231

      Debian (ergo Ubuntu), Fedora, OpenSUSE - all of these play nice with UEFI in my experience. Secure Boot's the pain, unless you use Ubuntu, which plays nice with it.

      It's possible to get others to play nice (eg rEFInd boot loader), if you can get all the binaries signed and the keys into your mobo's keystore. But that's a pig in the tits so I just turn off SB and have done with it.

      1. Martin an gof Silver badge

        Debian (ergo Ubuntu), Fedora, OpenSUSE - all of these play nice with UEFI in my experience

        Just to add my 2p - recently installed OpenSUSE on the wife's new laptop and it worked better with UEFI on than it did with it off. With UEFI disabled there were display issues (wouldn't get the correct resolution) and in particular suspend and shutdown issues. Nine times out of ten trying to get the machine to shut down resulted in it hanging, requiring a forced power-off.

        I have to say I've never had this before, so I was somewhat surprised.

        M.

      2. itzman
        Linux

        MINT 17.3 here..but no sign of

        /sys/firmware/efi/efivars

        so not sure what this is all about

        1. Chika
          Linux

          Re: MINT 17.3 here..but no sign of

          Does your system use a UEFI boot system or does it use a BIOS? If it's the latter then I'm not too surprised that it's missing.

          Generally, I would tend to suggest that doing anything to the system outside the accepted data or home areas, especially using an administration mode, is not a good idea regardless of OS. That particular directory isn't the only that can be used to brick an installation with the use of rm -rf!

    4. Anonymous Coward
      Anonymous Coward

      I used to disable UEFI when installing Linux

      and then I discovered the rEFInd boot manager and removed Grub completely. Auto detection of newly compiled kernels during initialisation, so you can easily boot your new one or choose the old one when you've mucked up your kernel config...

    5. AdamWill

      You can't "disable UEFI"

      You can't "disable UEFI". It's an absurd concept. It's like saying "disable BIOS". If you "disable" your system's firmware it's not going to do anything.

      You can ask a UEFI firmware which has a CSM to boot in BIOS compatibility mode. That's what you're talking about, but it's not at all the same thing.

      1. pmartin66

        Re: You can't "disable UEFI"

        They should go educate themselves. Blaming MS, they are one company that is involved with THE STANDARD

        http://www.uefi.org/faq

    6. thames

      With Ubuntu (14.04), when I built a new PC I just stuffed the DVD into the drive, and it booted up and installed just like it always did. I didn't touch the firmware. There was no drama or fiddling with anything.

      I'm not a fan of UEFI however, for reasons that have to do with security. Matthew Garret wrote a blog post on it a few years ago when he was working on UEFI support for Linux, and he mentioned that there were more lines of code in UEFI than there were in the Linux kernel, if you exclude drivers (to get an apples to apples comparison). On the other hand, Intel had no plans for security support, and the motherboard makers had no way of coordinating and pushing out security fixes. Garret found a security hole, and when he contacted Intel to report it and ask what their plans for fixing it were, their reply was "none".

      Personally, I would prefer something like Coreboot for most applications. It's small and simple, and so presents less of a security maintenance problem. It's also what a number of popular Chromebooks ship as their firmware, so it obviously works. Put the complicated stuff in the OS, as they already have established mechanisms to handle security fixes for the bugs which are inevitable in any complex system.

  2. Richard Jones 1
    FAIL

    Sounds Really Clever?

    Perhaps NOT?

    I assume that same bit of folly would mean that a system with a faulty hard drive or no hard drive would suffer the same failure or would something slightly less dumb recognise that error condition? Could a bricked machine be recovered by removing the hard drive and adding the required files back via another system?

    Or was it all part of some really daft sealed box effort to stop users ever changing anything in the computer they have paid to, well 'sort of' borrow till it breaks.

    1. DN4

      Re: Sounds Really Clever?

      The hard drive has nothing to do with it. Entire /sys is a virtual filesystem (with a bunch of other virtual fs usually mounted inside).

      1. P. Lee

        Re: Sounds Really Clever?

        >The hard drive has nothing to do with it.

        Accurate and slightly missing the point. :)

        Corrupted mobo flash has the same effect. Where is the "restore UEFI to factory defaults" button/option on boot?

        Poor mobo design.

        1. itzman

          Re: Sounds Really Clever?

          Where is the "restore UEFI to factory defaults" button/option on boot?

          Generally a jumper on the Mobo.

        2. Anonymous Coward
          Anonymous Coward

          Re: Sounds Really Clever?

          "Corrupted mobo flash has the same effect. "

          Get an up to date mobo that has dual-bios, most made in the last 4-5 years have dual-bios areas to ensure a backup bios is available. My old Gigabyte ( now in it's 4th year ) bricked the firmware upgrade last month, it immediately replaced the corrupted firmware with the other good copy, I had no choice in the matter. I downloaded the update again, flashed again and it worked on the second go.

    2. Hans 1

      Re: Sounds Really Clever?

      It is not a file on the hard drive, just a set of special files that represent efi variables. I do not quite understand how this works, tbh, but it might be time to disallow "rm -rf /", Solaris gets that one right ... ;-).

      Now, I obviously think the implementation is bad, I mean, imagine you delete a file there, you brick your system (should not be possible). Systemd, Systemd, Systemd .... naughty, naughty!

      And, just another example of closed-source firmware BS we have to put up with ...

      1. Kristian Walsh Silver badge

        Re: Sounds Really Clever?

        It's nothing to do with systemd. Nothing. The driver isn't trapping the case where the user wipes the objects that the driver exposes through the /sys/ hierarchy. You don't even need rm -rf / for this; you can just cd into the appropriate directory and issue rm -rf *

        This is a longstanding "problem" with the Unix permissions model. "Write" always implies "delete", but these are actually separate permissions, and other, non-Unix-derived OS treat them as such. Actually, Unix is the odd-one-out here, but its ubiquity makes people think that its behaviour is the norm.

        For comparison, VMS had "Read, Write, Execute, Delete"; Windows NT unsurprisingly maps the VMS permissions to "Read, Modify[=Write], Execute, Full Access[ which allows Delete]" - on both these systems, being able to write means only that: you can open the object, and modify its contents, even truncate it, but you can't remove it from the filesystem. Even CP/M's limited model distinguished between deletion and writing: the two permissions settings possible on a file were write-access [RO=off] and deletion [System=off].

        1. PassiveSmoking

          Re: Sounds Really Clever?

          Having a separate write and delete permission wouldn't really fix things. There'd be nothing to stop somebody with write permission but not delete permission to overwrite a sensitive file with a zero-length one.

        2. kryptylomese

          Re: Sounds Really Clever?

          If you can write to a file then you can delete its contents even if the permissions do not allow you to actually delete the file, so you have to do something slightly different to break your computer but it will still break if you are stupid enough. An experienced Sys Admin will always tell you take a backups of files before doing anything to them!

        3. Dan 55 Silver badge
          Facepalm

          Re: Sounds Really Clever?

          It's everything to do with systemd, it shouldn't set things up to let root write to UEFI configuration settings by default, especially given that many Linux machines are effectively single user (owned by one person, running a root and a user account).

          Even better, it should not mount it until it is needed, then afterwards unmount it.

          We've found the culprit. It's systemd, in the bedroom, with the stupid design. Again.

          1. Doctor Syntax Silver badge

            Re: Sounds Really Clever?

            "It's everything to do with systemd"

            Much as I share your general opinion of systemd it appears not to be the culprit this time. Read to the end of the article.

            1. Dan 55 Silver badge

              Re: Sounds Really Clever?

              The device driver maps a filesystem delete to a UEFI configuration entry delete. Now this might be reasonable thing to do in limited circumstances, but then systemd mounted it read-write at boot and let inexperienced and accident-prone users shoot themselves in the foot and kill certain UEFIs (computers).

              So what was the use case for mounting it read-write all the time, because I can't think of one. What are the disadvantages? Admittedly I first thought about security, not bricking your computer, but both will do as huge disadvantages that should be avoided if possible.

              As an example for a different take on things, look at turning on TRIM on Macs with non-Apple SSDs. The average user can't do it. The experienced user can, if they log into an administrator account, open the terminal, give a special command, read a disclaimer and what could go wrong, and type 'yes' (or similar). A similar procedure should be done for mounting UEFI r/w here.

              1. Down not across
                FAIL

                Re: Sounds Really Clever?

                So what was the use case for mounting it read-write all the time, because I can't think of one. What are the disadvantages?

                Indeed. Whilst I agree that biggest fault is at the UEFI implementation if it can't recover from its configuration having been wiped by reinstating default configuration, systemd mounting efivars r/w at boot is stupid.

                Why not mount it read only and only temporarily mount it read-write if a command/API needs to make a configuration change, then umount it and mount as read only again. Ok so it takes few tics to faff about with unmount/mount but how often do you need to write to UEFI configuration?

          2. James Loughner
            Facepalm

            Re: Sounds Really Clever?

            Have to be able to write to the EFI variables to add a OS or for updates to grub. The problem is that the EFI BIOS has no recovery and stupidity of using the rm -r / as root. Any that do deserve to brick their machine.

            1. CrazyOldCatMan Silver badge
              Facepalm

              Re: Sounds Really Clever?

              > stupidity of using the rm -r / as root.

              Did that many, many years ago (slakware 0.99pl15, downloaded to floppies using a friend's work connection).

              At 5am (having started building it at 9am) having got everything (auto-dial, email, nntp) working correctly, thought "I'll just clean it up a bit"..

              Meant to go into the /tmp directory and clean it out and ended up putting a space between the / and the tmp.

              Turns out that rm -rf / tmp is a touch different than rm -rf /tmp - who knew?

              Fortunately I managed to hit ctrl-c before the rm ate the /etc directory so it was just a case of re-running the install as an upgrade and preserving current settings. But I did that *after* about 10 hours sleep.

              1. Dan 55 Silver badge

                Re: Sounds Really Clever?

                About "rm -rf /", all it needs is a badly written script missing an environment variable or two to generate that. The Linux Steam client did something similar a while back.

                Just because the kernel can mount the UEFI as a file system, doesn't mean to say that you should do it at boot-up as r/w.

                I think I heard something similar in Jurassic Park.

              2. Anonymous Coward
                Anonymous Coward

                Re: CrazyOldCatMan

                Which is why I'll never migrate over to Linux fully. I make too many typos.

                1. Chika

                  Re: CrazyOldCatMan

                  Which is why I'll never migrate over to Linux fully. I make too many typos.

                  Same here with the typos. That's why I never use sudo or su unless I really have to.

                  It's something that people overlook. Unlike so many Windows users who install and run as admins from start to finish, it is often the case that Linux and Unix users don't do that for the simple reason that people are fallible and you get no second chances, especially at CLI level.

                  Windows users could do this too but you often find that the poor design of Windows generally can make this tricky at times - remember that the interface for Windows and DOS was originally conceived as a standalone concept rather than a networked one. Unix and Linux were always considered as a multiuser environment and has all the benefits of that.

                  Mind you, having said that, Windows is catching up there although it is Microsoft themselves that often let the side down when you need to boost your credentials for whatever reason!

              3. el_oscuro

                Re: Sounds Really Clever?

                Or perhaps someone should visit this website:

                http://www.theregister.co.uk/2016/02/03/line_break_ep1/

            2. Doctor Syntax Silver badge

              Re: Sounds Really Clever?

              "Any that do deserve to brick their machine."

              No, they deserve a better machine for their money.

          3. John Sanders
            Holmes

            Re: Sounds Really Clever?

            It has nothing to do with Systemd, systemd only exposes the UEFI functionality, if anything the kernel is more at fault (if you want to poke fingers at) than systemd.

            What everybody seem to miss is that windows has the same problem, a 40 line C/C++ program can whack the UEFI as well as the rm command in Linux.

            1. Tim Brown 1

              Re: Sounds Really Clever?

              Systemd may not be the principle culprit but it's certainly an accessory to the crime. Why does it mount that special filesystem r/w by default?

              Just another little bit of evidence that the systemd developers don't think things through and that their whole approach is a disaster waiting to happen.

          4. AdamWill

            Re: Sounds Really Clever?

            The efivars are mounted writeable because *we actually need to write to them*. The UEFI boot manager, for instance, is controlled in this way; if you want to modify the boot configuration, which is a perfectly normal thing to do, you write an efivar. They're explicitly *intended* to be writeable.

            1. CrazyOldCatMan Silver badge
              Stop

              Re: Sounds Really Clever?

              > if you want to modify the boot configuration, which is a perfectly normal thing to do

              How often? I would say it's a pretty reasonable thing to make it a two(or three)-stage operation:

              1. Unlock UEFI via UEFI-unlock (with appropriate access rights a-la sudo)

              2. Run tool to change UEFI vars

              3. Either let r/w access expire with time or have uefi-lock command. I'd favour the former..

              All scriptable and reduces the chance of bricking UEFI. And, unless someone fiddles drastically, the standard rm command ain't gonna be doing that..

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like