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