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, Insightful) by korger on Tuesday February 09 2016, @07:17PM
Many people pointed out that the cause of this problem lies in EFI itself, which allows to be written from the OS. While that is true, a responsible and secure OS would make steps to prevent that from happening, especially by accident. Instead, systemd widely exposes this problem by mounting the EFI fs read/write, all for the purpose of being able to boot into the firmware setup.
That's right, for the sake of one obscure feature, that most people shouldn't be using anyway, they create a huge vulnerability on the system. This reflects the attitude of the systemd developers in general, who prefer features to security. Even if users do not make the mistake of clobbering EFI themselves, malware can easily do that now on their behalf. In a world where malware is an increasingly bigger concern and not just for Windows users, using systemd is asking for trouble.