Excerpt: Running rm -rf / on any UEFI Linux distribution can potentially perma-brick your system.
As a public service announcement, recursively removing all of your files from / is no longer recommended. On UEFI distributions by default where EFI variables are accessible via /sys, this can now mean trashing your UEFI implementation.
There is this systemd bug report requesting that UEFI variables be mounted as read-only by default. Lennart Poettering had initially responded and simply said, "Well, there are tools that actually want to write it. We also expose /dev/sda accessible for root, even though it can be used to hose your system. The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root. But beyond that: root can do anything really." He then closed the ticket. --- end excerpt ---
http://www.phoronix.com/scan.php?page=news_item&px=UEFI-rm-root-directory
"And they closed the ticket"? That tuxedo on the cockroach is so elegent!
Ok, *now* tell me why we shouldn't hate systemd?
mark
Once upon a time, m.roth@5-cent.us m.roth@5-cent.us said:
Excerpt: Running rm -rf / on any UEFI Linux distribution can potentially perma-brick your system.
Did someone think running "rm -rf /" is a good idea?
Ok, *now* tell me why we shouldn't hate systemd?
This has zero to do with systemd. This is a by-product of how the kernel driver and user-space tools for EFI are implemented. The kernel driver exposes EFI variables in a writable sysfs filesystem, and so that's how the user-space tools set/update/delete the variables. Trying to force a change on that interaction from an intermediary is just wrong. If the maintainers for the EFI-related code think it should change, they'll need to coordinate that change between the kernel and user-space.
The bigger issue is that there is apparently some UEFI implementations that can't handle certain variables being deleted or overwritten. Yes, that could happen from an errant rm, but there are other ways that could happen. Vendors that can't recover in some way (like BIOS CMOS corruption can be recovered with a jumper) should be named-and-shamed as well as potentially blacklisted in some way in the EFI driver.
On Mon, 1 Feb 2016 13:44:48 -0600 Chris Adams wrote:
Did someone think running "rm -rf /" is a good idea?
Quote from one of the people who commented on that article:
QUOTE:
You have this in a script: rm -rf "${DIRECTORY}"/
Now, you have a bug in the script and ${DIRECTORY} is not initialized. You then get rm -rf / executed. One should always ensure that DIRECTORY is not empty before running this. Or better, never end with /. If you have rm -rf "${DIRECTORY}", then only rm -rf gets executed, causing rm to fail since no file/directory is provided. END OF QUOTE
On 02/01/2016 11:54 AM, Frank Cox wrote:
On Mon, 1 Feb 2016 13:44:48 -0600 Chris Adams wrote:
Did someone think running "rm -rf /" is a good idea?
Quote from one of the people who commented on that article:
QUOTE:
You have this in a script: rm -rf "${DIRECTORY}"/
Now, you have a bug in the script and ${DIRECTORY} is not initialized. You then get rm -rf / executed. One should always ensure that DIRECTORY is not empty before running this. Or better, never end with /. If you have rm -rf "${DIRECTORY}", then only rm -rf gets executed, causing rm to fail since no file/directory is provided. END OF QUOTE
Yeah, that can happen, but I remember being taught that was an extremely bad scripting practice back in 1998 when I took my first Linux class.
On Mon, February 1, 2016 1:33 pm, m.roth@5-cent.us wrote:
Excerpt: Running rm -rf / on any UEFI Linux distribution can potentially perma-brick your system.
Yes, I kind of like "rm -rf /". If my memory doesn't fail me, long ago it was one of the tricky questions in sysadmin exam (not that anymore if I read what you, Michael, write further correctly...). Anyway, let's imagine we are back then, then what
rm -rf /
will do you your system? How dramatic this command is?
Well, it definitely will obliterate your /etc with all your settings. Then it will start deleting /dev, and once it deletes the block device your root filesystem "/" lives on, all trouble ends there. So, you just take your drive, and you will be able to mount on different machine /home, /usr, /var and what's left of your / partition. /etc is gone, bit this only as dramatic as it gets (thanks for alphabetical order the command follows).
Sorry about long spam message, everybody. I just so liked that tricky question from my past, I couldn't hold myself.
Valeri
As a public service announcement, recursively removing all of your files from / is no longer recommended. On UEFI distributions by default where EFI variables are accessible via /sys, this can now mean trashing your UEFI implementation.
There is this systemd bug report requesting that UEFI variables be mounted as read-only by default. Lennart Poettering had initially responded and simply said, "Well, there are tools that actually want to write it. We also expose /dev/sda accessible for root, even though it can be used to hose your system. The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root. But beyond that: root can do anything really." He then closed the ticket. --- end excerpt ---
http://www.phoronix.com/scan.php?page=news_item&px=UEFI-rm-root-directory
"And they closed the ticket"? That tuxedo on the cockroach is so elegent!
Ok, *now* tell me why we shouldn't hate systemd?
mark
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Mon, February 1, 2016 1:56 pm, Valeri Galtsev wrote:
On Mon, February 1, 2016 1:33 pm, m.roth@5-cent.us wrote:
Excerpt: Running rm -rf / on any UEFI Linux distribution can potentially perma-brick your system.
Yes, I kind of like "rm -rf /". If my memory doesn't fail me, long ago it was one of the tricky questions in sysadmin exam (not that anymore if I read what you, Michael, write further correctly...). Anyway, let's imagine we are back then, then what
rm -rf /
will do you your system? How dramatic this command is?
Well, it definitely will obliterate your /etc with all your settings. Then it will start deleting /dev, and once it deletes the block device your root filesystem "/" lives on, all trouble ends there. So, you just take your drive, and you will be able to mount on different machine /home, /usr, /var and what's left of your / partition. /etc is gone, bit this only as dramatic as it gets (thanks for alphabetical order the command follows).
I just discovered that I couldn't even re-cite alphabet correctly today: it is /bin that you loose, but /etc alphabetically goes after /dev, so will not even loose your /etc, all you will need it to restore portion of your /dev and the whole /bib (which you can do easily if you have "twin" system around...)
Sorry about long spam message, everybody. I just so liked that tricky question from my past, I couldn't hold myself.
Valeri
As a public service announcement, recursively removing all of your files from / is no longer recommended. On UEFI distributions by default where EFI variables are accessible via /sys, this can now mean trashing your UEFI implementation.
There is this systemd bug report requesting that UEFI variables be mounted as read-only by default. Lennart Poettering had initially responded and simply said, "Well, there are tools that actually want to write it. We also expose /dev/sda accessible for root, even though it can be used to hose your system. The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root. But beyond that: root can do anything really." He then closed the ticket. --- end excerpt ---
http://www.phoronix.com/scan.php?page=news_item&px=UEFI-rm-root-directory
"And they closed the ticket"? That tuxedo on the cockroach is so elegent!
Ok, *now* tell me why we shouldn't hate systemd?
mark
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++ _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
wait. would deleting the inode /sys/(whatever) actually modify UEFI memory? sure, writing to those inodes could do all sorts of harm, but deleting the inodes in the /sys filesystem, I'm not so sure this isn't a tempest in a teapot so to speak.
John R Pierce wrote:
wait. would deleting the inode /sys/(whatever) actually modify UEFI memory? sure, writing to those inodes could do all sorts of harm, but deleting the inodes in the /sys filesystem, I'm not so sure this isn't a tempest in a teapot so to speak.
It's going to get /boot. And under there, it'll get /boot/EFI.
mark
On 2/1/2016 2:07 PM, m.roth@5-cent.us wrote:
John R Pierce wrote:
wait. would deleting the inode/sys/(whatever) actually modify UEFI memory? sure, writing to those inodes could do all sorts of harm, but deleting the inodes in the /sys filesystem, I'm not so sure this isn't a tempest in a teapot so to speak.
It's going to get /boot. And under there, it'll get /boot/EFI.
so it will delete inodes there... does that damage the EFI hardware? I would think you'd have to open files and write data to actually modify the EFI stuff.
my only C7 systems right now are VMs which don't have uefi, so I can't look and see what all this stuff actually is.
John R Pierce wrote:
On 2/1/2016 2:07 PM, m.roth@5-cent.us wrote:
John R Pierce wrote:
wait. would deleting the inode/sys/(whatever) actually modify UEFI memory? sure, writing to those inodes could do all sorts of harm,
but deleting the inodes in the /sys filesystem, I'm not so sure this isn't a >tempest in a teapot so to speak.
It's going to get /boot. And under there, it'll get /boot/EFI.
so it will delete inodes there... does that damage the EFI hardware? I would think you'd have to open files and write data to actually modify the EFI stuff.
my only C7 systems right now are VMs which don't have uefi, so I can't look and see what all this stuff actually is.
Yeah, I don't think we really know, until someone's willing to brick a many-thousand-dollar server....
mark
On Mon, February 1, 2016 4:24 pm, Gordon Messmer wrote:
On 02/01/2016 01:59 PM, John R Pierce wrote:
would deleting the inode /sys/(whatever) actually modify UEFI memory?
Yes. That is how the UEFI management interface works.
Will doing
rm -rf /
actually delete anything in /sys? IMHO, not. The above command first will get to removing /dev, and it will delete /dev/sda1 or whichever device / filesystem lives on. And after that the command will fail, as there will be nothing accessible under / on that system after device root filesystem "/" lives on will be deleted. So, IMHO, that nasty command will never get to /sys, so all related to UEFI vars controlled through /sys filesystem will stay as they are. You will brick the box, but only in a sense you will have to restore /boot on your hard drive and /bin which these days is symlink (on CentOS 7), so actual content of /usr/bin where symlink points will stay intact. And portion of /dev - whatever alphabetically is before root filesystem device.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On 02/01/2016 02:46 PM, Valeri Galtsev wrote:
Will doing
rm -rf /
actually delete anything in /sys? IMHO, not.
Yes, it will. Probably. It's possible that it'll hang on some of the files in /proc if it gets to that directory before /sys, but that's largely a matter of chance.
The above command first will get to removing /dev, and it will delete /dev/sda1 or whichever device / filesystem lives on. And after that the command will fail, as there will be nothing accessible under / on that system after device root filesystem "/" lives on will be deleted.
Access to your filesystems doesn't depend on the device nodes after they're mounted. You can remove all of the nodes in /dev, and your filesystems remain available. Spin up a VM and test it. I promise, it works.
And portion of /dev - whatever alphabetically is before root filesystem device.
rm doesn't process files in alphabetical order. It processes them in directory order, which is unpredictable.
On 02/01/2016 01:48 PM, Valeri Galtsev wrote:
I just discovered that I couldn't even re-cite alphabet correctly today: it is /bin that you loose, but /etc alphabetically goes after /dev, so will not even loose your /etc,
I'm pretty sure none of that is correct. Once "rm" launches, all of the libraries and files that it needs are memory mapped and reference counted, so they're going to remain available while it removes the entire filesystem structure.
Spin up a VM and try it out.
On Mon, February 1, 2016 4:23 pm, Gordon Messmer wrote:
On 02/01/2016 01:48 PM, Valeri Galtsev wrote:
I just discovered that I couldn't even re-cite alphabet correctly today: it is /bin that you loose, but /etc alphabetically goes after /dev, so will not even loose your /etc,
I'm pretty sure none of that is correct. Once "rm" launches, all of the libraries and files that it needs are memory mapped and reference counted, so they're going to remain available while it removes the entire filesystem structure.
All true, except for: to actually write stuff permanently to hard drive (that is modify whatever the content of hard drive is) the system needs to access /dev/sda1 (I call from now /dev/sda1 device which "/" filesystem lives on), and once /dev/sda1 is deleted there will be no further hard drive write operations. There will be no way for system to access anything under /, which will cause "rm" command to fail fataly. I will kickstart install centos 7 in a moment and will do exactly this:
cd /
rm -rf /
(the first command is to avoid even "can not get CWD", which shouldn't matter ;-)
So, I'll see in a moment how much I'll loose on the drive, and will it or will it not be sufficient to rsync /boot from "twin" box, and restore /bin symlink. Will get back with either "crap, indeed I was wrong", or "yes, even on latest CentOS 7 system it is still so". Whatever the result is, I'll enjoy this experiment. Thanks for giving me incentive to do it!
Incidentally, let me know if there is anything I should change in my experiment for that to give us more definite answers that just "oh, look, I still have /etc, /home, /usr... intact on hard drive". What specifically should I do to learn that in a course of this command /sys was never touched? Any ideas?
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Once upon a time, Valeri Galtsev galtsev@kicp.uchicago.edu said:
All true, except for: to actually write stuff permanently to hard drive (that is modify whatever the content of hard drive is) the system needs to access /dev/sda1 (I call from now /dev/sda1 device which "/" filesystem lives on), and once /dev/sda1 is deleted there will be no further hard drive write operations.
Incorrect. Once the filesystem is mounted, the kernel access doesn't go through the filesystem /dev node, similar to how once rm is running, it doesn't need the /lib64/libc.so.6 node.
Excerpt: Running rm -rf / on any UEFI Linux distribution can potentially perma-brick your system.
"And they closed the ticket"? That tuxedo on the cockroach is so elegent! Ok, *now* tell me why we shouldn't hate systemd? mark
As much as I don't like systemd, it has NOTHING to do with system and everything to a poor admin or newbie blindly following others advice.
My suggestion is to ALWAYS fully qualify *ANY* directory you want to rm -rf, period.
I speak from experience. Years ago had a script that would cd into a directory and then rm - rf * it. Problem started when I accidently deleted said dir and the PREVIOUS dir was /. Needless to say, the server was happily committing suicide before I figured out the problem.
Lessons learned: 1. Fully qualify ANY rm -rf command 2. Make sure you always have good backups, I did! 3. I became really, really good at disaster recovery :) 4. Upper Management WILL get cranky over an event like this!
Just my 2 cents worth...
Richard
--- Richard Zimmerman Systems / Network Administrator River Bend Hose Specialty, Inc. 1111 S Main Street South Bend, IN 46601-3337 (574) 233-1133 (574) 280-7284 Fax
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of m.roth@5-cent.us Sent: den 1 februari 2016 20:34 To: CentOS Subject: [CentOS] In A UEFI World, "rm -rf /" Can Brick Your System
As a public service announcement, recursively removing all of your files from / is no longer recommended.
I'm not following, has it ever been recommended (on a working system)??
Or is this one of those ironic posts? 8-)
In article 75D47FDC6A99F24F87A6465BAF326D5018C50F69@COLUMBA02.user.uu.se, Sorin Srbu Sorin.Srbu@orgfarm.uu.se wrote:
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of m.roth@5-cent.us Sent: den 1 februari 2016 20:34 To: CentOS Subject: [CentOS] In A UEFI World, "rm -rf /" Can Brick Your System
As a public service announcement, recursively removing all of your files from / is no longer recommended.
I'm not following, has it ever been recommended (on a working system)??
Or is this one of those ironic posts? 8-)
I think the point is that hitherto, if you kill a system with "rm -rf /", you can still do a re-installation from scratch. If I understand correctly what people are saying, killing the UEFI stuff stops you ever being able to do a re-install on that box. Is that correct? Is there no way to do a factory reset of the BIOS?
Cheers Tony
On Tue, 2 Feb 2016 10:18:09 +0000 (UTC) Tony Mountifield wrote:
killing the UEFI stuff stops you ever being able to do a re-install on that box. Is that correct?
Apparently so.
Is there no way to do a factory reset of the BIOS?
Apparently not.
Once upon a time, Frank Cox theatre@melvilletheatre.com said:
On Tue, 2 Feb 2016 10:18:09 +0000 (UTC) Tony Mountifield wrote:
killing the UEFI stuff stops you ever being able to do a re-install on that box. Is that correct?
Apparently so.
Just to clarify: this appears to be a problem with some particular buggy UEFI implementations; this is not a universal problem with the UEFI design or anything. It is unclear (just "some MSI boards") which models/revisions/etc. have this particular problem. There have been other isolated UEFI implementation problems before (some Samsung laptops for example, with a particular UEFI version and Linux kernel driver version plus a samsung-laptop driver enabled).
This isn't meant to diminish the impact; certainly UEFI is proving to be problematic in ways the BIOS wasn't (although the early days of "IBM compatible BIOS" implementations also had weird issues from time to time).
-
Alice Wonder -
Chris Adams -
Frank Cox -
Gordon Messmer -
John R Pierce -
m.roth＠5-cent.us -
Richard Zimmerman -
Sorin Srbu -
tony＠softins.co.uk -
Valeri Galtsev