SoylentNews is people
SoylentNews
A number of users have reported that running "rm --no-preserve-root -rf /" not only deletes all their files (as expected), but also permanently bricks their computers (which is not). Tracing the issue revealed that the ultimate cause was that SystemD mounted the EFI pseudo-fs as read-write even when this FS was not listed in fstab, and deleting certain files in this pseudo-fs causes certain buggy, but very common, firmware not to POST anymore. A user reported this bug on SystemD's GitHub issue tracker, asking that the FS be mounted read-only instead of read-write, and said bug was immediately closed as invalid. The comment thread for the bug was locked shortly after. Discuss.
Links:
https://github.com/systemd/systemd/issues/2402
http://thenextweb.com/insider/2016/02/01/running-a-single-delete-command-can-permanently-brick-laptops-from-inside-linux/
(Score: 4, Insightful) by Anonymous Coward on Tuesday February 09 2016, @03:33AM
This this this this this. It's comments like this that occasionally make me wish I would sign up for a login so I had mod points.
This isn't a SystemD problem. SystemD has many problems, but this is not one.
This is stupid firmware decisions on top of the Really Stupid Decision, namely that firmware can be changed without moving a physical jumper like in the Good Old Days. Nothing the OS does should be able to brick a computer. If it can, that's the firmware's fault.
This is directly parallel to SQL injections. Your database should never die because some user named Robert');DROP TABLE *;-- signed up for an account. Likewise, your firmware should never allow itself to be harmed by the user, especially not to the extent that it cannot be booted again. If this means adding a jumper to the board, add the jumper. The world would be a better place with firmware update jumpers.
(Score: 4, Insightful) by KilroySmith on Tuesday February 09 2016, @03:57AM
Perhaps I'm ignorant here, but doesn't this bug imply that SystemD is deleting things that it doesn't own? That's a bug. What purpose in life is served by SystemD reaching into the EFI FS and screwing things up?
The fact that there's a firmware bug that gets triggered by this incorrect behavior doesn't excuse the incorrect behavior.
But, perhaps there's a good reason for this behavior and I simply don't know what it is.
(Score: 3, Informative) by Anonymous Coward on Tuesday February 09 2016, @04:23AM
Perhaps I'm ignorant here, but doesn't this bug imply that SystemD is deleting things that it doesn't own? That's a bug. What purpose in life is served by SystemD reaching into the EFI FS and screwing things up?
Yes, you are ignorant. SystemD ain't deleting anything. ALL it is doing is mounting the EFI filesystem read-write - exactly as the title of the submission says.
Any deletion of EFI variables is coming from somewhere else. Like doing "rm -rf /"
(Score: 5, Touché) by maxwell demon on Tuesday February 09 2016, @07:01AM
And why does it mount the EFI file system read/write, when not requested to be the user?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 4, Insightful) by TheReaperD on Tuesday February 09 2016, @08:56AM
It seems to be trying to do something similar to how PRAM works on MACs. A reserved space in the firmware that software can write data. I personally think that it is a really horrible idea but, there seems to be a lot of demand from some software vendors to be able to write data to hardware. Though I can see valid uses for it, such as storing your software serial numbers for reinstall (such as Windows 8/10) I see far more opportunities for abuse.
Ad eundum quo nemo ante iit
(Score: 2) by maxwell demon on Tuesday February 09 2016, @10:47AM
Well, as long as I, as user, can decide whether I want to enable it, I'm OK with such support. But if it is enabled unconditionally, for providing functionality I'm not even planning to use, that's not OK.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Wednesday February 10 2016, @09:52PM
> there seems to be a lot of demand from some software vendors to be able to write data to hardware
and systemd bends over, while $rookie_programmer_writing_code_in_his_spare_time would have had more security concerns. I am not surprised at systemd devs, overenthusiasm and wanting to change the world is understandable. But, fuck, what about RedHat? They write the drivers for linux FFS
(Score: 1, Insightful) by Anonymous Coward on Tuesday February 09 2016, @02:24PM
> And why does it mount the EFI file system read/write, when not requested to be the user?
Why does it mount /dev read-write when not requested to by the user?
You can nit-pick anything to death if you are motivated. None of this would be an issue if the firmware wasn't buggy in the first place.
(Score: 2) by fido_dogstoyevsky on Tuesday February 09 2016, @09:50PM
None of this would be an issue if the firmware wasn't buggy in the first place.
And if systemd wasn't sloppy enough to let that sort of bug through.
It's NOT a conspiracy... it's a plot.
(Score: 2) by HiThere on Wednesday February 10 2016, @04:32AM
Sorry, but theres *LOTS* of buggy hardware out there. When software is designed to run on that hardware it is *expected* to compensate for those bugs.
Yes, it's a hardware bug. It's **ALSO** a software bug.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2, Interesting) by Arik on Tuesday February 09 2016, @06:25PM
Because it's Poettering-ware and that's his philosophy. The 'user' is not intended to be a system administrator, the 'user' is conceived of as completely innocent of all computer skills and the system will be designed to ensure that s/he stays that way. It's nearly inconceivable for him to permit any increase in user control, in any area, because the entire thrust of his development is to disempower the user in every way possible.
Also, I haven't confirmed this so it may just be a rumor, but there was talk about using the R/W EFI disk to enable a remote-control reboot to windows on a dual-boot machine. Maybe that's considered a killer app over in systemD land?
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @06:34PM
The last comment to the bug report, by Mr. Poettering, explains why writes are enabled:
(Score: 3, Insightful) by maxwell demon on Tuesday February 09 2016, @06:41PM
And when I don't want to issue that command, then there's no point in having it writeable.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 5, Informative) by Immerman on Tuesday February 09 2016, @04:28AM
As I understand it SystemD is deleting nothing, it's simply mounting EFI in the file system as read-write.
If YOU then tell the OS to delete everything in the file system, that command obviously interacts with the RW-mounted firmware in potentially catastrophic manner, if neither the motherboard nor filesystem have appropriate safeguards in place.
Basically, you could cause this exact same problem on a SystemD-free computer simply by mounting the EFI read-write by hand. SystemD is simply taking one step that primes the system to expose the bug in other code IF you proceed to do something that is generally (but not always) considered a Very Bad Idea.
(Score: 2) by VLM on Tuesday February 09 2016, @01:05PM
If YOU then tell
Or a bug.
In this bifurcated era where smart people use pkgng and nix and whatever else and the lowliest of the noobs think "wget http:root_me_root_me_harder.sh | /bin/bash" is also a package manager, there was an example I don't remember and for some reason can't google where some commercial software shell script accidentally pulled a "rm -Rf /"
(Score: 1, Informative) by Anonymous Coward on Tuesday February 09 2016, @11:25PM
(Score: 2) by Immerman on Wednesday February 10 2016, @03:11PM
Indeed. I didn't mean to imply that you had to do it intentionally or directly, only that the user had to independently initiate the action, and that there was nothing systemD-specific about the problem.
(Score: 5, Informative) by KilroySmith on Tuesday February 09 2016, @04:36AM
OK, so this was so confusing to me that I actually spent 15 minutes reading about it.
Linux allows mounting the EFI pseudo-FS. Everybody agrees this is a good thing.
SystemD always mounts it, and mounts it RW by default, because:
When you do your "rm --no-preserve-root -rf /", the EFI filesystem starts erasing stuff - as you've requested. If, however, you're new to a SystemD-equipped system, and aren't used to the EFI FS being mounted, you will unexpectedly start screwing with the EFI FS.
A tempest in a teapot. The only problem I see here is that the choice of default mount for the EFI FS - if they had chosen ro, there'd be no issue, and "systemctl reboot --firmware" could remount the FS RW for the length of time necessary to set the variable prior to rebooting. The choice of rw is dangerous even in the case where the EFI BIOS doesn't misbehave, because unexpected write access to the BIOS variables shouldn't occur.
(Score: 2) by jimshatt on Tuesday February 09 2016, @08:49AM
(Score: 2) by HiThere on Wednesday February 10 2016, @04:39AM
I think that leaving it mounted rw when you don't need it so counts as a bug. But certainly refusing to fix the problem when it starts bricking systems counts as a bug. And an extremely bad one, though the severity of the bug is not so much in the bug itself as in the administrative process holding it in place.
Prior to this event I had thought that the problems being reported about systemd were all "teething problems" and that they would go away as the software matured. Now It looks more like they are being intentionally frozen in place, though one may speculate about the reasons for why this is being done.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 5, Insightful) by pTamok on Tuesday February 09 2016, @11:14AM
There is a principle in security, which is the 'principle of least access' - you get the minimum access needed to do your job.
In this case, systemd opening the efi filesystem as rw when it didn't need to violates that principle: it should, as you point out later in your post, only open the filesystem for rw when it _needs_ to write, given what this pseudo filesystem is actually for.
If you think this argument is wrong, reflect on why some people prefer to use strongly typed languages. In principle, you can write everything in self-modifying assembler, and treat pointers as integers and have all sorts of fun - the point is not whether you can do it, the point is whether or not you should.
Having sane defaults is a good thing.
(Score: 5, Insightful) by Thexalon on Tuesday February 09 2016, @03:08PM
You know, this is the kind of response that truly bothers me. Here we have:
- A known problem with a pretty clear description of what's wrong.
- An obvious solution, namely to mount read-write only when you actually need to, because it's dangerously stupid to have it read-write all the time (as demonstrated by the problem)
And the response from Lennart Poettering is "won't fix, because it might require a bit of extra code for a single obscure feature". That's not the response to a bug that gives me any kind of confidence that Lennart should be in charge of anything remotely resembling a critical component of most major Linux distributions.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 0) by Anonymous Coward on Friday February 19 2016, @02:55AM
You should have seen him defending breaking su because Pulseaudio somehow didn't work alongside it otherwise.
This by using systemd's pam module to alter a xdg environment variable if your ran su or su -l, so that anything that dependend on that variable to tell them where to stash their settings file would stop the initial users settings file.
His defense was that su was a broken concept.
Then later someone offered him a fix to pulseaudio so that the variable change was no longer needed. But this happened outside the bug report discussion, and the people following it had to rely on third parties to keep an eye on the various mailing lists. Eventually i think the bug report died because it was tired to a Fedora version that was no longer supported.
Then they introduce functionality to systemd that mimics su using Linux namespaces/containers.
Seriously, the whole systemd thing is a mishmash of OSX-isms, Solaris idolation, and an attempt to bypass Torvalds on kernel details by countermanding them via the init process (disabling sysreq combos, changing mount defaults, and the list keeps growing).
(Score: 5, Insightful) by bornagainpenguin on Tuesday February 09 2016, @04:16AM
Yeah? Well my response is in agreement with you to a point---nothing the OS does should be able to brick a computer. Can you guess what SystemD just did?
Oh well it's not SystemD's fault you say. It was the fault of poorly written firmware. The manufacturer made this happen.
Maybe. But just as sure as gravity sucks, the manufacturer is going to claim, just like you did that nothing the OS does should be able to brick a computer. Then they're going to ask you if this happened while running Windows. When you tell them you are running Linux they're going to say that running Linux is not supported on that hardware.
Because nothing, NOTHING an OS does should be able to brick a computer, except now thanks to SystemD Linux does brick computers. Great going guys!
You can piss about all you want about whose fault it is, but the fact of the matter is that SystemD enabled it to happen. It was a factor. And now people are without working hardware as a result. Likely unable to get any kind of warranty support on their hardware due to running unsupported operating systems, even if the hardware were brand new.
I wonder how many other standard things in Linux are capable of causing this type of trouble once SystemD has been added to the mix?
(Score: 1, Insightful) by Anonymous Coward on Tuesday February 09 2016, @05:32AM
Yup. Never heard anyone complain about this happening with WINDOZE. Just sayin'. WINDOZE never bricked your shitty laptop here. At least not in this way.
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @07:23AM
Actually, You can brick a windooze laptop, exactly in the same way and because of the same fuckup by the motherboard manufacturers. AFAIR it was a twenty-something bat file that You had to write, but still.
(Score: 2) by bornagainpenguin on Wednesday February 10 2016, @01:17AM
Look, it's not about whether or not Windows can be made to brick due to bad firmware. I'm sure that it's quite doable, this isn't the point.
The point is manufacturers are going to be able to claim that their hardware works fine in Windows, so this is the result of running an unsupported operating system on their hardware. Just like Secureboot this is about eliminating the after market use of hardware by way of installing new operating systems. It's about planned obsolescence. It's about passing the buck.
Also, let's be real here. It's not unusual to do a command wipe of the system with "rm --no-preserve-root -rf /" in *nix. It's quite a bit more unusual for some one to craft a bat file of the nature you're describing.
This is callus disregard for the hardware of others by the systemd people and their handling of this situation makes me wonder what other surprises lurk inside.
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @11:04AM
nothing the OS does should be able to brick a computer. Can you guess what SystemD just did?
It has always been the choice of the OS whether or not to allow dangerous things which can easily brick a computer. SystemD just made the choice to do so.
I remember dicking around back when Linux was first coming out. Back when you had to write it to a boot sector yourself. When there was no installer. Back then I was experimenting with my own OS (not just a kernel), but at that stage I was working on my compiler and FS and decided to booted GNU/Linux to use GCC to bootstrap my own assembler.
For fun on that GNU/Linux system I decided I'd recreate a music playing program I had used on DOS. One fun thing to do is mess with the CMOS timer to modulate the PC speaker and make it play music. Older machines had a nice big PC speaker, and it could produce far better quality audio than today's little piezoelectric beepers. Back in the old DOS / BBS days computer nerds would exchange .MOD files the way normals did mix-tapes.
Linux forced me to run such x86 assembler programs as root. I made a mistake in my code and learned that bad things can happen even using the bog hardware interfaces. On many motherboards it was trivial to corrupt your CMOS and brick the machine. One could brick the hardware on MSDOS with just a few opcodes. Back then Linux made an effort to prevent non-kernel code from bricking the machine. Sadly, now it seems those days of sanity are long gone. The entropy has cropped up in its maintainer pool, and thus it's increasingly senile brain is giving way to dementia.
All things end. It's bitter sweet watching Linux die. C'est la vie! [osdev.org]
(Score: 2) by mrchew1982 on Tuesday February 09 2016, @05:10PM
The year of the Linux desktop just went down the drain! Thanks systems! (/sarcasm)
Seriously though, in concept I agree 100%… but the reality is that unless you add another init system which would take more time to boot, you have to be able to update your bootloader from software. This dictates that there will invariably be the ability to "brick" your device.
Honestly its not new behavior, ever had a bios flash go bad? That's why the high-end gaming boards include a bios backup feature of some kind, or a socketed chip.
Now, I do agree that there should probably be some kind of hardware switch to prevent wanton rewriting of the boot software. The new Chromeboxes uses a motherboard screw to bridge two contacts.
If it is necessary to write to the bootloader all the time to change variables, it seems preposterous to me to leave your entire bootloader in a read/write state. This is why partitions were invented, store your variables in a separate one with read/write acess and a failsafe set in the read only section with the main code.
Seems to me that the devs are only concerned with one thing, boot speed. They will plough under safety and security to reduce boot times by half a second. It's sad to see the penguin fall for this, hopefully we can pull back a bit.
(Score: 2) by rleigh on Tuesday February 09 2016, @05:24PM
Most of the time, you don't even need to use efivars to update the bootloader. This is located on the EFI system partition, which is a FAT filesystem on your system disc. You only need to access the efivars to change the boot order, or to add, remove or change the loader for your linux install. None of these are regular operations; I've used it twice, ever: once to tweak the boot order (could also be done via the UEFI BIOS), and once to remove an older linux install which was wiped off the disc and needed removing from the EFI settings. So you could safely leave efivars unmounted, or mounted read-only, with zero impact on normal system operation, or on upgrade. The only time you need it writable is during installation of a brand new system, when switching bootloaders (i.e. the EFI system partition file path), and when removing an old system. There are other cases where you might want it writable, but these are atypical; it would be perfectly reasonable to mount it and/or remount it r/w on these occasions; efibootmgr and other tools could do this for you.
(Score: 2) by fido_dogstoyevsky on Tuesday February 09 2016, @10:01PM
Seems to me that the devs are only concerned with one thing, boot speed. They will plough under safety and security to reduce boot times by half a second. It's sad to see the penguin fall for this, hopefully we can pull back a bit.
But speed is SO important. It's not as if anything bad can happen [wikipedia.org] (scroll down to "Ammunition Handling").
It's NOT a conspiracy... it's a plot.