Running "rm -rf /" Is Now Bricking Linux Systems (phoronix.com)

An anonymous reader writes: For newer systems utilizing UEFI, running rm -rf / is enough to permanently brick your system. While it's a trivial command to run on Linux systems, Windows and other operating systems are also prone to this issue when using UEFI. The problem comes down to UEFI variables being mounted with read/write permissions and when recursively deleting everything, the UEFI variables get wiped too. Systemd developers have rejected mounting the EFI variables as read-only, since there are valid use-cases for writing to them. Mounting them read-only can also break other applications, so for now there is no good solution to avoid potentially bricking your system, but kernel developers are investigating the issue.

Comments

first

[Anonymous Coward]

first

Re:first

[Penguinisto]

first

rm -rf /first/*.*

By the by, the above 'code' snippet may well brick a *nix box - use at your own risk. I saw first-hand that doing an rm -rf *.* was perfectly capable of blowing away an entire install (including all mounted devices), no sweat - at least as late as 2006 when a junior admin I once worked with made that rather horrendous typo in his regex...

But overall, why the hell is this news? I mean, every OS has this problem (see also the ancient deltree, or the newer rd /s, or getting stupid with the GUI Disk Utility in Windows or OSX, etc.)

Boys and girls, this is why you don't give ordinary folks admin/root/wheel/whatever privileges, eh?

Re:first

[Penguinisto]

Oh... now I get it - wipes the UEFI too... neat-o!

Re:first

[AchilleTalon]

rm -rf /first* is sufficient. Why the *.*? There is no need to remove only those with dot and in the first subdirectory. If you believe you need to match the dot otherwise the * will match only everything before the dot, one day you will be in deep trouble.

Re:first

[Anonymous Coward]

MS Windows teaches children to use that junk because of its way of handling file extensions. =/

Re:first

[Penguinisto]

The *.* catches the '..' , causing the rm command to jump up a directory (eventually to / ).

Re: first

[chaboud]

+1 to you for circling back once you got that it bricks the system (and not just the install).

Re:first

[Darinbob]

The glob expansion won't do this if you start with "*" so it shouldn't search hidden files or directories.

Re:first

[salnikov]

First to actually type "rm -rf /"?

Re: first

[Anonymous Coward]

21st century CIH.

Re:first

[Time_Ngler]

I actually tried this with rm -rf -i /first/*.* but it didn't work. Maybe they fixed it?

Re:first

[hawkinspeter]

I'm surprised that you've included a dot in that - it'd be more effective to run rm -rf /first/*

Isn't this what --preserve-root is for?

[Anonymous Coward]

Seems like the kernel is the wrong place to solve this problem.

Re:Isn't this what --preserve-root is for?

[gnupun]

This looks like an EFI design bug. Why should EFI allow the OS or any other software brick the system by deleting its variables? Like OO, EFI should allow access to these variables through methods and not directly.

Re:Isn't this what --preserve-root is for?

[Flavianoep]

For what? As a parameter for the command rm -rf /? Why would anyone use the command rm -rf / to begin with?

Re:Isn't this what --preserve-root is for?

[castionsosa]

I'm curious if booting from BIOS/MBR would do the trick. Higher end BIOSes still have the ability to not use UEFI and just do things the old fashioned way. IIRC, this doesn't expose the UEFI variables at all, providing some brick-resistance. Of course, you lose Secure UEFI functionality, making MBR attacks possible, but it is taking the lesser evil.

Re:Isn't this what --preserve-root is for?

[MightyYar]

On my keyboard, the "\" key is directly above the "return" key. I have accidentally struck "return" at the same time as "\", resulting in entering the command before I meant it to. I've never done this as root or at root, but I'd be mighty pissed if I bricked my hardware with a simple mistake on the command line.

Re:Isn't this what --preserve-root is for?

[NotInHere]

Btw, BIOS allows the OS to brick it as well. Just run "flashrom -E --programmer internal". (Haven't tested it for obvious reasons).

Re:Isn't this what --preserve-root is for?

[Anonymous Coward]

To my understanding, you can't boot anymore, at all. If we could simply boot to BIOS and reflash the firmware this wouldn't be such a big issue.

Re:Isn't this what --preserve-root is for?

[Dolda2000]

To be fair, reading TFA it doesn't seem to be a general EFI bug at all, but merely a bug with some implementations of it. TFA mentions "some MSI notebooks", but isn't more specific than that. So yes, this seems like a particular hardware bug, rather than a bug with either UEFI, the Linux kernel, systemd, or any other software bug in general.

Re:Isn't this what --preserve-root is for?

[afidel]

BIOS/MBR is just an EUFI personality on modern systems so if EUFI is trashed well enough it can't load the BIOS personality. Unless you're saying boot to BIOS until a fix or workaround is found?

Re:Isn't this what --preserve-root is for?

[Anonymous Coward]

You can access BIOS and CPU microcode in just the same fashion.

Re:Isn't this what --preserve-root is for?

[mark-t]

That exact accidental scenario happened to me once.... while I was root, when I was intending to erase the contents of only one directory off of root. I aborted the command with ctrl-c immediately, but the command had already done irreparable damage. Fortunately, this was before UEFI, so I was able to reinstall the OS from scratch and restore my user folders from a nightly backup.

Re:Isn't this what --preserve-root is for?

[peppepz]

Linux (GNU coreutils) won't execute rm -fr / . You have to explicitly add the option --no-preserve-root to execute that command.

That said, I don't know if hip linux distributions have replaced coreutils with something else.

Re:Isn't this what --preserve-root is for?

[ArmoredDragon]

BIOS no longer exists at all in modern systems. If you look at its limitations, (which modern OSes had to work around) it's kind of ridiculous that it lasted as long as it did. You have UEFI which is modular (and contrary to popular belief, UEFI has nothing to do with a graphical shell or boot code signing, rather those are optional modules that most motherboard manufacturers include, the first to make their product shiny, and the later because IT Security professionals have been wanting it as a means of eliminating boot code malware; you can load your own keys if you want, and because MS signing keys are so common they're often included by default.)

UEFI remains compatible with things that need BIOS by including a module (often called Compatibility Support Module) that adds archaic crap like certain interrupts if the OS needs them and POST if any hardware you have needs that. Protip: If your setup doesn't need any of that crap, turn off the BIOS compatibility module and you get a faster boot speed.

Re:Isn't this what --preserve-root is for?

[Midnight Thunder]

On my keyboard, the "\" key is directly above the "return" key. I have accidentally struck "return" at the same time as "\", resulting in entering the command before I meant it to. I've never done this as root or at root, but I'd be mighty pissed if I bricked my hardware with a simple mistake on the command line.

This is probably why some people type the rm command backwards or do an ls first then modify the previous entry. More work, but safer.

Also make me wonder whether there are any implementations of 'rm' that would prompt for the first execution of an execution (semi interactive)?

Re:Isn't this what --preserve-root is for?

[Bengie]

"rm -rf /" is undefined by the rm standard. Why it even works is beyond me.

Re:Isn't this what --preserve-root is for?

[skids]

Never happened to me, but I've come close enough to have managed to develop a healthy "spider sense." Whenever I type "rm" at a hash prompt my adrenaline immediately spikes and I switch to hunt-and-peck-and-verify typing mode.

Re:Isn't this what --preserve-root is for?

[ArmoredDragon]

That's what I love about running in ESXi: Just take snapshots before you do anything big.

Speak of which, I wonder if I could brick the UEFI in my hypervisor? Must find out...

Re:Isn't this what --preserve-root is for?

[parenthephobia]

Actually, it's precisely defined. POSIX requires rm to ignore an argument which is the root directory.

Re:Isn't this what --preserve-root is for?

[goarilla]

To safeguard myself from accidentally, executing possible dangerous command lines.
I've trained myself into using the following precautionary routine (sh shell):
- Start the line with a comment (#)
- Create the command line
- Inspect
- Remove the shebang
- Run

While this doesn't safe me much from bad commands if I fail or neglect inspection it does
safe me from pressing the enter key erroneously. Which happens a lot more since the key varies in size and placement and important shell letters surround it.

Re:Isn't this what --preserve-root is for?

[vtcodger]

"To my understanding, you can't boot anymore, at all. If we could simply boot to BIOS and reflash the firmware this wouldn't be such a big issue."

That's entirely too sane. I think you can probably scratch BIOS programming from your list of possible future occupations. You'd have to take a LOT of drugs and stay stoned in order to comply with modern practices

An even better answer would be to try the following concept: A BIOS is a simple and robust, non-writable boot system residing in Read ONLY Memory. BIOSes are small, simple, things that have to be written well since you only get one shot at doing them. Once your device goes into production, you are stuck with whatever the code does.

Note that doesn't preclude insane complexity in the layers of code that are loaded by the BIOS. Modern programming practices can live on .... just not in the lowest level of boot code.

BTW, why do folks think that a design that allows users to inadvertently irretrievably cripple hardware can possibly be secure? If you can accidentally brick the damn thing from a keyboard, what do you think hostile agents can do once they've penetrated your system?

Re:Isn't this what --preserve-root is for?

[jones_supa]

People should stop calling it "UEFI/BIOS".

Re:Isn't this what --preserve-root is for?

[mark-t]

Having had a less than ideal misttyped rm command go awry on me at one time, I now *always* preface any initial intent to rm anything from the shell with 'echo'. I do this whether or not I am root, look at the output, and if it all looks good, I then repeat the command without 'echo' by hitting the up arrow and deleting the first word.

Re:Isn't this what --preserve-root is for?

[TheCarp]

And? Its not like rm -rf / is the only way to recurse filesystems deleting things.

These things can easily happen from typos and scripts.... so like:

"rm -rf $MYPATH/*" becomes "rm -rf /* if $MYPATH" is unset.

I dunno, I am very much of the feeling that anything that can brick the system should be hidden behind a hardware switch in order to update. If a motherboard advertised having a jumper that needed to be set in order to update boot info, I would consider that a desirable feature in general.

Re:Isn't this what --preserve-root is for?

[kenaaker]

This variant would probably have the same effect, but is not nearly as obvious. Execute it anywhere in a directory structure and bad things happen.

rm -rf .*

I ran across it when I was trying to clean out some .name directories in a home directory. (The key to the thing is that .. matches .*)

Re:Isn't this what --preserve-root is for?

[mark-t]

That incident has since made me paranoid of using the rm command directly from the shell.... Although I recovered everything I had lost from the nightly backup, much of that day's work was still gone, and it was still a painful experience to reset many of the main configurations that were not part of my /home folder from the defaults back to my desired preferences.

So now, whenever I am about to rm anything, whether I am root or not, I always initially type it as 'echo rm ....' and look at the output to make sure I have typed it correctly. If I have, I then hit up-arrow and delete the first word.

I haven't had any scares since I started doing this.

I just realized that the poster to who I had responded above was talking about the backslash key, when for some reason I had parsed that as talking about the backspace key, even though he had typed it as '\'. I must have read the '\' as a backslash, and then somehow further mutated that in my brain to 'backspace'.

Re:Isn't this what --preserve-root is for?

[castionsosa]

I didn't realize that UEFI is everything now.

I wonder how tough it would be to have a sane implementation of it. First, a small stub that can copy back a version of UEFI from a ROM (not EEPROM... true ROM.) Perhaps, in addition, a pristine backup copy that is kept read-only, so an updated version can be kept ready to go. Neither of these two can be altered. This way, if the UEFI firmware gets fricasseed, it isn't too difficult to get the machine back to an operable state. Phones can do this with their bootloaders.

Ideally, it would be nice to have a hypervisor in UEFI that can be turned on, with it doing translation (where the files are shown, but not editable, or are virtualized). Someone blows away a filesystem, who cares. It would have to be done on the hypervisor layer to have any effect.

Re:Isn't this what --preserve-root is for?

[nmb3000]

This looks like an EFI design bug. Why should EFI allow the OS or any other software brick the system by deleting its variables? Like OO, EFI should allow access to these variables through methods and not directly.

That you reached +5 makes me weep for Slashdot.

It's completely normal for a *nix based system to expose something like UEFI variables through the filesystem. It's a concept called Everything is a File and is the same reason why root can read and poke places in /proc and /dev to get information about the system or make changes to it. I can sympathize with the systemd developers on this one (I know, get a rope) because making a unilateral decision to force UEFI read-only over this one issue will have a long-standing and huge impact of system administration (and this goes double controlling large networks of systems).

The fact that root running rm -rf / causes problems shouldn't surprise anyone. Even with newer flags like --no-preserve-root, running as root means exerting ultimate control. Some care is expected or eventually you'll get burned.

Besides, the real question here I think is: Why don't these motherboards have a ROM backup that can be used to restore and boot the boards after catastrophic failure of their saved state? Even without the rm -rf / red herring, that seems like a brain-dead requirement, and one that legacy boards have supported for decades.

Re:Isn't this what --preserve-root is for?

[parenthephobia]

I was merely observing that allowing "rm -rf /" to work is prohibited, not that it was impossible in general to break a computer...

Re: Isn't this what --preserve-root is for?

[Anonymous Coward]

Liberty > Security

Re:Isn't this what --preserve-root is for?

[vtcodger]

Is there anything that prevents code that really needs to write the UEFI from unmounting a default read/only file system and remounting it as read/write? Have the crazies deprecated mount and umount? And really now, how much need to write UEFI is there likely to be in any configuration not designed by complete lunatics?

Re:Isn't this what --preserve-root is for?

[bored]

The problem is that UEFI missed the KISS principal and is basically an OS itself. In that way, the principals (not necessarily the implementation) of the original PC BIOS are actually a much better target for for an OS bootloader. See uboot (which actually probably goes a little to far the in opposite direction because it lacks the ability to run option rom/support 3rd party plug in devices). You complain about BIOS, but you have to understand that the BIOS design evolved from PCs with 8/16 bit processors and a few KB of ram, all the way to 64-bit computers with hundreds of GB of ram, along the way supported thousands of different peripherals. By comparison UEFI is a tiny slice of the modern computing ecosystem, and most non PC devices abandoned UEFI and instead went for simpler boot mechanisms more reminiscent of BIOS (see cellphones, etc).

BTW; UEFI still does POST (in the generic sense, often with POST codes), its also configures PCIe interrupts and the APIC, which is required for ACPI which remains in UEFI as much as it was in BIOS. Only on ARM64 can you get away from UEFI requiring ACPI to be useful, in the form of UEFI/DT. Which makes one question why run UEFI at all instead of uboot/DT which go together better. (just to be clear ARM64 also "supports" UEFI/ACPI).

Re:Isn't this what --preserve-root is for?

[Anonymous Coward]

Why? Why are there always twats popping up asking "why would you do that?" when you issue a perfectly valid command and hit some problem some other twat rigged for the unwary?

Re:Isn't this what --preserve-root is for?

[MightyYar]

That's smart, but doesn't it interfere with auto completion? I'm sadly reliant on that feature. I suppose I could do it in two steps.

Re:Isn't this what --preserve-root is for?

[MightyYar]

I'm not brave enough to try it on Solaris and FreeBSD or Mac. :)

Re:Isn't this what --preserve-root is for?

[MightyYar]

Haha, I'm an idiot. I type in Dvorak and I actually meant the "/" key (which in Dvorak is the "]" key on QUERTY) but mistyped it several times. So much for accuracy of the Dvorak layout!

Re:Isn't this what --preserve-root is for?

[Anonymous Coward]

That's not a shebang. That's just a comment. A shebang is "#!".

Re:Isn't this what --preserve-root is for?

[steveg]

Back in the dotcom days, I had a developer that wanted to clean his home directory up. He suspected that the dotfiles were corrupt, so he figured the best thing to do was get rid of them all and start over.

He issued the command (from his home directory):
rm -rfa .*

I have no idea why he was doing that as root. When the command that he expected to take a fraction of a second didn't come back immediately he realized something was wrong and hit Ctl-C, but it had already done quite a bit of damage.

We had backups -- he lost less than a week of work. But that was still a lot.

Re: Isn't this what --preserve-root is for?

[Opportunist]

Try to convince your CISO of that.

Re:Isn't this what --preserve-root is for?

[SuricouRaven]

I prefix it with a #. Once I've typed the line in and verified it, home-del-enter.

Re:Isn't this what --preserve-root is for?

[Opportunist]

That works if, and only if,

1) "flashrom" is actually installed on a production machine (and I honestly can't think of a reason why it should be).
2) "flashrom" is in the path (which I can even less think of a reason why it should be).
3) "flashrom" is executable in normal multiuser mode (which it should not be for VERY obvious reasons).

rm, on the other hand, ...

Re:Isn't this what --preserve-root is for?

[phantomfive]

The problem is that UEFI missed the KISS principal and is basically an OS itself.

Yeah, agreed.
Security researchers looked at the complexity of EFI and said, "Anything so complex has to be insecure." They were right.

Re:Isn't this what --preserve-root is for?

[sexconker]

It's "shabang", not "shebang", and you've only listed the "sha".

# - Sharp
! - Bang
#! - Shabang

"Shebang" is a word unto itself and it has nothing to do with "shabang" beyond people getting them mixed up.

Re:Isn't this what --preserve-root is for?

[weave]

Way back in the early 90s when we first got a Unix box at work, one of the admins felt that all the programs in /bin should really be owned by bin so he did a chown bin /bin/* /usr/bin/*

Re:Isn't this what --preserve-root is for?

[phantomfive]

Besides, the real question here I think is: Why don't these motherboards have a ROM backup that can be used to restore and boot the boards after catastrophic failure of their saved state?

Yes, that is where the focus should be.
They should have had a jumper or something that resets the UEFI to default.

Re:Isn't this what --preserve-root is for?

[Opportunist]

Besides, the real question here I think is: Why don't these motherboards have a ROM backup that can be used to restore and boot the boards after catastrophic failure of their saved state? Even without the rm -rf / red herring, that seems like a brain-dead requirement, and one that legacy boards have supported for decades.

Because money? That chip holding the backup costs money. Yes, we're talking cents here, but we're also talking about manufacturers that use inferior capacitors with a price difference in the sub-cent range per board.

Re:Isn't this what --preserve-root is for?

[Opportunist]

This is what VMs with snapshots have been invented.

Ubuntu 15.10 informed me that it's dangerous to do so and that --no-preserve-root is required to circumvent this security feature.

Re:Isn't this what --preserve-root is for?

[Opportunist]

So do a

rm -rf /home/..

Which surprisingly WOULD circumvent the --no-preserve-root safeguard if it didn't run into the problem that removing a subdirectory of home that is actually a parent directory causes a blocking situation...

Re:Isn't this what --preserve-root is for?

[Opportunist]

Oh. But

rm -rf /home/../*

works like a charm

(reverting to snapshot)

Re:Isn't this what --preserve-root is for?

[yuhong]

I think the ARM SBSA folks are moving toward UEFI/ACPI now.

Re:Isn't this what --preserve-root is for?

[Anne Thwacks]

paranoid of using the rm command directly from the shell

Apply one gNurd bonus stamp to your Geek card.

Re:Isn't this what --preserve-root is for?

[goarilla]

It does interfere with auto completion but not on filepaths.

Re:Isn't this what --preserve-root is for?

[peragrin]

The better questions is why do evI variable need to be read/write all the time? A better security precaution would be to in mount and remount as read/write on as needed basis. Just to prevent viruses from using that to store data.

Re: Isn't this what --preserve-root is for?

[Anonymous Coward]

For dot-stuff I use .??*

Re:Isn't this what --preserve-root is for?

[Anonymous Coward]

> Also make me wonder whether there are any implementations of 'rm' that would prompt for the first execution of an execution (semi interactive)?

`rm` does prompt unless you specify the `-f` option.

You can override the `-f` option if the `-i` option is also present. You can force this with `alias rm='rm -i'``

`rm` is part of the basic UNIX toolchain so a lot of scripts depend on it, it's a standard the way it operates.

Re:Isn't this what --preserve-root is for?

[Cinnamon Beige]

This looks like an EFI design bug. Why should EFI allow the OS or any other software brick the system by deleting its variables? Like OO, EFI should allow access to these variables through methods and not directly.

That you reached +5 makes me weep for Slashdot.

It's completely normal for a *nix based system to expose something like UEFI variables through the filesystem. It's a concept called Everything is a File and is the same reason why root can read and poke places in /proc and /dev to get information about the system or make changes to it. I can sympathize with the systemd developers on this one (I know, get a rope) because making a unilateral decision to force UEFI read-only over this one issue will have a long-standing and huge impact of system administration (and this goes double controlling large networks of systems).

The fact that root running rm -rf / causes problems shouldn't surprise anyone. Even with newer flags like --no-preserve-root, running as root means exerting ultimate control. Some care is expected or eventually you'll get burned.

Besides, the real question here I think is: Why don't these motherboards have a ROM backup that can be used to restore and boot the boards after catastrophic failure of their saved state? Even without the rm -rf / red herring, that seems like a brain-dead requirement, and one that legacy boards have supported for decades.

They don't have a ROM backup because UEFI was supposed to be taking its place, meaning that in fact the original question is important and the bottom line may be that UEFI is in and of itself broken--given its entire point is to prevent boot hijacking, having even a mildly unimportant part of it that could be affected by rm -rf / strikes me as a nice blinking neon sign of where to start work for a proof-of-concept boot hijacker that will not be bothered by UEFI, and perhaps you could even manage to suborn UEFI to make it actually more difficult to reverse?

Honestly, I'd rather go for a system where I can boot to a certain level and get an error message if a hijacking attempt got made, and could live with having to have physical access to the computer was required if I wanted to install an OS. I'd mind it requiring a special dongle, but I feel that it's probably easier to deal with having to protect computers from roving bands of people maliciously flashing motherboards than a bad attempt to prevent remote attempts...

Re:Isn't this what --preserve-root is for?

[Anonymous Coward]

Leave Ricky Martin alone!

Re:Isn't this what --preserve-root is for?

[goarilla]

Right, I have no idea why I made that mistake, I should know better :S.

Re:Isn't this what --preserve-root is for?

[Cinnamon Beige]

I dunno, I am very much of the feeling that anything that can brick the system should be hidden behind a hardware switch in order to update. If a motherboard advertised having a jumper that needed to be set in order to update boot info, I would consider that a desirable feature in general.

That'd certainly be a good way to implement an actually secure boot, though I would cheerfully enough settle for any method that requires 'person with physical access' verification. I'm not sure I quite want to have to crack open a case when I just want to boot a live disk, especially if I'm doing something as basic as trying to check to see if a laptop that's still covered by warranty is suffering a hardware or a software problem or other diagnostics, and there's also the risk of people forgetting to reset the jumper afterwards. Something simple as paperclip-in-hole switch (a la emergency resets and releases) probably would do the trick, since if nothing else it would be easy to both check for and fix it if somebody forgets to remove the paperclip to take it out of that mode.

Re:Isn't this what --preserve-root is for?

[Flavianoep]

All of the exemples people are mentioning are mistakes. My question is why would one do rm -rf / intentionally so as to use --preserve-root to prevent whichever problems?

Re:Isn't this what --preserve-root is for?

[Bengie]

POSIX may have changed, but at one point, running the idea of not allowing "rm -rf /" to work by default was heresy to an official POSIX expert until someone realized that part of the standard said if /dev (or something, I forget what path), would be a target of the pattern, then the entire call is undefined as per the standard. Solaris eventually added a protection to refuse to run, but different *nix systems handle it differently.

Re:Isn't this what --preserve-root is for?

[sumdumass]

Used to be that you could recover a trashed bios by renaming a boot rom and putting it on a floppy. Sometimes there was a few key combination to hold. It has been a while since I had to even mess with it though. That is likely out of the question now.

I'm surprised there isn't something default recover mode. .rm just deletes stuff so it is still there should be a way to undelete. Also the boot sector used to be copied to another part of the hard drive. Is there something backup of the EUFI?

It's crazy. If your drive dies your computer is bricked to.

Re:Isn't this what --preserve-root is for?

[mike.mondy]

[ ... ] It's completely normal for a *nix based system to expose something like UEFI variables through the filesystem. It's a concept called Everything is a File and is the same reason why root can read and poke places in /proc and /dev to get information about the system or make changes to it.

Sure. But is the mapping provided here sane? It makes sense to provide a view of the variables as files. Reading the file should return that variables value. Writing the file should change that variables value. OK, so far.

If deleting the file is to have any effect on the actual UEFI variables, it should mean deleting the variable, not zeroing it. Does deleting UEFI variables from the BIOS even make sense? Note that for /dev, the files represent read/write/ioctl access to a device but that deleting a /dev file is like deleting a pointer to an object - it removes your pointer but has no effect on the object itself (and any other similar pointers are still usable). I strongly suspect that the filesystem for these variables should work the same way. Even if creating entirely new variables and deleting them from UEFI is a valid thing to do, it probably needs to be done by a mechanism other than filesystem semantics.

Re:Isn't this what --preserve-root is for?

[Darinbob]

Yup, why should a boot time OS-agnostic system rely on putting it's own values on the OS media? It shouldn't be in any media except that built in to the mother board (NVRAM if small and sane, or more if it's a bloated boot loader like UEFI, but never a hard drive).

Re:Isn't this what --preserve-root is for?

[Darinbob]

BIOS is just a bootloader. UEFI is just a boot loader. They *should* be small and simple, except that the PC grew up in a model where the BIOS did most of the heavy lifting, being used even after boot up. UEFI expands the feature creep. Many systems would just have a simple and small first stage boot loader that's nearly impossible to brick through OS actions, then a second stage boot loader if there's something more to do (like GRUB, etc). That second stage can be screwed up of course but it shouldn't brick the system as a whole.

Re:Isn't this what --preserve-root is for?

[Anonymous Coward]

lol, archaic crap like interrupts.

Re:Isn't this what --preserve-root is for?

[Anonymous Coward]

Besides, the real question here I think is: Why don't these motherboards have a ROM backup that can be used to restore and boot the boards after catastrophic failure of their saved state? Even without the rm -rf / red herring, that seems like a brain-dead requirement, and one that legacy boards have supported for decades.

Cost is why. Those legacy with backup ROM have mostly been the gamer/tweaker/overclocker types as they are frequently flashed or pushed to breaking point and soft-bricks are common. Commodity hardware has a very different use profile, one where people never update firmware or touch the bios/uefi console at all.

Re:Isn't this what --preserve-root is for?

[Mryll]

find/exec with an ls -l command that can be replaced with an rm command can also be useful for verifying what's about to happen

Re:Isn't this what --preserve-root is for?

[gnupun]

That you reached +5 makes me weep for Slashdot.

It's completely normal for a *nix based system to expose something like UEFI variables through the filesystem. It's a concept called Everything is a File [wikipedia.org] and is the same reason why root can read and poke places in /proc and /dev to get information about the system or make changes to it.

That is a very shortsighted statement. Nowhere did I mention not to expose the EFI variables as files. My only condition was that EFI should make it very difficult for the OS or any other software to f*ck up these variables that are needed to boot up the system. But it would surprise me that as the systemd of the BIOS world, EFI, would be based on sane design decisions.

Re:Isn't this what --preserve-root is for?

[omglolbah]

The issue is not that the UEFI data is on any drive, it is that the NVRAM of the UEFI is mounted as a read/write filesystem which gets clobbered by rm-ing /

Re:Isn't this what --preserve-root is for?

[omglolbah]

The issue is not that the data is on a hard-drive. The issue is that the NVRAM of the UEFI is mounted read-write under root, which lets the rm -rf / command wipe it out from NVRAM.

Re: Isn't this what --preserve-root is for?

[Anonymous Coward]

Uh. What is the deal?

Re:Isn't this what --preserve-root is for?

[Mryll]

find/exec with an ls command that can be replaced with rm can also be useful for previewing the destruction

Re:Isn't this what --preserve-root is for?

[Darinbob]

Well. That seems like a half thought out idea. Several places actually. The UEFI firmware should be able to survive even if this happens, at least having a default state that allows recovery. The OS may want this data for some reason, but make it read-only, and preferably not even mounted until some tool explicitly wants access to it. But then, I have to spend time on my job thinking about how things can go wrong so maybe I have the wrong perspective...

Re: Isn't this what --preserve-root is for?

[Anonymous Coward]

Exactly, something like having a delete_variable file you can write the variable name into. Like other hardware interfaces.
The developers were absolutely retarded there.
Attempting to remove class/usb won't send 12V down the ground pin.

Re:Isn't this what --preserve-root is for?

[ArmoredDragon]

I said certain interrupts, dingus. For examples, see interrupts 13h interrupt 10h, both of which are no longer relevant.

Re:Isn't this what --preserve-root is for?

[Pseudonym]

The problem is that UEFI missed the KISS principal and is basically an OS itself.

That's kind of like complaining that most peripherals are computers themselves. Yes, it's an OS-lite, but it only has to run on one revision of one motherboard, and it doesn't have to do everything.

At least UEFI can be persuaded to get out of the way. I'd rather have UEFI than SMM any day.

Re: Isn't this what --preserve-root is for?

[Anonymous Coward]

Some vendors allow for flashing without a working bios or redundant bioses... Anyone dare try this on a gigabyte board a dual bios and UEFI?

Re: Isn't this what --preserve-root is for?

[Anonymous Coward]

Who the fsck cares about a boot speed on a system running 24/7 on a UPS?

Re: Isn't this what --preserve-root is for?

[Anonymous Coward]

they were never relevant anyways, maybe in a signaling sense but you could in/out all on your own.
See: t13.org

This specifically is why your first and second stage boot loaders were position restricted to being under the 2gb mark etc but why you could support drives bigger than your bios could see.

Re: Isn't this what --preserve-root is for?

[Anonymous Coward]

Eg shadowed ram lol

Re: Isn't this what --preserve-root is for?

[Anonymous Coward]

You can directly write uefi file system code on msi mobos ? Sounds more like a feature to me.

Re: Isn't this what --preserve-root is for?

[Anonymous Coward]

Okay, two more things

ONE don't forget uefi support in Linux was rushed hacked etc.
I'm not saying anything about uefi OR Linux here, just reminding everyone that support doesn't necessarily mean proper.

TWO about the five cent backup rom: let's not forget the impending size increase of your ultra book I?

Re: Isn't this what --preserve-root is for?

[Anonymous Coward]

Hot plug devices for boot selection later on maybe? It could be asynchronously modified by the cpu or UEFI... You're making me want to enable uefi now...

It might even need atomic operations... Is this literally direct access to device memory or does the chip know we're modifying it?

Re: Isn't this what --preserve-root is for?

[Anonymous Coward]

When I have to build a few dozen servers and each takes 10 fucking mins to post and I have to make raid changes and reboot, I care a fucking lot about post speed fucking sucking donkey dick.

I have better things to do like jack off to ducks raping each other.

Re:Isn't this what --preserve-root is for?

[thegarbz]

running as root means exerting ultimate control.

Total control should not allow a user to hard brick a device. Ever. That's a UEFI bug period. The fact that Linux exposes the variables as a file has nothing to do with the fact that embedded programmers (such as the ones coding UEFI) should never assume any variable exposed for writing by an external source is sane. There should be hard coded defaults to revert to in case of corruption or deletion.

You should not be able to hard brick a system even as root. Period. Especially using a common command.

Re:Isn't this what --preserve-root is for?

[NotInHere]

1) "flashrom" is actually installed on a production machine (and I honestly can't think of a reason why it should be).
2) "flashrom" is in the path (which I can even less think of a reason why it should be).

Its a debian package. All you need to do is "apt-get install flashrom" as root. Other distros have it probably as well.

3) "flashrom" is executable in normal multiuser mode (which it should not be for VERY obvious reasons).

I don't know what you mean with "multiuser mode", but the standard debian package for flashrom doesn't have setuid bit set, and of course the kernel only allows flashrom to act if its executed by root. I guess its similar for "rm -rf /": it doesnt brick anything if executed as non-root user.

Re:Isn't this what --preserve-root is for?

[hucker75]

Aren't most PC motherboards dual BIOS (and now dual UEFI)? Fuck one up, copy the other one across, which cannot be accessed (presumably) from the OS.

Re:Isn't this what --preserve-root is for?

[david_thornley]

My practice is that, whenever entering a root command by whatever means (sudo counts), I type it and then sit on my hands while looking at it. Looking while paying attention to anything else doesn't count as looking at it. If it still looks good, I take my hands out from under my thighs and press Enter.

And I can't remember why I adopted that rule. Damn. Memory's the second thing to go.

Re: Isn't this what --preserve-root is for?

[Miamicanes]

If the headphone jack state can be read by UEFI, one sensible option would be to require that an Android or iPhone-type 4-lead stereo headset be plugged in and the headset's "action" button (which shorts two lines together) pressed to trigger or enable actions that could be destructive (or allow recovery from them).

Example: rm -rf / borks UEFI. Plug in the headset & power up while pressing the action button to get to a menu that allows you to restore UEFI from an immutable ROM image that can then be updated to a newer one, flash a newer UEFI image, or wipe the nvram and restore it to default values from the current bootloader.

Or they could license FTDI's IP and embed a JTAG programmer in the USB controller, so you could them do a hardware reflash from another computer (or even an Android phone with USB-OTG cable).

For security (and prevent drive-by attacks by rogue USB peripherals), they could add a jumper & disable JTAG-via-USB unless explicitly jumpered. To keep people from LEAVING it jumpered, the system could refuse to continue past the bootloader until the jumper gets removed.

Re:Isn't this what --preserve-root is for?

[Dr_Barnowl]

I do the Japanese Train Driver Thing, making your brain process the idea through extra pathways adds redundancy.

Re:Isn't this what --preserve-root is for?

[zentigger]

So, to back the OP. If one of the UEFI design goals was "eliminating boot code malware." Having run-time writeable boot code looks like an EFI design bug.

Re: Isn't this what --preserve-root is for?

[Eunuchswear]

and I have to make raid changes and reboot,

While I am in violent agreement about your general point -- slow boot problems are not important until you have to boot at which point slow boot can be a disaster -- what kind of cruddy raid system needs a reboot to change its config?

Re:Isn't this what --preserve-root is for?

[thoughtlover]

Exactly... and how about just mapping said command to

echo "I'm sorry, Dave, I can't do that."

Re:Isn't this what --preserve-root is for?

[thoughtlover]

First off, you shouldn't be able to run this command unless you're root. Otherwise you'd have to sudo.

Re:Isn't this what --preserve-root is for?

[Anonymous Coward]

Congratulations, you just designed a race condition.

"Systemd developers have rejected ..."

[Anonymous Coward]

"Systemd developers have rejected ..."

No surprise there.

Hey, systemd developers know better than you how your server should be configured.

Re:"Systemd developers have rejected ..."

[Anonymous Coward]

I dont know how this squarely sits as an issue for just systemd. Openrc still has those mount points susceptible as much as systemd.

No this is an issue because UEFI reads off the hard disk and Linux has read write mount points. Which just needs to be flagged as read only, I fail to see why this couldn't be spin locked so-to-speak.

Re:"Systemd developers have rejected ..."

[Junta]

They have a point. The whole point of them being mounted is for utilities like efibootmgr to be able to use them.

There are two parties to be frustrated with:
-Firmware developers, for not being resiliant in the face of such shenanigans
-The kernel efivars implementation: for modeling these things as plain files with 'rm' meaning delete from firmware (you can rm /dev/* all day long, and not actually affect any of the referenced devices). Should have made removal be a special ioctl, even if otherwise normal files.

Re:"Systemd developers have rejected ..."

[Junta]

No, UEFI doesn't read variables off the disk, there's a kernel module that understands EFI confiig flash space, and exposes the data. Removing files from that pseudo-filesystem is like nuking the config flash area. Note firmware should still be able to tolerate this in theory, but it's not just 'some files got removed'.

The most robust answer is that efivars should not interpret unlink() to erase from flash, instead offering some special ioctl() so a calling program can say they *really* mean it.

Re:"Systemd developers have rejected ..."

[MrKaos]

Since the UEFI is not accessible for change:

-The kernel efivars implementation: for modeling these things as plain files with 'rm' meaning delete from firmware (you can rm /dev/* all day long, and not actually affect any of the referenced devices). Should have made removal be a special ioctl, even if otherwise normal files.

IIUC, so that when you remove the character device it doesn't allow and unlink to reach the UEFI? Is that the implementation issue you mean? Surely the kernel can abstract the access to UEFI to allow writes to pass and just remove the character special device on an unlink so the machine still boots the hardware.

I do rm -rf / more often than you would think. Sometimes I deliberately fail systems this way while they are running so I know how they fail when I loose a filesystem with a running application, it helps identify what is happening if I see the same thing occurs on live systems. It doesn't mean I want to trash the test boxes though.

This kind of explains some hardware failures of some hypervisors we had last year. We were scratching our heads at how voltage spike could take out two machines the same way through 10 of thousands worth of power conditioning gear whilst they were powered down, they both had corrupted UEFI bios, everything else was fine.

Re:"Systemd developers have rejected ..."

[NotInHere]

I wonder, why don't they just provide a configuration setting for this? Then everybody can decide what they want. In the kernel, this works super well. Not just on the build system level, but also on the config level once the kernel is built. Take sysrq for example, its a similar situation. You can use it for malicious purposes like killing a lock screen, but if you don't care you just edit /proc/sys/kernel/sysrq, and you get back the old functionality. And some distros even provide a file in /etc which is read at startup so that the change is persistent.

Re:"Systemd developers have rejected ..."

[afidel]

Just mount them RO by default, require the user to remount as RW if they need to run one of the applications that actually needs RW permissions. This has been done for other critical filesystem components on various Linux distributions since forever.

Re:"Systemd developers have rejected ..."

[Rockoon]

Firmware developers, for not being resiliant in the face of such shenanigans

The firmware guys didnt ask that its contents be exposed as just another generic part of the storage hierarchy. Its supposed to be Handle With Care.

Re:"Systemd developers have rejected ..."

[Junta]

While that may be true, it could be considered an attack vector. We have been focusing on accidental corruption, but it makes for a pretty mean thing to do to some poor saps hardware. Resiliency in the face of such a condition is not too unreasonable, it's just a test case that hasn't really been pursued to date. UEFI having missing configuration should be easy enough for code to cope with.

Re:"Systemd developers have rejected ..."

[Junta]

I can't think of another single instance of hardware/firmware entity being modeled in just such a way. The whole 'devnode' concept serves to segregate some of this special stuff away from common filesystem operations using special ioctl calls. I know they are a tad more annoying to deal with than a totally regular file, but it's not that terrible.

Re:"Systemd developers have rejected ..."

[Eunuchswear]

Third comment on the bug:

(note that you can remount it readonly at boot, simply by adding an entry for it into /etc/fstab, that is marked "ro")

-- poettering

Re:"Systemd developers have rejected ..."

[TWX]

Wouldn't the best policy be to simply not let rm propagate through mounted filesystems beyond the initial filesystem, other than to basically cause an unmount condition prior to deleting the mount point itself?

Re:"Systemd developers have rejected ..."

[Junta]

UEFI is accessible for change. Note the standard doesn't demand that 'getting bricked' be possible, it's the firmware developer implementations that have issues.

Right now the efi variables are normal files:
$ ls /sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c -l
-rw-r--r-- 1 root root 57 Jan 22 09:58 /sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c

So my proposal would be either to make each something like a character device, with special ioctl for 'deletion', or a normal file, except ignore 'unlink()' and provide a separate character device with ioctl to remove the variables, or some 'echo delete Boot000 > whatever' type interface. The latter is probably the best all things considered.

The whole acess to the variables space is already an abstraction, so efivars can do whatever they want (though would break downstream utilit(ies) expecting to be able to unlink, but I think that's worth the work. A utility can be backward compatible by checking for existence of new interface, and falling back to unlink should that new remove interface be missing.

Re:"Systemd developers have rejected ..."

[Junta]

There are various options to do just that on various utilities, but the status quo is that they are not default.

The 'you really didn't mean to remove root, did you?' in rm already should provide a measure of protection against the 'rm -rf /' case specifically, but it's a convenient shorthand to denote a failure scenario that could be reasonably mitigated without too onerous of an interface for things looking to use the efivars correctly.

Re:"Systemd developers have rejected ..."

[Rockoon]

While that may be true, it could be considered an attack vector.

Major parts of all modern operating systems are dedicated to reducing attack vectors. Even main memory has an OS gatekeeper.

While I sit here wondering why the fucking bios variables dont have an OS gatekeeper, I find it a bit alarming that instead of access restrictions there is in fact a red carpet.

Re:"Systemd developers have rejected ..."

[Anonymous Coward]

They have a point. The whole point of them being mounted is for utilities like efibootmgr to be able to use them.

Why do they have to be R/W all the time though?

Can't efibootmgr mount the same thing read-write under /tmp/efi-XXXXXXXXXXXXXX/ when it needs to make changes, with 0100 permission of that tempdir so no one can walk it accidentally, then un-mount when done?

Re:"Systemd developers have rejected ..."

[Anonymous Coward]

Why not just use the MBR like a well adjusted being?

Re:"Systemd developers have rejected ..."

[Junta]

That would make sense, but that's not the convention. I still think it would be more resilient for the kernel implementation of that pseudo-filesystem to *not* treat unlink so gravely, and provide an alternative interface.

Of course they would be right in calling out the firmware implementations for buggy behavior, but it doesn't seem like a terrible compromise to do that to mitigate risk a little.

Re:"Systemd developers have rejected ..."

[dfsmith]

Maybe someone should petition the sysfs guys to have a "00erasable" file as the first dirent in the UEFI space: the variables can only be removed if that file exists. Hopefully "rm *" will remove that file first, making the rest unerasable.

Re:"Systemd developers have rejected ..."

[MrKaos]

UEFI is accessible for change. Note the standard doesn't demand that 'getting bricked' be possible, it's the firmware developer implementations that have issues.

Right now the efi variables are normal files: $ ls /sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c -l -rw-r--r-- 1 root root 57 Jan 22 09:58 /sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c

Thanks, I've not paid enough attention to this, I'm glad it didn't catch me.

So my proposal would be either to make each something like a character device, with special ioctl for 'deletion', or a normal file, except ignore 'unlink()' and provide a separate character device with ioctl to remove the variables, or some 'echo delete Boot000 > whatever' type interface. The latter is probably the best all things considered.

It seems reasonable, especially as it would offer a degree of protection against shitty UEFI implementations.

The whole acess to the variables space is already an abstraction, so efivars can do whatever they want (though would break downstream utilit(ies) expecting to be able to unlink, but I think that's worth the work. A utility can be backward compatible by checking for existence of new interface, and falling back to unlink should that new remove interface be missing.

Indeed, breaking a few utilities is a small price to pay so you can't brick a motherboard. Software can change.

Re:"Systemd developers have rejected ..."

[Eunuchswear]

And nearly the last comment:

Locking this one. Note sure which peanut gallery site linked this...

-- poettering

Slashdot, get your peanuts here!

LOL, what?

[gstoddart]

So, which is it .. UEFI is catastrophically broken, or the way it's implemented is clueless and naive?

Because this sounds so horribly broken it isn't funny.

Actually, no, it's actually quite funny in a big giant "WTF" kind of way.

Re:LOL, what?

[Anonymous Coward]

According to wikipedia:
"Linux kernel exposes EFI variables data to userspace via efivarfs (EFI VARiable FileSystem) interface (CONFIG_EFIVAR_FS) - mounted using efivarfs kernel module at /sys/firmware/efi/efivars - it has no maximum per-variable size limitation and supports UEFI Secure Boot variables. Introduced in kernel 3.8. "

No idea if it's read only access or otherwise, but there is potential in bricking UEFI by other means, not just with systemd.

Why the hell isn't the default, stock UEFI info stored on ROM and then repopulated in such cases? Better to have to manually restore the security keys than to be left with a chunk of hardware that now needs JTAG resuscitation.

Re:LOL, what?

[Anonymous Coward]

Sorry, wrong source. I got this from the Arch Linux wiki page, not wikipedia. Additionally, they mention the bricking potential and recommend adding an fstab entry with the ro mount option for safety.

Love the Arch community.
https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#UEFI_Variables_Support_in_Linux_Kernel

Re:LOL, what?

[Dolda2000]

Not that UEFI isn't catastrophically broken, but reading TFA, in this case the real problem seems to be the way it is implemented on some motherboards (TFA mentions "some MSI notebooks" without specifying further). Even if EFI vars are broken, that really shouldn't brick your motherboard unless the motherboard itself is buggy. Makes me wonder if the owners have tried resetting their NVRAM, or if that too is perhaps impossible on these motherboards.

Re:LOL, what?

[Ol Olsoc]

So, which is it .. UEFI is catastrophically broken, or the way it's implemented is clueless and naive?

Choose door number 1.

Re:LOL, what?

[squiggleslash]

Kinda a mix of everything. It's worth noting that, according to ex-kernel hacker Matthew Garrett, you can achieve the same bricking using a 20 line program in Windows. So it's not a Linux (or systemd! Seriously, don't we have enough hate against systemd without TFS adding fuel to the fire?) issue, it's more a design fault.

Clearly UEFI variables are expected to be written to by suitably privileged programs under consumer operating systems, otherwise Windows and Linux wouldn't expose them the way they're exposed. Yet clearly variables are being exposed like this that shouldn't be written to under normal circumstances.

Re:LOL, what?

[Anonymous Coward]

It's shitty implementations on a handful of low-end motherboards. Think intel atom or cheaper AMD based stuff.

Re:LOL, what?

[Junta]

Yes, the firmware should be more resilient to these interfaces doing crazy things.

But also, in Linux, the interface lends itself to accidental nuking, rather than an explicit targeted effort. So one could say that's a problem too. Even if it was working in a robust manner, a system only being able to boot to setup menu is a valid interpretation (you deleted the entire boot order, including network, usb ports, etc). So it's worth not being in a position of getting screwed up by 'rm -rf / tmp/somelittledir'

Re:LOL, what?

[Anonymous Coward]

The latter. Some Linux kernel developers are pretty lazy and love to pretend that virtual filesystems (debugfs, sysfs, procfs, securityfs, etc) are a perfectly reasonable way to interact with userland because it makes things easy on them. Userland then typically takes the kernel developer's expectations and smashes them against a wall. It is the kernel's most important job to abstract away the hardware in a way that makes it accessible to userland programmers, but not so easy to access that it introduces input validation concerns and puts the actual hardware at risk. If anything, virtual filesystems have made hardware programmers lazier, and we need to be able to expect some level of restraint.

Re:LOL, what?

[Gojira Shipi-Taro]

Well it lends itself to accidental nuking if you make a habit of doing operations as root. rm -rf / or any variation of it shouldn't nuke a sstem on it's own. if you don't need sudo before that to do real damage, you're doing it wrong.

Re:LOL, what?

[Ol Olsoc]

Kinda a mix of everything. It's worth noting that, according to ex-kernel hacker Matthew Garrett, you can achieve the same bricking using a 20 line program in Windows. So it's not a Linux (or systemd! Seriously, don't we have enough hate against systemd without TFS adding fuel to the fire?) issue, it's more a design fault.

Yeah. It's nothing short of amazing when a UEFI fault becomes automagically a systemd fault.

Must..... resist......argghhhh!! ummhhh! Oh hell!

Thanks Obama!

Re:LOL, what?

[Anonymous Coward]

Any changes to the firmware should only be possible by flipping a hardware switch first. Coincidentally, that would also make whole secure boot schmoo obsolete. But we can't have end-consumers control their own computers, can't we?

Re:LOL, what?

[vtcodger]

"So, which is it .. UEFI is catastrophically broken, or the way it's implemented is clueless and naive?"

Why do you believe those options are mutually exclusive?

Re:LOL, what?

[gstoddart]

And, now ask yourself ... what can you do about that fact?

What's that? Nothing at all because the consortium who defined it doesn't care about what Linux does?

So, yes, UEFI may be broken ... but it may also be that the way Linux is using it is wrong. And here, wrong is defined by "what did the people who built UEFI say?".

Re:LOL, what?

[Anonymous Coward]

rm should require a final parameter that is not a filename if it's called with --force or --recursive. Since all absolute paths start with a slash, it's too easy to accidentally delete everything by fat-fingering enter after the first slash. Hasn't happened to me, but I'm always acutely aware of the danger whenever I recursively delete, even as a user.

Re:LOL, what?

[Anonymous Coward]

Yeah. It's nothing short of amazing when a UEFI fault becomes automagically a systemd fault.

It's deliberately not a part of /sys, but a separate file system that can be mounted in a subdirectory of /sys, if you desire to mess around with efi variables, or mounted read only (without the rest of /sys being read only), if you need to read these variables without risking accidentally changing anything.

And then systemd goes on and mounts it read-write by default, without the user asking for it.

While systemd may have a valid reason for doing this (for those that use a certain feature, at least), mounting it read-write by default seems quite risky.

Re:LOL, what?

[omnichad]

You mean like --no-preserve-root?

Re:LOL, what?

[trevc]

This confirms that Linux is much more powerful than Windows. In Windows, it takes 20 lines of code to brick your system, Linux can do it in one command.

Kinda a mix of everything. It's worth noting that, according to ex-kernel hacker Matthew Garrett, you can achieve the same bricking using a 20 line program in Windows. So it's not a Linux (or systemd! Seriously, don't we have enough hate against systemd without TFS adding fuel to the fire?) issue, it's more a design fault.

Clearly UEFI variables are expected to be written to by suitably privileged programs under consumer operating systems, otherwise Windows and Linux wouldn't expose them the way they're exposed. Yet clearly variables are being exposed like this that shouldn't be written to under normal circumstances.

Re:LOL, what?

[Anonymous Coward]

No, what I mean is this:
> rm -rf /var/log
and then you fat-finger enter, and rm tells you:
rm: will not remove recursively without final option parameter
because what you would have to type to actually delete all of /var/log would be rm /var/log -rf, for example. You shouldn't be able to delete recursively with a filename as the last parameter. Maybe make that a general rule, not just for recursive deleting.

Re:LOL, what?

[Anonymous Coward]

Seriously, don't we have enough hate against systemd without TFS adding fuel to the fire?

No. Systemd delenda est!

Re:LOL, what?

[tricorn]

There should ALWAYS be a way to reset a boot loader to a default usable state, whether it's by holding down the power button for 10 seconds or some other hardware based override, or having the bootloader on a microSD card that you can take out and fix on any other computer, or a pre-boot-loader phase where a keyboard override routes to a low level interface where you can fix things, or a jumper or switch inside the case that does the same thing. There should also always be a backup firmware image that can be used.

I'd also think that having the efivar interface expose each variable as a separate file isn't a particularly good idea. Having a simple program to modify variables using another mechanism isn't all that terrible, the convenience of being able to use echo to change a variable isn't worth the risk.

An ARM system I use has u-boot variables at a fixed location on the SD slot boot device, which is hardwired (on the SoC with fuses) to be the only boot source (which can then boot something else either from the SD card or some other device, u-boot itself starts up in well under a second). You can take the microSD card out and put whatever bootloader you want on it, or modify the variable block from the OS by direct writes to a partition (or to a known location on the raw device). The block is checksummed, and u-boot falls back to a default configuration if it's trashed.

The program to read or write variables is quite simple and easy to use in a script.

There's no reason UEFI couldn't do something similar. Last I looked I didn't see an open UEFI implementation on ARM, it might be fun to try replacing u-boot with UEFI and see what it takes to get Linux to boot with it.

Re:LOL, what?

[Grishnakh]

Linux *is* using it wrong, and it's unfixable, because the only "right" way to use it is to use Windows on it, because that's what the consortium intended.

Pretty lousy when a cabal of companies conspire to only support a monopoly in operating systems. You'd think they'd want more competition in that market; it doesn't do hardware makers any good to have all their wagons hitched to a single OS maker that's liable to lead them off a cliff (look at how unpopular Windows is these days).

Re:LOL, what?

[gstoddart]

Pretty lousy when a cabal of companies conspire

Sadness accrues.

Yes, companies get together and foist crap on us because there's something in it for them.

They don't care about competition, they want to maximize profits. If circling the wagons around what MS wants does that for them, that's what you'll get.

But let's not be surprised that markets get skewed by collusion among players in the market. Because that kind of crap pretty much always happens.

Re:LOL, what?

[INT_QRK]

I may not be getting this, I admit, so this is not meant as challenging or critical, but what linux user would/might/could "accidentally" log in to a console as root, then issue an "rm -rf" command? I can see how a malware script might, given a prior enabling compromise of root, but "accidentally" doesn't compute. In my understanding, gaining root, or Windows admin, privilege pretty much allows malicious actions anywhere, so I don't get at this point why this is earth shattering.

Re:LOL, what?

[wolrahnaes]

if you don't need sudo before that to do real damage, you're doing it wrong.

I completely agree with you, but there are a lot of people doing it wrong.

Re:LOL, what?

[Anonymous Coward]

Comparing a routing command to a 20 line program in Windows??? Quite a stretch to claim they are the same thing.

Re:LOL, what?

[Anonymous Coward]

My first thought on "rm -rf /" is that this would be used maliciously as a practical joke or intentionally to brick someone's system knowing the issue exists. You'd still either need physical access, convince an idiot to type it in who has physical access, or find some kind of remote privilege escalation to do this. It's still a bad bug. I can't remember the last time (if ever) where I wanted to rm -rf / ... Typically you just don't do that ever. The system and especially the BIOS/UEFI should always be resilient enough to boot into a generic default state that will let you recover or reinstall.

Re:LOL, what?

[phantomfive]

Not that UEFI isn't catastrophically broken, but reading TFA, in this case the real problem seems to be the way it is implemented on some motherboards (TFA mentions "some MSI notebooks" without specifying further)

The problem is UEFI is so complex that many manufacturers make a lousy implementation with a lot of copy-paste code (from Intel's reference implementation). Their QA process seems to be something like, "Does Windows boot? If it does, then it must be ok."

Of course, manufacturers should be blamed for their mistakes, but if UEFI were simpler, there would be less room for mistakes.

Re:LOL, what?

[benjymouse]

It's worth noting that, according to ex-kernel hacker Matthew Garrett, you can achieve the same bricking using a 20 line program in Windows.

You mean to say that if I accidentally type that 20 line program on Windows, compile it, type the name and hit Enter, my box is toast? That's scary!

Thanks for the warning. I'll be wary of those 20 lines. What were they again, just so that I do not type them accidentally?

Re:LOL, what?

[MachineShedFred]

My motherboard has a dual-ROM setup, so that if the active one gets hosed from either a bad update, or some stupidity like this, there is a procedure to recover without RMA or extreme measures.

I have no idea why this isn't a standard thing on every motherboard now that EEPROM is so cheap.

Re:LOL, what?

[Anonymous Coward]

And then systemd goes on and mounts it read-write by default, without the user asking for it.

systemd only mounts it read-write because the distro tells it to do so. If the distro maintainers thought that RO efivars was a good idea (it isn't) they could make it so by adding it to fstab as read-only. Users can do the same.

Mounting efivars as RO is a bad idea that breaks userspace software and doesn't solve the fundamental problem at all, since people can still brick their non-spec UEFI motherboards.

Re:LOL, what?

[squiggleslash]

Are you in the habit of accidentally typing "sudo rm -rf /"? (From memory AND PLEASE DON'T TRY IT IIRC many implementations of rm actually refuse to execute that particular command because it's so dangerous, they figure if you really need to, you can always try rm -rf /* or something like that.)

Just so you're aware, if you do type rm -rf /, you will bork your system and destroy all your data, together with any on attached network shares, regardless of whether you have a sucky BIOS or not. It's just in the latter case, you might also physically brick the computer.

Re:LOL, what?

[Anonymous Coward]

OEM's point of view: margins are thin, if a reset/recover facility is only used by 1 in 10,000,000 users but costs us 5c to implement per motherboard, drop it.

This is especially true of low-end, budget OEM's like MSI (I sadly own one such MSI laptop, it is crap). The whole UEFI saga was to improve security and prevent this type of bricking. Give me old fashioned BIOS, but all the new machines don't come with that anymore.

New kid engineers with bright ideas - UEFI, systemd. Then after 15 years they learn the same lessons the old timers were shouting at them about. Maybe they fix it, only for the next generation of new bright engineers... ad infinitum...

Re:LOL, what?

[Junta]

Consider it a stand in.

So if root, and you 'rm -rf / tmp/directory', accidentally putting in a space, things could be bad. Note that this requires a number of bad practices to get here, but it's plausible in the real world and historically would only ruin all your data and OS (gee 'only')

However there was, for example, a mistake in a Steam script, that basically did somethnig like:
rm -rf $HOME/.steam
But $HOME could be empty (or something like that, I think it was a more common scenario, some other obscure variable). Either way, 'hilarity' ensued.
This was not a human running a command, but the steam installer. Stupid mistakes like this happen all the time, but generally *not* in something as widespread as steam.

Re:LOL, what?

[Anonymous Coward]

I blame SystemD for this. Nothing you do to the file system should be able to break the hardware. Period. Exposing these as writable is absurd. I don't give one goddamned fuck about your "use cases" for writing them. If you want that shit, remount it r/w or provide some alternate boot configuration. The default state should not exposed them to deletion via rm -rf /. That is only something a fucking moron (which, I will admit, most SystemD developers and proponents are) would want.

Re:LOL, what?

[squiggleslash]

The fact that distribution makers (who configure systemd) would have configured sysvinit to do exactly the same damned thing doesn't bother you?

Re:LOL, what?

[goarilla]

What about the situation where you want to rm safely with pathname expansion (globbing) ?
rm -rf -- *

Re:LOL, what?

[Cinnamon Beige]

I may not be getting this, I admit, so this is not meant as challenging or critical, but what linux user would/might/could "accidentally" log in to a console as root, then issue an "rm -rf" command? I can see how a malware script might, given a prior enabling compromise of root, but "accidentally" doesn't compute. In my understanding, gaining root, or Windows admin, privilege pretty much allows malicious actions anywhere, so I don't get at this point why this is earth shattering.

I'd expect it to require at least one PEBKAC problem, which could be as innocent as a user who is not getting sufficient sleep. Would it actually be difficult to implement something that will give a clear visual flag when in somebody is logged in as root, even in command line, so it takes a lot more effort to be unaware of if you're currently root or not? Something as simple as just inverting the display colors would be hard to miss, robust, and potentially simple to implement. (It might also happen to encourage only logging in as root when absolutely necessary as a side effect, which may not be a Bad Thing.)

Re:LOL, what?

[HiThere]

I believe that were I to do this, it would have no effect unless I was logged in as root. Obviously, I'm not about to try. But the only things in "/" that have write permission to other than root are:
lrwxrwxrwx 1 root root 31 Dec 17 2014 initrd.img -> /boot/initrd.img-3.16.0-4-amd64
drwxrwxrwt 38 root root 4096 Feb 1 13:17 tmp
and
lrwxrwxrwx 1 root root 27 Dec 17 2014 vmlinuz -> boot/vmlinuz-3.16.0-4-amd64
and two are those are links to a file that itself only has write permission given to root.

Similarly for "/var/log". So if "rm -rf /var/log" would do anything at all I would consider the system broken. Similarly for "rm -rf /*". I'm still trying to wrap my head around what "m -rf /" *should* do even with root permissions, but without it since
drwxr-xr-x 25 root root 4096 Sep 28 12:04 . and
drwxr-xr-x 25 root root 4096 Sep 28 12:04 ..
it clearly shouldn't do anything. So if it were to then I would consider the system broken.

Re:LOL, what?

[HiThere]

Mod parent +6 insightful and +6 informative. Or higher.

Re:LOL, what?

[Grishnakh]

The problem, as I see it, is that manufacturers may *think* that circling wagons around what MS wants will maximize their profits, but I think they're terribly mistaken. Just look at how badly the PC market is doing these days. No one's buying the things any more, unless they're basically forced to because their old PC died of old age. The market is saturated, and people are moving to mobile devices which don't have all the problems that Windows has. PC makers would do better if they pushed devices with different OSes; remember when netbooks were brand-new, they were selling pretty well with Linux, until MS screwed them over by requiring netbook makers to only sell them with Windows, killing the netbook market altogether, and creating a market which the iPad and later Android tablets exploited.

Even worse, now MS is starting to make their own hardware (the Surface line), which threatens to put some of the other OEMs out of business.

Re:LOL, what?

[Anonymous Coward]

I've used an ARM system where the ROM contains a minimal first-stage bootloader that reads the second-stage bootloader from eMMC into SRAM - but first it listens over the standard USB port for a special message, in which case it downloads the second-stage bootloader over USB instead. Then the second stage can initialise DRAM etc, and download the third stage (which might be u-boot), until you've got enough of a running system to download an entire new eMMC image over USB and flash it. Even if you've completely wiped your eMMC and corrupted every piece of writeable memory, all you need is a standard PC and you can re-bootstrap the whole thing.

I've also used an Intel embedded system where if you simply misconfigure your UEFI BIOS, the only way to recover is with several hundred dollars of special flashing hardware connected to the appropriate port on a debug board and driven by a Windows-only tool.

One of those platforms is significantly less fun to develop for than the other.

Re:LOL, what?

[kitezh]

Steam had a problem with this not long ago if the Steam directory was moved. Mind you, it only deleted the user files (unless you run your machine as root).

Re:LOL, what?

[Anonymous Coward]

Manufacturers don't care a bit about UEFI, they just want to sell hardware. So who was it that forced UEFI on everybody else?

Re:LOL, what?

[Anonymous Coward]

It could either treat -- as "I know what I'm doing" or make an exception for one particular "--eol" option which confirms the intentional end of the line if it's the last parameter. "--eol" would be ignored if it occurs before --, and it would be treated as a file name if it appears after -- but isn't the last parameter.

Re:LOL, what?

[niftymitch]

Not that UEFI isn't catastrophically broken, but .....

Good golly, WTF.... If true, Call the FBI and the Department of Homeland security.

Recall the stuxnet attack. This tells me that because there is a requirement for user space
writing of files a bad boy virus could do it on demand. Any time any place any ....

Viruses have been known to lurk for a long time only to activate much later. A vulnerability
like this is serious and worse exists to protect systems from attack.

Both windows and linux are apparently vulnerable. These machines need to be excluded
from deployment in government, hospitals, banks, -- we are not talking about a painful
reload of the OS and data from backups this is hardware. Both costly and difficult
to deliver. Older hardware is out of production so this flaw mandates updates that may
not be able to use peripherals like DRAM, Drives, network hardware...

WTF.... if true this is a global risk.

Re:LOL, what?

[Anonymous Coward]

I'm a UEFI firmware developer whom works on reference UEFI implementations. I can tell you that all of the firmware that I work on does properly fall back to the default configuration if either the CMOS is corrupted (due to a dead battery for example) or if a needed variable does not exist.

That said, your typical OEM system has one BIOS engineer takes the code me and my colleagues write and spend ~1-2 weeks doing all the changes necessary to boot it on a given board design. These engineers usually are not as good coders as people who work on the reference BIOS, and usually their job performance ratings are based on how many boards they did that year and don't consider how many bugs or how many BIOS releases they did for each board. Usually they need to do at least 50 boards a year to get a good rating. You can imagine how much care and effort they put in to each board...

Re:LOL, what?

[Krishnoid]

Don't forget to (accidentally) install a compiler first.

Good thing I posted this, that could have been a close call!

Re:LOL, what?

[Anonymous Coward]

QUOTE: "I blame SystemD for this. Nothing you do to the file system should be able to break the hardware. Period. Exposing these as writable is absurd"

How is this systemd's fault then?
I figure you're not a generally knowledgable person (calling systemd devs "morons" and suggesting they mount it ro by default without actually understanding what is going on gives me that impression), but do you realise that access rights have very little to do with this?

Mounting it ro is akin to opening a tigercage at the local zoo and posting a sign that says "Danger! Tigers ahead".
It doesn't solve the underlying issue.

Re:LOL, what?

[doccus]

So, which is it .. UEFI is catastrophically broken, or the way it's implemented is clueless and naive?

Because this sounds so horribly broken it isn't funny.

Actually, no, it's actually quite funny in a big giant "WTF" kind of way.

Yes

Re:LOL, what?

[david_thornley]

The cabal doesn't want to support a monopoly in OSes. There's good money in selling Linux boxes. It isn't in desktop systems (although 1% of the market is still pretty impressive in absolute terms), but in servers.

Re:LOL, what?

[Anonymous Coward]

Try entering rm -rf / on any modern unix system (Linux, BSD, Mac OS X) and see what happens. HINT: it does not delete the root filesystem.

Re:LOL, what?

[Anonymous Coward]

Mounting efivars as RO is a bad idea that breaks userspace software and doesn't solve the fundamental problem at all, since people can still brick their non-spec UEFI motherboards.

What the SystemD crowd actually means by this is that SystemD is one of those programs that could fail if efivars are mounted as RO.

Knowing Poettering that's probably the ONLY thing they care about

We actually write to the EFI fs in systemd. Specifically, when you issue "systemctl reboot --firmware" we'll set the appropriate EFI variable, to ask for booting into the EFI firmware setup. And because we need it writable we'll mount it writable for that.

Re:LOL, what?

[Anonymous Coward]

Clearly UEFI variables are expected to be written to by suitably privileged programs under consumer operating systems, otherwise Windows and Linux wouldn't expose them the way they're exposed.

For example, putting the lsass in a more protected mode in Windows involves setting a UEFI variable with the administrative rights simply by adding a registry key. Deleting the variable requires a separate tool, or disabling the secure boot to reset the UEFI variables.

Re:LOL, what?

[Anonymous Coward]

That the matter and question is schizophrenic and a fish s hook, so now they can SEE there are NO real engineers with knowledge in these comments, which is good for the anthropoid species who DO NOT WANT COMPUTING EXISTING. Beware if you do not get a real discussion here, those do exist and do benefit from the whole computer affair being dismissed as NOT NATURAL and STUPID.

Re: LOL, what?

[Anonymous Coward]

Take your medication man

Cough... systemd...

[Anonymous Coward]

In other news, Poettering remains the best advocate Apple has for switching geeks to their platform... they should pay him, really.

Re:Cough... systemd...

[Anonymous Coward]

You forgot FreeBSD.

Huh?

[Anonymous Coward]

It's just now bricking systems? Wow, all this time I could have been running "rm -rf /" with reckless abandon ...

Re:Huh?

[Anonymous Coward]

I read up on this - it's bricking the system as in "wiping EFI data in ROM", meanin the motherboard is now a brick. Prior to UEFI and systemd, 'rm -rf /' would only wipe the disk, and you could rebuild from backups if you had them

Re:Huh?

[Anonymous Coward]

It's not ROM, it's NVRAM.

Re: Huh?

[Anonymous Coward]

moar liek NSARAM

Re:Huh?

[Ol Olsoc]

I read up on this - it's bricking the system as in "wiping EFI data in ROM", meanin the motherboard is now a brick. Prior to UEFI and systemd, 'rm -rf /' would only wipe the disk, and you could rebuild from backups if you had them

So they have systemd on Windows now too?

Re:Huh?

[Anonymous Coward]

Don't come here with your fancy-pants logic. It's not appreciated. There's hatin' t' be done!

Re:Huh?

[clockley(571021718)]

The wipe EFI data on linux you need systemd, to wipe the EFI data on windows you need 20 lines of code.

Re:Huh?

[wonkey_monkey]

"wiping EFI data in ROM"

Can you see which bit you got wrong there?

Re:Huh?

[Anonymous Coward]

I read up on this - it's bricking the system as in "wiping EFI data in ROM", meanin the motherboard is now a brick. Prior to UEFI and systemd, 'rm -rf /' would only wipe the disk, and you could rebuild from backups if you had them

You are wrong. Upstart and SysVinit distros have exactly the same problem with motherboards with faulty UEFI implementations since they too mount /efivars as read-write.

Re:Huh?

[Ol Olsoc]

The wipe EFI data on linux you need systemd, to wipe the EFI data on windows you need 20 lines of code.

So in what universe does that ever mean that it's systemd's fault?

Seems to me like a severe vulnerability, and it exists because UEFI is messed up. Is 20 lines of code some new thing that would put the writer in the GBOWR's?

Seems to me like a new vector for ransomware on the PC. Grab admin access through one of the ways, and send a message, "Pay us X number of bitcoin or we'll execute 20 lines of code on your Windows machine. and brick it".

And you'll still blame that on systemd!

I just cannot understand the illogic some folks engage in. Perhaps that happens when one picks a target to hate, and loses their reason in it, or just needs a simple one word soundbyte to point out as the source of all ills.

Re:Huh?

[Anonymous Coward]

I read up on this - it's bricking the system as in "wiping EFI data in ROM", meanin the motherboard is now a brick.

I don't think ROM means what you think it means.

Re:Huh?

[vtcodger]

"Wow, all this time I could have been running "rm -rf /" with reckless abandon ..."

You mean that you don't have a "rm -fr /" line in your /etc/crontab file? If you wish to have a secure system i think you need to add it.

Immediately

Security is too important to procrastinate about.

(And yes, I'm joking .. I think)

Re:Huh?

[Anonymous Coward]

Prior to UEFI 'rm -rf /' would only wipe the disk

Fixed it for you.

systemd is not a cause, don't spread FUD by implying they are.

Re:Huh?

[Anonymous Coward]

"wiping EFI data in ROM"

You keep using that word. I do not think it means what you think it means.

Re:Huh?

[KGIII]

And they say Windows is easier.

Re:Huh?

[Anonymous Coward]

"wiping EFI data in ROM"
Say out loud the full wording associated with the acronym R.O.M. and you'll see why your statement is incorrect

Re:Huh?

[thegarbz]

This problem has nothing to do with systemd and you can cause the same issue on non-systemd linux and if you're good at coding in BSD or Windows too.

Re:Huh?

[Anonymous Coward]

Wiping data in Read-Only Memory. Now that's serious skills!

Re:Huh?

[Schmorgluck]

Some systemd haters can't help bringing it on the table even when it's totally irrelevant. Makes them feel smart.

Captain Obvious to the rescue!!!

[Anonymous Coward]

I would have thought this was rather obvious. Anyone with even a beginner knowledge of Linux would know command rm -rf / is disastrous. I guess the stupid bar in the world really has hit the floor if people are running this unintentionally.

Re:Captain Obvious to the rescue!!!

[tigersha]

Yeah but viruses and spelling mistakes do actually happen.

Re:Captain Obvious to the rescue!!!

[fluffernutter]

I have full backups... it would be nice to know that I could use them to restore the system and keep going if I ever ran that command by mistake.

Re:Captain Obvious to the rescue!!!

[Anonymous Coward]

Deleting your entire hard drive is not the same as bricking your device, Captain. Or at least it should not be.

Re:Captain Obvious to the rescue!!!

[Anonymous Coward]

It always fried your OS. But now it apparently also destroys your motherboard if you can't reset the UEFI somehow.

Re:Captain Obvious to the rescue!!!

[Anonymous Coward]

Depends on the level of disaster you're expecting. You'd expect it to wipe the filesystem, however you'd expect to be able to reinstall afterwards. This story seems to be saying you can trash your UEFI BIOS in a non-recoverable way, and I certainly wouldn't have expected that (probably because I have no clue about UEFI).

Re:Captain Obvious to the rescue!!!

[Githaron]

Back in college, I ran the command for shits and giggles on a system that we were redoing anyway. I would have been immensely pissed if I found out it bricked the system because some firmware was mounted as writable space.

Re:Captain Obvious to the rescue!!!

[Anonymous Coward]

I'm a little surprised that motherboards don't keep a tiny read-only repository of code to restore from in case you FUBAR the writeable parts. Isn't BIOS code measured in KB? That's trivial space to devote to brick prevention.

Re:Captain Obvious to the rescue!!!

[Anonymous Brave Guy]

Yes, malware is probably the biggest real danger here.

That said, over the years I've also seen my share of very sheepish-looking engineers whose scripts didn't guard against an empty environment variable...

Re:Captain Obvious to the rescue!!!

[Junta]

The code is not overwritten, but the code is not expecting *all* variable store data to be wiped, and may go down impossible paths.

If this becomes a standard test case, then you'll see firmware get more resilient to this over time.

Re: Captain Obvious to the rescue!!!

[Anonymous Coward]

/ is the root directory, which includes BIOS equivalent variables under Linux. It has never been "the hard drive" in Unices, not like C:\ is a device specifier in Windoze.

Re:Captain Obvious to the rescue!!!

[dmomo]

I wouldn't say it's as obvious as you make it seem. There is a difference between erasing the entire file system (obvious) and bricking the hardware by destroying the firmware.

Re:Captain Obvious to the rescue!!!

[mattventura]

I think the transition of malware from mischief to profit puts a stop to that. I can change voltages on my motherboard with a software utility, if someone wanted to cause hardware damage they could easily do so in malware.

Re:Captain Obvious to the rescue!!!

[Culture20]

I always tell new admins to type the path being deleted first, then type /bin/rm -r at the beginning of the line. Those pesky / and \ are too close to the enter key. Especially a problem for Windows.

Re:Captain Obvious to the rescue!!!

[Culture20]

It used to be done on purpose on sacrificial systems to show how processes stay resident in memory. Now they have to be really sacrificial.

Re:Captain Obvious to the rescue!!!

[sjames]

No. rm -rf / means reinstall or restore from backup. The non-obvious part is that your motherboard may never boot again.

Re:Captain Obvious to the rescue!!!

[phantomfive]

If this becomes a standard test case, then you'll see firmware get more resilient to this over time.

The standard test case for UEFI seems to be, "Does it boot Windows?" Those drivers tend to be really buggy.

Re:Captain Obvious to the rescue!!!

[Anonymous Brave Guy]

You make a good point, though it probably requires some degree of actual knowledge and skill, or at least a suitable malware toolkit, to cause damage by playing with electrical levels. Any script kiddie can do 'rm -rf /' and surely it's practically the first thing any mischief-makers will try.

It's still crazily easy to do this by mistake as well, though.

Re:Captain Obvious to the rescue!!!

[LinuxIsGarbage]

The code is not overwritten, but the code is not expecting *all* variable store data to be wiped, and may go down impossible paths.

If this becomes a standard test case, then you'll see firmware get more resilient to this over time.

Bricking a motherboard due to a bad firmware flash has been a serious concern for a long time (due to power-cut, or a bad floppy, or whatever). Support for any sort of backup firmware has always been sporadic. So I won't hold my breath.

Re:Captain Obvious to the rescue!!!

[maugle]

The last two motherboards I've bought boasted twin BIOS chips, such that if the active BIOS was corrupted a quick jumper connection would copy the read-only contents of the backup chip to the active chip, providing an easy out from a possibly bricked computer. Sounds to me like the affected motherboards didn't offer a similar feature for EFI, and were very cavalier about how they stored their system-critical data, so we should file this bug under "lazy/negligent mobo manufacturer".

That said, the kernel should be a bit more careful when applying "rm -rf" to EFI vars. When I decide to send my current setup to oblivion, I'd prefer it not take my hardware along for the ride.

Re:Captain Obvious to the rescue!!!

[Megane]

Don't forget the scripts that fail to work with path names that contain blanks! This is quite common on OS X when the hard drive is usually named "Macintosh HD". (I renamed mine to "Macintosh-HD" just in case.)

Re:Captain Obvious to the rescue!!!

[Megane]

Or it may simply be unable to access things like USB and SATA controllers when their configuration is erased. If it was unable to access keyboard and display, you wouldn't be able to use a "reset to defaults" option, if there even was one.

Re:Captain Obvious to the rescue!!!

[Megane]

Clearly you don't know much about *NIX if you think that a file system is the same as a hard drive, and that every directory entry in the file system corresponds to a collection of sectors on a hard drive. Besides, this isn't even about deleting everything from the / root, you can also start at the root of the fake file system that represents the EFI variables, or do a recursive delete that goes backwards like "rm -rf .*".

Re:Captain Obvious to the rescue!!!

[Megane]

You're surprised that crappy programmers that don't even think about such possibilities are employed to do BIOS work for motherboard companies?

Gonna get lambasted for this but...

[Narcocide]

Isn't "not running systemd" a good solution?

Re:Gonna get lambasted for this but...

[The Evil Atheist]

Mounting UEFI variables as read only breaks things too. How will you get rid of that problem once you get rid of systemd? Or is everything systemd's fault by default now?

Re:Gonna get lambasted for this but...

[Anonymous Coward]

Isn't "not running systemd" a good solution?

Nope, as it is a bug that affects any OS which mounts uefi variables in read-write. windows, too.

Re:Gonna get lambasted for this but...

[Anonymous Coward]

Windows and other operating systems are also prone to this issue when using UEFI

For this particular issue, no, not running systemd doesn't seem necessarily to be a good solution.

Re:Gonna get lambasted for this but...

[LichtSpektren]

No, because the problem isn't systemd, it's UEFI.

Re:Gonna get lambasted for this but...

[Dolda2000]

While not running systemd is always a good idea, it wouldn't change anything with regards to this, as the EFI variables are in /sys/firmware/efi/vars regardless of what init system you use.

Re:Gonna get lambasted for this but...

[Anonymous Coward]

Nope. Since the issue is with efivars, not any particular init system or system/service manager.

Re:Gonna get lambasted for this but...

[Junta]

Except in windows, you have to be pretty intentional about it. Format C: or recursive delete of all of the drives would not cause this to happen. You have to be on a mission to screw up the system then.

Of course, that's still an issue, but nothing new. Most anything that allows it's firmware to be updated can allow folks to screw it up. All BIOS implementations could be screwed up by a knowledgeable person seeking to inflict pain. The new part is where Linux kernel modeled this data as regular files where unlink() is taken in a vary dangerous way.

Re:Gonna get lambasted for this but...

[Junta]

The problem is less UEFI, more kernel design decision meets occasional real world scenario.

You could do this by writing to CMOS in BIOS. You could do this by writing junk to the BIOS flash space. You just couldn't do so accidentally, and vendor to vendor proprietary interfaces meant the knowledge was less common.

The answer is not to revert to the bad old days of no interoperable access to firmware configuration, but to rethink the interface to avoid this sort of accident.

A follow up is for vendors to explicitly test loss of all EFI variable space that their runtime services allow to be removed.

Re:Gonna get lambasted for this but...

[arth1]

Seems to me that this can be alleviated with selinux. Deny all write access to those paths except when in an explicit context, which the few tools that need that access will have, and even root will have to newrole into to use.

Re:Gonna get lambasted for this but...

[Anonymous Coward]

Or is everything systemd's fault by default now?

Yes, or maybe M$. This is Slashdot after all.

Re:Gonna get lambasted for this but...

[evolutionary]

I've read a few things about systemd that are not entirely positive. There seems to be a religious war about using or not using (and whether it should be optional). The thing is, hindsight is 20/20. When Linux was first conceived (and MS windows for that matter), no one foresaw anything like UEFI. How could they? Well..maybe if you were Nostradamus, but I'm not sure even he predicted this one. (anyone care to check his notes?) A living growing system must adapt to it's environment to survive and Linux (and MS Windows), are "living", growing, changing, evolving system. This is all part of the process. I just wonder how long before some genius says "hey, how about a new status on certain file/file locations that has an additional sudo like layer so people have to confirm this before they potentially nuke a UEFI system"). I'm sure it will happen eventually (hopefully very soon, we've had time to consider this...). I remember reading, "Make an idiot proof system, and the universe will build better idiots.". We'll get through this. Of course deleting things recursively is a dangerous operation and perhaps this is a sign that we should all stop being lazy and remember that "with great power comes great responsibility.". :D

Re:Gonna get lambasted for this but...

[The Evil Atheist]

You have to be pretty intentional to run rm -rf / as root...

Re:Gonna get lambasted for this but...

[Anonymous Brave Guy]

Exactly. The real problem here isn't that root can do stuff. The real problem is that root can do stuff accidentally by sneezing five metres away from the system at lunchtime.

Of course, the other real problem is that anyone is crazy enough to make hardware/firmware where you can delete essential data like this and have no recovery or at least factory reset mechanism, regardless of anything the OS might be doing. People making hardware vulnerable to this should be getting named and shamed as well.

Re:Gonna get lambasted for this but...

[Junta]

No you don't.

rm -rf / tmp/throwawaydir

Re:Gonna get lambasted for this but...

[The Evil Atheist]

Really? How come your system doesn't say you don't have permission to delete / ?

Re:Gonna get lambasted for this but...

[Junta]

Note I've never actually done this, but I'm just saying I can see how someone could end up doing it. Most of us may know better, but that smug sense of knowing better doesn't really help those who will ruin their day beyond any ability for them to recover.

Re:Gonna get lambasted for this but...

[Richard_at_work]

His point was the act does not have to be intentional - never underestimate the power of a finger fuckup... especially when logged in (or using sudo) with enhanced permissions.

Re: Gonna get lambasted for this but...

[Anonymous Coward]

Breaks things how? AFAIK only grub, systemctl reboot and efibootmgr use the efivars. This could be easily solved by having those programs remount efivars writable. They all need sudo anyway.

Re:Gonna get lambasted for this but...

[Ol Olsoc]

Isn't "not running systemd" a good solution?

No, because it is a UEFI problem that can be invoked in Windows also. And last time I checked, Windows doesn't use systemd.

IOW, you could have a nationwide pogrom, summarily shoot the developers and proponents of systemd, make the use of systemd a capital crime, and you'd still have the problem because it is a UEFI problem.

Re:Gonna get lambasted for this but...

[Anonymous Coward]

Most/all recent versions of rm on Linux/BSD/OS X will refuse to remove the root filesystem without the flag -nopreserveroot.

It actually does have to be intentional at this point.

Re:Gonna get lambasted for this but...

[The Evil Atheist]

I wasn't being smug. I was noting that doing something as specific as that while running as root is on par in intentionality as your Windows example. Your comment wasn't helpful either, to say that it's harder to do in Windows.

Re:Gonna get lambasted for this but...

[Ol Olsoc]

Except in windows, you have to be pretty intentional about it.

Yeah, so? I wouldn't doubt there are some bad guys who have some intentions to do it.

I don't know that because it is a tiny little bit harder to do in windows, that it makes systemd the bad guy in a UEFI fault.

Re:Gonna get lambasted for this but...

[The Evil Atheist]

My point is that logging in as root or typing sudo and a password is intentional. You can't accidentally get root permissions. That's why they exist.

Re:Gonna get lambasted for this but...

[Dolda2000]

While that may be true, most systems don't use SELinux, and for fairly good reason if you ask me. I've tried a couple of permutations on the idea, and having several parallel security systems has never really come out as a good thing in the end. Especially one as complex as SELinux.

Re:Gonna get lambasted for this but...

[Junta]

That doesn't mean that a *lot* of people run fast and loose as root. It's a very bad practice, but it shouldn't be *this* bad.

Re:Gonna get lambasted for this but...

[naasking]

no one foresaw anything like UEFI. How could they?

Well that's just not true. IBM PowerPC and Sun Systems hardware had firmware for a very long time. x86 was way behind the curve on this one, and firmware was well understood by then. Perhaps UEFI has its own quirks, but it was hardly novel.

Re:Gonna get lambasted for this but...

[Richard_at_work]

And his point is still not about whether your root permissions are accidental or not, its the accidental space between the '/' and the rest of the path, meaning you end up with 'rm -rf /' bring run, with some garbage data on the end.

The command being run is not the command intended to be run...

Re:Gonna get lambasted for this but...

[The Evil Atheist]

There's no should or shouldn't about it though. It's the root account. By definition, everything the system allows you to do is achievable from that account. The argument should not be "it shouldn't allow you to do that even as root", but "there should probably be higher privileges below root rather than making people go all or nothing". I would agree with the second argument, but I'm the one making it.

Re:Gonna get lambasted for this but...

[omnichad]

cd /tmp
rm -rf throwawaydir

FTFY

Re:Gonna get lambasted for this but...

[The Evil Atheist]

And MY point is that it IS about whether your root permissions accidental or not. I can type rm -rf / tmp by accident right now and nothing would happen because I AM NOT ROOT. I simply cannot trash my hardware in that way without first having intentionally logged in as root or sudo. The comparison is simply moot.

Re:Gonna get lambasted for this but...

[Rockoon]

Mounting UEFI variables as read only breaks things too

...but it doesnt break the hardware.

Re:Gonna get lambasted for this but...

[Anonymous Coward]

or you could try this goodie from Bash back in the day, bit me quite severely:

%~/somedir: rm -rf *

Yeah. It took "*" to mean ".." too.

Re:Gonna get lambasted for this but...

[The Evil Atheist]

And how is still systemd's fault?

Re:Gonna get lambasted for this but...

[Narcocide]

Thank you! This is the informative response I was looking for. I was not actually trolling (this time) but I knew I'd probably be down-modded as such anyway.

Though, that doesn't account for why the /sys/firmware/efi directory isn't even present on my system.

Re:Gonna get lambasted for this but...

[CrashNBrn]

Couldn't PAM be configured to prevent "rm -rf /" ?

Re:Gonna get lambasted for this but...

[Etcetera]

Mounting UEFI variables as read only breaks things too. How will you get rid of that problem once you get rid of systemd? Or is everything systemd's fault by default now?

It's not systemd's fault that the kernel allows access to UEFI variables; it's systemd's fault for mounting those variables in a read/write mode by default and closing the bug WONTFIX because LP didn't think it was a problem. systemd now controls that default, not the distributions, not the writer of the `mount` program, not the initscripts package (on RedHat)... and even /etc/fstab is considered more like a guideline than a rule for systemd to interpret.

As I wrote in a post on that Github bug report that the Great And Powerful Lennart saw fit to remove:

If the authors of systemd didn't want to have to be smack in the [middle] of issues caused by disk mounts, perhaps they shouldn't have assumed disk mounting duties from other projects... nor advocated the removal of the easily adjustable init script which controlled them.

Just a thought.

And furthermore, systemd is keeping it R/W because it's a apparently feature not a bug:

We actually write to the EFI fs in systemd. Specifically, when you issue "systemctl reboot --firmware" we'll set the appropriate EFI variable, to ask for booting into the EFI firmware setup. And because we need it writable we'll mount it writable for that.

Thanks, systemd. This is now the time to point out that /sbin/init didn't need to do sh*t like "boot into the EFI firmware setup" and this is exactly why people with concerns about systemd say that it's doing too much. Putting systemd (either pid1 and/or the package into the whole) in the loop is not necessary and is not a paradigm anyone ever asked for... except the freedesktop.org crowd, and Lennart himself.

Re:Gonna get lambasted for this but...

[sjames]

No, the answer is non-bug ridden EUFI that has a simple sane way to return to factory settings if you wipe the variables. In the BIOS days, no amount of screwing up the CMOS settings would brick the board. Worst case you have to remove the battery for a moment to return to defaults and then re-configure from the CMOS menu. Most boards had a jumper for that as well.

You could brick it by erasing the flash, but that was in no way a usual operation for configuring the machine. Some boards even had a recovery path for that where it would boot from a protected backup flash.

Put a reset to factory jumper on the board and have EFI detect that and replace any existing variables with the factory default and the problem goes away.

Re:Gonna get lambasted for this but...

[phantomfive]

The answer is to include a way in the UEFI to restore the default configuration so something like this doesn't brick it irrecoverably.
Rethinking the interface would be nice, but wouldn't stop malicious users.

Re:Gonna get lambasted for this but...

[benjymouse]

I don't know that because it is a tiny little bit harder to do in windows, that it makes systemd the bad guy in a UEFI fault.

You can not accidentally write to those variables in Windows when trying to format a disk or do other admin work.

The problem is that systemd has put those variables directly in harms way. *Never* would you expect that removing all files from a file system would delete variables outside the operating system - in the firmware.

The file system is *owned* by the operating system, which is a subordinate of the firmware. The control chain goes: firmware > boot-loader > operating system > file system. For the file system to cause damage to the firmware is a design bug, even if the endpoints to do such damage has been exposed by the firmware.

Re: Gonna get lambasted for this but...

[Anonymous Coward]

Breaks things how? AFAIK only grub, systemctl reboot and efibootmgr use the efivars. This could be easily solved by having those programs remount efivars writable. They all need sudo anyway.

There are also "syslinux, "Clover", "sd-boot", "rEFInd" etc. Lots of programs will break, the code changes needed aren't trivial either, and all this for a band-aid that doesn't solve the problem at all. The problem should fixed at kernel level, and there is already a kernel-fix available that doesn't break every boot loader in existence.

Re:Gonna get lambasted for this but...

[Ol Olsoc]

I don't know that because it is a tiny little bit harder to do in windows, that it makes systemd the bad guy in a UEFI fault.

You can not accidentally write to those variables in Windows when trying to format a disk or do other admin work.

can write to those variables in Windows as something malicious.

The tap-dancing to make UEFI an open sore, ready to be exploited, the fault of Systemd, while using weak arguments to make it no problem at all in Windows says a lot. Not much of it very good.

Re:Gonna get lambasted for this but...

[Junta]

Yes, UEFI should be implemented properly (and in fact there are a host of things to allow an implementor to properly protect data they could get broken by, if they can't be bothered to tolerate the data).

However, that's a criticism of vendor implementations of UEFI rather than UEFI itself. Of course one could say that UEFI being so complicated means it's harder to get right, and that would be a valid point. In this particular scenario though, all it would take is for vendors to have standardized on a data format in CMOS in BIOS, and the same thing could have happened in BIOS land (and potentially worse, since in UEFI there's the aforementioned complicated stuff to protect variables, but in a hypothetical old-fashioned BIOS, with standardized CMOS would just be free reign).

Re:Gonna get lambasted for this but...

[Junta]

Yes, that's proper practice. The problem is the punishment for bad practice has not historically included making the hardware inoperable without the intervention of the hardware supplier, who may deem such damage out of warranty.

Re:Gonna get lambasted for this but...

[Junta]

systemd did not do that. The implementations of UEFI that fail to protect themselves given the available mechanisms (yes, UEFI design anticipated just this sort of BS and added yet more complexity to provide for protection), the efivars interface design, the convention of mounting efivars all the time and r/w did that. systemd was following an existing precedent when they did that.

I don't like systemd, not a huge fan of UEFI, but I want to be crystal clear on the specific culprits and how it came to pass.

Re:Gonna get lambasted for this but...

[omnichad]

But this is really an EFI bug as others have said. Deleting those variables should regenerate with default values, not brick the motherboard.

Re:Gonna get lambasted for this but...

[Junta]

That is true. The problem is whether you hold out for the ideal or mitigate the risk of the reality. Of course, if this behavior persists and enough a stink raised, then system vendors might pay attention and test this as a matter of course. Now this won't help if say MSI doesn't care about Linux directly, but MSI probably uses AMI for their firmware, and at least *one* AMI client would hopefully propogate among the vendors.

Re:Gonna get lambasted for this but...

[omnichad]

Now this won't help if say MSI doesn't care about Linux directly

This isn't Linux-only. It's just easier to exploit. All you need is root/admin and direct hardware access and you can overwrite EFI in-OS.

Re:Gonna get lambasted for this but...

[Junta]

Yes, though that ventures into a vulnerability (requires pretty explicit intent) and away from accidental mishap. So in theory should be considered very grave, but in practice the system vendors are even more lax about security issues than things like this.

Re:Gonna get lambasted for this but...

[Anonymous Coward]

You're honestly trying to tell me that RedHat can't change the systemd configuration (or code) to match their desires?

Or that, given the desire to boot into EFI firmware setup, a tool other than init wouldn't have the same problem that systemd does and wouldn't require the same writable filesystem to complete its task? Is your argument that such tools shouldn't exist? Because you didn't make any claims about how this is a problem because the two tools you would have need with sysvinit are now a single tool.

Re:Gonna get lambasted for this but...

[Etcetera]

Or that, given the desire to boot into EFI firmware setup, a tool other than init wouldn't have the same problem that systemd does and wouldn't require the same writable filesystem to complete its task? Is your argument that such tools shouldn't exist? Because you didn't make any claims about how this is a problem because the two tools you would have need with sysvinit are now a single tool.

No, of course a tool like that would have a reason to exist, just like there are OS tools *now* that can flash firmware, reset BIOS variables, or whatnot. (Whether it's secure to have host-OS level access to those types of features is a different, albeit related question, of course...)

The problem is in what you've posted:

a tool other than init

/sbin/init doesn't need to do anything with BIOS or EFI variables; /sbin/init just needs to init. We've already booted.

If there are OS tools (like update_firmware from Dell's OMSA toolkit) requiring more access, then let them handle whatever they need to handle. And if they break, or do something stupid like leave something in read/write mode on the filesystem that can cause you to accidentally accidentally brick your server, then we get to blame them.

We don't want or need systemd to be involved in this, and we really don't want or need the systemd developers involved in this. No one died and made them benevolent dictators over the Linux userspace.

Re:Gonna get lambasted for this but...

[Dolda2000]

That's probably just because you didn't boot in UEFI mode.

Re:Gonna get lambasted for this but...

[Ol Olsoc]

Isn't "not running systemd" a good solution?

No, because it is a UEFI problem that can be invoked in Windows also. And last time I checked, Windows doesn't use systemd.

IOW, you could have a nationwide pogrom, summarily shoot the developers and proponents of systemd, make the use of systemd a capital crime, and you'd still have the problem because it is a UEFI problem.

Thank you systemd haters, who have not taken the place of microsoft shills in modding anything they disagree with as a troll. tl;dr systemd haters = microsoft shills, only unpaid.

Re:Gonna get lambasted for this but...

[Anonymous Coward]

> This is now the time to point out that /sbin/init didn't need to do sh*t like "boot into the EFI firmware setup" and this is exactly why people with concerns about systemd say that it's doing too much.

Really? Cause it sounds like you just found out about it.

Re:Gonna get lambasted for this but...

[Anonymous Coward]

So your post was indeed offtopic to the bug, not sure why you act surprised.

Re:Gonna get lambasted for this but...

[thegarbz]

Systemd is doing nothing here. The problem is not the kernel, it's not systemd mounting read/write, it's not even that you can write a specific program to write / delete these specific variables. It's not a linux problem. It's not even a UEFI problem.

It a specific coding problem from a specific case where the coder of a specific implementation of UEFI exposed variables to the system in ways designed to be written but didn't write a contingency to it being written incorrectly or deleted. It's firmware coding 101 and the person responsible should be castrated and banished to a userspace never to work on something as critically important as a bootloader again.

While you're blaming LP you can also blame my cat, she's meowing right now and I'm sure it's just as much her fault as LP's that a UEFI system is now borked by running a privileged command from an elevated position assisted by a kernel module specifically designed to all it to happen on a system designed (poorly) to have this changeable in the first place.

Re:Gonna get lambasted for this but...

[david_thornley]

There is nothing wrong with having UEFI variables available for read/write. If you're going to screw with them, you have to expect to have to do something special to boot up again if you mess up. What is wrong is having it possible to change UEFI variables to the extent that it's not possible to boot. That's not a systemd problem. Any motherboard that can be effectively destroyed by running software on it has big problems.

If I can remove or reinstall disk drives or RAM or whatever, use a DVD or USB stick or something to boot to the point where I can reinstall the OS, reload all the software I'd installed, and connect to Dropbox for my personal files, it's not actually bricked. These motherboards have a user-accessible brick mode.

Re:Gonna get lambasted for this but...

[Etcetera]

It's a systemd problem because of the defaults that it sets, not because of the buggy implementation.

Y'all are missing the point. There's no good reason for the init system to try to rewrite EFI variables, hence no reason for the init system to force mount efivarsfs into r/w mode. It's an unsafe default and there's absolutely NO reason for an init system to have a care (or a say) about the local policy one might adopt or prefer in dealing with that issue.

The systemd developers have decided to adopt the kitchen sink approach and consume other utilities and processes within the boot system. With the default action here present at https://github.com/systemd/systemd/blob/master/src/core/mount-setup.c#L110 systemd is now involved in complaints about exposing an unsafe mount point by default, and flippantly closing it WONTFIX.

Re:Gonna get lambasted for this but...

[Etcetera]

You're honestly trying to tell me that RedHat can't change the systemd configuration (or code) to match their desires?

Won't, sadly, and for the record... https://bugzilla.redhat.com/show_bug.cgi?id=1304078:

Jóhann B. Guðmundsson 2016-02-02 16:42:09 EST

This got closed as WONTFIX upstream no need to carry on with this here...

Fedora's policy of trying to stay close to upstream is about 15% to blame, and the rest is simply what distros will end up doing: taking the easy path. This is why centralization is a bad thing... It's going from the Bazaar back to the Cathedral in terms of lack of meaningful ability to influence. The "systemd cabal" is exactly that.

Re:Gonna get lambasted for this but...

[david_thornley]

In other words, it's a systemd problem because it doesn't hide the self-destruct switch enough? And that the fact that the motherboard comes with a convenient software self-destruct switch isn't really a problem? Is it a problem with the vendor for not selling these mobos only to supervillains?

Re:Gonna get lambasted for this but...

[Etcetera]

In other words, it's a systemd problem because it doesn't hide the self-destruct switch enough?

Yes. There's a reason Big Red Buttons in datacenters usually have a protective cover on them.

And that the fact that the motherboard comes with a convenient software self-destruct switch isn't really a problem? Is it a problem with the vendor for not selling these mobos only to supervillains?

I've absolutely never said that the motherboard issue isn't a problem. In fact, I'm not sure I've seen *anyone* say that *anywhere* online in this entire debate... What IS a problem is that a random github project has control over the types of things that used to be decided at a much more distributed level. Complaints to distros are now sent upstream, where the self-described cabal decides what does and doesn't fit into their agenda for the Linux userspace.

No one asked for this.

Easy bricking for your convenience

[Anonymous Coward]

Stuff like that makes me long for a write protect jumper on the motherboard again.

Don't put it into the global linux filesystem

[Anonymous Coward]

What are the valid use cases? Can't writing anything to UEFI be done through some other way than the filesystem?
And also UEFI itself is flawed if everything is exposed in a "flat" way like this.

Re:Don't put it into the global linux filesystem

[Junta]

Note that the whole *nix way is 'everything is a file'. So to have it off in a hidden namespace would run counter to that philosophy.

Of course, historically things like devices and such have been special non-regular files. That way rm /dev/sda doesn't do anything freaky. It may be a good idea to rethink firmware data being modeled is plain files, but still be in the discoverable filesystem namespace.

What else did you think would happen.

[Anonymous Coward]

Of all the things you could run that you might expect to 'brick' your system surely 'rm -rf' as root would be the one.

Consequences arise from actions. I hate UEFI as much as the next guy, and don't get me started about SystemD but this looks like click bait.

Damn, got me.

Re:What else did you think would happen.

[Anonymous Coward]

No, I wouldn't expect rm -rf to brick my system. I would expect it to remove everything, and then I'd have to reinstall. I would not expect my computer to become unusable to the point that I couldn't reinstall an OS.

Re:What else did you think would happen.

[Ol Olsoc]

Of all the things you could run that you might expect to 'brick' your system surely 'rm -rf' as root would be the one.

Consequences arise from actions. I hate UEFI as much as the next guy, and don't get me started about SystemD but this looks like click bait.

Damn, got me.

Well, it's kind of clickbait, but its proper nerdish clickbait. It's even a sort of test, if you will. While the systemd haters will automatically jump on another chance to rail on about it, anyone who reads the article will see that it isn't a systemd problem, its a UEFI fault. Because you can make the same thing happen in Windows. A little "harder" and no doubt, but systemd could be wiped off the face of the earth, and not fix the problem.

New Geek meme : Thanks, systemd!

Re:What else did you think would happen.

[itsdapead]

Of all the things you could run that you might expect to 'brick' your system surely 'rm -rf' as root would be the one.

No, you'd expect 'rm -rf /' to hose your linux installation, maybe your data too and require re-installation or restore from backup. That doesn't qualify as bricking.

"Bricking" means corrupting the firmware held in non-volatile memory on your device so it can't be revived without specialist reprogramming equipment - this usually only happens if you botch an attempt to re-flash the firmware.

The term has been watered down and abused as click-bait in the past, but this sounds like the real deal: the claim is that 'rm -rf /' can now permanently erase part of the firmware and make it non-trivial to restore your system. I guess YMMV depending on your motherboard's BIOS-flashing facilities.

Re:What else did you think would happen.

[blue9steel]

I have to agree. Although none of the parties involved are fully responsible, this combination of factors produces a very nasty situation. At the very least an attempt to delete files of this sort should generate a warning and confirmation dialog or require a special switch of some kind.

Re:What else did you think would happen.

[Anonymous Coward]

I have to agree. Although none of the parties involved are fully responsible, this combination of factors produces a very nasty situation. At the very least an attempt to delete files of this sort should generate a warning and confirmation dialog or require a special switch of some kind.

Actually, I do consider the makers of UEFI primarily responsible. Essential system variables should not be stored on the hard drive. Rather they should be put on a ROM chip on the motherboard. The only way it should be possible for these variables to be changed is by re-flashing that ROM; preferably this should only be possible by resetting a jumper on the motherboard. How in the hell they thought storing essential BIOS parameters on the hard drive would be a good idea, I have no idea. This was a spectacularly bad idea and they should have foreseen the consequences from the very beginning. But, unfortunately, we are where we are now....

What the doctor ordered...

[Dolda2000]

so for now there is no good solution to avoid potentially bricking your system

Have you tried not running rm -rf /?

Re:What the doctor ordered...

[Anonymous Coward]

so for now there is no good solution to avoid potentially bricking your system

Have you tried not running rm -rf /?

Shit happens. I once saw a guy accidentally type:

rm -rf / some/random/directory #Note the space after the '/' character.

... just a slip of his thumb but he did it in a root shell and unfortunately for him he was such a fast typer that nobody present could intervene quickly enough.

Re:What the doctor ordered...

[Dolda2000]

I don't want to be that guy, but this is why you
1. Don't type fast when your command starts with rm -rf;
2. Never rm -rf by absolute path at all;
3. Never start typing rm -rf at all, but type the rest of the command first and then edit in the rm; and
4. Don't use root shells, but sudo, and edit in the sudo last on potentially destructive commands.

There may be good reason to break one or more of these rules at one time, but never all four.

Re:What the doctor ordered...

[The Evil Atheist]

Or just use tab autocomplete.

Re:What the doctor ordered...

[Anonymous Coward]

Rule 2 is the winner. There are few, if any, valid reasons for rm -rf by absolute path. If you have to wipe out a whole directory and all its contents from the command line, you should be in its parent or close enough that you can use a relative path.

Re:What the doctor ordered...

[LichtSpektren]

so for now there is no good solution to avoid potentially bricking your system

Have you tried not running rm -rf /?

Shit happens. I once saw a guy accidentally type: rm -rf / some/random/directory #Note the space after the '/' character. ... just a slip of his thumb but he did it in a root shell and unfortunately for him he was such a fast typer that nobody present could intervene quickly enough.

So your complaint appears to be that when one recklessly uses root commands, it should only wipe out all their data, not all their data plus their motherboard? That's not terribly urgent. It'd be like complaining that handguns are too powerful, when I shoot somebody in the head it should only kill them, not kill them and also leave a hole in the wall.

Re:What the doctor ordered...

[Anonymous Coward]

Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab Tab

I saw if you 're not using tab then you get what's coming to you. It not only saves time but it VERIFIES what you're typing is correct. Trying to auto-complete that directory wouldn't have worked, which should have told the user to slow down and take a look at what's wrong.

I've found it's good practice to always add -rf to the end of my remove commands in case you accidentally hit enter you're not going to forcefully remove some parent directory by accident.

Re:What the doctor ordered...

[aliquis]

I didn't followed the idea of someone else who replied to you who suggest to use the path first, and not act fast, and so on.

Anyway I had a keyboard where the shift key didn't worked no longer (back in the days when the keyboard wasn't mechanical.)

I wanted to remove all the files and did rm -rf followed by what was intended to be a * on the numerical keypad but it's not one I use often (maybe I did then to reach directories and type *?), anyway I ended up with a / and that was how that happened. (Return followed quickly because I was done with the line, I though.)

Re:What the doctor ordered...

[l3v1]

Well, shit happens when someone doesn't _read_... It doesn't matter what's the reason, if a line starts with rm I _always_ read the whole line several times before committing, just to be sure. Not surprisingly, no such accidents ever happened to me.

Re:What the doctor ordered...

[Anonymous Coward]

I start every rm -r command with "echo". After it prints properly I remove the "echo".

Re:What the doctor ordered...

[dargaud]

Yeah, and also how about NOT using UEFI and installing your Linux systems in normal mode ? I don't even know if there are advantages to using UEFI on Linux since it's the very first thing I disable when I first boot a system.

Re:What the doctor ordered...

[Anonymous Coward]

I'm not sure why it's an unimagineable usecase that someone may want to remove all the data from a computer without actually destroying the hardware in the process.

Re:What the doctor ordered...

[Anonymous Coward]

you got it wrong.
his intend was to make a hole in the wall ( remove the contents of a given fs )
but he accidentally blew someone's head ( brick his computer )

Re:What the doctor ordered...

[Anonymous Coward]

so for now there is no good solution to avoid potentially bricking your system

Have you tried not running rm -rf /?

There are some sloppy scripts that run 'rm -rf ${var}', and if $var is not tested for emptiness, and the process was spawned in /, then it becomes a problem.

We had a similar case a little while ago where some had something close to the above, but it was done /research/mylab/ and it nuked a bunch of files/directories that were group writable. We had (read-only) snapshots, so it was relatively recoverable, but it with a few hundred terabytes it took a while.

Re:What the doctor ordered...

[Anonymous Coward]

so for now there is no good solution to avoid potentially bricking your system

Have you tried not running rm -rf /?

Obviously, that's the best way, but there is an alternative: Use GNU rm.

This is a modern GNUism of rm, but if you try to do an rm -rf / as root, you get an error:

rm: it is dangerous to operate recursively on '/'
rm: use --no-preserve-root to override this failsafe

You can also try the trick of putting a file called -i in / I can't say every version of rm will like this, but GNU rm has had -i take precedence over -f for a long time, and it will ask. Obviously try this a non critical directory structure before relying on it.

Re:What the doctor ordered...

[Anonymous Coward]

How about "when I shoot someone in the head it should only kill them, not nuke the whole fucking city"? That seems like a considerably more appropriate.analogy. Yours seem quite disingenuous.

Re:What the doctor ordered...

[Anonymous Coward]

Tell yourself that next time someone typed it on your computer while you were away.

This is why you don't let morons design boot partitions.

Re:What the doctor ordered...

[Anonymous Coward]

Just use rm -rfi / you will be prompted then on each file as it gets removed.

Re:What the doctor ordered...

[Anonymous Coward]

The strange thing is that TFA seems to suggest 'rm -rf /' is something that, in the absence of this bug, you might actually want to do.

As a public service announcement, recursively removing all of your files from / is no longer recommended.

For now, be forewarned you probably don't want to rm -rf / your Linux system if using modern UEFI hardware.

It sounds like a joke, but given the source (Phoronix) it's a bit hard to tell.

Re:What the doctor ordered...

[suutar]

More like "when I take the wrong turn at the rental place and run over the tire spikes they should just trash my tires, not melt down my engine block"

Re:What the doctor ordered...

[Anonymous Coward]

and...

5. never make a file named "-rf"

Re:What the doctor ordered...

[Anonymous Coward]

More precise analogy would be, if i shoot someone in the head, the entire apartment block shouldn't be vaporized by the explosion.

Re:What the doctor ordered...

[Anonymous Coward]

# mkdir fubitches
# chattr +i fubitches
# rm -Rf fubitches
rm: cannot remove `fubitches': Operation not permitted

Just make those files chattr +i when not in use and turn it off briefly when write access is required.

Re:What the doctor ordered...

[Anonymous Coward]

Actually, it would work if his pwd was /

Re:What the doctor ordered...

[thegarbz]

Have you tried not running rm -rf /?

Who said the owner of the computer was the one running it?

Re:What the doctor ordered...

[sjames]

You have it exactly backwards. When I use a taser on someone, it should only drop them to the ground, not kill them.

When I rm -rf / a machine, it should leave it ready for a re-install or reload from backups. It should not kill it forever.

Re:What the doctor ordered...

[Anonymous Coward]

Tell yourself that next time someone typed it on your computer while you were away.

This is why you don't let morons design boot partitions.

It's also why you don't leave an unattended moron in the presence of a computer that hasn't been properly secured. Just sayin'.

Re:What the doctor ordered...

[wolrahnaes]

So your complaint appears to be that when one recklessly uses root commands, it should only wipe out all their data, not all their data plus their motherboard? That's not terribly urgent. It'd be like complaining that handguns are too powerful, when I shoot somebody in the head it should only kill them, not kill them and also leave a hole in the wall.

Killing the motherboard is a lot worse than just losing what's on the hard drive. When a hard drive dies (effectively the same result as 'rm -rf /' in a traditional environment in one of my clients' machines I can replace it with a random one from stock and reinstall the OS from a USB stick within an hour. Restore from backup takes whatever time it takes for how much data that machine had over gigabit ethernet.

If an otherwise good motherboard gets nuked, now I have to get parts that may be in a proprietary formfactor, I have to completely pull apart the machine, etc.

For your gun analogy it'd be more like if it brought the whole building down rather than just putting a hole in the wall.

Re:What the doctor ordered...

[mattventura]

Then rm rejects the argument because you have to specify --no-preserve-root in order to actually delete /. You haven't actually been able to rm -rf / for years now.

Re:What the doctor ordered...

[Anonymous Coward]

I read somewhere (can't remember where) that any potentially destructive shell command you should start out with a '#'. It's a good habit.

Re:What the doctor ordered...

[Anonymous Coward]

In the first scenario, I still have hardware that I can recover my backed up data on to...

Re:What the doctor ordered...

[Anonymous Coward]

"/" autocompletes just fine...

Re:What the doctor ordered...

[scdeimos]

It's a fairly significant change of behaviour. There might be valid reasons to issue rm -rf /, such as to erase a system before a clean installation. You should not expect that to erase critical firmware data and brick the motherboard because it's never been able to do that previously. That said if I was erasing a system I'd probably be booting from a LiveCD and reformatting the old sda.

Re:What the doctor ordered...

[LinuxIsGarbage]

I question the benefit of UEFI ever. I understand the intention is to remove limitations resulting from trying to use 1980's based BIOS code 35 years later, but I don't see it solving more problems than it causes. About the only thing I've come up with is allowing boot volumes greater than 2TB, since it allows GPT partitioned disks.

As to why you would run it, for better or worse you may find fewer and fewer systems with Legacy boot mode. Especially with Secureboot

Re:What the doctor ordered...

[Anonymous Coward]

My usual snafu, getting rid of editor backups: rm *~ Be wery wery carefilly here.

Re:What the doctor ordered...

[Anonymous Coward]

I don't want to be that guy, but this is why you

1. Don't type fast when your command starts with rm -rf;

2. Never rm -rf by absolute path at all;

3. Never start typing rm -rf at all, but type the rest of the command first and then edit in the rm; and

4. Don't use root shells, but sudo, and edit in the sudo last on potentially destructive commands.

There may be good reason to break one or more of these rules at one time, but never all four.

One of the things I typically do before recursively removing a bunch of files is to do an "ls" of those files first. If that works as expected, I can redo that command with "ls" changed to "rm -rf".

Re:What the doctor ordered...

[anon mouse-cow-aard]

I don't want to be that guy, but this is why you 1. Don't type fast when your command starts with rm -rf;

I typed this slowly: rm -rf /;

2. Never rm -rf by absolute path at all;

cd /; rm -rf .

3. Never start typing rm -rf at all, but type the rest of the command first and then edit in the rm; and

/<^H><^H>rm -rf ? how does this help ?

4. Don't use root shells, but sudo, and edit in the sudo last on potentially destructive commands.

sudo rm -rf / ? sudo /<^H><^H>rm -rf ?

There may be good reason to break one or more of these rules at one time, but never all four.

There is no substitute for just knowing what you are doing, and not doing the bad thing. I've seen people complicate their lives with incantations, and all it usually does is make it fail in a more complicated way. Simplicity is easier to remember.

Re:What the doctor ordered...

[Anonymous Coward]

and you backup, and you have backups and you have a good backup and you regularly test your backups and you have offsite backups and you have historical backups.

TLDNR: BACK THE HELL UP

Re:What the doctor ordered...

[houghi]

I do number three. Took me a while to get used to it, but now I will type e.g. 'rm * -rf' and that gives me just enough time to realize I am in the wrong directory (because on the wrong terminal or wrong tab) or that I needed to type e.g. 'rm tmp/* -rf'.

Because doing e.g. a tab for completion at the wrong moment can be terrible.

Even not being root, it has saved me a few times. At least several hours of work that would have been lost otherwise.

Re:What the doctor ordered...

[david_thornley]

I'd be a little more confident about that if I always remembered what directory I was in. Have you never been surprised by what pwd prints?

Re:What the doctor ordered...

[allo]

Just try
rm -rf $foo/*

do not forget to set "foo" to a value before ... or else ...

Hall of Shame

[Anonymous Coward]

Just an idea, but perhaps someone should set up a database that accepts failure reports and, consequently, shames all the hardware devs into fixing their (U)EFI implementations.

While I don't agree with mounting efivars rw by default, accidental deletion shouldn't permanently render one's computer an expensive piece of Lego.

I never run rm -rf

[140Mandak262Jamuna]

I always run sudo \rm -rf That is the way to do it, you whippersnappers.

Re:I never run rm -rf

[Anonymous Coward]

I always run sudo \rm -rf That is the way to do it, you whippersnappers.

Funny, except beards still use su. I recall sudo (and PAM) receiving frequent security advisories about 15 years back.

I did run rm -rf as root once, deliberately to see what would happen. Never once have I done it accidentally although most linux distributions now ship with systemd; pretty much the same thing then the one step further of replacing core system programs with crap donotworkalikes!

Re:I never run rm -rf

[Dasher42]

What, sudo and not \sudo? Get off my lawn!

Re:I never run rm -rf

[Anonymous Coward]

Is this guaranteed to work? What if halfway through, rm decides that it needs a dynamic library that it just erased? It's better to boot from a live CD/DVD/USB and erase the hard drive from there.

Systemd developers have rejected

[QuietLagoon]

...Systemd developers have rejected mounting the EFI variables as read-only...

So the sane solution is rejected because the underlying design is bad?

Re:Systemd developers have rejected

[LichtSpektren]

...Systemd developers have rejected mounting the EFI variables as read-only...

So the sane solution is rejected because the underlying design is bad?

systemd isn't in the wrong here. If you make the UEFI variables read-only, you lock down the hardware.

Re:Systemd developers have rejected

[gstoddart]

That's called taking the high-ground because fixing it would violate the elegance of their code, and blaming the underlying stuff as inelegant is just easier.

It's one of those mentalities which leas to "I'd rather fuck up your system and lose your data than put a chink in my perfectly elegant solution which causes the problem".

It seems to me if you can fuck up your system by writing to this stuff, and you sometimes need to write to it, you need to have damned good guard code around it, semaphores, and an actual understanding of what you're supposed to do to lock and unlock it.

If mounting read-only is problematic, and mounting read-write is problematic ... then it seems like the solution needs to understand that, and not simply go with one of the two wrong solutions and insisting the problem lies elsewhere.

Otherwise you're just saying "not my problem", and being a dick over your wrong, but otherwise awesomely elegant code.

UEFI exists as it is, and it isn't up to these guys to decree it should change ... nobody consulted them when they built it, they're not going to consult with them in terms of how not to fuck it up.

Re:Systemd developers have rejected

[LichtSpektren]

It has nothing to do with elegance. Turning UEFI variables into ROM is the equivalent of locking the hardware down. systemd isn't in the wrong here. But judging by your posting history, I guess you would never admit that even when it's blindingly obvious.

Re:Systemd developers have rejected

[Anonymous Coward]

Utter bollocks!

systemd is not in the wrong here and you can blame it all you want (talking about elegant code, I very much doubt you even know how to write code. Probably just a silly old neckbeard who thinks "bash" is the epithome of "low-level coding".

Setting it to ro wouldn't particularly change the attack surface. It's very much security through obscurity.

The real issue here isn't that thick headed people can accidentally brick their mainboard but that someone with malicious intent can gain root access and finish your computer off for good. You think a guy who is able to gain root access to your system is too incompetent to remount that area as rw?

Re: Systemd developers have rejected

[ceoyoyo]

That seems more than a little black and white. Mounting UEFI vars as read only by default, requiring specifically mounting write to change them would solve a lot of problems. Making writing to UEFI not a file system operation would too. You know, like BIOS used to be.

I remember we used to have to write down our hard drive specs because BIOS settings could be overwritten by bad memory accesses. Thank god someone fixed that (and invented auto detection).

Re:Systemd developers have rejected

[Anonymous Coward]

>systemd isn't in the wrong here.

Which is why it happens on ALL linux boxes and not just the ones running systemd.

Oh wait...

Re:Systemd developers have rejected

[gstoddart]

I don't give a crap about systemd ... but at the core here, is someone has written code to work with a system they didn't create, and the solution is apparently to either be wrong by being read-only, or be wrong by being read-write.

What you can't do is say "given that both of these solutions are wrong, I'm going with one and blaming the other".

Yeah, whatever, I don't give a crap -- UEFI is a spec which exists separate from Linux. Either you can work with it as it exists, or you can almost kinda sorta work with it except for the corner case in which you break things.

If "rm -rf" breaking things is "by design", then it's a shitty design because it's incorrectly applying a model to something which clearly doesn't apply. But UEFI isn't going to change because Linux wants it to.

I don't give a shit what component it is, it sounds like it's mode of operation is more nuanced than the either/or bullshit I see here -- if doing it all one way or all another way is defective, the problem lies in insisting it still makes sense to do it all one way or all the other.

Grafting a particular way of doing things on top of things which don't work the way you think it does is YOUR DAMNED PROBLEM ... I don't know if it's the kernel, or systemd, or the complete lack of a coherent way of doing this right.

So, I really don't give a damn about your opinion about my posting history ... what I see is people using UEFI in a way that isn't compatible with it, and refusing to fix it.

Go ahead, brick your system, I don't care. But don't pretend like you can ignore how this mechanism is intended to work ... no matter how broken the underlying system is. UEFI wasn't designed to benefit Linux, it was designed to benefit Microsoft.

If Linux can't work with it without shooting themselves in the foot, that's going to have to be something the Linux community deals with.

If it needs to be locked an unlocked in order to get the semantics right, do that. But don't whine when you decide you're not going to do that and it ends up causing problems.

Re:Systemd developers have rejected

[bluefoxlucid]

The report was that SystemD needs this, but other tools need it too.

Re:Systemd developers have rejected

[QuietLagoon]

...systemd isn't in the wrong here....

I did not say it was.

.
The underlying design of having use cases that need write access to UEFI is the issue.

Re: Systemd developers have rejected

[Junta]

Note this isn't so much a UEFI v. BIOS thing, it's the fact that UEFI standardized an interface for the configuration information, and Linux implemented an interface that modeled it as a normal-as-possible filesystem. UEFI itself doesn't prescribe at all how to model the variables, just defines the interface to allow the kernel to do so.

Re:Systemd developers have rejected

[green1]

How hard would it be to simply mount it as read-only by default, but with the option to re-mount read-write when needed?

This doesn't have to be so black and white.

Re:Systemd developers have rejected

[silas_moeckel]

Your thinking much like the systemd guys that it's a binary thing. It's not. Right now the sane default is the uefi data is read only (and probably limited to root and some selinux lockdown on top of that). While I realize the uefi variables are meant to be non volatile and shared between operating systems reality is today it's dangerous to allow general access to them.

Overall this seems like a firmware issue if the clear cmos jumper does not set all of this back to the factory state it's broken.

Re:Systemd developers have rejected

[Ol Olsoc]

That's called taking the high-ground because fixing it would violate the elegance of their code, and blaming the underlying stuff as inelegant is just easier.

It's one of those mentalities which leas to "I'd rather fuck up your system and lose your data than put a chink in my perfectly elegant solution which causes the problem".

Cool story bro. Now tell us why systemd is responsible for the same action on a Windows machine.

Otherwise you're just saying "not my problem", and being a dick over your wrong, but otherwise awesomely elegant code.

UEFI exists as it is, and it isn't up to these guys to decree it should change ... nobody consulted them when they built it, they're not going to consult with them in terms of how not to fuck it up.

Dayum, I'm going to award you one - no make it two internets. When a person has such hatred for systemd that they make everything it's fault - and I guess by extension the bricking of UEFI on Windows as well is systemd's fault, you sort of bridge the gap between technology and religion.

Re:Systemd developers have rejected

[omnichad]

UEFI wasn't designed to benefit Linux, it was designed to benefit Microsoft.

Secureboot was designed to benefit Microsoft. UEFI benefits everyone. BIOS is slow booting, tedious, and doesn't hand off to the OS fast enough. And it can't boot drives larger than 2TB either.

Re:Systemd developers have rejected

[Anonymous Coward]

Impressive rant. Now, are you even aware that using Windows doesn't make you immune. And how far do you trust Microsoft not to fuck this delicate thing up at some point? Or someone finding a way via Windows?

UEFI is crap, crap, crap and crap. It's utterly broken and failed. The only "benefit" it has is that Microsoft has become the potential gatekeeper for what you're allowed to run on your own computer, and that's it. The sooner people realize that, and start to demand getting the good old BIOS back the better.

Re:Systemd developers have rejected

[suutar]

at least, of having them often enough that "remount as writeable only when needed" isn't viable.

Re:Systemd developers have rejected

[gstoddart]

Now, are you even aware that using Windows doesn't make you immune. And how far do you trust Microsoft not to fuck this delicate thing up at some point? Or someone finding a way via Windows?

Yes. Not in the slightest. Already been done in 20 lines of code as I understood it.

I assume it's exactly as broken as Microsoft designed it to be.

UEFI is crap, crap, crap and crap. It's utterly broken and failed. The only "benefit" it has is that Microsoft has become the potential gatekeeper for what you're allowed to run on your own computer, and that's it.

Sure it is. And when Linux has the clout to get hardware makers to build stuff they want, then feel free.

In the mean time, Microsoft has achieved exactly what they wanted, and if this is causing Linux to break, then Linux people need to deal with it instead of whining about it ... because the reality is Microsoft doesn't give a crap about you, and isn't going to let the UEFI spec change to help Linux.

This is hardly the first time a new piece of technology Microsoft has pushed has proven to be lacking.

You might as well complain that Adobe should finally abandon Flash because it's crap ... it's been crap for 15+ years, but nobody seems overly concerned.

But don't pretend like throwing a hissy fit about how it's broken is going to change the fact that it's broken. Yes, it's broken by design ... but the people who designed it don't give a damn.

Your choices boil down to: implement it in such a way as to make it less broken, or leave it broken. Expecting the spec to change because it's a problem on Linux just won't happen. Because the people who wrote it have no interest in how it impacts Linux.

Re: Systemd developers have rejected

[ceoyoyo]

Absolutely. BIOS wasn't more "locked down" than UEFI just because you couldn't change BIOS settings through a r/w file interface. Maybe a bit more inconvenient for system utility authors, but it seems to me that's a good thing.

Re:Systemd developers have rejected

[gweihir]

That is the way the systemd malware gets developed. Bugs are always other peoples faults and protecting users is not an option.

Re:Systemd developers have rejected

[gweihir]

What do you mean "lock down the hardware"? I expect my hardware to be locked down and not change its settings unless I go to the BIOS set-up. My take is that systemd is very much at fault here for not protecting the user.

Re:Systemd developers have rejected

[sjames]

No, you force root to deliberately remount it rw when (and only when) it is actually necessary.

Re:Systemd developers have rejected

[Anonymous Coward]

BIOS is slow booting, tedious, and doesn't hand off to the OS fast enough

GAH, IT'S NOT FAST ENOUGH!!!, billions of people are gonna die because their smart airbags didn't finish booting!!!!!!!!!!!!!!!!

And it can't boot drives larger than 2TB either

Because 2Tb should be enough for every OS and 2Tb drives are more reliable than larger ones.

Re: Systemd developers have rejected

[phantomfive]

To quote another user:

There was a time not too long ago when malware could be dealt with by "simply" reinstalling the OS. Now malware can infect your PC's firmware, your USB sticks' and hard drives' firmware, make your graphics card go up in flames, and brick your motherboard.

This is a UEFI problem. A person can avoid typing "rm -rf /" but a malicious user should not be able to destroy your system.

Re: Systemd developers have rejected

[Junta]

If they had implemented a 'biosvars' module that understood particular vendor(s) proprietary schemes, then a BIOS system would have the same problem. On the face of it, this is one area where UEFI improved things, having a cross-vendor standard to do something that was formerly proprietary. This enabled a feature that was formerly out of reach for the kernel. The controversy is around how the kernel opted to implement it, and how the convention ended up for that being mounted rw all the time.

My opinion is that unlink shouldn't muck with it. Another opinion is why mount it as a matter of course when it's used very rarely. Another opinion is that it could be mounted RO (though I think you might as well skip mount all together at that point). None of this is really calling out the UEFI layer design as bad (though a vendor's implementation of it may be). There are things to criticize UEFI for (too complex, overthinknig the early boot process, having a relatively huge amount of memory reserved for the sake of runtime services that aren't used that often), but modeling firmware configuration in a cross-vendor way should not be one of them.

Re: Systemd developers have rejected

[Anonymous Coward]

Mounting UEFI vars as read only by default, requiring specifically mounting write to change them would solve a lot of problems.

Mounting efivars as RO will break existing userspace programs and is a crude solution that won't solve the fundamental problem at all. People would still be able to brick their faulty motherboards in various ways, including re-mounting it as RW when using "rm -rf" "just to see what happens".

Making writing to UEFI not a file system operation would too. You know, like BIOS used to be.

The legacy UEFI interface isn't exposed as a filesystem, but that doesn't prevent faulty motherboards from being bricked by a simple variable deletion.

A kernel developer have made a fix that doesn't break userspace stuff.

Re: Systemd developers have rejected

[phantomfive]

If they had implemented a 'biosvars' module that understood particular vendor(s) proprietary schemes, then a BIOS system would have the same problem.

That's true, it's technically a UEFI implementation problem, not a problem with UEFI itself. Especially since other boards don't have this problem. (UEFI being complex lends itself to this sort of problem more easily, but there's not really an excuse for the implementation).

Re:Systemd developers have rejected

[Anonymous Coward]

You neckbeards are pathetic beyond reason.

2TB and four partitions are enough for everybody? Tell that to people with use cases other than gaming and office work.
I currently have 4TB in my desktop.

Accidentally booted up with BIOS emulation (not enabling legacy BIOS support in the UEFI GUI is not enough on some boards. On mine I also have to explicitly tell the bootloader to boot the USB installer into UEFI mode) and installed an MBR scheme to it the first time around, then soon regretted it because I couldn't simultaneously have two OS' on it without running out of partitions.

Really?

[Anonymous Coward]

What happened to booting from CD/usb? How about bringing up a system where all batteries are dead, so there were no power for bios stuff? The latter was a hassle, but you could always get those things going before.

Re:Really?

[Anonymous Coward]

How do you boot from external media prior to POST?

Re:Really?

[Anonymous Coward]

That won't help much when the UEFI parameters for talking to your optical drive or USB ports have been trashed.

Stupid is as stupid does

[Githyanki]

I had to read the article just to see if there was something more to the article than "Dur, dont be stupid".
Nope, nothing to see here. Do not run as root user. Anyone stupid enough to run as root user is going to hose their system by typing a wrong command sooner or later anyways. This article will not help.

Re:Stupid is as stupid does

[kav2k]

We're not talking about hosing the OS. We're talking about hosing the motherboard.

Well... EVERYTHING is a file!

[CajunArson]

You wanted the "everything is a file" UNIX approach*.. well, you got it, including the ability to delete *every* file.

Incidentally, while systemd was being blamed for this, the underlying /sysfs structures have zippo to do with systemd, so put down the pitchforks.

* Which has never actually been completely true but is a popular catch phrase.

Re:Well... EVERYTHING is a file!

[The Evil Atheist]

Basically, bugs are also now part of the filesystem.

Re:Well... EVERYTHING is a file!

[Anonymous Coward]

You wanted the "everything is a file" UNIX approach*.. well, you got it, including the ability to delete *every* file.

rm -rf /dev doesn't delete all my hardware.

Re:Well... EVERYTHING is a file!

[AmiMoJo]

This seems like a problem with the rather simplistic UNIX user account system. Some apps need to write to /efivars, but deleting critical stuff can actually brick some badly implemented UEFI firmwares. So the firmware is broken, but so is the simple system where root can write to anything it likes that is mounted for writing.

On other systems admin accounts are not quite that powerful. They can still accidentally copy a file over /dev/sda, but at least there is an extra step required to do it. Merely being an admin is not enough, you need to ask specifically for permission to do stuff like that. The UNIX method of just relying on root not to make mistakes is risky.

Re:Well... EVERYTHING is a file!

[Anonymous Coward]

It's good that we can't (yet) accidentally delete CPU microcode.

Re:Well... EVERYTHING is a file!

[Anonymous Coward]

You wanted the "everything is a file" UNIX approach*.. well, you got it, including the ability to delete *every* file.

Incidentally, while systemd was being blamed for this, the underlying /sysfs structures have zippo to do with systemd, so put down the pitchforks.

* Which has never actually been completely true but is a popular catch phrase.

NOOOOO! UNIX philosophy is absolutely INFALLIBLE in every scenario! Blame systemd instead, heretic!

Re:Well... EVERYTHING is a file!

[Anonymous Coward]

You wanted the "everything is a file" UNIX approach*.. well, you got it, including the ability to delete *every* file.

Crap, I just deleted my ram. Brb, gotta download more.

Re:Well... EVERYTHING is a file!

[Anonymous Coward]

so, when you delete /dev/dsp, do you expect to not be able to use your audio device ever again, or merely to not be able to open /dev/dsp and write to it until you recreate it?

Re:Well... EVERYTHING is a file!

[Anonymous Coward]

the problem is that it's mounted rw by default. Perhaps booting into into a restricted environment with it mounted ro while that stuff gets updated would have been more appropriate.

Try this!

[Anonymous Coward]

Try running fuk /u

Are systemd devs all retards?

[Anonymous Coward]

This seems irrational:
"Systemd developers have rejected mounting the EFI variables as read-only, since there are valid use-cases for writing to them. Mounting them read-only can also break other applications, so for now there is no good solution to avoid potentially bricking your system, "

Can't you just mount read only anyway? Fuck the broken apps. Does every system have them? It should be my choice but systemd devs are arrogant assholes. Are these "valid use cases" universal?

If Gentoo is ever systemd only I'll be done with Linux.

Re:Are systemd devs all retards?

[green1]

exactly, why not mount them read-only by default, with the ability to re-mount as read-write as needed?

Re:Are systemd devs all retards?

[Anonymous Coward]

You write "This seems irrational:"
then go on an irrational rant. Are you for real?

It has zilch to do with systemd and setting it to read-only isn't a solution (unless you don't want access to efibootmgr and only care about that additional level of security through obscurity), btw. But thanks for playing!

Re:Are systemd devs all retards?

[Anonymous Coward]

Because some implementations fail immediately without RW perms. Instead of going around in circles guessing and offering half-assed solutions, it's time to list the all mobos/laptops where this is a problem. No doubt 99% of the world isn't affected and it's down to one or two shit boards. Then demand answers.

Re:Are systemd devs all retards?

[Anonymous Coward]

How about making them read-only (regardless of mount options) and require specific ioctl calls for modifications? That's much less accident-prone.

Re:Are systemd devs all retards?

[LichtSpektren]

This seems irrational: "Systemd developers have rejected mounting the EFI variables as read-only, since there are valid use-cases for writing to them. Mounting them read-only can also break other applications, so for now there is no good solution to avoid potentially bricking your system, "

Can't you just mount read only anyway? Fuck the broken apps. Does every system have them? It should be my choice but systemd devs are arrogant assholes. Are these "valid use cases" universal?

If Gentoo is ever systemd only I'll be done with Linux.

wtf is wrong with you? systemd should break a fair number of programs to prevent idiots from bricking their system by running self-destructive commands? I bet if it was the other way around, you would complain that systemd breaks programs by loading UEFI variables as ROM.

Re:Are systemd devs all retards?

[Anonymous Coward]

This is the philosophy of non-system-programmers: "I'll chmod 777 everything because sharing and writablilty and freedom!" Even seasoned Windows admins don't make this kind of mistake.

Re:Are systemd devs all retards?

[gweihir]

Because, you know, that would mean systemd protecting users from some bug that is not theirs. They don't do that and screw the user.

Re:Are systemd devs all retards?

[Anonymous Coward]

This seems irrational:
"Systemd developers have rejected mounting the EFI variables as read-only, since there are valid use-cases for writing to them. Mounting them read-only can also break other applications, so for now there is no good solution to avoid potentially bricking your system, "

Can't you just mount read only anyway? Fuck the broken apps. Does every system have them? It should be my choice but systemd devs are arrogant assholes. Are these "valid use cases" universal?

If Gentoo is ever systemd only I'll be done with Linux.

1. systemd only mount "/sys/.../efivars" as read-write because the distro tells it so. If the distro wanted systemd to mount "efivar" read-only, they could just tell it so by generating the proper fstab file.

2. Mounting efivar as read-only breaks userspace big-time, like in breaking the ability to update the kernel (and boot loader).

3. Gentoo and OpenRC also mount efivar as RW. But whether you use OpenRC or systemd, you always have personal choice in mounting efivar as RO. Just deal with the userspace breakage yourself, or file a RFE at your distro bug-tracker.

4. Mounting efivar as RO is a stupid idea that won't prevent people from bricking their faulty motherboards. There is already a kernel-patch that solves most problems without breaking userspace tools.

Re:Are systemd devs all retards?

[rahvin112]

No. But the people that wrote UEFI are evil fucking bastards.

Re:Are systemd devs all retards?

[Anonymous Coward]

So you're advocating that systemd just arbitrarily break user-space applications that used to work, because fuck them?

Isn't that exactly the sort of thing that you'd be the first to lead a lynch mob against the systemd developers for?

Re: Are systemd devs all retards?

[Anonymous Coward]

Lol you're a retard!

Re: Are systemd devs all retards?

[Anonymous Coward]

Fuck every program. Not my problem. Systemd itself is just as likely to brick my system when some shit pottering code deletes the files.

Re: Are systemd devs all retards?

[Anonymous Coward]

Yes. Fuck any pile of modern desktop shit built on this uefi and systemd shit nobody asked for.

Re:Are systemd devs all retards?

[Anonymous Coward]

exactly, why not mount them read-only by default, with the ability to re-mount as read-write as needed?

Here is my suggested solution:

First, in the best of all possible worlds, UEFI would be scuttled and we would go back to storing these essential system variables in ROM on the motherboard which could only be accessed by physically resetting a jumper on the motherboard. Assuming one doesn't want to follow this sane advice, make a separate password-protected partition which is mounted read only where these essential system variables would be stored. Then the only way these system variables could be accessed would be by remounting that partition as read/write. While I still think this is completely insane, it is apparently less insane that what we have now.

Just my $0.02 worth....

Re:Are systemd devs all retards?

[david_thornley]

Anyone ever heard of personal responsibility around here? When you mistype something, it should not only brick your computer but put sugar in your gas tank and start an Ashley Madison account for your wife. We don't need any big brother around here.

low SNR these days on /.

[bill_mcgonigle]

The

Re: low SNR these days on /.

[bill_mcgonigle]

@whipslash - can we get a fix to the submit button location on the mobile layout so that a double-tap on the spacebar on Android that's 2mm too far to the right doesn't hit ->| (close keyboard) and Submit?

Re: low SNR these days on /.

[Pikoro]

That is because your keyboard is part of systemd.

Re: low SNR these days on /.

[fahrbot-bot]

@whipslash - can we get a fix to the submit button location on the mobile layout so that a double-tap on the spacebar on Android that's 2mm too far to the right doesn't hit ->| (close keyboard) and Submit?

No. There are valid use-cases for that and changing it might also break other applications, so for now there is no good solution to avoid potentially submitting unintentionally. [ Just getting ready for when /. is folded into systemd. :-) ]

Re: low SNR these days on /.

[vandamme]

I suppose next you'll be wanting an edit button. Well, beat it and go to ZDNet. We always do things perfectly the first time around here.

Re:low SNR these days on /.

[Anonymous Coward]

Nice article...!

Re:low SNR these days on /.

[Anonymous Coward]

Nice article..!

Well, what did you expect...

[Anonymous Coward]

...so for now there is no good solution to avoid potentially bricking your system...

That's why most versions of rm feature a --no-preserve-root option that is required if you issue that specific command. If you really want to remove all files on a the root partition, use the --one-file-system argument, or just don't do that.. ever... formatting the partitions is a much simpler solution.

Most motherboards now offer some type of "BIOS recovery" (their words, not mine.) This allows the board to be brought back to factory state regardless of the contents of flash,nvRAM. Typically the restore software is in mask rom, and can't be written to.

Linux is a fragile house of cards

[Osgeld]

And its by ignorant design mostly

for example last night I removed the soduku game that came with my distro, thanks to its dependency tree and debian / ubuntu's package management removing this one stupid game took half of XFCE with it, and I was left with a command prompt

say what you want about windows, it doesnt fuck the entire system if I uninstall solitaire

Re:Linux is a fragile house of cards

[Anonymous Coward]

Maybe Linux isn't for you.

Re:Linux is a fragile house of cards

[LichtSpektren]

And its by ignorant design mostly

for example last night I removed the soduku game that came with my distro, thanks to its dependency tree and debian / ubuntu's package management removing this one stupid game took half of XFCE with it, and I was left with a command prompt

say what you want about windows, it doesnt fuck the entire system if I uninstall solitaire

You're a fucking idiot. Whenever you install or remove something with apt, it tells you exactly what's going to be removed with it. So you chose to blindly ignore the warning prompts and wiped out your DE in spite of it. The exact same thing happens if you randomly delete folders in your Win32 folder as well.

You could've avoided it by carefully using apt flags, but again, you're a fucking idiot.

Re:Linux is a fragile house of cards

[Anonymous Coward]

You could've avoided it by carefully using apt flags, but again, you're a fucking idiot.

A user shouldn't need to do that. It should be smart enough to know that other things are using it as a dependency and be smart enough not to remove those things.

It's a shitty design.

Re:Linux is a fragile house of cards

[LichtSpektren]

You could've avoided it by carefully using apt flags, but again, you're a fucking idiot.

A user shouldn't need to do that. It should be smart enough to know that other things are using it as a dependency and be smart enough not to remove those things.

It's a shitty design.

A newbie user shouldn't be fiddling with their packages from the terminal either. Ubuntu comes with a software center that allows one to easily add and remove software without this happening to you.

Re:Linux is a fragile house of cards

[segedunum]

How about you can the fucking idiots who modded this shite 'insightful' read the summary and TFA - or is that too much to ask? Silly me. It's Slashdot.

Re:Linux is a fragile house of cards

[Anonymous Coward]

And you're more of a fucking idiot.

There is no reason to suppose that removing a game should remove much more than the game (maybe a library or two used only by the game, but that's it).

No sane package management system would do things this way.

This has bit me too, but I noticed that the list of things to remove was way longer than it should have been and stopped it, but it wa something like remove a small application and have it want to remove things that were fairly important.

Re: Linux is a fragile house of cards

[ceoyoyo]

No, he's not an idiot. He's a normal person. Normal people click uninstall and expect their game to be uninstalled, not their OS's GUI. Linux package managers are well overdue for redesign. Making hardware brick able by software is also bad design. Mounting firmware as ordinary rw files, ditto.

Re:Linux is a fragile house of cards

[Feral Nerd]

And its by ignorant design mostly

for example last night I removed the soduku game that came with my distro, thanks to its dependency tree and debian / ubuntu's package management removing this one stupid game took half of XFCE with it, and I was left with a command prompt

say what you want about windows, it doesnt fuck the entire system if I uninstall solitaire

I'm not a fan of the Debian packaging system but it's not that bad. You must ether have done something really wrong or you are just really bad at trolling. For one thing apt-get tells you what it is going to remove so if you blindly accepted you have only yourself to blame. Secondly I'm having a hard time believing that apt-get would actually uninstall that many packages for such a trivial program.

Re:Linux is a fragile house of cards

[The Evil Atheist]

But Linux was working, right? So it didn't fuck up Linux, nor the base Debian/Ubuntu install. It fucked up XFCE, which is something that is an unfortunate side effect of having the user interface as an uninstallable add-on. The fact you use XFCE on Ubuntu means you chose that desktop environment by choice. Would you rather Linux make it easier for you by forcing you to use KDE 4.0 (or Gnome 3), say, so that it can't be uninstalled by accident?

Re: Linux is a fragile house of cards

[LichtSpektren]

No, he's not an idiot. He's a normal person. Normal people click uninstall and expect their game to be uninstalled, not their OS's GUI. Linux package managers are well overdue for redesign. Making hardware brick able by software is also bad design. Mounting firmware as ordinary rw files, ditto.

Well, there's two problems with that. One is that he explicitly stated he was using Ubuntu, which comes with a GUI software center. However, he decided to use the terminal anyway, which leads to our second problem: apt will explicitly tell you what you're going to remove whenever you run sudo apt-get remove foobar, and he ignored it and ran it anyway. Which is his right, but one should be aware that anybody can do the same thing in OS X and Windows, so this isn't a problem with Linux so much as stupidity.

Re:Linux is a fragile house of cards

[LichtSpektren]

And you're more of a fucking idiot.

There is no reason to suppose that removing a game should remove much more than the game (maybe a library or two used only by the game, but that's it).

No sane package management system would do things this way.

This has bit me too, but I noticed that the list of things to remove was way longer than it should have been and stopped it, but it wa something like remove a small application and have it want to remove things that were fairly important.

The very first distro I used was Xubuntu. And like our GP, I wanted to remove some of the unnecessary games that came with the distro, so I too used sudo apt-get remove in order to do so. And I have absolutely no recollection of the entire DE being dependent upon sudoku. So it sounds like the GP is just making shit up. Even if he wasn't, he was still a numbskull, but he probably did make it up.

Re:Linux is a fragile house of cards

[Anonymous Coward]

and yet every single "how to do X in linux" tutorial starts by telling you to open a terminal and type sudo XYZ

Re:Linux is a fragile house of cards

[Anonymous Coward]

You could've avoided it by carefully using apt flags, but again, you're a fucking idiot.

A user shouldn't need to do that. It should be smart enough to know that other things are using it as a dependency and be smart enough not to remove those things.

It's a shitty design.

The system IS smart enough. Even if the only reason XFCE was installed for was sudoku it won't be uninstalled until you say yes to 'delete no longer used dependencies'.

Using sudoku to install the desktop environment of your choice is also kind of baffling. The dektop environment is usually flagged 'manually installed' and a short search in the package tree shows that no suduko in the repository depends on a window manager or desktop. Either there is a totally broken debian based distro out there or the story is made up.

Re:Linux is a fragile house of cards

[Anonymous Coward]

No, you're the idiot, because

1. you can't see WHY a newbie user shouldn't be subjected to the nonsense of losing half of the desktop due to uninstalling a game.
2. you demonstrated your ignorance and stupidity by abusing him for a perfectly reasonable point.

Kindly crawl away and die. We don't need your sort in the Linux community.

Re:Linux is a fragile house of cards

[Anonymous Coward]

It's not a shitty design of Linux. It has nothing to do with design of Linux. It's the fault of the packaking of the software. If what you say really is the case then someone fucked up by packaging the solitaire as a requirement for XFCE. So a fault in execution, not in design.

Re: Linux is a fragile house of cards

[Anonymous Coward]

+2 Insightful? WTF? This simply cannot be true, unless xfce was only installed because you requested solitaire be installed. You must have done something truly awful to delete your whole GUI environment by removing solitaire.

Re: Linux is a fragile house of cards

[AmiMoJo]

Linux package managers are well overdue for redesign.

I'm sure Pottering will oblige in due course.

Re:Linux is a fragile house of cards

[Anonymous Coward]

Oh yeah, heaven forbid you want to uninstall the built-in crappy calendar orage. It's a required of the xfce desktop. You kill it, your desktop is GONE.

Re:Linux is a fragile house of cards

[Anonymous Coward]

The concept of dependencies – especially when functionally entirely independent – is nonsense and needs to be changed. It is also an opportunity for bad apps to achieve immutability, that is, if newbs won't remove them for fear of losing their GUI as a consequence.

Mr. Shuttleworth: So you say you don't want Amazon Search on your system? Ha ha ha!

Linux Newb: But Mr. Shuttleworth, I thought Linux was about freedom and such, configurable to my liking! Pleeeease!

Mr. Shuttleworth: Ha ha ha... Lets see you configure things at the command line.... Ha ha ha.

Linux Newb: Gee, all this Linux stuff reminds me of Windows. Maybe I'll just try BSD.

Poettering: Noooooooooooooooooo!

Re:Linux is a fragile house of cards

[Anonymous Coward]

It is theoretically possible that this happened.
Say the game was installed through some meta package that depends on lots of stuff but contains nothing. Lets call it "xfce-desktop" or something.
Uninstalling the game will then take the meta package with it because it's dependencies will no longer be fulfilled.
Now that meta package was the only thing that depended on a lot of other packages. So they can be and will removed if you do not tell apt not to.

Re:Linux is a fragile house of cards

[evolutionary]

Which distro was it? Ubuntu, Debian, Mint, another? It could be integrated as a gnome dependency but that seems strange. There are many flavors and it's possible not all of of them do this (I may try on virtual OS's just to confirm). Yes, it is illogical, but being open source + community driven, we have the ability to change it, either in code for submissions, or in bug reports. The thing about MS (Especially Windows 10 which sends data about you which is hard-impossible for a non-techie especially in Home edition to block/shut off and even Windows 7/8 may have their systems hijacked if they don't disable Windows updates in the "Services" and now there is no description in new updates so you have no clue what they are doing until it's too late..), is if the community says something is bad/irritating, MS says politely "f** you". With Linux distros, you have a chance of being heard. The only way MS hears anything, is if given an "offer you can't refuse" by the US government, or if everyone stops using MS Windows. (which while there is chance is happening with more Android/iOS/MacOS/Linux users leaving MS in disgust as they realize there ARE choices), is happening at a snail's pace. So it's your choice: Go with an OS where your opinion might matter, or with an OS that couldn't care less because they still think you are beholden to them.

Re: Linux is a fragile house of cards

[Anonymous Coward]

I've managed to mess up systems real badly by using aptitude and blindly accept conflict resolutions that involved removing and downgrading packages (or leaving dependencies unresolved). But that only happened because I thought I was smarter than apt-get (package xxx could not be installed? Bah! aptitude will fix that)...I had backups anyway.

I've never seen systems get messed up because of trivial apt-get operations otherwise (dist-upgrade between different versions is always hit-or-miss, though).

I have, however, seems windows systems become stuck in a reboot loop after a routine windows (critical) update, which is no fun to solve because you don't even get a console, or logs or anything. Not even live CD with some basic rescue utilities. Knoppix has saved my arse countless times in those situations.

Re:Linux is a fragile house of cards

[Anonymous Coward]

That didn't happen, unless you had installed your desktop environment by pulling it in automatically when you installed the game. Even then it would have taken an explicit instruction to the package manager to remove packages that are no longer required by other packages. There are lots of problems with package management, but what you describe is not among them.

Back on topic, the UEFI debacle is obviously due to the firmware relying on externally modifiable data in a way which causes unrecoverable problems if that data is deleted or mangled. Even root should not be able to shoot themselves fatally in the foot by deleting every piece of configuration data that root can access. The worst that should happen is that the system comes up with a factory default configuration. UEFI is horribly designed and implemented worse.

Re:Linux is a fragile house of cards

[amiga3D]

Well I gotta tell you I've seen programs removed and suddenly the system would not boot on Win7. Seems the uninstaller took a few system files with it. Shitty developers can fuck up absolutely anything.

Re:Linux is a fragile house of cards

[LichtSpektren]

and yet every single "how to do X in linux" tutorial starts by telling you to open a terminal and type sudo XYZ

Are you sure you want to say every single? Because that leaves you open to a lot of counter-examples wrecking your case.

Re:Linux is a fragile house of cards

[LichtSpektren]

Oh yeah, heaven forbid you want to uninstall the built-in crappy calendar orage. It's a required of the xfce desktop. You kill it, your desktop is GONE.

I'm just curious what OS you think *isn't* guilty of this. Guess what happens if I try to uninstall the taskbar from Windows or the Apple menu from OS X? Oops, my whole GUI is wiped out; the OS probably wouldn't even boot at that point.

Re:Linux is a fragile house of cards

[Anonymous Coward]

I think what he did was remove the games package, which probably marked the xubuntu-desktop metapackage for removal too (games being a dependency of the metapackage which, by design, has dependencies on ALL of the xubuntu/xfce packages). Removing the metapackage made all packages it depended on i.e. most of the xfce into "automatically installed and no longer needed packages" which the OP probably removed by naively issuing an && sudo apt-get -y autoremove to clean up the dependencies of the sudoku, but ended up getting way more.

OP should have
*known what the fuck they were doing on the command line before doing it
*know how the package management works
*how dependencies and metapackages work
*don't use the -y option for anything auto
*pay some fucking attention when you see more packages marked as remove than you bargained for and use ctrl+c to kill the apt-get command before it completes
*just left sudoku installed. It probably took a few KB of hard drive space for the executable and *maybe* some sort of libsudoku or something like that.

Re:Linux is a fragile house of cards

[Qbertino]

Yepp, Some package managers are on crack too often.

Debian Stable removes the network stack by default if you uninstall the Gnome GUI. Fucked up my day when I was doing a server-install and just wanted to ditch the GUI as a last move. Since then I always leave the GUI installed - even though that's actually pretty retarded for a Linux Server Host. ... But that's Debian for you.

Re:Linux is a fragile house of cards

[LichtSpektren]

Well I gotta tell you I've seen programs removed and suddenly the system would not boot on Win7. Seems the uninstaller took a few system files with it. Shitty developers can fuck up absolutely anything.

A particular example of this is some nasty rootkit that comes (came? Not sure if they still do this) with Adobe Acrobat for Windows. The purpose of the rootkit is (was) to prevent people from pirating the software, but if it was tampered with or improperly deactivated, it had a tendency to throw a wrench into the entire booting process.

Re: Linux is a fragile house of cards

[Spacelord]

> No, he's not an idiot. He's a normal person. Normal people click uninstall and expect their game to be uninstalled, not their OS's GUI

No he's not an idiot, a fucking liar is what he is. There is no way that in any package management system XFCE would have a dependency on a Sudoku app, if anything the dependency would be the other way around. So no, removing Sudoku would never result in XFCE being deleted. Not even Ubuntu would be that stupid.

Re:Linux is a fragile house of cards

[PantherX]

The replies to this comment are why a lot of level headed people who don't use Linux, never will and those who do, won't use Internet forums.

Re:Linux is a fragile house of cards

[blind biker]

Sorry, but the package manager's behavior in this instance is indefensible. It absolutely positively shouldn't fuck with XFCE just to remove an app.

Re:Linux is a fragile house of cards

[serviscope_minor]

for example last night I removed the soduku game that came with my distro, thanks to its dependency tree and debian / ubuntu's package management removing this one stupid game took half of XFCE with it, and I was left with a command prompt

Which distro, and what system did you use to tell it to uninstall the package? And did you file a bug report?

say what you want about windows, it doesnt fuck the entire system if I uninstall solitaire

Neither does Linux. I've never had such a thing happen. I've had plenty of fucked windows installs on the other hand...

Re: Linux is a fragile house of cards

[Anonymous Coward]

I know you fanboys love Linux, but calling someone a liar for sharing their negative experience really is taking that to douchebag extremes. I mean, way to prove that Linux fanboys are all wankers.

Since I don't love Linux, I only have to use it, I can confirm that this sort of thing is exactly the kind of shit that Linux pulls on you all the fucking time, and if you're some kind of Linux genius you can probably figure out why it happens and fix it, but short of the requisite 10,000 hours you're fucked, which is why Linux on the desktop is still a complete joke.

Re: Linux is a fragile house of cards

[Anonymous Coward]

Why in the world are you installing the desktop in a server install in the first place? You have to manually select to install it using the text based installed...

Re: Linux is a fragile house of cards

[LichtSpektren]

Windows and OS X on the desktop are also jokes because when I accidentally (read: recklessly type shit into the command line) remove software, I get all sorts of problems.

Also, trucks aren't ready for the road because when I tear out pieces of the engine nondiscriminately, sometimes it doesn't turn on anymore.

Re:Linux is a fragile house of cards

[LichtSpektren]

Sorry, but the package manager's behavior in this instance is indefensible. It absolutely positively shouldn't fuck with XFCE just to remove an app.

Rest assured that the GP is probably full of shit.

Re:Linux is a fragile house of cards

[Anonymous Coward]

There are two reasons for that. Firstly, it's a choice between text and screenshots, and GUI interfaces have a tendency to change. Second, the text commands tend to be more broadly useful -- there are a dozen or more desktop environments and god knows how many distros, but there are far fewer differences from the command line perspective.

$ sudo test
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

        #1) Respect the privacy of others.
        #2) Think before you type.
        #3) With great power comes great responsibility.

There isn't really a way to idiot-proof a command line, especially with effective root permissions. Should sudo warn you on each use? Should every tutorial have the disclaimer that "FYI an errant keystroke will hose your system" ? And out of curiosity, is it possible to do more or less the same thing with cmd.exe/PowerShell?

Re:Linux is a fragile house of cards

[LichtSpektren]

Yepp, Some package managers are on crack too often.

Debian Stable removes the network stack by default if you uninstall the Gnome GUI. Fucked up my day when I was doing a server-install and just wanted to ditch the GUI as a last move. Since then I always leave the GUI installed - even though that's actually pretty retarded for a Linux Server Host. ... But that's Debian for you.

That's because the network stack is built into GNOME, considering it's meant to be manipulated through its GUI. You could've prevented this by (1) checking what you were removing before you went through with it [as apt will clearly warn you of], (2) keep a secondary network stack installed in fact the first malfunctions, and (3) using system snapshots as something to rollback to if you're displeased with some changes you make.

Re:Linux is a fragile house of cards

[peppepz]

Boy, Windows is so advanced that it fucks itself in the background, while you use it - no need to uninstall solitaire.

Re:Linux is a fragile house of cards

[Ol Olsoc]

say what you want about windows, it doesnt fuck the entire system if I uninstall solitaire

They do that with updates.

Re: Linux is a fragile house of cards

[Feral Nerd]

I've managed to mess up systems real badly by using aptitude and blindly accept conflict resolutions that involved removing and downgrading packages (or leaving dependencies unresolved). But that only happened because I thought I was smarter than apt-get (package xxx could not be installed? Bah! aptitude will fix that)...I had backups anyway.

I've never seen systems get messed up because of trivial apt-get operations otherwise (dist-upgrade between different versions is always hit-or-miss, though).

I have, however, seems windows systems become stuck in a reboot loop after a routine windows (critical) update, which is no fun to solve because you don't even get a console, or logs or anything. Not even live CD with some basic rescue utilities. Knoppix has saved my arse countless times in those situations.

I've also seen Windows get 'bricked' after an update as well as 'OS X'. That's 'bricked' from a normal user's point of view, I could usually fix the problem but then I have a CS degree. The same has happened with Linux boxes (i.e. 'bricking' that was fixable with a high degree of computer knowledge) but it's quite rare that it's so bad I can't even boot to command line. These days the most irritation I get from Linux is annoying glitches and bugs that are mostly due to poor quality control but that also depends on the distribution. Some distributions are way better at quality control than others.

Re:Linux is a fragile house of cards

[Osgeld]

guess what, I used the little ubuntu software center to uninstall it

Re:Linux is a fragile house of cards

[Osgeld]

xbubtu and the ubuntu software center

Re:Linux is a fragile house of cards

[LichtSpektren]

guess what, I used the little ubuntu software center to uninstall it

And what version of Xubuntu was this?

Re: Linux is a fragile house of cards

[AmiMoJo]

I've had that happen before, many years ago, with some other bit of software. You have to have the package manager remove old dependencies that it thinks are no longer required. Here's someone on the Ubuntu forum with a similar issue: http://askubuntu.com/questions...

I imagine the GP was trying to free up some space so asked for old packages that were no longer needed to be removed, and the package manager just decided to delete everything it had previously marked as no longer required. The correct behaviour would be to re-check all dependencies first, which I'm sure you can manually force somehow but that doesn't excuse this.

Re:Linux is a fragile house of cards

[Osgeld]

Xubuntu 14.04.3 LTS

Re:Linux is a fragile house of cards

[TangoMargarine]

*pay some fucking attention when you see more packages marked as remove than you bargained for and use ctrl+c to kill the apt-get command before it completes

I tried that once and it was pretty much the equivalent of shooting my package manager in the head. I ended up with a number of packages with conflicting versions that it couldn't figure out how to resolve, and I didn't know how to fix.

Don't do that unless your beard is sufficiently long.

Re:Linux is a fragile house of cards

[Anonymous Coward]

Agreed.

``sudo apt-get remove blah'' should remove blah, and if nothing else is using them, dependencies associated with blah. It's crazy to nuke dependencies which are still in use by other parts of the system. I shouldn't need to use a flag to make that behaviour happen. That should be default.

Re:Linux is a fragile house of cards

[omnichad]

On at least Windows 7, you can get rid of the shell and it will still boot. You can open task manager with CTRL+ALT+DEL and launch programs. When you minimize a program, it goes down in the corner as a little bar just like it did in Windows 3.1

As late as XP, you could set progman.exe as your shell...which was weird.

Re:Linux is a fragile house of cards

[LichtSpektren]

Xubuntu 14.04.3 LTS

OK, now I know you're full of shit. There's no dependencies on sudoku in Xubuntu 14.04.

Tried it in the software center, too. There's no dependencies.

Re:Linux is a fragile house of cards

[LichtSpektren]

On at least Windows 7, you can get rid of the shell and it will still boot. You can open task manager with CTRL+ALT+DEL and launch programs. When you minimize a program, it goes down in the corner as a little bar just like it did in Windows 3.1

As late as XP, you could set progman.exe as your shell...which was weird.

I didn't say crash explorer and dwm, I said uninstall it.

Re: Linux is a fragile house of cards

[Anonymous Coward]

Snappy should fix this no?

Re: Linux is a fragile house of cards

[LichtSpektren]

> No, he's not an idiot. He's a normal person. Normal people click uninstall and expect their game to be uninstalled, not their OS's GUI

No he's not an idiot, a fucking liar is what he is. There is no way that in any package management system XFCE would have a dependency on a Sudoku app, if anything the dependency would be the other way around. So no, removing Sudoku would never result in XFCE being deleted. Not even Ubuntu would be that stupid.

I can confirm this is the case: http://s23.postimg.org/yxo666n...

Re:Linux is a fragile house of cards

[omnichad]

I didn't say crash explorer and dwm, I said uninstall it.

You said uninstall the taskbar. The only way to uninstall explorer.exe is to delete it and set the shell to something else (or blank). Windows will still boot. DWM isn't responsible for the task bar and has nothing to do with the discussion.

Re:Linux is a fragile house of cards

[Osgeld]

all I can tell you is that was the only thing I uninstalled, rebooted and im at a command prompt

Re:Linux is a fragile house of cards

[Anonymous Coward]

The difference is between an app and a (GUI) system component removal - the former should not have the impact that the latter does. I have seen this on several Ubuntu versions over the years when I wanted to get rid non-English fonts and other such language-related items I would not ever use to reduce update volume/frequency/directory clutter, and so forth. I was greatly annoyed to see the proposed list of components to remove did indeed include important pieces of the DE that I realized would break it badly if removed, so I had to quit that notion in those situations, and leave all those useless language bits littered all over my system directories.

Now if it was one particular app having that impact, I would just rename it, and/or turn off its execute bits.

One definitely needs to look before leaping with such actions (i.e. check the list of components to be removed before proceeding)!

YMMV

Re:Linux is a fragile house of cards

[LichtSpektren]

all I can tell you is that was the only thing I uninstalled, rebooted and im at a command prompt

Show me your syslog and I can tell you what happened. But your anecdote, as reported, is inaccurate: uninstalling sudoku had nothing to do with your DE getting fudged.

Re: Linux is a fragile house of cards

[ceoyoyo]

Assuming you mean Ubuntu Snappy, kinda. The transactional updates will let you roll back changes (which is awesome) but it doesn't really fix the fact that package managers shouldn't be doing stupid stuff like that in the first place. The new package managers coming out of the major distros should hopefully fix a lot of the problems with the old ones.

Re: Linux is a fragile house of cards

[ceoyoyo]

It's a little worse than that. At least on Ubuntu, the package manger is pretty aggressive about removing old stuff. When you install or uninstall a package it mentions that it found all this old cruft, and would you like to remove it (Y/n)? A regular user is pretty likely to just say yes. You don't need to specifically be trying to free up space.

Re: Linux is a fragile house of cards

[ceoyoyo]

I doubt very much he told apt to remove his window manager. The apt system (either apt itself or some Ubuntu package(s)) has some buggy bits that don't do so well keeping track of dependencies. As someone else pointed out, this is probably the code that looks for unneeded libraries. The OP wanted to remove his game, but apt said "by the way, here's some other stuff I found that you don't need anymore, want me to remove it?" and the OP hit yes (sounds like a good idea, no?).

You can't do the same thing in OS X. I don't know about Windows. The app store can't remove or modify system files unless you're explicitly installing an OS upgrade.

In general, programs on the Mac are much more self-contained, at the expense of a bit of replication of libraries. The OS X bundle/framework paradigm is excellent, and well worth copying. I'm not sure what app store Windows does, but in the past this kind of problem in that OS was known as "dll hell." Linux has much of the same problem, and the currently implemented fixes are pretty clunky.

Re: Linux is a fragile house of cards

[Spacelord]

Except he is in fact a liar. As others have confirmed in this thread, removing sudoku via apt-get does not remove xfce. In fact it doesn't remove anything but the actual sudoku app.

So I'm sure he issued a bunch of other apt-get commands he has conveniently forgotten to mention here because he had no idea what the hell he was doing, and then he goes on to blame Linux and apt-get for his own willful ignorance.

Re:Linux is a fragile house of cards

[Archangel Michael]

I can see this happening, MAYBE. But only because he installed all the dependencies when he also installed the game. When he tried to uninstall the game, it took all the dependencies that were installed when the game itself was installed. MAYBE.

That would be the ONLY case where I could see something like that happening. Again, MAYBE.

Re:Linux is a fragile house of cards

[benjymouse]

Well I gotta tell you I've seen programs removed and suddenly the system would not boot on Win7. Seems the uninstaller took a few system files with it. Shitty developers can fuck up absolutely anything.

On Windows, uninstallers cannot delete system files. Since Vista, Windows Resource Protection has prevented even processes running as administrator or SYSTEM from changing/deleting system resources (files, registry keys etc). Only the "trusted installer" account can write those files, and only the WindowsUpdate process runs as trusted installer. It will not install 3rd party applications.

Not saying that an uninstaller cannot do other harm which could toast the boot process, but it cannot delete system files. Safe mode will trust *only* system files, and should always be able to load - bar hardware failures.

Re: Linux is a fragile house of cards

[rahvin112]

He's already talked about doing so and I wouldn't be surprised if he's started. He wants to standardize pieces of linux that have been a nightmare of aging incompatible code. A natural stop on that path would be Linux package managers. As much as I love Apt-get, and I like emerge they all ultimately suck. They call it dependency hell for a reason.

Ultimately we'd all be better off if someone could figure out a better, more robust and more modern solution to Linux Package managers.

Re: Linux is a fragile house of cards

[benjymouse]

You can't do the same thing in OS X. I don't know about Windows.

Windows has had Resource Protection since Vista. Even before that, Windows File Protection going back to Windows 2000.

Only Windows Update can run as "Trusted Installer" - and only trusted installer is allowed to replace or change system files.

Re:Linux is a fragile house of cards

[adolf]

What is this newspeak "network stack" that you are referring to?

Last I checked, the "network stack" consists of things like TCP, IP, the physical layer, and other such mumbo-jumbo that is entirely done in the kernel and has fuck-all to do with userland.

Re: Linux is a fragile house of cards

[bmo]

They call it dependency hell for a reason.

or DLL hell.

That's only fixable if we abandon the .dll or .so or whatever and have everything statically linked for every program.

Not gonna happen.

--
BMO

Re:Linux is a fragile house of cards

[Anonymous Coward]

Man, how do you still have a job? "Install from minimal base system" is the right response, not "leave massively pointless userspace attack vector installed because I don't know the difference between a TCP/IP stack and networkmanager".

Re:Linux is a fragile house of cards

[Anonymous Coward]

You didn't simply uninstall sudoku. When your package manager said "hey, the desktop metapackage depends on sudoku, do you want me to uninstall the whole thing?" you said "Yes". Innocent mistake perhaps, but not the package manager's fault.

Re:Linux is a fragile house of cards

[Anonymous Coward]

But your anecdote, as reported, is inaccurate: uninstalling sudoku had nothing to do with your DE getting fudged.

It is not inaccurate at all. *YOU* are unable to reproduce the bug. That doesn't mean the bug does not exist or that others have not run into it. I guess logical thought must be a tough thing for Linux cheerleaders like you.

Re: Linux is a fragile house of cards

[Anonymous Coward]

Ever since I had the same problem, I just install the base system from ghe installer and do the rest with commands to get rid of those hiccups. I lost entire GUI after uninstalling a simple game when I wasn't experienced as I am now

Re:Linux is a fragile house of cards

[Anonymous Coward]

Nope, it doesn't remove "the network stack". It by default removes the now unneeded nicer GUI-centric frontend network-manager, but you can of course still get online using the standard cli tools, which you would prefer on a server anyways.

Also, wtf do you mean by "leave the GUI installed"? Why would you install it in the first place if you don't want it (it is literally one checkbox in the installer)?

Re: Linux is a fragile house of cards

[Trogre]

Linux package managers are well overdue for redesign.

Perhaps so, but there's nothing on any other mainstream operating system that can compare in terms of software management.

And no, the OSX and Windows App Stores don't come remotely close.

Re:Linux is a fragile house of cards

[Anonymous Coward]

Why not do a minimum netinstall and build off that?

Re:Linux is a fragile house of cards

[Anonymous Coward]

I'm surprised you do not already have been aware that the problem is actually the simple fact that the attempt to remove an application can remove much of the system. you're really, really stupid know?

Re:Linux is a fragile house of cards

[Anonymous Coward]

Is it the grub command prompt? If so, your drive has bad sectors (hardware fault) and the boot loader can't find your boot partition. Throw the disk in another computer and copy the data ASAP!

Re: Linux is a fragile house of cards

[Kidbro]

> No, he's not an idiot. He's a normal person. Normal people click uninstall and expect their game to be uninstalled, not their OS's GUI

No he's not an idiot, a fucking liar is what he is. There is no way that in any package management system XFCE would have a dependency on a Sudoku app, if anything the dependency would be the other way around. So no, removing Sudoku would never result in XFCE being deleted. Not even Ubuntu would be that stupid.

Actually, it could. Imagine you have a virtual package, say xfce-environment, which depends on sudoku and everything else XFCE. This package is the only package that is explicitly installed, and through it you got your DE. The system is configured to automatically remove packages that are not explicitly requested (mine works that way - when I remove a package, any package that is installed solely because it's a dependency of that package is also removed). So, luser uninstalls sudoku, which forces removal of virtual packagee xfce-environment (since this virtual package has a dependency on everything, including sudoku), now every single other package that xfce-environment depended on, which has no other reasons to exist on the system, will also be uninstalled. I can see this happening, and have seen similar situations myself.

Now, I don't think the system is in the wrong here - the user should probably have paid a bit more attention, but I do not think his story is necessarily false.

Re:Linux is a fragile house of cards

[tepples]

I'm guessing it refers to NetworkManager, the GUI tool for finding available networks and configuring interfaces to connect to them. WLAN in particular is a lot more complex than ye olde ifup eth0.

Re: Linux is a fragile house of cards

[david_thornley]

I had an XP laptop once that apparently couldn't take a certain Windows update. After that one, it would just stop and hang at random intervals, requiring a restart. I was going to use System Restore to figure out which update, but when I started the bisection process it stopped and hung in the middle of replacing a file needed for the user interface (don't remember which one), so I had to boot from floppy, figure out which file was missing, download a copy somewhere, and replace it before I could boot Windows again. At that point, I just System Restored it back to when I got it, and decided never to buy a Compaq laptop ever again. That particular decision has become a bit easier to adhere to, to be honest.

Re:Linux is a fragile house of cards

[david_thornley]

The comments here are why a lot of level-headed people have a prejudice that anti-Linux comments are likely from haters. This is not a Linux problem. The fact that this report shows how the problem can come up while running Linux doesn't mean it can't or won't happen on any other OS.

Re:Linux is a fragile house of cards

[david_thornley]

To preserve this capability, Windows 10 does its best to not give the user a choice about accepting updates.

Re:Linux is a fragile house of cards

[david_thornley]

Using your reasoning, all ACs are idiots who don't know what they're talking about.

After all, you're describing one specific event, which probably didn't happen quite the way you tell it (whenever I get sufficient information about such a story, there's almost always important things left out), and concluding from that that Linux is screwed up.

To quote a friend, "Everyone generalizes from one example. I know I do." However, this friend actually knows it's a joke.

Re:Linux is a fragile house of cards

[Anonymous Coward]

No, it also happened to me. I uninstalled one small thing, and half of Gnome got uninstalled with it.

Do you know why uninstalling minesweeper kills the OS? Because Linux sucks, and the package system is broken beyond repair, so the Gnome developers came up with a 'smart' hack to make installing Gnome easy. They release one "mock" package that depends on everything file inside the distribution, so when you install that package you also install everything. Simple!

Except if you don't want minesweeper, or in my case disability support. You uninstall it, and then you break the dependencies of the "mock" Gnome package, so it also gets uninstalled, and then aptitude or apt-get tries to be smart and destroys even more things. When you report the problem to the Devs, the answer is "do not uninstall anything, and problem solved", or "we don't want to go the MS route". So, I did the sensible thing and uninstalled Linux.

but if you are happy with your shitty OS stuck in the 70s, you can keep using it.

Better solution

[Anonymous Coward]

Code the "rm" command to block "rm -rf /", there is no valid use case for running that command, if someone wanted to wipe a drive they should just use a partitioning utility from a separate boot device.

Re:Better solution

[Spacelord]

Have you even read the article?

Are you going to block rm -rf /sys/firmware/efi/efivars too? In fact are you going to add filters for everything that the rm command is not supposed to delete? How about the > command then. What if you did > /sys/firmware/efivars/* ? Would you block that too? How about the cp or mv command? dd? echo? cat? I could easily come up with some destructive stuff using those commands. Good luck with preventing all that.

And even if you could change all your shell utilities to block all potentially destructive modifications, it would still not prevent a rogue program or an attacker who gained root on your system to run their own code and permanently brick your system.

Read that carefully: permanently. brick. your system. Not: oh shit my linux is broken, I have to restore from backup or reinstall, but: oh shit, my motherboard is fried and I have to buy a new computer.

This is dangerous stuff, and it is something new to take into account when playing around with your computer. It used to be that nothing you did in software could damage your hardware, and there was something liberating about that idea. This has now changed.

I'm struggling to come up with a valid use case

[Anonymous Coward]

At what time would I ever use 'rm -rf /'

Why wouldn't I reformat the partition?

Re:I'm struggling to come up with a valid use case

[segedunum]

Whoosh. This shouldn't brick a system.

Re:I'm struggling to come up with a valid use case

[danbob999]

"rm -rf /" doesn't reformat anythings. I only deletes files, from all mounted partitions, including any mounted network share. It's not the same as mkfs.ext4

Re:I'm struggling to come up with a valid use case

[Anonymous Coward]

At what time would I ever use 'rm -rf /'

Why wouldn't I reformat the partition?

I've used rm -rf / in training classes for people new to Unix/Linux. Started off the class by doing this to show everyone how important it is to pay attention to what you are typing, what user you are when you are typing commands, and how there is no safety net asking if you really want to do this. Would then proceed to install the system so the class would get that experience.

Other than that, can't really think of any valid use case.

Re:I'm struggling to come up with a valid use case

[itsdapead]

At what time would I ever use 'rm -rf /'

After accidentally hitting return partway through typing 'rm -rf /something/you/actually/wanted/to/delete'; running a shell script with 'rm -rf $MYPATH' where $MYPATH had got set to '/'; by installing malware and giving it the admin password or some other equally stupid screw up.

If you are omnipotent and infallible and never have, or never will, make a stupid screw-up like that (or run IT support in a perfect world where none of your lusers can pull rank and demand admin rights on their PCs) then all well and good. Otherwise, the consequences just got raised from restoring the hard drive to replacing the motherboard.

Re:I'm struggling to come up with a valid use case

[TangoMargarine]

Yes, and that completely ignores the question.

Re:I'm struggling to come up with a valid use case

[itsdapead]

At what time would I ever use 'rm -rf /'

Addendum: see the first example here!

Re:I'm struggling to come up with a valid use case

[danbob999]

the question was "Why wouldn't I reformat the partition?"
The answer is that he can format his partition if he wants to, but the proper way to do it is not to use the rm command at all.

Re:I'm struggling to come up with a valid use case

[TangoMargarine]

The answer is that he can format his partition if he wants to because the proper way to do it is not to use the rm command at all.

Exactly! So to restate,

At what time would I ever use 'rm -rf /'

You just keep reiterating the question as if it's somehow the answer. Or by

"rm -rf /" doesn't reformat anythings. I only deletes files, from all mounted partitions, including any mounted network share. It's not the same as mkfs.ext4

did you mean

rm and format are two different things. You'd want to format in a situation where you didn't want to rm.

? Which isn't really helpful at all, but just a tautology.

low SNR these days at /.

[bill_mcgonigle]

The kernel dev who wrote the efi code says it's not a systemd problem and following the bug report's suggestion would be the wrong way to solve the problem.

But don't let that stop you from jumping on your favorite whipping boys.

Re:low SNR these days at /.

[Anonymous Coward]

Why is there always a systemd angle to such problems but not a SysVinit one? Systemd is a "favorite whipping boy" exactly because it is all over the place and pervasive, like Linux borreliosis.

Re:low SNR these days at /.

[AmiMoJo]

A reasonable solution would be for the distros to mount /efivars as read only, and apps that need to change them can specially mount it for writing, and then put it back to read only again.

Re:low SNR these days at /.

[Anonymous Coward]

Why is there always a systemd angle to such problems

There isn't. Not always. Not even very often. Calm down a notch or two with the hatred. As a bonus, other people will be more likely to listen to what you have to say, if you do.

Re:low SNR these days at /.

[thegarbz]

A more reasonable solution would be to smack whoever wrote UEFI code for not having it cope with corruption / missing data on a part of the system that specifically has write access enabled. I mean we got around the whole thing of bricked BIOSes some 10 years ago, why have we regressed?

Re:low SNR these days at /.

[Anonymous Coward]

Gosh, SystemD defenders are sure sensitive.

I guess if I believed in SystemD that much, and I mean really believed it was the only way to go. Maybe I'd feel offended too if someone had the audacity to want to choose a different init system.

From my observation, people wouldn't be whipping on it in most of the cases, deserved or not, if it had remained an option instead of the only option.

Re:low SNR these days at /.

[jtayon]

Or as pointed to use ioctl

http://linux.die.net/man/2/ioc...

Since the file "abstraction" has not been enough since the beginning of unix, ioctl enables you to add to your "file" extended capacities. And since I guess systemd is coded in something different than shell, it has access to ioctl.

But the problem with LP is not complex: he might be a genius that love spaghetti flying processes but he does not care to break things that used to work. He is a genius.

And at the opposite of linus torvalds, he acts like a dictator (which is fine for a successful design) too, but not a benevolent one that cares about the users' peace of mind and least surprise principle. Linus shout on contributors/devs that introduce surprising behaviours. LP shout on users that complain of surprises.

You may like it, sysadmins hate that. I now work on BSD and reinstalled windows for the rest and my mind is now at peace.

I love the arrogant bulliers that ensure the stability of my system. I do not like arrogant bulliers that mess with my work tools.

Re:low SNR these days at /.

[Anonymous Coward]

Gosh, SystemD defenders are sure sensitive.

Personally, I'm neutral.

But I suspect some of the sensitivity comes from the sometimes outright vile hatred displayed by some of the SystemD attackers.

Could have something to do with it...

This is why BIOS is separate

[Anonymous Coward]

Having come up during the advent of computers, this is PRECISELY why we separated hardware bootstrap firmware from user-accessible code in the first place, and did not make provisions for user-space access to change it. The hardware had to continue to operate and boot regardless of the stupid things users and developers did.

That all went out the window the moment we started with this "update your BIOS from the O/S" bullshit. And now, apparently, "let's give userspace read/write access to the bootstrap firmware willy nilly," which is complete and utter stupidity.

Re:This is why BIOS is separate

[LichtSpektren]

Having come up during the advent of computers, this is PRECISELY why we separated hardware bootstrap firmware from user-accessible code in the first place, and did not make provisions for user-space access to change it. The hardware had to continue to operate and boot regardless of the stupid things users and developers did.

That all went out the window the moment we started with this "update your BIOS from the O/S" bullshit. And now, apparently, "let's give userspace read/write access to the bootstrap firmware willy nilly," which is complete and utter stupidity.

People shouldn't be executing rm -rf / to begin with. As a user that doesn't wipe out his whole system by accident, I would like to protest your argument by saying that I like that the boot files are easily accessible, it allows me to learn more about how my OS works and how to debug errors in the booting process.

Re:This is why BIOS is separate

[Anonymous Coward]

You and a bunch of other people in this thread are continually missing the point, which is certainly not that you could somehow accidentally type rm -rf /. Nobody gives a fuck about that. The point is that you shouldn't be able to brick your hardware from user space, just as the GP has laid out.

There was a time not too long ago when malware could be dealt with by "simply" reinstalling the OS. Now malware can infect your PC's firmware, your USB sticks' and hard drives' firmware, make your graphics card go up in flames, and brick your motherboard.

Re:This is why BIOS is separate

[Anonymous Coward]

People shouldn't be executing rm -rf / to begin with.

So, it's the fault of the rm developers?

Re:This is why BIOS is separate

[Anonymous Coward]

Fuckin right. BIOS belongs on chip, not on disk. Simple as that.

Re:This is why BIOS is separate

[LichtSpektren]

You and a bunch of other people in this thread are continually missing the point, which is certainly not that you could somehow accidentally type rm -rf /. Nobody gives a fuck about that. The point is that you shouldn't be able to brick your hardware from user space, just as the GP has laid out.

There was a time not too long ago when malware could be dealt with by "simply" reinstalling the OS. Now malware can infect your PC's firmware, your USB sticks' and hard drives' firmware, make your graphics card go up in flames, and brick your motherboard.

Rootkits are nothing new. They existed in BIOS as well.

Re:This is why BIOS is separate

[Anonymous Coward]

Jeez, you don't even know what your talking about. This has nothing to do with rootkits...

Re:This is why BIOS is separate

[Anonymous Coward]

No. This is either a PEBKAC or an ID-10-T issue. The correct remedy is to remove the user.

Re:This is why BIOS is separate

[thegarbz]

And now, apparently, "let's give userspace read/write access to the bootstrap firmware willy nilly," which is complete and utter stupidity.

Except it's not access willy nilly. It's select access to a part of a system that allows the user to perform a specific function.

The problem was that idiot programmers didn't consider the writeable parts being empty to be a valid usage scenario. This is a big no-no for embedded programming. If you give external access to something you need to cope with corruption, erasure, etc.

Re:This is why BIOS is separate

[Anonymous Coward]

He meant BIOS malware.

Re:This is why BIOS is separate

[Anonymous Coward]

Exactly. These guys who are blaming UEFI want firmware to be designed in the same way as mobile apps with all the "User Experience" crap, with excessive safeguards... Firmware is designed to be run at a low level, and the single consideration should performance, security and avoiding *inadvertent* corruption.

Who the hell said that just because the OS CAN access the firmware, that it SHOULD make it accessible as a normal file? Then why not make microcode a file? storage device firmware a file? That to me is the biggest flaw in the "everything is a file" approach. The best approach IMVHO would be a hybrid of Windows and Linux approaches : all storage filesystem data on /{path}, all other kinds of files (devices, EFI vars) on \{path} .

Boot partition... you have that backed up right?

[Anonymous Coward]

If you run "rm -rf /", don't you suddenly have other problems than your boot partition? That partition is so easy to backup compared to the old MBR, there is no excuse! I once formatted my boot partition by mistake (yes, "mkfs.ext4 /dev/sda1" is as dangerous in the hands to the stupid) but it didn't quite "brick" my system

What kind of retard would run that command?

[Anonymous Coward]

Who the fuck runs "rm -rf /" on their Linux system?

I just use legacy mode

[Anonymous Coward]

I have always used legacy mode in bios for Linux installs. I guess this must help, I have not experienced any problems? UEFI is perfectly fine, I think it was a big positive for PC's. I suppose those dual booting Linux with Windows in UEFI have the potential for experiencing this more.

Perhaps some terminal commands should be locked

[LichtSpektren]

There are too many imbeciles that will brick their system by typing in random terminal commands they found on the Internet, like fork bombs or using wget to download a trojan. rm -rf / is only the most famous of this kind of command. Then they will complain that Linux is too fragile and dangerous to use for new users, blah blah blah.

I was thinking of a possible solution to this. Perhaps the distros meant for newbies (Ubuntu, Mint, elementary, Zorin, etc.) could lock by default the most well known terminal commands that fuck your system up. When trying to execute them (even with root privileges), they will get something like "ERROR: This command is extremely dangerous. To execute, go to [distro's website].org/foobar." This page will have the password in order to bypass the lock, but only at the bottom of some text that explains exactly what will happen, and if you do anyway, that the distro has absolutely 0% liability to what will happen to your system.

Re:Perhaps some terminal commands should be locked

[dbarron]

I see your comment and see the umm wisdom in it, however, it's somewhat analagous (IT-wise) to 'Don't shoot your foot with a gun.'.

If you don't understand why you shouldn't do this...you shouldn't have root access. It's as simple as that.

Re:Perhaps some terminal commands should be locked

[The MAZZTer]

I'm pretty sure Ubuntu at least locks by default. There's a -no-root-preserve switch or something that you HAVE to specify to do an rm -rf /, otherwise the command fails.

Re:Perhaps some terminal commands should be locked

[peppepz]

The most common implementation of rm on Linux (GNU coreutils) does exactly what you're asking.

# rm -fr /
rm: it is dangerous to operate recursively on '/'
rm: use --no-preserve-root to override this failsafe

Re:Perhaps some terminal commands should be locked

[Anonymous Coward]

Going to a website is insane and ridiculous, but let's pretend you were just referring to an extra layer of security/nagging/inconvenience.
In that article:
1) rm -rf / — this is already fixed, at least in the sense that you can't remove the root dir this way any more. If you want to run sudo rm -rf /bin then there's nothing stopping you, but unrestricted use of rm is about as common as the windows user who decides to clean up that "messy" Windows folder, and about as hard to prevent.
2) Bash fork bomb. I'd like to hear your fix for that one.
3) mkfs -- yeah, that's probably a good one to restrict. Even if you know what you're doing you're not going to be running that very often, so a layer of security/inconvenience wouldn't be too bad.
4) > /dev/sda Are you going to break shell redirection, or the 'everything is a file' concept, or every program that tries to access the hard disk directly, or all of them at once?

I'm going to quit here. Honestly, I'm okay with Linux being restricted to people smart enough not to do these things. I only recommend it to programmers and old people at this point. The programmers have realistic expectations about software working correctly, and the old people are never going to do anything that could potentially break the system. I mean, my mom upgraded to Windows 10 the other week, but she can't really be blamed for that.

Re:Perhaps some terminal commands should be locked

[Anonymous Coward]

Those messages should be displayed along a smiling clip in ASCII

Re:Perhaps some terminal commands should be locked

[wonkey_monkey]

I wonder if my distro does that as well.

If I don't report back, it doesn't.

Re:Perhaps some terminal commands should be locked

[LichtSpektren]

If you're using sudo and not logged in as the root user, then it won't automatically execute without the admin password.

Re:Perhaps some terminal commands should be locked

[Anonymous Coward]

If you don't understand why you shouldn't do this...you shouldn't have root access. It's as simple as that.

In my experience "shouldn't" and "doesn't" are not even on the same Venn diagram.

Re:Perhaps some terminal commands should be locked

[thegarbz]

I was thinking of a possible solution to this.

I have an easier one. Send programmers who work on embedded systems, firmware etc back to school where they should have learnt very early on that any part of a system that is specifically exposed should be able to cope with complete corruption if the system itself is not easily field-repairable.

UEFI runs on a memory card? No problem. UEFI is burnt on a chip on the motherboard? The programmers should be repeatedly kicked in the balls for allowing this to happen. Outside of complete manual re-flashing of a bootloader going tits up, software bricking hardware just shouldn't be happening anymore.

Re:Perhaps some terminal commands should be locked

[Cinnamon Beige]

Actually, why not have those locked by default, period? You might even set it up so advanced users could have the option of configuring the lock so they could instead get a process like 'confirm root password and that you want to' instead of having to visit the distro's website, but it might be sanest to just flat out have certain commands always locked.

Re:Perhaps some terminal commands should be locked

[BadDreamer]

You do not comprehend the meaning of "brick". A fork bomb will not brick a system. Nor will a trojan. Nor will doing "rm -rf /" on a system which does not have uefi variables mounted rw.

Bricking means the system becomes a BRICK. No matter what you do, you can not reboot it. You can't even boot from external media to reinstall. Replacing the hard disk will not make it boot. The system is a BRICK. Dead, and unable to boot at all.

That is bricking. That is not possible to achieve with fork bombs, or trojans, or removal of OS files. Fucking a system up is not bricking. This is on a completely different scale.

Re:Perhaps some terminal commands should be locked

[Anonymous Coward]

2) Bash fork bomb. I'd like to hear your fix for that one.

There is actually a fix for that. It involves tweaking some variables that limits how many processes can be spawned. See: http://www.cyberciti.biz/tips/linux-limiting-user-process.html

This could perhaps be set to prevent fork bombs by default on newbie friendly desktop distros like Ubuntu (maybe it is, I haven't check). Setting it by default is a little tricky as how many processes can be handled is hardware dependent, but you could probably set levels that would work for most desktop systems and wouldn't affect performance. Probably shouldn't be set by default on distros intended for more advanced users or for server use though.

Re:Perhaps some terminal commands should be locked

[Reziac]

I didn't need any such commands for Mint to brick itself. All I did was attempt to change a video setting using the provided interface, and somehow that toasted GRUB.

(Semi-reproducible, ie. have had it happen twice now. Won't happen again, cuz Mint is history.)

Re:Perhaps some terminal commands should be locked

[ChrisMaple]

Fedora, and I assume other distros, alias rm to rm -i. This should be enough to dissuade the casual idiot.
On the other hand, one of the first things I do with a new installation is remove that alias.

Re:Perhaps some terminal commands should be locked

[pepa65]

Number 4 (>/dev/sda) doesn't really do anything, as /dev/sda is a block device. On a regular file it would get truncated to length zero.

Windows malware?

[Anonymous Coward]

How come we haven't heard of massive bricking on Windows systems by malware that bricks system boards? Could it be that bricking is not possible by bricking malware on windows where bricking malware could actually brick a system board on a brickable linux box?

Factory reset, anyone?

[Anonymous Coward]

So, where is your holy grail called UEFI variables stored? If its not on the hard disk then its possibly in the NVRAM of your system. So, yes you can erase them or modify them, but shouldn't have the System a "factory reset" function that cleans the mess after an accident?

Re:Factory reset, anyone?

[Anonymous Coward]

shouldn't have the System a "factory reset" function that cleans the mess after an accident?

Yes, it should. But in some cases it doesn't work.

Is rm running as a user or as root?

[Anonymous Coward]

The FA doesn't say.

Recurse, Repeat, Randomize

[Anonymous Coward]

Same shit different lifetime.

Time for another Extinction Event to maximize the available Entropy.

Linus Fails Again

[Anonymous Coward]

This command does NOTHING on my superior Windows machines. We do not allow such viral commands here in the grown up world of computing.

No fix?

[Anonymous Coward]

Just create rm() function where you assign something else for rm -rf /

Source it from .bashrc

Problem solved.

?? How on /. did this get modded insightful??

[Kludge]

See the subject line.
Obviously this poster has no idea
1. of what he is doing
2. that XFCE in Debian is not "Linux"

Re:?? How on /. did this get modded insightful??

[Anonymous Coward]

Perhaps the mods read "inciteful".

Hm...

[Anonymous Coward]

C'mon folks, nobody forces you to use systemd. I run a Debian "testing" system with systemd-provided init disabled and everything works fine for me so far.

Don't Spell It "Systemd" Or "systemd"

[Anonymous Coward]

Spell it SystemD.

That way it looks like an ASCII penis.

Re: Don't Spell It "Systemd" Or "systemd"

[Anonymous Coward]

Yes, the "y" in SystemD is a stylized ball sack if you think of a profile view of a dick.

Re:Don't Spell It "Systemd" Or "systemd"

[Anonymous Coward]

S=====D

SystemD

I can defiantly see the similarity for sure!

Wait a second...

[Anonymous Coward]

What is all this? I thought rm -rf / was the official procedure for upgrading from RHEL6 to RHEL7?

FUD on top of FUD

[s.petry]

Linux is anything but fragile. Stop blaming the OS for a shitty design in UEFI! Linux is so stable and solid that it lets you run "rm -rf /" and it will actually do what you asked it to until it can no longer figure out the machine it's on and commands needed to talk to a disk. This is a more than 45 year old design. Yes, that's right. In AT&T's original Unix you could also kill a system with "rm -rf /".

'but', 'but', 'but', oh shut up and stop spreading FUD! "rm" is the remove command, "-r" is recursive, and "-f" is force. You need to be root to run this with any success, so it's not like any old user can remove everything.

The problem is that UEFI allows an OS to write to areas which it should not be able to write to. If you open all the PROM in a system it's not just the OS that can brick a system. A malicious person can do so just as easy, and without being so obvious as running "rm -rf /"

Re:FUD on top of FUD

[AmiMoJo]

The weakness is that root can write to that virtual filesystem. With selinux or other operating systems some special permission is required via an API, so trying to delete some files won't accidentally delete some critical non-files that were virtualized into a filesystem for convenience.

A simple ioctrl required before writing is possible would fix this and make the system more secure and stable.

Re:FUD on top of FUD

[Anonymous Coward]

This is nothing new from UEFI. Solaris is similar on SPARC CPU's in using the "eeprom" command to update the firmware from a Solaris Unix shell command line. When I did those sorts of things in a prior job over 10 years ago, it was usually to do things such as to run Openboot PROM updates from Sun support, implement firmware password protection for new servers (a key installation checklist item of course), or change boot options (autoboot wanted sometimes, not others - management went back and forth on that ...), etc.

Regarding "rm -rf /" in that Solaris (2.6) environment, someone had the notion that we could wipe disks that way when decommissioning servers (or just disks), but I quickly found that as parts of the filesystem "disappeared", the command could not continue if it needed to reload any software from the just-deleted directories to continue deleting (don't remember the exact cause/effect sequence, but that is what it boiled down to - maybe volume management?) - scratched that idea rather quickly ;-}

YMMV

Re:FUD on top of FUD

[thegarbz]

The problem is that UEFI allows an OS to write to areas which it should not be able to write to.

Not quite. The problem is UEFI doesn't consider a missing variable to mean "default". There are valid reasons for being able to write to it. There's less valid reasons for it to allow a dodgy write to brick the system.

Re:FUD on top of FUD

[Anonymous Coward]

Linux is anything but fragile.

When you're a superuser, anything is fragile.

Stop blaming the OS for a shitty design in UEFI!

The shitty design (in this case), was on the part of the implementer (MSI, and some Samsung devices), not UEFI. Additionally, the method that Linux uses to expose the EFI environment variable service to userspace (a virtual filesystem) was very thoughtlessly implemented, and gives userspace far more trust than it deserves. I don't like UEFI that much, but it isn't to blame for this mess, and the man that wrote that code in the first place agrees.

Linux is so stable and solid that it lets you run "rm -rf /" and it will actually do what you asked it to until it can no longer figure out the machine it's on and commands needed to talk to a disk. This is a more than 45 year old design. Yes, that's right. In AT&T's original Unix you could also kill a system with "rm -rf /".

You have a very strange definition of stable, and until now rm -rf / would simply wipe the root filesystem and all filesystems mounted in the tree along the way. The point of the article is that rm -rf / (or rm -rf /sys/firmware/efi/efivars) can now have very hard to reverse effects on firmware (and by extension, hardware) due to poor implementation on the vendor's side, and a bit of carelessness on the kernel side.

'but', 'but', 'but', oh shut up and stop spreading FUD! "rm" is the remove command, "-r" is recursive, and "-f" is force. You need to be root to run this with any success, so it's not like any old user can remove everything.

There is a big difference between removing all of the files on a disk, and causing difficult to reverse firmware issues that prevent the motherboard from even POSTing. Your inability to see the difference is troubling.

The problem is that UEFI allows an OS to write to areas which it should not be able to write to. If you open all the PROM in a system it's not just the OS that can brick a system. A malicious person can do so just as easy, and without being so obvious as running "rm -rf /"

There is no such thing as "areas which it should not be able to write to" with respect to the EFI environment variable service. The running kernel can modify whatever variables it likes, and its up to the vendors implementation of UEFI to decide whether or not that succeeds. It's also up to the vendor to make sure that it can handle missing EFI environment variables gracefully. It should not be possible to brick a motherboard by deleting EFI environment variables, and it's not UEFI's fault that this happens.

Re:FUD on top of FUD

[belthize]

It would not make it more secure. As the GP pointed out rm is just an example. Adding a user level hoop to jump through doesn't fundamentally change the nature of the problem. Root should be able to write to any filesystem exposed to it in read/write mode. The problem is it shouldn't have read/write access to that area . period . hard stop.

If you want a secure system then it's the data owners job to decide who does and doesn't have access, not to grant access to everyone and hope they do the right thing. In this case it's 100% UEFI's fault for exposing it's data in read/write mode.

Re:FUD on top of FUD

[david_thornley]

This whole "root" business is a red herring. The issue is that it is possible to overwrite those variables with software executing normally on the machine, and that can brick* the thing. It's not systemd's fault. It's not Linux's fault. It's the UEFI implementation's fault.

Depending on what you're running, it's easier or harder to overwrite those variables. I don't know if Linux is more or less dangerous. My W7 laptop features an astonishing number of people who are not me who want to run their software on it without letting me know in advance, and that's not nearly as true for my Ubuntu box.

*I'm not using any newfangled definition of "bricked" here. If I can do something to the drives that doesn't involve physically replacing them, boot from some sort of medium, and reinstall the OS, it ain't bricked. If it becomes physically impossible to boot or reinstall the OS or something, that's bricked.

A related issue

[Anonymous Coward]

I assume this problem occurs only in you are running with root priv.
It should be noted that running:
          rm -rf .*
Will also have a similar effect because the rm will work its way up the directory tree to "/"

A work around to avoid this kind of disaster is to use the following to remove everything below the CWD:
        rm -rf .??*

Mount RO by default / mount RW temporarily

[Anonymous Coward]

This is another case of stupid design. The UEFI section should be mounted RO by default and remounted RW just long enough to make required changes when required. The tinkerers can be satisfied as well while still providing additional stability.

Re:Mount RO by default / mount RW temporarily

[Anonymous Coward]

Errr. Think about what you said for a second and consider the implications.
Your proposed "design" is just as stupid as the next one. For one, what defines a "required changed"? What keeps a black hat from remounting the vars rw and deleting them?

Re: Boot partition... you have that backed up righ

[Anonymous Coward]

*sigh*

Read the fucking article before you make an ass out of yourself. Hell, in this case, the difference between "OS doesn't load" and "computer is bricked" is clearly explained.

Virtual machines ?

[pklinken]

This doesn't apply to VMs I hope

Makes sense

[phishybongwaters]

It makes perfect sense for a format of my drive to brick my entire system, that makes perfect sense, in 1968. My bad, I thought this was 2016.

Re:Makes sense

[wonkey_monkey]

It makes perfect sense for a format of my drive...

Pass your geek card through /dev/shredder.

Re:Makes sense

[david_thornley]

Do you mean the box as tall as the operator that has two huge tape reels in it, or the thing that looks like a top-loading washing machine that can be opened to reveal a large canister? I wasn't around quite that early, and I have painful memories of JCL that would make various assumptions about the drives, but I really don't remember talking much about formatting either thing. You certainly wouldn't format the big thing that you fed card decks into (which would probably be attached to a process, and read cards on demand - I'm vaguely remembering something about HASP being available about that time but not before).

(Data density wasn't that great back then either. You could get little iron filings or something that you could dump on a part of a tape to read off the magnetized dots.)

Problem is Secure Boot

[Anonymous Coward]

In order for the OS (Windows/Linux/Unix) to use the Secure Boot mode, they have to be able to add their keys to the Secure Boot - EFIVARS table.

What this sounds like is a poor implementation of that feature since it's allowing all of the UEFI Firmware to be wiped instead of the Secure Boot area.

This makes my Asus Board far more valuable due to their Crash Free implementation that can load a firmware replacement/upgrade w/o a CPU or RAM installed by using a hardware button and dedicated USB port to do so so I'm quite a bit happier as it's a damn good use for an old 128-512M flash drive

New slashdot meme

[Nidi62]

I'm not saying it was aliens, because it was actually systemd.

Hype Brick or real Brick?

[Lumpy]

When I hear Bricking it means I have to toss the hardware or whip out a JTAG or EEPROM programmer.

Is this "bricking" real or just someone not understand what the word actually means and a initialize and reinstall of the OS will fix everything.

Re:Hype Brick or real Brick?

[dmomo]

It says in TFA that firmware is overwritten (and on a UEFI system, effectively the BIOS). So, simply reinstalling the f Operating system would not work in this case. Whether or not it's truly bricked, would depend on whether it's possible to re-flash that firmware. I'm sure that it IS possible, but how to do so would depend on how the machine is physically configured. Perhaps by putting some utility on a flash card? Perhaps by opening the computer case and doing something more pyhsical. So, no. Probably not bricked in the purest sense, but certainly more so in a practical sense than simply removing the OS.

Re:Hype Brick or real Brick?

[sjames]

It's a real brick. Stupid EFI won't come up far enough to let you change the variables and it has no way to reset to factory short of re-flashing with an external programmer (if you can get a good image to flash).

The new shiny screws up something that's been working fine for 32 years.

Re:Hype Brick or real Brick?

[Anonymous Coward]

This is real bricking. This isn't reinstall the OS, this is grab an EEPROM programmer or trash it.

Re:Hype Brick or real Brick?

[BadDreamer]

It's real bricking. The motherboard is dead. You need to reprogram the UEFI chip to make it work again, using a JTAG or an EEPROM programmer.

There is no way to get an OS to boot, from existing media or external media, so there is no way to initialize or reinstall.

Re:Hype Brick or real Brick?

[Mryll]

I have a feeling something like this happened with my nephew's system when he attempted a Win7->10 upgrade. Not sure why and he may have messed up, but he claims it was bricked to the point he couldn't get into the UEFI and gave up on it. It might be reparable with a fixed UEFI I suppose.

Re:Hype Brick or real Brick?

[Anonymous Coward]

Give it a shot and let us know how it turns out.

Re:Hype Brick or real Brick?

[toddestan]

My guess is that somehow the EFI system partition got messed up. That's enough to stop some computers from booting (essentially the UEFI on some boards seem to scan all connected storage devices to see if they are bootable and on some if they find a corrupted EFI partition they don't handle it very well). If he pulls the hard disk and it boots again then that's the problem. This can be annoying problem to fix, if the computer won't boot up with the drive connected. You can take the drive to another computer and zero out the partition table, and then you can put the drive back into the original computer and start over. In theory SATA is hot pluggable so you could boot something like a Linux live CD then connect the hard drive if you don't have a second computer handy, but don't blame me if you fry something.

Re:Hype Brick or real Brick?

[pepa65]

So you have a JTAG or EEPROM programmer -- would you know how to fix it if the efivars had just gotten wiped?? I would love to have access to resources and instructions on what needs to happen..!

I never run rm -rf /

[maelkum]

I never run rm -rf /. But when I do, I [Connection lost]

Why IS systemd hated so much?

[Anonymous Coward]

I've seen this over and over, but no real concrete reason for it.
Why IS systemd hated so much?

Don't give me your silly "chaaange!" arguments either. An actual reason.
Does it make Linux more vulnerable?
The only thing I have heard is it changes the way scripts are parsed, or something.

Not 100% sure, I've not used Linux in-depth and the last time I used it was 2004 on a laptop when I quickly threw a Slax Live distro on a disc because my HDD died.
Is it worth avoiding? Or, for a newer system (the one I am making), is it perfectly fine to get in to?

Re:Why IS systemd hated so much?

[peppepz]

It takes some control away from administrators/developers/users and concentrates it into the distribution maintainer. Most people appreciate this, because they like to work less, some people don't, because they like to fix things themselves when they break, to use their system in a manner that the distribution maintainer hasn't planned, or to know the details of how the system works.

In practice, you can't avoid it if you want to use the most common userspaces for Linux. The average user won't care about its presence per se.

Re:Why IS systemd hated so much?

[TangoMargarine]

Obviously you can type. Go look it up on Wikipedia.

The design of systemd has ignited controversy within the free software community. Critics argue that systemd is overly complex and suffers continued feature creep, and that its architecture violates the design principles of Unix-like operating systems. There is also concern that it forms a system of interlocked dependencies, thereby giving distribution maintainers little choice but to adopt systemd as more user-space software come to depend on its components.[64]

Not really

[ssam]

You also need the "--no-preserve-root" and to have a buggy motherboard UEFI implementation. The problem is that deleting stuff in /sys/firmware/efi/efivars resets some variables in the UEFI. If the implementation follows the spec then that is like doing a factory reset on your motherboard. For some poor hardware they fail to boot after this. The kernel already has some protection for some bad hardware, more will be added shortly ( https://gist.github.com/mjg59/... ).

Re:Not really

[Anonymous Coward]

The "--no-preserve-root" thing doesn't help when you "rm -rf /sys/firmware/efi/efivars".

UEFI is TCPA repackaged, nice and shiny.

[Qbertino]

I ran into this UEFI crap about half a year back, when I had to adjust some BIOS settings and couldn't, because I didn't have windows installed. I couldn't believe it. RMSes worst nightmares come true, today. Un-fucking-believable.

UEFI is just another machiavellian attempt at controlling our hardware from start to finish. It's basically the old TCPA bullshit repackaged. How the fuck anyone could install let alone design and build a BIOS whos UI is depedant on what OS is installed on the HDD is totally beyond me. I honestly am of the opinion that those who designed this freakin' insane UEFI BIOS crap and peddle it should be brought before court for malicious malpractice and willfully undermining computer security.

UEFI in my book is definitely a reason not to buy the hardware using it.

BTW: How come no one get's worked up about that? Everyone is pissing their pants about systemd, but UEFI doesn't get half as much bad press. I remember the TCPA uproar - that was a good one. How about now?

Re:UEFI is TCPA repackaged, nice and shiny.

[Anonymous Coward]

How the fuck anyone could install let alone design and build a BIOS whos UI is depedant on what OS is installed on the HDD is totally beyond me.

That has nothing to do with UEFI, per se. I'm sure they could have made the same terrible design choice with legacy BIOS.

Re:UEFI is TCPA repackaged, nice and shiny.

[Anonymous Coward]

1) I don't believe your claim that any UEFI system required Windows to make an adjustment. I have never seen, nor heard of such a thing.

2) Which systems are you buying that do not have UEFI? Please point out the plentiful selection of hardware made in the last 2-3 years without UEFI. I'll wait.

Re:UEFI is TCPA repackaged, nice and shiny.

[Anonymous Coward]

What? I seem to distinctly remember shitstorms about UEFI, even on /.
Maybe you should use some kind of a search engine.

Re:UEFI is TCPA repackaged, nice and shiny.

[Anonymous Coward]

BTW: How come no one get's worked up about that? Everyone is pissing their pants about systemd, but UEFI doesn't get half as much bad press. I remember the TCPA uproar - that was a good one. How about now?

Oh, I'm worked up. I'm just powerless to do anything about it. I knew it was all going to go wrong when MS-DOS took over.

Re:UEFI is TCPA repackaged, nice and shiny.

[omnichad]

Secureboot is only a tiny part of UEFI. BIOS is outdated.

If a motherboard maker doesn't implement a settings screen for UEFI, that's a poor implementation. But a lot of them (most) make one that looks just like what you'd find in BIOS while others make them a pretty GUI with mouse support.

BIOS has a lot of legacy garbage slowing down boot, and it doesn't support boot drives > 2TB.

Re:UEFI is TCPA repackaged, nice and shiny.

[omnichad]

BIOS doesn't have parameters in a standardized location. It would be very difficult to have this happen because nobody's going to create a unified filesystem based on wildly different implementations.

Re:UEFI is TCPA repackaged, nice and shiny.

[Anonymous Coward]

Stay away from the branded machines. Oh, you might be talking about a laptop. Never mind :(

Re:UEFI is TCPA repackaged, nice and shiny.

[thegarbz]

UEFI in my book is definitely a reason not to buy the hardware using it.

So lock yourself in a cave away from technology is the only option?

Re:UEFI is TCPA repackaged, nice and shiny.

[Anonymous Coward]

Can you name the Motherboard manufacturer? A few years back I bought an AMD based Asus Motherboard with EFI. I had no issues editing the BIOS and I never had to install Windows or special utilities that were Windows only in order to modify BIOS. It's probably down to the manufacturer and their implementation.

Either way I agree w/ you about this being complete BS. If a motherboard required Windows to edit settings I would return it as defective. My last new PC was a SuperMicro using sever components.

Re:UEFI is TCPA repackaged, nice and shiny.

[Trogre]

Mod parent up.

UEFI and its inbred cousin, Secure Boot, are a scam to give Microsoft Corporation the final say in what you can and cannot boot on your computer.

Re:UEFI is TCPA repackaged, nice and shiny.

[blind biker]

UEFI in my book is definitely a reason not to buy the hardware using it.

So lock yourself in a cave away from technology is the only option?

Your logical fallacy is: strawman.

You misrepresented someone's argument to make it easier to attack.
By exaggerating, misrepresenting, or just completely fabricating someone's argument, it's much easier to present your own position as being reasonable, but this kind of dishonesty serves to undermine honest rational debate.
Example: After Will said that we should put more money into health and education, Warren responded by saying that he was surprised that Will hates our country so much that he wants to leave it defenceless by cutting military spending.

Re:UEFI is TCPA repackaged, nice and shiny.

[Microlith]

Nothing quite like someone so prominently showing off their ignorance.

I ran into this UEFI crap about half a year back, when I had to adjust some BIOS settings and couldn't, because I didn't have windows installed.

I know the mode you speak of, it can be utilized effectively from Linux. Amusingly, it requires efivars to be writable as this article discusses.

UEFI is just another machiavellian attempt at controlling our hardware from start to finish.

Just like the BIOS was, right?

How the fuck anyone could install let alone design and build a BIOS whos UI is depedant on what OS is installed on the HDD is totally beyond me.

Fortunately, that's not at all the case. You are right about one thing: it is totally beyond you.

How come no one get's worked up about that?

Because not everyone is as blatantly ignorant about it. Or if they are, they are kindly keeping their mouths shut until they learn more.

Re:UEFI is TCPA repackaged, nice and shiny.

[thegarbz]

Not at all. Only if you interprate everything someone says as literal for the sole purpose of using the word strawman which is so cherished here on /.

Now rather than nitpicking my english why don't you instead:
- Show us current solutions that don't implement UEFI.
- Show us solutions going forward that don't implement UEFI.
- Show us how both the latest versions of Windows and the latest versions of OSX (who together make up the most common and widely used desktop OSes) without UEFI.

I was being figurative, but now that I think about it this whole locking yourself in a cave may be the only way to actually escape UEFI intrusion on the PC.

Re:UEFI is TCPA repackaged, nice and shiny.

[Anonymous Coward]

What has your complaint got to do with UEFI? Couldn't someone have just as easily designed a bad non-UEFI BIOS that required Windows?

Re:UEFI is TCPA repackaged, nice and shiny.

[LinuxIsGarbage]

TCPA is alive and well in the form of TPM

Bricked?

[MBGMorden]

Jesus I thought we'd gotten rid of that stupid "brick" term for simple issues. If it's a COMPUTER - you can't "brick" the damned thing if you take the hard drive out and throw it in a river.

"Bricked" indicates that the firmware is bad. A bad BIOS flash will brick a system. Something of that level. Anything that can be fixed via an OS reinstall ain't "Bricked".

Re:Bricked?

[wonkey_monkey]

Perhaps you try reading the summary.

"Bricked" indicates that the firmware is bad.

Yes, yes it does. And that's exactly what's being described.

Re:Bricked?

[Anonymous Coward]

We're using the term bricked here because it mounts the UEFI firmware as writable, meaning if you do a rm -rf /, you're wiping out firmware-level files. Unless the device has a management device (such as ILO or iDRAC) that can flash firmware independent of the system's ability to fully function, this is a motherboard replacement.

Re:Bricked?

[AmiMoJo]

That's what this is. Some really crappy UEFI firmware from MSI can be bricked by deleting some of the EFI variables. The only way to recover is to reflash the BIOS memory chip with an external programmer. On laptops the chip is often surface mount with no pins, so you have to desolder it with hot air, flash it and replace it.

Okay, technically it is recoverable, but in reality its well beyond the ability of most computer repair shops, if they can even figure out what the problem is.

Re:Bricked?

[Anonymous Coward]

Not a RTFA type I take it? That's the whole point of this: On certain machines, rm -rf / does indeed get the efi boot firmware into an unrecoverable situation, equivalent to a bad bios flash.

Re:Bricked?

[Anonymous Coward]

Apparently you did not read the summary or the article past that word. Running the command and removing the UEFI variables can cause the computer to be unable to POST, not even approaching fixable by OS reinstall.

Re:Bricked?

[Anonymous Coward]

Yet in this case, the MB _is_ bricked: some files /sys/firmware/efi/efivars/ hold variables for the UEFI, and deleting those files also clears such variables on NVRAM; on some motherboards, the computer fails to POST, hard drive or not.

Re:Bricked?

[Anonymous Coward]

Read the article next time, how are you going to reinstall the OS when you can't even get the motherboard to boot anything, even in Legacy BIOS mode?

Re:Bricked?

[blind biker]

How did this shite get modded "Insightful"? The poster got it wrong 100%.

In other news...

[PvtVoid]

... hitting yourself in the head with a hammer may cause headaches, or unconsciousness.

Re:In other news...

[Anonymous Coward]

Yes, but the fact is, that if I did hit myself on the head with a hamer on a system without UEFI and systemd I really can get a headache. UEFI and systemd manage to add a nice hard spike to the end of the hammer, so that it penetrates my skull.

Re:In other news...

[thegarbz]

But typically doesn't result in death.

Re:In other news...

[Anonymous Coward]

More like thinking about hitting yourself in the head with a hammer may cause blunt trauma? Nah, no way to fix this stupid and unnecessary analogy.

Immutable Bit

[PantherX]

Why don't we just set the contents to these to immutable (by default) and if there are legit reasons to change values through software, just add the subroutines to flip the bit back and forward and verify, etc. Done.

chattr +i for those who are not aware.

Re:Immutable Bit

[omnichad]

And where would that attribute be stored? On a filesystem? In RAM? I don't know how attributes are handled on other virtual filesystem trees, so I admit to being naive.

Re:Immutable Bit

[phantomfive]

Because a malicious user shouldn't be able to brick your device that way, either.
There are plenty of ways to avoid accidentally ruining a system this way (including not typing "rm -rf /") but they don't prevent a hacker from destroying your system.

Re:Immutable Bit

[Anonymous Coward]

For once I agree with phantomfive.

Kudos for not blaming systemd, not shouting "interfaces!" and not linking to your journal.

Brick..

[Anonymous Coward]

You Keep Using That Word, I Do Not Think It Means What You Think It Means

It sounds like you get to do a rebuild and not that you brick your hardware.

When you brick something you cannot rebuild it, you have reduced it to the usefulness of a brick, hence "bricked" it.

Data center...

[tekrat]

Not so easy to remove the hard drive or re-install the OS from scratch remotely. The problem people are encountering is that they are physically thousands of miles from the hardware.

I mean, for the last 10 years, I have worked on a computer I've never seen. The Mainframe is in Delaware, and I am in New Jersey.

But I can easily imagine a situation where I'm in Manhattan, but the Linux machine is located in a data center in New Mexico, or even worse, Mumbai. Effectively, I have zero access to the hardware, so yes, in such a situation the machine is effectively "bricked".

SysFS fault?

[La Gris]

Why is SysFS deleting/erasing variables/files on RM?
Can't these be handled like special device INodes?
It is not like you can delete /dev/null by accident right?

Not a bug, but a feature!

[rkoot]

nuff said

F*@king moderation

[Duckman5]

To our new overlords: Can someone please fix this lame javascript based moderation system and put in a submit button? I can't count the number of times I've picked overrated instead of funny because my finger came close enough to my touchpad to move the mouse. This whole replying to undo moderation thing is lame. At the very least there should be an undo mod button.

To AmiMoJo: Sorry for the wrong mod.

Okay, what about a "more special" directory?

[VernonNemitz]

A while back I installed Debian on an experimental system for learning more about Linux, and came away feeling a bit lost, because (compared to some other distros) there seemed to be oodles of new config files, scattered everywhere. Trying to keep track of them all was, for me, nightmarish. I wished all the config files were located in a single root-level directory (like "home"), perhaps named "cfg".
Well, if such a thing existed, that directory might be considered too valuable to be allowed to get included in any generic remove-all system command, and could thus be a safer place for the UEFI variables. One could go inside that directory and deliberately erase everything, but the specter of knowing that all the system's config files would be destroyed might give one pause,before daring to actually specify that command.

Re:Okay, what about a "more special" directory?

[mrex]

I wished all the config files were located in a single root-level directory (like "home"), perhaps named "cfg".

You've just invented /etc...

Re:Okay, what about a "more special" directory?

[bored]

Great plan until systemd started putting its "unit" files (great non descriptive name eh? its hard to come up with a less descriptive name) in /lib and then overriding them with /run and /etc.

Re:Okay, what about a "more special" directory?

[Anonymous Coward]

Great plan until systemd started putting its "unit" files (great non descriptive name eh? its hard to come up with a less descriptive name) in /lib and then overriding them with /run and /etc.

Just wait until systemd asks your favorite distro to bend over. Then you'll find out how appropriate the name is.

Re:Okay, what about a "more special" directory?

[Anonymous Coward]

Great plan until systemd started putting its "unit" files (great non descriptive name eh? its hard to come up with a less descriptive name)

It is a great name. Being the ant-init, systemd is the unit, just like 7up is the uncola. You're just mistakenly pronouncing it "yoonit" instead of "uhnit".

Re: Okay, what about a "more special" directory?

[buchanmilne]

It's better than 90% of a backup of /etc being taken up by xml schemas (of the configuration files), none of which I have ever seen the need to modify.

Yes, I'm looking at you gconf.

The systemd approach also makes it easy to identify if any files were customised.

Re:Okay, what about a "more special" directory?

[phantomfive]

But don't worry, systemd team plans to completely replace everything in /etc so it can be empty and clean.

Re:Okay, what about a "more special" directory?

[Coren22]

In Linux, the config files are "supposed" to be located in the /etc directory. Sometimes they are instead located in with the install, but that isn't the "unix way".

Re: Okay, what about a "more special" directory?

[Anonymous Coward]

Haha talking about the "unix way" in these dark ages of SystemD and UEFI...

Re:Okay, what about a "more special" directory?

[thegarbz]

This isn't as bad of an approach as you think. Just imagine what we'd be talking about right now if UEFI designers had their variables in a different location and only overwritten by another location if it existed.

I'm a fan of a hard default somewhere with a user configuration elsewhere. It would have solved this bug here and it would simplify the upgrade process for many programs.

Re:Okay, what about a "more special" directory?

[Anonymous Coward]

There was a per-user configuration directory in ~/.config/, one of the freedesktop standards IIRC, but it never seemed to catch on. The only program I remember using that is openbox.

Of course, system-wide configuration files should all be in /etc/, except for the odd program that has been installed with a custom PREFIX. It's pretty rare on Linux, but this always happens on NetBSD and FreeBSD for packages installed from pkgsrc and ports (/usr/pkg/etc/ and /usr/local/etc/)

Heh

[JWW]

So the advice is: don't delete your all you files if you want your computer to work? Huh, whoda thunk it?

Shooting ourselves a rocket in the foot.

[jtayon]

So, be it under linux or windows ... (I guess BSD too with hard enough efforts) ....ill intentioned persons can brick computers running UEFI.

Now computers could potentially be bricked remotely... progress is an amazing thing.

And adding the "rm /" in the surface of exposure is kind of adding well intentioned clumsy persons to the equation.

And everybody knows that clumsy persons are more frequent than ill intentioned persons.

This makes systemd choices almost criminal in terms of risk management.

Re:Shooting ourselves a rocket in the foot.

[jtayon]

And giving script sciddies a very easy method to leverage the bricking.... Congrats.

Boneheaded and with straightforward solutions

[FreeUser]

This is so boneheaded it beggars belief. The straightforward solution is to require the UEFI variable filesystem (or whatever it is called these days) to be mounted read-only, and require (UNIX anyway, but something analogous ought to work for Windows too) an application to do a "mount -o remount,rw" to do whatever it needs to do, then do a "mount -o remount,ro" when it's finished. Not as nice as having UEFI not be seriously broken, but workable, and there's not much of an excuse for things like systemd, openrc, etc. implementing this where appropriate (and for any UEFI crap that can brick a system, this is appropriate).

Applications don't like it? Tough, patch the damn things. Requireing firmware to be exposed to harm like this on any operating system is unacceptable.

Re:Boneheaded and with straightforward solutions

[Anonymous Coward]

Good luck if you have two different things trying to update EFI variables at the same time! What you have described is the classic enable/disable interrupts problem. A enables, B enables, then when one disables access, the other one fails. Maybe something could be added to the kernel for SysFS to request the variables be made writable and to relinquish said request (in other words, a reference counting implementation), but that would immediately break anything that already expects to be able to fuck around in the EFI variables at will.

Of course it can be argued that the real problem is crappy EFI implementations that don't check the configuration for consistency or can't boot to a state where they can be reset to defaults using a keyboard and display.

Re:Boot partition... you have that backed up right

[omnichad]

Boot partition? You have no idea what you're talking about.

an rm -rf / will wipe EFI vars as well. The motherboard will not boot anything, regardless of what is on your drives.

This would not have happened...

[Anonymous Coward]

without systemd!

Re:This would not have happened...

[Anonymous Coward]

Yes, yes it would've happened without systemd.
Particularly as it also happens on Windows.

The UEFI implementation is fundamentally broken. No piece of userland software is going to fix it in an acceptable way.
And no, mounting ro is not a fix. It's a cheap hack that doesn't do anything to alleviate the situation. It protects people from their own stupidity while breaking other applications. And black hats will still be able to remount those variables before bricking your hardware.

Mount as read-only and ...

[MacTO]

Why can't it be mounted as read-only, and remounted as read-write when necessary? Something like "mount -o rw [mount_point]" does that job.

Misplaced blame much?

[JustNiz]

If the BIOS isn't even robust enough to use defaults for critical variables that can be deleted, then I'm gonna say this is OBVIOUSLY a problem with crappy BIOS code, not with the OS that ran the app that actually did exactly what it was told to do.

Solution! Route all I/O through systemd.

[Anonymous Coward]

Its gonna happen sooner or later anyway.

Really!?

[Anonymous Coward]

Why would you run rm -rf / in the first place?

Linux gives you disk damage anyway (Try dd if=/dev/zero of=/dev/sdXXX bs=1M)

If you use Ubuntu 14.04...

[Anonymous Coward]

and have "pre-released updates" box checked in software updates, you will bork networking if you do an update. The only way to fix it is to download the stable libnl packages from another computer and transfer them with a flashdrive and reinstall them. I'm a Linux fanatic, but this was a major boo boo on the developers part. And what idiot would run rm -rf on any Linux system? That's just clickbait for Windoze idiots.

rm and POSIX

[Anonymous Coward]

The most common implementation of rm on Linux (GNU coreutils) does exactly what you're asking.

# rm -fr /

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

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

That would be violating POSIX by allowing it at all:

If either of the files dot or dot-dot are specified as the basename portion of an operand (that is, the final pathname component) or if an operand resolves to the root directory, rm shall write a diagnostic message to standard error and do nothing more with such operands.

* http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html

Solaris and FreeBSD rm(1) do the right thing as well:

* https://svnweb.freebsd.org/base/head/bin/rm/rm.c
* https://web.archive.org/web/20061101213104/http://blogs.sun.com/jbeck/date/20041001

finally a use for selinux?

[Anonymous Coward]

I'm sure selinux could be configured to allow systemd to access the uefi variables file system, while silently blocking everything else.

That said, I tend to disable selinux as it never causes anything but pain when silently stopping things from working with little to show for it.

Sarcastic recommendation of sudo rm -rf /

[tepples]

It might be for the benefit of non-technical users who don't understand that the chat or forum user recommending sudo rm -rf / is up to no good. At least if the system is bootable from install media, the user can restore /home from backup.

systemd and Linux packaging

[Anonymous Coward]

Linux package managers are well overdue for redesign.

I'm sure Pottering will oblige in due course.

Why is this being modded "Funny"? They're actually working on it:

* http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html

I don't always use rm -rf

[ChadSmith4920]

I use dd if=/dev/zero of=/dev/sda instead.

Gateway those suckers off?

[Anonymous Coward]

Would it be possible to hide the real files, make some FIFO buffer files which are read by a gateway program, which then queues writes to the real files?

* Remove immutable bit.
* Write to file.
* Set immutable bit.

You'd have to get seriously unlucky to wipe those files out after that.

Every computing device should be user-re-settable

[davidwr]

In most cases, electronic devices should be able to be reset back to a factory state by their owners, preferably with a hardware switch that cannot be disabled by any software.

Exceptions would be for things like car-odometers/disk-drive-power-on-hours logs that need to be kept for fraud-prevention or things that the customer himself doesn't want to be re-settable, like anti-theft protection.

Chernobyl Virus 2.0

[Anonymous Coward]

Anyone?

Sue em

[Anonymous Coward]

Millions of european Facebook users, journalists, NGOs complained for years about siphooning of private data over to US, achieving nothing. But in reality, it took only ONE determined student of law to actually TAKE LEGAL STEPS and KICK ZUCKERBERGS BALLS at the European court of justice.

If you really care, take action.

In other news...

[Anonymous Coward]

Running your car straight into a wall at 90mphrenders it useless.

No, the problem is the Unix "everything is a file"

[benjymouse]

The mental model of a file system - the expected behavior - is for it to be hierarchical. We silently expect anything below a certain path to be subordinate. Already this model is broken because devices can be mounted, files symlinked/hardlinked etc. That something much more fundamental to a system than a file system directory can be found deep in the hierarchy is a violation of the hierarchy.

That's why it is surprising that removing everything from the file system may cause higher order information to be deleted as well. You do not expect that. The impulse to map everything to a file deep in the filesystem is dangerous.

Sure, you can probably write/destroy UEFI variables from windows, but not as unintentional collateral damage from deleting a directory.

Dumpster divers of the world, unite!

[Anonymous Coward]

Death to the UEFI menace.

BIOS+MBR forever!

i thought phoronix knew better

[orogorhotmail.com]

Since a "few years", on "most distros", you need to pass --no-preserve-root to rm rf slash to actually do something.

Just out off office; too tired to look up exactly :
But a "few years" is about 3-5 years
"Most distros" means maybe >90% of the linux userbase
Some other unices got that new default, but as other unices are often older systems, i wouldn t bet on the userbase percentage

Re:i thought phoronix knew better

[Anonymous Coward]

The same is not true for "rm -rf /*" though and it doesn't fix the underlying issue.
If a black hat hellbent on destroying your hardware is able to take over your system, " --no-preserve-root" isn't going to be a particular barrier for that person.

PC firmware is always crap

[Anonymous Coward]

Anyone who's been reading the linux kernel mailing list since the 90s knows that most PC vendors ship BIOS/firmware/whatever that is often half or mostly broken.

Power management, in particular, is pretty bad. It's so bad that Microsoft ignores the system firmware and implements their own power management scheme, complete with a white list of known hardware and workarounds.

Why did anyone think UEFI would be different?

obCarAnalogy

[ihtoit]

I'm not going to change out my engine because tyres keep blowing, I'm going to stop driving over glass.

If there is a way to stop rm~ from killing a machine, if it's a situation I ever come across (I haven't had to think about it, to be honest, beyond noticing a system partition of 300MB on my notebook and thinking to myself "You know, that looks important, better make sure I've got a backup"), then I say thank fuck for Replay and shadow copies.

Wisdom from Grandpa

[Phreakiture]

My Grandpa was very fond of one particular expression. From time to time, I would ask him what would happen if you did X, Y and Z, where such a combination was likely to result in a Bad Thing happening.

His response was usually, "Well, you just don't do that."

dumb dumb dumb

[Anonymous Coward]

Systemd developers have rejected mounting the EFI variables as read-only, since there are valid use-cases for writing to them.

Then have those EFI variables mounted read-write when it's necessary to write to one of them. It's not like mounting something readonly sets it in stone until the end of days, and it is probably just as easy to handl

Mounting them read-only can also break other applications

If those other applications can't handle a simple error state that they can trivially recover from, then they're likely to already be broken. Either that or they're weak command line programs trying to infiltrate the strong command line program paradigm.

TL;DR: Colonel Lazyness gets promoted to General.

Re:dumb dumb dumb

[Anonymous Coward]

Those other applications are things like grub and efibootmgr.
Even if they could handle it, what is the point?

Do you honestly think it's a good idea to tape over the problem rather than actually fixing it?
When your car engine is overheating every time you hit 50 miles per hour, do you actively try to stay below 49 mph for the rest of your or your car's life or pay someone to fix it?

New Encryption-ware

[PRMan]

Next up, instead of encrypting your files, they'll just demand a bitcoin or permanently ruin your hardware...

HA HA, open sores fail.

[Anonymous Coward]

Yet another example of how open sores software is complete and utter garbage. Not only does most open source software SUUUUCK, but the whole trend of putting all sorts of random code on github is just doing little but propagating that crap code. Open sores is a development model that produces shit code, is actively HURTING the profession (as in destroying the ability of programmers to make a living, you know, WRITING GOOD CODE) and is well past its prime. I just have to wonder when the morons in the open sores community will all come to realize they have been make into cuckolds by guys like Eric Raymond and Tim O'Reilly.

Malware

[nuckfuts]

If you can brick your motherboard from userland, then so can malware.

Immutable Files

[nuckfuts]

Isn't this the kind of thing that the immutable attribute was designed for?

Easy workaround

[Anonymous Coward]

$ grep EFI .config
# CONFIG_EFI_PARTITION is not set
# CONFIG_EFI is not set
CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y

A bad rm -rf /.

[Anonymous Coward]

A bad rm -rf /. would nuke a system...it wouldn't BRICK a system.

Nuking a system is fixable....
    boot from a floppy (or something else)
    format harddrive
    reinstall.

Brick - throw system away. You're done.

Dont. Use. UEFI.

[Anonymous Coward]

Just don't
Dont. Use. UEFI.

This is a massive security problem.

[nbritton]

This is a massive security problem, someone could run this on 10,000 servers in parallel all at once and the business would be down for months replacing all the motherboards. Figure $500 and 1 hour per motherboard replacement and you are looking at 10,000 man hours and $5 million dollars in hardware damages alone.

Article summary isn't quite accurate

[fzammett]

"...Windows and other operating systems are also prone to this issue when using UEFI"

Well, no. They have the same underlying potential problem, yes... but Windows isn't susceptible to the rm -rf / since it doesn't, by default, have the rm command. These two aren't quite the same thing. The summary makes it sound like there's parity between Linux and Windows but that's not accurate. It takes about 20 lines of code (as per the article) to do the same thing on Windows. So yeah, it's a legitimate UNDERLYING problem, but let's not make it sound like it's the same situation on both platforms 'cause it's not really.

Re:Article summary isn't quite accurate

[Anonymous Coward]

Umm. But it really is the same situation.
The trigger might be different but it is the same problem.

Someone can quite easily transfer a precompiled binary of that 20 lines of code to your Windows machine and run it, thus bricking your device.

People seem to miss the real implications here. The fact that the hardware can be bricked that way, at all.

I tested this, it gets worse than the headline

[scourfish]

Not only did it erase the firmware on my motherboard, it also deleted all of my files!

A possible solution. There are probably better...

[Anonymous Coward]

1) Store EFI variables in two in 'special' partitions (flag one as current, and one as stand-by). Do not mount either of those partitions, EVER.
2) On boot, do a bit-for-bit copy of the 'current' EFI partition to a third, 'live' EFI partition. Mount *that* partition read-write.
3) On shut-down, or any time you need to save values, do sanity checks of the EFI data before doing a bit-for-bit copy of the 'live' EFI partition over the 'non-current' version, then flip the flag to mark *that* one as current, and the other as stand-by.
4) If the system can't boot from the 'current' EFI data, flip the flag, so the 'stand-by' copy is now the 'current' copy.
5) If the system can't boot from *that*, get the EFI settings from the hardware, replacing *both* the 'current' and 'stand-by' partitions' content.

Since the hardware is treated as a emergency, default-state restore cache, you never write to those via the OS.
Ideally, the hardware should prevent you from bricking it, but this will allow the OS to mitigate the risk of something wiping hardware-only EFI values.

4 digit TROLL

[Anonymous Coward]

Yes, yes. We all already knew that but don't let that stop you from posting some flamebait troll garbage! You didn't even try to disguise it as a response to someone claiming such. You just threw a new thread out there as if that's all we're talking about. Even TFS isn't blaming it. And this bullshit gets a +5 Informative! Just because he has a 4 digit UID doesn't means he's a freakin soothsayer people!

So does this mean that sysvinit...

[Anonymous Coward]

...is not subject to this ludicrously dangerous vulnerability, and systemd is?

I mean, effectively, that's the reality on the ground right now, right?

I've been neutral on systemd, more or less, but...

Re:So does this mean that sysvinit...

[Anonymous Coward]

It is subject to the very same "vulnerability", depending on the distro maintainer.
Besides. Even if a distro decided to mount EFIVars as read-only, that's not a solution at all. If a hacker gains access to your computer, he can easily remount them as read-write and brick your system.

so UEFI and systemd are causing this...

[sonamchauhan]

Good excuse to get control over your own hardware. Bring back BIOS, /init and /var/log/messages. Systemd and UEFI can stay - just so long as they add 'emulate old ways' settings :-)

No need for clean

[aberglas]

There is no need to reset the boot loader.

Most consumer machines do not even come with a replaceable operating system.

If the system gets hosed or riddled with viruses you just buy a new one. Does not happen very often. People accept that.

You hark back to days when you could have some understanding and control over your machine. Those days are long gone. Think about how a teenager interacts with a computer. That is the future.

Joanna Rutkowska is right: read-only BIOS sticks.

[anon mouse-cow-aard]

you need for the BIOS to be a read-only thing that can only be written from another computer. Yes, it can be rather inconvenient to have to have a removable BIOS stick, but it would be simple to recover from this by just removing the stick and re-writing it on another machine. http://www.pcworld.com/article... Having a read-only BIOS is great against hacking also. It also makes bios upgrades safer. You just have two sticks and always keep your old one as a backup.

No shit.

[Anonymous Coward]

"Running "rm -rf /" Is Now Bricking Linux Systems "
No shit that bricks a linux system. It has been for over 20 years! It is the "delete system32" equivalent of the unix world, except that it will also erase any user files as well.
Please use a better title like "Running "rm -rf /" Is Now Bricking UEFI Systems"

also
"Systemd developers have rejected mounting the EFI variables as read-only"
God dammit systemd. Why is it always you behind shit like this.

Re:No shit.

[Anonymous Coward]

QUOTE: "No shit that bricks a linux system. It has been for over 20 years!"

No, it hasn't. "Bricking" means to literally turn a piece of hardware into a doorstop. A system with a deleted root partition is easily recoverable. A system with a defective UEFI is not.

QUOTE: "God dammit systemd. Why is it always you behind shit like this."

'cept it's not them "behind" this, at all. Someone simply posted it to their github bugtracker.
It has nothing to do with how the variables are mounted. The problem ought to be solved on a hardware level.

Mounting those variables read-only is like opening the tiger cages at a local zoo and placing a sign in front of them that reads "Beware! Do not disturb tigers!"

UEFI is the problem

[epyT-R]

UEFI is the problem. Whatever 'enhancements' it brings belong as OS services.

is it just me...

[Anonymous Coward]

or hasn't that particular command always been a case of id10t pebkac?

newer is better

[Anonymous Coward]

not.

Do we want systemd to be our babysitter now?

[BobbyWang]

Are people seriously advocating for systemd to be a babysitter for the root user? I would definitely be more upset if systemd posed restrictions upon what I was allowed to do (as root). But, sure, I understand the problem (which Etcetera seems to be the only one to touch upon) that systemd makes it harder to strengthen the security by generally limiting the possibilities to customize your system.

People who come from a DOS/Windows background also seem to think that "rm -rf /" should be expected to work like "format c:". But the root is not just the (first) harddrive and as a user of Unix (where "everything is a file") I would rather translate it to "delete everything there is to delete, yes really". I wouldn't find it strange if stuff on the network got deleted too, not just regular files but printer queues and whatever. Not to mention all sorts of flash memory of any sort of attached device.

If anyone is to blame here it's the BIOS developer I think. A more robust implementation would have some fallback code in ROM that lets you at least install a new flash image. But while PCs have generally been quite robust (until now), where have been other more easily bricked systems. Sometimes you can remove the flash IC and rewrite it. Sometimes you just have to toss the hardware. It's annoying but it doesn't make me blame the software for not preventing me from doing the mistakes I did (which wasn't simply running "rm -rf /" by the way).

Surrender Monkeys

[vaene]

I prefer rm -fr / because then in my mind I can blame it on the French.

I still have some 27C512 around somewhere ..

[niks42]

.. of course it would be quite easy to design an in-circuit programmer, but generally they were read-only with the exception of a UV light or being left on a window sill ..