Running "rm -rf /" Is Now Bricking Linux Systems (phoronix.com)
699
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.
LOL, what? (Score:4, Interesting)
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? (Score:5, Insightful)
Re:LOL, what? (Score:5, Informative)
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? (Score:5, Interesting)
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 [intel.com]). 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.
Comment removed (Score:5, Interesting)
Re:LOL, what? (Score:4, Insightful)
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: (Score:3)
It's worth noting that, according to ex-kernel hacker Matthew Garrett [twitter.com], 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? (Score:4, Insightful)
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: (Score:3)
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: (Score:3, Insightful)
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).
Huh? (Score:4, Funny)
It's just now bricking systems? Wow, all this time I could have been running "rm -rf /" with reckless abandon ...
Re:Huh? (Score:5, Informative)
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
What the doctor ordered... (Score:4, Insightful)
Have you tried not running rm -rf /?
Re:What the doctor ordered... (Score:5, Insightful)
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.
I never run rm -rf (Score:2)
Systemd developers have rejected (Score:2)
...Systemd developers have rejected mounting the EFI variables as read-only...
So the sane solution is rejected because the underlying design is bad?
Re: (Score:2)
...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 (Score:4, Insightful)
...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: (Score:3)
at least, of having them often enough that "remount as writeable only when needed" isn't viable.
Re: (Score:3)
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
Re: Systemd developers have rejected (Score:4, Informative)
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.
Well... EVERYTHING is a file! (Score:5, Informative)
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: (Score:2)
Are systemd devs all retards? (Score:3, Insightful)
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: (Score:3)
exactly, why not mount them read-only by default, with the ability to re-mount as read-write as needed?
low SNR these days on /. (Score:3)
The
Re: low SNR these days on /. (Score:2, Insightful)
@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: (Score:3)
That is because your keyboard is part of systemd.
low SNR these days at /. (Score:5, Informative)
The kernel dev who wrote the efi code says [twitter.com] 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.
This is why BIOS is separate (Score:4, Insightful)
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 (Score:5, Insightful)
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.
Perhaps some terminal commands should be locked (Score:3)
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. [howtogeek.com] 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 (Score:5, Informative)
Hype Brick or real Brick? (Score:3)
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? (Score:4, Informative)
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.
Not really (Score:3)
UEFI is TCPA repackaged, nice and shiny. (Score:4, Interesting)
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 [wikipedia.org] 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. (Score:4, Funny)
Nothing quite like someone so prominently showing off their ignorance.
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.
Just like the BIOS was, right?
Fortunately, that's not at all the case. You are right about one thing: it is totally beyond you.
Because not everyone is as blatantly ignorant about it. Or if they are, they are kindly keeping their mouths shut until they learn more.
Bricked? (Score:3, Insightful)
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? (Score:4, Informative)
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? (Score:4, Informative)
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.
In other news... (Score:3)
... hitting yourself in the head with a hammer may cause headaches, or unconsciousness.
Misplaced blame much? (Score:3)
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.
Re: (Score:2)
Yeah but viruses and spelling mistakes do actually happen.
Re: (Score:2)
Re: (Score:2, Insightful)
Re:Gonna get lambasted for this but... (Score:5, Insightful)
Re:Gonna get lambasted for this but... (Score:5, Informative)
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 [twitter.com] on that Github bug report [github.com] that the Great And Powerful Lennart saw fit to remove [github.com]:
And furthermore, systemd is keeping it R/W because it's a apparently feature not a bug:
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: (Score:2)
Re: (Score:3)
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 expl
Re: (Score:3)
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 pa
Re:Gonna get lambasted for this but... (Score:5, Informative)
Re:Gonna get lambasted for this but... (Score:5, Interesting)
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... (Score:4, Interesting)
Re: (Score:2)
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 wh
Re:Gonna get lambasted for this but... (Score:4, Informative)
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: (Score:3)
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
Re: (Score:2)
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.
Re:What else did you think would happen. (Score:5, Insightful)
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: (Score:3)
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!
No, the problem is the Unix "everything is a file" (Score:3)
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 d
Re:"Systemd developers have rejected ..." (Score:5, Interesting)
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: /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.
-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
Re: (Score:3)
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: (Score:3)
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 ..." (Score:5, Interesting)
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 ..." (Score:4, Insightful)
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 ..." (Score:5, Informative)
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: (Score:3)
Re: (Score:3)
Re: (Score:2)
Re: (Score:3)
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.
FUD on top of FUD (Score:5, Informative)
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: (Score:3, Interesting)
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 (Score:5, Insightful)
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 (Score:4, Funny)
Linux package managers are well overdue for redesign.
I'm sure Pottering will oblige in due course.
Re: (Score:3, Insightful)
> 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: (Score:3, Insightful)
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: (Score:3)
We're not talking about hosing the OS. We're talking about hosing the motherboard.
Re:Isn't this what --preserve-root is for? (Score:5, Insightful)
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: (Score:3, Interesting)
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: (Score:3, Informative)
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? (Score:5, Informative)
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? (Score:5, Insightful)
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:Okay, what about a "more special" directory? (Score:5, Informative)
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? (Score:5, Insightful)
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? (Score:3)
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:Isn't this what --preserve-root is for? (Score:5, Insightful)
"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: (Score:3)
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? (Score:5, Informative)
Re:Isn't this what --preserve-root is for? (Score:5, Informative)
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 [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. 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? (Score:5, Insightful)
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: (Score:3)
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: (Score:3)
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: (Score:3)
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 difficul
Re: (Score:3)
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: (Score:3)
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? (Score:5, Interesting)
Re: (Score:3)
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? (Score:4, Insightful)
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: (Score:3)
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