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 …

  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..

            2. Down not across

              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.

              I don't think anyone disagrees with that. However there is really no need for it to be *always* mounted r/w. Mount it r/o, and if changes really are needed/intended then temporarily mount r/w.

        4. Anonymous Coward
          Anonymous Coward

          Re: Sounds Really Clever?

          "This is a longstanding "problem" with the Unix permissions model. "Write" always implies "delete""

          No it doesn't! Write for a file and write for a directory mean different things. The file write means you can write to/append the file, the directory write means you can delete it. If you want a file that can be written to but not deleted give the file write permissions but remove write permissions from the directory. Come on , this is unix for dummies. If you don't know this you really shouldn't be administering or even using a unix system. Homework - what does the execute bit mean for a directory...

          But as others have said , with file write said you can overwrite the contents anyway which is essentially a delete.

        5. Frumious Bandersnatch

          Re: Sounds Really Clever?

          "Write" always implies "delete"

          Actually, not quite. Being able to write to (an existing) file just depends on the file permissions. Being able to delete depends on both the file permissions (*) and the permissions in the containing directory. If I 'chmod -w' the directory but the file has regular rw permissions then I can write to the file, but I can't delete it.

          (*) actually, it's only the rm command that will prevent me from deleting a file with no write permissions, but this is only a convention used by that particular tool. If I were to use unlink instead (either the system call or the command-line tool) setting the file to read-only would not stop the file from being deleted.

        6. Down not across

          Re: Sounds Really Clever?

          It's nothing to do with systemd. Nothing.

          Erm, not quite "Nothing". Just not only systemd. To quote the article...

          This problem isn't specific to systemd, though, it's just that systemd mounts efivars as read-write by default – any non-systemd Linux distro could choose to do the same.

          So systemd mounts efivars as r/w so it does have something to do with it.

        7. This post has been deleted by its author

        8. Vic

          Re: Sounds Really Clever?

          This is a longstanding "problem" with the Unix permissions model. "Write" always implies "delete"

          This is not true,

          [vic@perridge foo]$ touch bar

          [vic@perridge foo]$ chmod 555 .

          [vic@perridge foo]$ cat bar

          [vic@perridge foo]$ echo "hello" >> bar

          [vic@perridge foo]$ cat bar

          hello

          [vic@perridge foo]$ rm bar

          rm: cannot remove `bar': Permission denied

          It is the directory's write permission that decides whether or not you can delete a file; the file's write permission merely decides whether or not you can write data to it.,

          Vic.

      2. cd / && rm -rf *
        Boffin

        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"

        The *nix paradigm is that "everything is a file". Once you get your head around that, it's all quite logical and goes some way to explaining how concatenating strings of commands by piping the output of one into another using a pipe | is so elegant and powerful.

        1. Anonymous Coward
          Anonymous Coward

          Re: Sounds Really Clever?

          Sorry. "Everything is a file" is really really annoying for people like me. It's a mouse. It's a keyboard. No, there are not 4 lights.

          1. Flocke Kroes Silver badge

            @TechnicalBen

            mouse: /dev/input/mouse0

            keyboard: /dev/input/event$(grep -l keyboard /sys/class/input/input*/name | tr -d a-z/)

            For those not technical enough to understand, the names of all the input devices (power botton, lid switch, ...) are available in pseudo files. I used grep to find which file is the keyboard and tr to extract the device number so I could generate the file name of the number of the keyboard device (In real life I would use the head command to pick out the first keyboard).

            Unix has plenty of tools to fiddle with text files. When the kernel presents information as a text file people with a minimal understanding of technology immediately get a whole tool box full of toys to do whatever they want with that information without having to create one-off applications for every simple task.

            Even Windows has (had?) something of the kind. A create a file called PRN in any directory and write some text to it, and it comes out the printer. You can do similar things with CON (the console) and AUX (the serial port). (I have not used Windows this millennium, so I do not know if these security disasters are still alive.)

            1. sabroni Silver badge
              Meh

              Re: For those not technical enough to understand

              Is that the differentiator? Sure it's not just "For those unfamiliar with linux"?

              Wind your neck in.

            2. Ken Hagan Gold badge

              Re: @TechnicalBen

              "Even Windows has (had?) something of the kind."

              I think this is still true: https://msdn.microsoft.com/en-gb/library/windows/desktop/aa365247%28v=vs.85%29.aspx (search for the section "Win32 Device Namespaces").

              As a historical note (of which you are presumably aware, since you mention it, but others probably aren't) this odd behaviour is for backwards compatibility. DOS 1.0 didn't *have* sub-directories, so in order to support apps that simply wrote to (say) "CON", DOS 2.0 had to pretend that these devices existed in every directory.

              It's utterly foul, but presumably MS have done their research and reckon that a significant number of end-users would wake up with broken apps if a new version of Windows ever fixed it. Such is life in the delightful world of closed-source software.

            3. Spoonguard

              Re: @TechnicalBen

              If you name your user profile CON you can't save any settings, so PRN and CON are still alive - presumably for legacy support

          2. John Sanders
            Linux

            Re: Sounds Really Clever?

            It is annoying until you learn to take advantage of it.

        2. Anonymous Coward
          Devil

          Re: Sounds Really Clever?

          It's one of the outdated Unix designs that made sense forty years ago where the systems were simpler, and the API and tools to work on them very, very limited. And people usually a little more skilled.

          Trying to bolt assumptions made forty years ago on today's systems is very, very dangerous, and this is a good example. The worst thing Linux ever did was to make an outdated OS free, so everybody jumoed on it just because they didn't have to pay for it.

          1. Anonymous Coward
            Anonymous Coward

            Re: Sounds Really Clever?

            Yes, it should be a proprietary undocumented interface that changes with every release. Damn these people who actually want to use + control their own computers!

          2. Anonymous Coward
            Anonymous Coward

            Re: Sounds Really Clever?

            "It's one of the outdated Unix designs that made sense forty years ago"

            You mean unlike Windows where it still pointlessly clings on to the idiotic drive letter paradigm for certain operations which first saw the light of day in CP/M - an 8 bit monitor program written in the 1970s? Unix might not be perfect , but its initial design still holds up well, unlike MS's offering which is constanly having to have bolt on extras to paper over the cracks of its piss poor initial design philosophy (if there even was one other than "Get it out the door ASAP").

            1. Roland6 Silver badge

              Re: Sounds Really Clever?

              You mean unlike Windows where it still pointlessly clings on to the idiotic drive letter paradigm for certain operations which first saw the light of day in CP/M

              Well I suggest one of the advantages of the drive letter paradigm, if used correctly, is that it can set a scope limit on commands. Which when you are dealing with non-IT expert users can be useful...

              1. Doctor Syntax Silver badge

                Re: Sounds Really Clever?

                "Well I suggest one of the advantages of the drive letter paradigm, if used correctly, is that it can set a scope limit on commands. Which when you are dealing with non-IT expert users can be useful..."

                You have C:\USERS. Now reformat the C: drive to reinstall the operating system.

                You have user directories in a separate file system mounted on /home. Now reformat the root file system to reinstall the operating system.

                Which works for you?

                1. Roland6 Silver badge

                  Re: Sounds Really Clever?

                  @Doctor Syntax - Format isn't the same as delete.

                  I've not aware of an implementation of rm that runs under Windows/Ms-DOS that behaves in exactly the same way as using rm on a Unix/Linux machine. In my experience on Windows/Dos the scope of the command is limited to an individual drive.

                  Your point about formatting the C: drive does however, remind me of just how Windows (including 10) is still wedded to the design constraints of the original IBM PC, namely the default usage of a single physical HDD and disk partition for system, swap and user data. With the advances made in fast and cheap storage there really is no reason why Windows (and specifically Windows Server and 10) don't readily support the use of separate physical drives for: system, swap/pagefile, user data. Yes I know you can 'fiddle' with Windows, but with SunOS 3 (1986) these were all readily selectable and configurable in the point-and-click install programme...

                  1. Doctor Syntax Silver badge

                    Re: Sounds Really Clever?

                    @Roland6

                    My point was that these different approaches have different strengths an weaknesses. Windows, as you say, has been trapped in an ancient past and is, in consequence, somewhat inflexible.

                    The Unix approach creates a unified file hierarchy out of as many disk partitions as the installer deems necessary or has available. My example was an instance of that - you can do a clean reinstall or upgrade of a Unix system and still preserve the users' home directories in /home, locally installed S/W in /opt etc provided you gave the matter a little thought when you did the initial install. OK, your can back up C:\Users and restore it later if you try to do the same thing in Windows but at best it's an extra step and at worst a real pain if your OS is so hosed you can't boot.

                    On the other hand rm -rf * when you're in / or rm -rf / is indeed dangerous IF you're working with root privileges. But it's a consequence of the flexibility that the single hierarchy brings. And there's always rmdir which by default will only let you delete a single, empty directory or rm -i which interrogates you before deleting anything or even rm -r without the -f flag.

                    By the way a mistyped mv when you're at or near / can also be drastic. rm -rf is the one thing you're warned about from pretty well the first day you learn anything about administering Unix-like systems but mv not so much. It's the one thing to have caught me out with a typo in >30 years.

                    After those >30 years of dealing with Unix and Unix-like systems I have a distinct preference for their flexibility and elegance; those drive letters just seem so clunky in comparison.

              2. Spoonguard

                Re: Sounds Really Clever?

                Unused by default, so not really that useful.

            2. Doctor Syntax Silver badge

              Re: Sounds Really Clever?

              "drive letter paradigm for certain operations which first saw the light of day in CP/M"

              AFAICR A good deal of CP/M's user interface was borrowed from the PDP8's operating system. Or did that borrow from something earlier still?

              1. Chika

                Re: Sounds Really Clever?

                AFAICR A good deal of CP/M's user interface was borrowed from the PDP8's operating system. Or did that borrow from something earlier still?

                Considering the age, I doubt that TSS/8 or its rivals of the day had any prior systems to work from generally.

    3. Richard Jones 1
      Happy

      Re: Sounds Really Clever?

      Thank you to those who clarified where the mess of UEFI stores its data.

      My mistake was assuming that its use of a look alike file structure meant that it was stored on the HD, I am glad it is not.

      However it appears to have been totally stupid that it should be possible to cut the heart out of what is increasingly appearing to an outsider to be a highly flawed downgraded BIOS replacement.

      Perhaps happily the present old BIOS machine may well last me until I no longer use a PC.

      1. AdamWill

        Re: Sounds Really Clever?

        This isn't a problem with UEFI, it's a problem with bad implementations of UEFI. Any decent implementation should boot without any efivars set, there's no reason why the firmware should assume any will be set.

        There have been bad firmwares since time immemorial. There are certainly lots of terrible BIOS firmware implementations. UEFI has no kind of monopoly on being implemented badly.

    4. Semanticist
      Thumb Down

      Re: Sounds Really Clever?

      This has nothing to do with the actual hard drive filesystem on the machine. Linux/unix presents non-file data as if it were a filesystem, like /proc, which is a list of running processes and information on them, or /dev which contains 'files' which represent devices. (So what a Windows person might think of as 'COM1' is '/dev/ttys0' or similar.)

      The problem here is that the driver that presents these firmware details takes a 'delete' action to remove data *from the computer's firmware* that it needs to boot. Allowing that by default is probably a mistake.

      1. Jonathan Richards 1
        Stop

        Re: Sounds Really Clever?

        > unix presents non-file data as if it were a filesystem

        Exactly so. This is the Unix way: in Unix, everything looks like a file, which means that you *can* pipe things between program outputs, network sockets, logical disk volumes, physical devices, and, crucially in this case, firmware (flash memory) on the motherboard. This is a Good Thing.

        The bad news is that, for some broken implementations of UEFI, if one clobbers the firmware, the computer is bricked. Bricked, as in won't POST; as in {attach suitable chain && redeploy > boat anchor}.

        All the fuss arises because the developers of software systems that make it possible for a (super)user to create boat anchors from expensive IT gear have a limited appetite for protecting people from their own, umm, creativity.

        rm -rf appearing on a command line should strike fear into you, even without the EFI angle. I didn't really like even typing it in a Reg comment just then... hence the icon.

    5. Anonymous Coward
      Anonymous Coward

      Re: Sounds Really Clever?

      I may be wrong here but my understanding of the situation is that particular FS is a part of the flash chip which holds the UEFI BIOS, sloppy coding by the BIOS authors and also by the Linux team(s) allows it to be erased, thus 'bricking' your system.

      However, this sound like exactly the kind of thing a recovery flash should be able to fix, you don't need a functioning BIOS to be able to perform one on many (all?) systems, it just relies on the bootblock in the flash chip being intact (and if the system powers on and stays on it's likely to be intact)

  3. phil 27

    So, those files becoming corrupted can brick the device. Ergo a disk error could do the same without any os interaction regardless of what is loaded on it.

    Design implementation flaw if it won't let you back into the bios to nuke efi & a bit of a gamble all round to run with regardless of what your flavour of os happens to be.

    1. Mage Silver badge
      Boffin

      Not on the HDD

      Just like TTY looks like a file on your HDD, my understanding is that these "files" are not actually files on the HDD, but in the Mobo's flash memory. Hence by default it would be safer if they were mounted on RO mode. I believe it's possible for example to have a device driver that mounts the 64 bytes RAM of a RTC chip (as used in 386, 484, old pentiums etc) on any mount point in the filesystem.

      Fortunately I don't yet have one of these new fangled machines. I did once send back a bricked Mobo. There was a flaw in the "CMOS /BIOS Setup" such that if you didn't exit (save or not) from the setup pages and simply hit the power button or unnplugged it (or had a power cut) it would brick the mobo. This is a quite different sort of flaw. UEFI sounds to me like a poorly thought out boot mechanism that is more vulnerable. I liked Mobos that had a physical jumper for flash RW vs RO as even on regular older non-UEFI, I've seen re-write utilities of flash via Windows on some DELL PCs. I didn't see one with a 2nd jumper for enable write to settings too. But if I was designing a system I'd have two jumpers. All security bets are off anyway with local access. Why not make it that remote access to BIOS (of any type) to change settings or re-write contents needs changing a physical switch. If people want it can be left always closed, or a cable to a panel keyswitch / button etc to avoid need to open box.

      1. Duncan Macdonald
        Black Helicopters

        Re: Not on the HDD - NSA

        But that would make it difficult for the NSA to insert its nonremovable spyware over the net!!

        As with the Intel Management Engine, I am fairly certain that the UEFI also had input from the NSA.

        1. DanDanDan

          Re: Not on the HDD - NSA

          > As with the Intel Management Engine, I am fairly certain that the UEFI also had input from the NSA.

          https://www.google.co.uk/search?q=UEFI+NSA

  4. This post has been deleted by its author

  5. Novex
    WTF?

    So, exactly...

    ...how are you supposed to install a new OS on a UEFI based PC if you can't wipe the old OS first?

    1. Mage Silver badge

      Re: So, exactly...

      Don't wipe ALL of the OS, you CAN wipe all of the disk. A new partition or format (via boot from CD/DVD/USB stick) will not erase these files, as they only appear when the OS is running: "... it is not a file on the hard drive, just a set of special files that represent efi variables."

    2. zanshin

      Re: So, exactly...

      Dropping the root filesystem (presumably from an installer boot) is fine. It's actually modifying the /sys/firmware/efi/efivar contents specifically that causes the problem. In other words, modifying files in there is translated into changing UEFI variables, and deleting files in there being translated into deleting the UEFI variables.

      Unmounting the whole thing would not have the same translation.

      1. Anonymous Coward
        Anonymous Coward

        Re: So, exactly...

        Thanks for the info. But your still making the mistake of speaking a foreign language to us Windows users/Linux newbies.

        Saying "it's not a file on your HDD, it's a file with UEFI settings" is, read by a windows user as "It's not a file on your HDD, it's a file (on your HDD) with UEFI settings". Because to windows, all files reside on the HDD or RAM, and RAM is considered safe to clear (we do it when shutting down ;) ).

        I think what you mean to say is that "It's not a file on your HDD, it's a file on your motherboards non-volatile memory [that is mounted by Linux in read/write mode] with UEFI settings". Or in the case where it's not the memory of the UEFI, but the live running command cue.

        It's more long winded, but wow, Linux users make as many assumptions as us Windows users. Please help us migrate over, we know you have it better over there! (For most stuff. I'm still bitter over the file system. :D )

        Thanks to Adam 52 for making it clear.

        1. James Loughner

          Re: So, exactly...

          It shows up in the system in the file system like all other things in your computer. To Unix all things are files and have a presence in the file system.

        2. Peter Gathercole Silver badge

          Re: So, exactly...

          The concept is actually very simple. "Everything as a file" means that you can use any tool you like that works with files on other things. It's incredibly powerful.

          An analogy to what was happening here could be like files in a remote share in Windows that appears on the windows desktop. It looks like folder containing files, but is not stored on any hard disk local to the system, and does not actually appear in the user's "Desktop" folder. It's abstracted to a different storage medium by the OS, so wiping the local disk by formatting it will not touch these files (in this case, on the share). Like psuedo filesystems in /sys, files on a share can be explicitly overwritten or deleted, but formatting the disk won't touch them.

          For a share, the files are actually stored on another computer. For the /sys directory on Linux, it is 'stored' (or translated) to another medium than the disk, which can include the NVRAM in UEFI. Some entities in /sys are read-only (mainly for providing information, but also for input only devices like keyboards and mice), but anything that can change will probably be writable with the appropriate permissions. Being able to write to UEFI allows Linux utilities to make useful changes to the way the system boots the OS, amongst other things.

          Like everything UNIXy, you should treat super-user (root) with more care, and you should never really do more than is actually essential with raised privileges.

        3. John Brown (no body) Silver badge

          Re: So, exactly...

          "Thanks for the info. But your still making the mistake of speaking a foreign language to us Windows users/Linux newbies."

          It's only foreign to point'n'click Windows users :-)

          con: prn: aux: lpt1: lpt2: com1: com2: etc are all physical devices in DOS/Windows which are abstracted at the command line as files.

          Judicious use of the command line commands mode, copy and ctty were sometimes the only way to get an MSDOS file transferred from one PC to another under certain trying circumstances. The lack of the legacy printer and RS232C serial ports makes it all a bit redundant nowadays, but you can still knock out a quick batch files from a command shell with copy con: file.bat, ending input with CTRL-Z (EOF marker). Making physical devices appear as a file is not something strange to MS users, it's just something you are unlikely to come across these days.

    3. petur

      Re: So, exactly...

      doing rm to wipe the OS is a daft thing to do anyway, you might have shared folders mounted and stuff like that.

      This really is a case of stupid users doing stupid things...

      1. itzman
        Linux

        Re: So, exactly...

        doing rm to wipe the OS is a daft thing to do anyway, you might have shared folders mounted and stuff like that.

        Indeed. and its a lot easier to simply throw an install disk in and say 'use the whole disk' Since rm is not a deletion, its an 'unlink' process anyway.

        OR use a live CD and dd /dev/null to the raw disk device before installation to really null out the data.

        I suspect what's happening here is one of these 'let's make it possible to access the BIOS parameters from running software, like wot Apple do' decisions.

        My new laptop did not document how to get to the bios on boot, but did supply a Noddy windows program that would disable secure boot and enable DVD as a boot device ahead of the disk..

        So I had to spend an hour activating windows to modify the bios - or UEFI - variables.

      2. Doctor Syntax Silver badge

        Re: So, exactly...

        "This really is a case of stupid users doing stupid things..."

        Or a curious user being curious. Didn't Chernobyl happen in a similar way?

      3. Lars Silver badge
        Happy

        Re: So, exactly...

        "This really is a case of stupid users doing stupid things". I do agree but lets not forget that lack of knowledge is not the same as being stupid. Feeling stupid again requires some intelligence.

    4. Adam 52 Silver badge

      Re: So, exactly...

      It's not about wiping the OS. Unfortunately Unix-likes expose a whole load of things that aren't files through the filesystem interface, so an unaware user can wipe important things when they think that they're wiping files.

      Whilst convenient for script writers this whole arrangement is a bit iffy, but its been like that for decades and not caused too much trouble.

      1. Anonymous Coward
        Anonymous Coward

        Re: So, exactly...

        Not really "iffy" but fundamental to the philosophy of "everything is a file"

        In reality, MSDOS and Windows do this too but hide it somewhat from the user, partially through a different address space - but that doesn't affect the principle.

    5. Novex

      Re: So, exactly...

      But what about a fresh clean format of the HDD? If the Mobo's bios thought it had an old OS on it that used files on the filesystem somewhere, and you needed to clean the HDD completely and start from scratch, how would the mobo know not to look for the old config files? According to the article, if the files are missing, then the boot is borked.

      Are we talking about a situation where the files are actually in the mobo bios, and Linux is making pointers to them with files in the running system, such that if the HDD is formatted the files that point to the bios settings don't matter as they haven't been updated/deleted by the OS itself to change anything in the bios? So is the issue here that if the delete is issued against those files in the Linux file system, then what actually happens is the settings in the bios are deleted...?

      1. Nigel 11

        Re: So, exactly...

        EFI is part of the BIOS. It is intended to be accessed as a filesystem. It's therefore bad design if corrupting that filesystem results in the Motherboard being bricked, rather than offering a "reset to factory" option.

        But rm -rf is not the right way to erase a disk on Linux. Assuming that you are not unduly concerned to erase data beyond the abiliity of a three-letter-agency to recover it (*), then the right tools are

        boot something like SystemRescueCD off a standalone CD or USB stick

        DISK=/dev/sda # or whatever

        smartctl -i $DISK # double-check you are about to nuke the right device

        dd if=/dev/zero of=/dev/$DISK bs=4M; sync #write all sectors to zero

        This also forces relocation of any bad blocks at a time when that will cause absolutely no harm, and lets you then use smartctl -A to see whether pre-emptive replacement of the disk might be wise. If you are in a hurry add count=10 to wipe only the partition table and anything lurking at the top of the first partition.

        (*) if you are worried about the three-letter agency the recipe is remove disk, drill several holes in its HDA, smash its electronics with a hammer, and immerse the disk in acid. Coca-Cola is probably an adequate substitute for hydrochloric acid or ferric chloride. Easy to obtain and no bothersome H&S forms needed. Solid-state disks probably require incineration though applying a Dremmel coarse grinding tool to all the big chips might suffice.

      2. Doctor Syntax Silver badge

        Re: So, exactly...

        "Are we talking about a situation where the files are actually in the mobo bios, and Linux is making pointers to them"

        No. The kernel has access to the mobo hardware and presents them to applications (including rm) through the same mechanism (the same semantics if you want to get technical) as files. Unix lookalikes do this for any hardware resource.

        The other thing to realise here is the Unix concept of mounting file systems. The root file system is a disk partition mounted on virtual mount point /. If you have any another disk partitions containing another file system such as your home directories you will need to provide a mount point for it. In the case of your home directory collection you will normally create a directory called home under the top level of your root file system. This is /home. You will then mount your home file system there so it appears as /home. The overall file system thus appears as a set of directories and their files nested within each other and a command such as rf -r will navigate it as a whole. Nevertheless it is still a number of individual disk partitions, each formatted as a separate file system mounted one on another.

        The file system-aware tools such as rm are not aware of the underlying partitions. Conversely formatting software is aware of the partitions but not of the mounting arrangements. If you were to re-format your root partition it would not touch your home partition which would simply loose its mount point until you made a new /home directory on the new root partition. This, by the way, is why it's a good idea to set up a Unix-like system with a separate /home file system - you can reinstall the operating system without losing user's data.

        Remember that I said hardware resources are made available by the kernel through file system semantics. We need a "file system" where they can be placed. Traditionally this is done through /dev. A virtual file system is mounted on the /dev mount point. Disks, disk partitions, keyboard etc will be "files" here. But such virtual file systems are the manifestation of specific kernel functions and not physical formattable disks they can't be reformatted. More recently kernel resources have also made available through file semantics via another virtual file system under the /sys mount point.

        Just as real file systems are not touched by formatting the partition with these mount points neither are the physical items, including the mobo resources, if the root file system is reformatted although, of course, they won't reappear on the reformatted partition until there's a running kernel in place. But just as real files are accessible by file-aware commands, so are the virtual files. And in this particular case the file system semantics offered by the kernel included deletion of what shouldn't have been deleted.

        HTH

    6. NikNakk

      Re: So, exactly...

      As has been stated, these are not files on your hard drive. Doing a wipe of the hard drive using a partition manager won't touch them. The problem comes with trying to wipe the contents of a virtual file system that is mapped to the firmware variables.

    7. rmoore

      Re: So, exactly...

      I think you'll find that using that command is the absolutely worst way to do it.

      One of the reasons is, it will wipe absolutely every (mounted) device it has write access to.

      It would be better to use a partitionmanager to delete or wipe/format partitions/drives.

      At least you'll only be wiping what you (probably) intend to.

    8. Novex

      Re: So, exactly...

      OK, I think I get this now. Linux loads all HDD and other device file systems into one file system, including the device that is the UEFI bios. So in Linux that just looks like a folder.

      Apologies for my inane initial question, but coming from a Windows background the Linux principal of having devices mounted such that they appear to be folders still catches me out.

  6. naive

    This is like BIOS flashing by Unix commands

    So with UEFI the OS gets access to BIOS settings like it would be normal files, and can delete them, a.k.a. a process comparable to the old fashioned BIOS flashing after floppy/cd boot ?.

    If it is a case of "Works as designed".. someone was not thinking.

    1. AndyS

      Re: This is like BIOS flashing by Unix commands

      >If it is a case of "Works as designed".. someone was not thinking.

      Yes - as the article points out, the firmware designer who decided not to check if variables were present. A simple IF in the BIOS would fix this: if variables aren't present, set to default values.

      The Linux programmers are now attempting various workarounds to solve the firmware problem.

      1. naive

        Re: This is like BIOS flashing by Unix commands

        Why put the blame at the firmware designer ?. If the documentation of an UEFI system clearly states that BIOS settings can be wiped when they are accessed in a certain manner, then the OS designer should not allow the user to brick his hardware. The "rm -rf /" is an issue since Unix was conceived over forty years ago, so why is anyone surprised ?.

        If somebody would have been thinking, there would be no write access to BIOS settings at filesystem level.

        1. The Mole

          Re: This is like BIOS flashing by Unix commands

          The blame is on the firmware designed because when developing firmware you should be coding defensively, you shouldn't assume that all the layers above you behave perfectly and understand the implications of operations they perform. They should have anticipated failure modes where the UEFI data gets corrupted/zeroed/deleted and coded to defend against this (failing back to using defaults).

          1. Nigel 11

            Re: This is like BIOS flashing by Unix commands

            I'm almost certain that if you can trash UEFI and brick your motherboard running as root on LInux, then you can trash UEFI and brick your motherboard running as Administrator on Windows. It may be harder to do it accidentally (though I doubt if that's by design, more probably by happenstance). Linux should take steps in the same direction of making accidents harder, like making the --one-file-system option a default for rm.

            Any blame needs to be placed squarely with the implementors of UEFI on the offending hardware. Possibly also with whoever specified UEFI if it does not explicitly state that a missing or corrupt UEFI filesystem or any or all missing UEFI variables must be recoverable errors from an end user's perspective.

            1. Vic

              Re: This is like BIOS flashing by Unix commands

              Linux should take steps in the same direction of making accidents harder, like making the --one-file-system option a default for rm.

              Perhaps. But then again, --preserve-root is the default behaviour for rm, which gives the POSIX-standard behavioiur of refusing to delete recursively from / - so this whole thing is pretty unlikely to occur...

              Vic.

        2. dajames

          Re: This is like BIOS flashing by Unix commands

          Why put the blame at the firmware designer ?

          Because it should not be possible for a software operation to brick the hardware, as it appears to be in this case. The firmware should at the very least have some "revert to factory settings" option that restores all the UEFI variables to default settings so that the machine can boot.

          [Nobody has yet said whether the hardware in question has a "CMOS reset" jumper, nor whether using this does indeed restore the UEFI settings. If it does the firmware designer is off the hook.]

          1. Doctor Syntax Silver badge

            Re: This is like BIOS flashing by Unix commands

            'Nobody has yet said whether the hardware in question has a "CMOS reset" jumper'

            Or if it has a glued-up case so you can't get at it!

        3. Peter Gathercole Silver badge

          Re: This is like BIOS flashing by Unix commands

          IF there is a problem, it's not with the rm command.

          About the only thing I can think may be at fault is the code that allows the UEFI variable to be accessed as part of sysfs. This will be some code in sysfs itself or an associated plug-in module to sysfs.

          As has been pointed out earlier, it may be possible to mitigate this slightly by changing the sysfs abstraction to UEFI so that anything that looks like a directory does not have the "w" bit set, preventing any of the UEFI variables that appear as files from being deleted (although we are talking about root here...), but that would not prevent someone with the correct privileges from overwriting the contents of one of the 'files'. It may also make it impossible to create new 'files' (variables), if this was required.

          I suspect that UEFI actually does have a filesystem like storage structure for it's own use (it's an OS of sorts, anyway), so it would make sense to the developer to make it appear under sysfs as a directory tree.

        4. Doctor Syntax Silver badge

          Re: This is like BIOS flashing by Unix commands

          "The "rm -rf /" is an issue since Unix was conceived over forty years ago, so why is anyone surprised?"

          It's not an issue. It's a fact of Unix life. If you want to rm -rf / why shouldn't you? You simply should be aware of the consequences in exactly the same way as you should be aware of the consequences of formatting your C: drive.

          OTOH firmware designers who make variables accessible to the OS should make their firmware sufficiently robust as to default to sensible options if the user, via the OS, does something nasty to them. And being bricked is not a sensible option. In this case it seems that the OS will have to be modified to protect mobos with less than sufficiently UEFI firmware.

    2. Anonymous Coward
      Anonymous Coward

      Re: This is like BIOS flashing by Unix commands

      Yes but not a good design, and no single design element at fault.

      A virtual file linking to firmware settings

      A dangerous file system delete that I can think of no use for other than fun

      Firmware itself also not coded defensively with a set of default settings in the event of them being missing/bad.

      Fixing any one is a workaround.

      BIOS should reset to factory default if it cant get operable values.

      recursive delete of root could be disabled

      Admittedly I am a bit light on knowledge of the boot process at this level but I am surprised firmware settings are needed as read/write for normal operations, perhaps this and the associated tools should be looked at so that the default is read-only. (anyone enlighten me on what the writes may be needed for?)

      either way this is not specifically a Linux or SystemD problem its a legacy architecture as its always harder to change these integration points with the hardware as neither side can do it alone.

      1. AndyS

        Re: This is like BIOS flashing by Unix commands

        >A dangerous file system delete that I can think of no use for other than fun

        Of course it's dangerous - it deletes things! That's what it's for. That's what it does.

        Let's take an analogy. I've got a spade. There are some places I shouldn't dig (Bessy's grave, the high voltage cable etc), but that's not the spade's fault.

      2. Dazed and Confused

        Re: This is like BIOS flashing by Unix commands

        > A virtual file linking to firmware settings

        > A dangerous file system delete that I can think of no use for other than fun

        Well apart from being able to set things like your boot paths and all of the other setting that can traditionally be set from FW.

        Using the boot device as an example, if you install an OS, any OS, onto a BIOS based system there is no generic way to know where BIOS is going to want to boot from. If it's a simple PC then it's easy to guess. If its a more complex server then perhaps this is a bit more of a problem since there might be several possible disks. Take an HP ProLiant as an example. The default BIOS boot selection order is CD, Floopy, USB (includes SD-Card), Disk & finally Network (which is frankly insane, but that's the default).

        But when it comes to disks there could be the internal SmartArray & external arrays which are perhaps connected via FC.

        So when you do an install you can chose whether to write the OS to the internal SmartArray, the internal SD-Card or the external multipathed FC array. If you're installing RHEL6.X (*)it is relatively easy to choose which disk will be your root disk and where you want to write the boot loader. RHEL6 then does a pretty good job of guessing (but it is guessing) on the BIOS drive order, but you have an option to specify which order it should assume they'll be in. Then comes the problem. The install tends to want to format the SD-Card, so BIOS then tries to boot from there, even though you've just installed onto the disk. So after the install you get a boot failure. Now this is easy enough to fix from either the iLO or the RBSU, but it needs to be fixed.

        If all these types of FW setting were accessible under /sys then it would be easy for the install to a) set the FW to boot from your chosen boot device & b) set the device mappings for the boot loader to match what the FW was doing.

        (*) RHEL6 seems easy here, with some versions of Debian I've found the need to break out to the shell and manually install GrUB on the right disk, some versions of Ubuntu I've found I've had to pull the SD-Card out before doing the install and with SLES11.3 I'm yet to find a way to configure multipathing during the install and not have it install the boot loader on one of the MP FC disks even if you write the OS to the internal array. I've no idea what other OS's such as Windows might do under these circumstances.

    3. Mage Silver badge

      Re: This is like BIOS flashing by Unix commands

      Yes, though I'm surprised it's not mounted RO by default. Why even does it need to remain mounted after boot is complete, rather than mounting it only if something needs changed?

      So, some stupidity by user*, but I wonder why it's implemented like this anyway.

      (*I'd wonder what else such a use of "rm" might remove on some systems. Pretty much EVERYTHING appears as a file in UNIX like systems.

      1. This post has been deleted by its author

        1. Nigel 11

          Re: This is like BIOS flashing by Unix commands

          So that you can 'safely' run rm -rf /

          rm --one-file-system -rf / # safe, for certain values of safe ...

          this will remove all files in your root filesystem, which is probably your operating system installation, hopefully not your /home files, and certainly not anything in sysfs.

          Personaly I think --one-file-system should be the default, especially if you are running as root, with a --really-do-recurse-into-all-filesystems option for the suicidally inclined.

          1. Chika
            Coat

            Re: This is like BIOS flashing by Unix commands

            Actually I can remember that the "f" switch never used to be necessary when I first started with Unix (I started with DRS/NX, aka SVR4) so rm -r / as a root user was all you needed.

            Mind you, I also recall a user many years ago deleting the entirety of the SYSTEM directory under MSDOS and Windows 3.0 (does that ever date me!) because they wanted to tidy the system up to free some space. You could do things like that back then!

            I see we still haven't got a sad old fogey icon yet!

  7. RIBrsiq
    FAIL

    I am all for allowing root and root-like users to brick the system they're running on, if the user so chooses. "With great power..." and so on, you know. But... if the user so chooses.

    Mounting bits of the firmware in obscure places in the filesystem tree cannot be the best way to handle things, surely...?

    I mean when you see "rm -rf /", what do you think that will do, if someone ran up to you in the street and asked you? "Wipe all disks" would be what comes to my mind and, I am willing to bet, the minds of most people who should know this stuff.

    Only retroactively would I think that maybe the FS tree might have held bits of the system that aren't actually on disks.

    And why take this risk...? So some script can pipe stuff into firmware variables directly? Who thought this is a good idea, anyway? Madness!

    1. AndyS

      There are whole chunks of the linux filesystem that aren't on the hard-disk.

      The entire /cat directory for one, and the entire /sys for another. Deleting these is... bad.

      I'm surprised this bricks the machine, but as you say, with root access a user can do all sorts of things. And as pointed out in the article, it's a flaw in the firmware, not checking for variables being present, not a flaw in the implementation of the filesystem (which Windows also does).

      1. RIBrsiq

        "Which Windows also does".

        In what way is that relevant to how Linux does things...?

        Besides, AFAIK, Windows does not mount the firmware under the FS. If it does, I would really appreciate knowing where to, so as to avoid mishaps.

        "The entire /cat directory for one, and the entire /sys for another. Deleting these is... bad".

        Not if one's wiping the system anyway.

        1. AndyS

          Re /cat partition...

          I started off writing a command: "cat /proc/partitions"

          Then I deleted the wrong bit of that when I edited it.

          So... s/cat/proc/g (or something similar).

        2. Chika
          Trollface

          "Which Windows also does".

          In what way is that relevant to how Linux does things...?

          If you go deep enough into any operating system, you will always find similarities.

          And if you are wiping the system anyway, why worry?

    2. This post has been deleted by its author

    3. davidp231

      With great power...

      I recall that if you logged into KDE as root on an old Mandrake distro, it warned you that you were logged in as root and you could do anything you liked, and the system "would do absolutely nothing to stop you".

      1. Chika
        Linux

        Re: With great power...

        As far as KDE 3 goes, you always got that nice bomb wallpaper in a root session...

    4. Doctor Syntax Silver badge

      "Who thought this is a good idea, anyway?"

      See Dazed & Confused's post for a valid use case.

    5. Ken Hagan Gold badge

      "I mean when you see "rm -rf /", what do you think that will do, "

      Even logged in as root, I think it will do nothing because it doesn't have --no-preserve-root. I still wouldn't want to accidentally type it on my own system, though. (Just the principle of the thing, you know. One shouldn't ever get *that* close to such a big mistake.)

      But like the other guy said ... a default of --one-file-system would be nice, too.

  8. Mage Silver badge

    Old Linux Steam Client ...

    I'm not a linux guru, though using and installing it since 1999 and flavours of UNIX since 1985 ... Is there a way to make "rm" command safer?

    I don't remember any accidents with it, though I have used it. There is always a first time -_-

    1. SecretSonOfHG

      Re: Old Linux Steam Client ...

      alias command is your friend here.

      1. AndyS

        Re: Old Linux Steam Client ...

        Not running it as root?

        Not running it against "/"?

        Not running it with the "-Rf" flags?

        Seriously, this is a pretty specific nuclear option, in which the user has jumped through 3 separate hoops to make it unsafe.

        1. RIBrsiq

          Re: Old Linux Steam Client ...

          "Seriously, this is a pretty specific nuclear option, in which the user has jumped through 3 separate hoops to make it unsafe".

          ...and if the user didn't fully intend to nuke the whole file system, you'd be perfectly right.

          But they probably *did* intend to nuke the file system, and *only* the file system. Not the firmware.

          1. Vic

            Re: Old Linux Steam Client ...

            But they probably *did* intend to nuke the file system

            In which case, they won't be using the rm -rf / command, since it will fail to do so. Adding the --no-preserve-root flag would turn it into a very slow way to detroy a computer.

            Vic.

    2. Paul Crawford Silver badge

      Re: a way to make "rm" command safer?

      There is "safe-rm" that has a blacklist of "dumb to try deleting" checks on what you ask for, and I think most modern versions of rm need '--no-preserve-root' if you give them '/' as the argument before destroying your OS (to catch mistakes like "rm -rf / tmp/*" where you mistyped, adding space in /tmp/*).

    3. Doctor Syntax Silver badge

      Re: Old Linux Steam Client ...

      "Is there a way to make "rm" command safer?"

      The -i flag.

  9. BongoJoe

    Article Picture

    What exactly is going on here?

  10. A Non e-mouse Silver badge
    WTF?

    Why UEFI variables write by default?

    Why on Earth are such variables writable by default? I can understand that tools that need to modify then need them to be mount read/write, but surely 99.9% of the time they can be mounted read-only? If someone needs to write to those variables, they can re-mount them as read/write.

  11. Anonymous Coward
    Anonymous Coward

    Shadow emergency recovery BIOS in eprom was such a good idea.

    Since then we have advanced progressively backwards.

    1. Mage Silver badge

      Re: Shadow emergency recovery BIOS in eprom was such a good idea.

      I had a bricked 486 once, I had a same model working MOBO and its 28 pin Flash BIOS IC worked in bricked mobo, so I booted the Flash R/W utility floppy, saved the contents, and WHILE the PC running, carefully levered out the 28 pin DIL IC and pushed in the one that made the mobo dead.

      Then wrote the file I saved. The process worked.

      I think the original game boy can use the same ICs so I considered making an adaptor with two sockets, one ZIF and a CE change-over switch. I suppose this was 1998 or 1999? I never did. I suppose the only socketed chip now is the CPU, and I'd guess maybe even that is soldered in on some laptops (and all in one PCs) that are made super thin with glued in batteries, like a tablet. There was a scope conversion for gameboy I nearly bought, but I have a real scope and "audio" ones via laptop and decent sound cards / USB boxes.

      1. Anonymous Coward
        Anonymous Coward

        Re: Shadow emergency recovery BIOS in eprom was such a good idea.

        Memory pinouts etc usually come from JEDEC. So an EEPROM of the same capacity but from a totally different vendor is likely to have the same pinout. The gameboy used mask ROM in cartridges and also used various mappers to do bank switching for games that won't fit into the address space of the cart slot.. So its fairly unlikely the chip used on your mobo was "the same one they used in them there gamebois" but any memory with the common SRAM style interface that's fast enough and uses the right logic levels will work.

  12. Fihart

    Odd photo.

    Presumably from stock library and, like so many, taken by photographer who has no knowledge of the subject being shot. Otherwise why would one insert a wholly unwired plug into a motherboard ?

    Other examples I can recall; ad with turntable arm lacking counterweights or turntable with arm on left side -- presumably correct shot flipped by dumb art director.

  13. davidp231

    The same situation can occur if you manage to blat the UEFI settings from the UEFI command prompt. I managed to kill (funnily enough), an MSI board doing that, in an attempt to clean out superfluous boot entries. While it did do what I wanted, the method used just happened to completely kill the board in the process: it just constantly power cycles for about half a second, constantly. Holding the reset button in or keeping the CMOS clear pins shorted keeps it on, but it's pretty useless in that state and removing either jumper or finger puts you back to square one.

    1. SImon Hobson Bronze badge

      > The same situation can occur if you manage to blat the UEFI settings from the UEFI command prompt. I managed to kill (funnily enough), an MSI board doing that, in an attempt to clean out superfluous boot entries.

      Exactly the point made by others - if deleting a file makes the mobo unbootable and unrecoverable then the designer f***ed up. There should never be a situation where it doesn't either impose sanity checks and use default values if needed, or have a "reset to sane values" option.

      I can see this becoming a fun game - buy a PC, delete the EFI files "just to test", and if it's bricked you get to take it back as not fit for purpose. Now if enough people did "testing" to determine which boards/devices were "faulty" then I think the manufacturers would soon "fix" it !

      Who's up for a trip to PC World ;-)

  14. Anonymous Coward
    Anonymous Coward

    Windows.

    > "...software running as administrator on Windows could trigger the same failure..."

    Well yes, but is it plausible that someone could do it accidentally?

    1. John Robson Silver badge

      Re: Windows.

      Why fuss about accidentally - it's the new ransomware.

      Don't reboot or everything is gone...

  15. oiseau
    Flame

    UEFI ? Not for me.

    Hello:

    > ... what's really dumb is bricking a machine by deleting the wrong file.

    Quite so.

    My MoBo belongs to me, not to MS or anyone else.

    And I'll stay away from UEFI as long as possible, it's just a way to keep MS installed machines from installing other OSs.

    Like I wrote on another thread:

    ... it's 2016 and you *still* cannot get access to your PC/workstation/server BIOS/firmware code.

    Cheers.

  16. Anonymous Coward
    Anonymous Coward

    Device driver bug

    Ultimately this is like a device driver allowing installation of the wrong version of firmware.

    If the data is bad - you need to error out (or put in a default value that works).

  17. PassiveSmoking

    Scratch Monkey

    Whenever you mount things that aren't really filesystems as filesystems you always risk some user running an inappropriate filesystem command on them. Users need to be aware that what they think they're doing and what they're actually doing might not necessarily be the same thing. Conversely, system designers should really think a bit more about how they might choose to expose certain things (like the EFI vars in this case). If these had been exposed via some interface other than the filesystem there would have been no problem.

    This puts me in mind of the scratch-monkey story. Allegedly, an old VMS mainframe was being used to monitor brain activity in monkeys using skull caps wired up to the machine through its disk interface with a hacked driver that presented the raw data to the machine as a read-only filesystem. One day a Digital engineer was called in to run regular maintenance on the machine. He apparently re-mounted the monkey filesystem as read/write and commenced the standard diagnostic routines on the disk hardware. The result was electric shocks were delivered to the monkeys, stunning several and killing a few. The fallout of this incident was apparently quite significant, as a valuable scientific experiment was destroyed, several monkeys were killed, and everyone directly involved was traumatised.

    So before you do anything crazy with your filesystem, always mount a scratch monkey.

    1. James Loughner

      Re: Scratch Monkey

      Users can't do it only the admin ie root can. The power of root is total. If a user has root power he should know better.

  18. Matthew 17

    if EFI and Linux is problematic

    Why does Linux run so well on a Mac?

    1. Dan 55 Silver badge

      Re: if EFI and Linux is problematic

      Because a Mac doesn't have systemd to mount the EFI variables as writable files in the filesystem.

      1. RNixon

        Re: if EFI and Linux is problematic

        It does if you're running Linux on it.

        I think the point being made was 'Linux works fine on Macs, which use UEFI, so UEFI must not have to be disabled to run Linux'.

        And re all the 'UEFI sucks' comments: Isn't UEFI the only widespread firmware standard suitable for non-x86/x64 hardware? Lots of ARM things use totally custom firmware, but quite a few PowerPC/POWER vendors use UEFI.

        And of course you can't install Windows on those boxes atall.

        1. Anonymous Coward
          Anonymous Coward

          Re: if EFI and Linux is problematic

          The defacto standard bootloader for ARM is u-boot now.

          You don't need something as complex as efi there as the machine is usually a fixed configuration.

          1. AdamWill

            Re: if EFI and Linux is problematic

            UEFI will be used by many aarch64 systems.

    2. PassiveSmoking

      Re: if EFI and Linux is problematic

      Because Apple's EFI implementation doesn't suck?

      1. Dan 55 Silver badge

        Re: if EFI and Linux is problematic

        It actually does suck, and lots...

        https://reverse.put.as/2015/05/29/the-empire-strikes-back-apple-how-your-mac-firmware-security-is-completely-broken/

        Sorry, I misread the original post.

    3. Lars Silver badge
      Linux

      Re: if EFI and Linux is problematic

      Reminds me of a comment some years ago that went something like this - "Linus Torvalds has decided to switch to Apple". I believe it was a triumphant Apple user who wrote it.

  19. cd / && rm -rf *
    Mushroom

    Quick way to brick a system...

    of course, this opens up all sorts of possibilities for naughtiness/malware.

    alias ls="dd if=/dev/urandom of=/sys/firmware/efi/efivars"

    for example.

  20. Fred M

    If it was Windows 10 rather than Linux that let you bork the firmware, I wonder how many of the arguments above would completely switch sides on whether the OS was at fault.

    1. Anonymous Coward
      Joke

      It's always the user at fault. There is only one user with Windows 10... Microsoft.

      (What, you thought you got to decide what it was doing? ;) )

  21. Kobblestown

    UEFI, Linux and other things

    For UEFI+Linux the indispensable resource is Roderick Smith's page:

    http://www.rodsbooks.com/

    As for the firmware, I'd only ask for two things: (1) be entirely accessible via an RS-232 interface and (2) offer a way for you to be in complete control of your machine. Like get rid of the SMM mode that can be used to shaft your machine without any chance of you noticing. And no - running it in a virtual machine (!) as Intel suggests as remedy for the vulns (an SMM vuln can screw even TXT setup), doesn't quite cut it. Because who's controlling the SMM VM...?

  22. Anonymous Coward
    Anonymous Coward

    Danger of rm -rf

    I see that rm has the option "--one-file-system". Should that be the default, perhaps?

    I once caused accidental damage by doing rm -rf chroot, where chroot had something else mounted in it.

    (Though obviously the main problem described in the article is crap hardware. Hardware should always have a "reset to factory defaults" button. Hardware should never be brickable by software. Not even by malicious software.)

    1. Daggerchild Silver badge

      Re: Danger of rm -rf

      Colleague had a server hacked and trashed via rm -rf /. Colleague still had a shell open on it. And a readonly NFS mount. Which they used to remotely reconstruct the system.

  23. tempemeaty
    Mushroom

    Fill In Here With Many Four Letter Words

    I'd like to thank the creators of Debian for getting so excited about systemd. NOW, can it please be put back in the oven and left there and not used again until it's done.

    Microsofts' non competitive monopoly tactics suck. What sucks even more is that the US Gov is looking the other way and allowing this sh*t.

    1. Fatman
      Joke

      Re: Fill In Here With Many Four Letter Words

      <quote>I'd like to thank the creators of Debian for getting so excited about systemd. NOW, can it please be put back in the oven and left there and not used again until it's done leave it there until is had been turned into nothing more than a pan of ashes.</quote>

      There!!!

      FTFY!

  24. Daggerchild Silver badge
    Megaphone

    Wanted: Lost Jumper

    Last seen, ancient motherboards. When worn, would protect your core BIOS from being overwritten.

    Also missing, rewriteable boot media with physical readonly switch.

    Security vs convenience + saving a few pennies on the bill of materials : No Contest.

  25. Pompous Git Silver badge
    Happy

    Thanks

    Learnt a helluva lot from this discussion.

  26. asdf

    can't resist

    >This problem isn't specific to systemd, though, it's just that systemd

    folks couldn't give two fucks your computer is bricked. Their elegant software is just helping point out indirectly how any one not working for Red Hat is a muppet retard.

    1. Chika
      Trollface

      Re: can't resist

      Systemd "elegant"?

      And my 81 year old mother is a stripper...

  27. Anonymous Coward
    Anonymous Coward

    Wanted - Motherboard no UEFI

    Wanted - Motherboard no UEFI - Do any manufacturers make modern motherboards with BIOS only, no UEFI?

    1. Dazed and Confused

      Re: Wanted - Motherboard no UEFI

      Not sure about UEFI, but I used EFI for donkeys years, it has lots of nice things about it. BIOS was dreamt up in about 1872 and had been kludged around a lot since then. EFI was an attempt to come up with an sensible approach to being able to add new things into your firmware when you add new things into your HW.

      This problem is down to a dumb implementation of UEFI, I don't know, it could be that other implementations are equally dumb.

      Lots of things can be controlled by variables in EFI, variables can be created and changed as deleted. The stupid thing is that you can remove variables and that will stop it from being able to boot at least as far as some EFI interface.

      I used to use EFI on Itanium boxes, and there it booted and took you into a nice Boot manager menu where you could set up all the boot options you liked, and it would normally also give you an option to access the EFI shell too, which was a bit like DOS. When the last generation Itanium systems switched to UEFI that nice boot manager seemed to disappear to make it look like a PC just booting what it was always going to boot and you had to do BIOS like things to get any interaction.

      If I could have that boot manager menu and shell approach I'd chose UEFI over BIOS every day of the week.

      BIOS must also have lots of internal variables. It is quite likely that combinations of these could brick a system too. I know one of my BIOS based boxes recently decided that it no longer wanted to boot from disk or from the network, even though the boot order options were set to boot from disk as the first choice. I ended up having to boot from a USB stick and re write the FW to the system.

  28. phands

    rm -rf / should only do damage if you're root.

    Trying rm -rf / as a normal user should fail because non-root users don't have permissions by default.

    In order for rm -rf / to do damage, other than to your own files in your home directory, you would need to use sudo (and even that can be further protected), or have su'd to root, or some other method of escalating privilege...or have done something idiot with permissions - which would need root access anyway. Certainly, ordinary users don't have write permission to /sys unless the system is mis-configured.

    Most distros no longer allow direct log in as root from the keyboard, so su escalation privileges and password are needed. This should be a non-issue.

    1. Vic

      Re: rm -rf / should only do damage if you're root.

      In order for rm -rf / to do damage, other than to your own files in your home directory, you would need to use sudo (and even that can be further protected), or have su'd to root

      And it still wouldn't matter.

      [root@perridge ~]# rm -rf /

      rm: it is dangerous to operate recursively on `/'

      rm: use --no-preserve-root to override this failsafe

      Vic.

  29. Kleykenb

    Click

    Bait

  30. Anonymous Coward
    Anonymous Coward

    This is a lot more serious than the article suggests

    If it is possible to brick a PC by writing to the wrong memory location (memory that is inhabited by writable flash in the motherboad) then any root/Administrator level security hole on a Windows or Linux PC allows malware to brick the PC.

    Now typically malware doesn't get so destructive, instead trying to leverage it to make money (send spam, capture banking info, lock files and extort the user) but all it takes is one person who's more assholey than greedy to modify existing malware and make it brick PCs to the point where it sounds like you need to buy a new one.

    This is a huge problem in UEFI design that this is even possible. I thought they all had a "dual BIOS" type system where if it won't boot it can revert to a second copy, to allow you to recover from bad flashes or making inappropriate settings in your config? Does UEFI not allow for that? Is it just this MSI laptop that allows writing values that will brick it or is this a more general issue?

    1. Dazed and Confused

      Re: This is a lot more serious than the article suggests

      It sounds more like an implementation issue, or others would be reporting the same issue on other boxes.

      It is certainly not a problem to have dual ROMs for EFI, actually the first EFI systems I came across didn't. The ones that were flown over to Europe to training the HW engineers when they were about to be first released were in the middle of a FW upgrade when the training centre had a total power outage. All but one of the boxes was in the middle of a reload and was bricked.

      The production versions of the machines had dual FW.

      There are a number of possible problems here though. Is it like deleting a file with a mirrored disk? It's deleted both copies?

      Is it that the ROM image thinks it's fine so hasn't triggered a switch to the backup ROM?

      Is it the case that it can't get far enough into the boot sequence to realise that it needs to switch to the backup copy.

      Or is it that it switches to the backup copy which can't boot this config either because its the data that's toast not the actual FW image in ROM.

  31. Mikey
    Coat

    Just an observation...

    ...but when you have a system that allows you total power over your machine, you should be too surprised when such consequences arise, expected or not. If you're going to wield such ability, you need to be prepared for the worst, no matter what system you use. Otherwise, you're shooting in the dark with no recourse to the inevitable ricochet.

    See, I know this is a dangerous thing to post, I know I'm going to get downvotes, I fully expect that. I already have my coat on, and will be laughing all the way out :O)

    1. Anonymous Coward
      Anonymous Coward

      @Mickey - Re: Just an observation...

      What you are saying is correct in the way that nothing stops me from wreaking havoc to my PC with a chainsaw if this is my wish. But in this case I'm fully aware that my expectations to still have a functionally PC will definitely no be met. However, I've worked for so long with computers under the assumption that software will not break hardware, at least not so easily.

      Just try to imagine the possibility of a criminal attack on a company's network of computers where some nasty malware will knock off all the PCs that bad that it will require purchasing of brand new computers. You can safely bet that a small dedicated team is looking right now for ways to do it and also that Linux will not be their main target.

      The idea that the same people that were giving us the old fashioned BIOS are now in charge of writing what amounts to a miniature OS is making me quite uncomfortable.

  32. JustNiz

    The fact that the MSI BIOS manfuacturer didn't think to handle the mind-numbingly obvious case where the UEFI configuration can be empty/uninitialised is most definately NOT the fault of Linux.

  33. Jeff Lewis

    Of course, over on the more primitive systems - you know - the ones used by around 98% of the world - they put the UEFI executables into a separate hidden partition and the keys into NVRAM so you can recover by just restoring the UEFI partition...

    But hey - I'm sure Linux knows better because it is the bestest OS ever...

    1. Dazed and Confused

      @Jeff Lewis

      This weakness must exist in all other OS's on this platform too. True Linux is making this information easily available and on other OS's you might need to dig further to find it. But that isn't the problem. The problem is that once the NVRAM has had the UEFI variables deleted the systems is bricked.

      It isn't a case of just recovering the UEFI partition. The systems is bricked, you can't recover anything using any OS. You need a method of restoring the NVRAM but the system won't boot far enough to allow you to do this.

  34. martinusher Silver badge

    Newbe Mistake

    Been there, done that. My particular screwup happened in prehistory, back in the 1980s with a PC running Xenix. Back then disc storage was tiny so it was easy to clag the system up with surplus list files so I thought I'd just get rid of them with a "rm -rf *.lst" from the top of the filesystem. Unfortunately the keyboard for what was the central development server was a bit naff so a space crept in between the * and the '.lst' (you can tell who was brought up on MS-DOS, can't you?). I noticed the problem immediately and killed the command but not before the damage was done. (Did I mention that I was also logged in as 'root'?) There was nothing to be done but leave the system running ...... we got six weeks out of it before a power dip forced us (me) to rebuild.

    Did I also mention that installing an 'ix' system in the good old days, especially one that came on innumerable 5.25" floppies, was a bit of a pain? These days Linux installation and recovery -- its simple (...pause to add "uphill in the snow -- both ways" somewhere).

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