13 ms·

Linux 4.5-rc5: efivarfs fixed to avoid “rm -rf /” bricking UEFI

279 points by the_why_of_y 11y ago

chm 11y ago
Well that is a nice follow-up! However I can't remember if I read someone arguing this was a feature...
- deleted 11y ago
  [deleted]
tvbn 11y ago
They disabled kernel feature to prevent systemd bug? It doesn't make any sense.
- cmurf 11y ago
  They disabled a kernel feature to work around a firmware bug (which not all computers have). The firmware really shouldn't allow modification of things that will cause the firmware to permanently face plant.
- cbd1984 11y ago
  This is a firmware bug. How is it related to systemd?
- Mic92 11y ago
  It is not disabled, but a immutable flag is set. You can still delete it by applying `chattr -i` first
- kbenson 11y ago
  It's not a systemd bug, it was just exposed by systemd. This was what most everyone seemed to completely miss in the prior exchanges. Another thing that was missed was that Lennart wasn't being unreasonable, nor was he saying it wasn't a problem (he specifically stated the opposite, in fact). I had a feeling at the time (based on his responses) that the reason he wasn't specifically stating he was going to fix it or open a bug report for it in systemd was that he was going to push it up-stack to a more appropriate place, and it looks like that's what happened.
  - captainmuon 11y ago
    I'd say it wasn't a bug in systemd's implementation, it was a bug in the design of systemd. Why require that evivarfs be mounted at runtime? You could easily make it so that it is only mounted at boot time if neccessary, or only when you run a tool that wants to write to EFI. I'd expect file operations to only permanently affect storage devices per default. Sure you can mount almost anything as a file in Unix, but to automatically mount more than necessary is bad design. It's like placing mystery files in the filesystem, and when a curious user deletes or modifies them, they loose their monitor's color profile, there printer's firmware, or all of their GMail attachments. You could say it was the user's fault to mess with it, but I'd say it's weird to expose such things as files (unless explicitly asked for by the user or a tool).
    - sandGorgon 11y ago
      EVERY single init system mounts it's rw. It is not specific to systemd. There are lots of situations where EFI boot variables need to be set by the OS. Systemd is as consistent as upstart in this.
      - Sanddancer 11y ago
        No. Sane operating systems don't present UEFI variables as a filesystem. Their structure, their contents, everything are not files. Period. efivarfs doesn't expose metadata regarding when variables are visible, does't expose any sort of interface to present a private key for managing secure variables, etc. It's just a bad, broken idea that should be completely removed.
        mjg59 11y ago
        > does't expose any sort of interface to present a private key for managing secure variables Nor does UEFI. The key is just provided as part of the SetVariable() payload.
        the_mitsuhiko 11y ago
        > No. Sane operating systems don't present UEFI variables as a filesystem Probably. But that's not systemd's fault.
- pavanky 11y ago
  It's not a systemd bug, it is not a kernel bug. It was a firmware bug. It is usually the Linux kernel that "fixes" these idiotic issues when vendors don't implement something correctly.
Mic92 11y ago
Instead of flaming systemd developers for mounting efivars read/write, the kernel is the right place to fix the problem for everybody!
- ajross 11y ago
  No, the firmware is the right place to fix the problem. A BIOS that bricks itself because of within-specification deletion of variables via a standard API is just plain broken. But in the real world no one ever fixes firmware bugs, so this is the best we can do.
  - kbenson 11y ago
    I think we can all compromise on "The firmware is the right place to fix the problem, the kernel is the right place to mitigate the problem."
    - ktRolster 11y ago
      Not really. Systemd could have fixed it, but it would have been a lot of work and a hack. The Linux kernel team could have fixed it, but it would have been a lot of work and a hack. The hardware manufacturers should have fixed it, but they don't care. The Kernel team showed they are professionals by stepping up and doing the work.
      - ambrice 11y ago
        What you mean is: systemd could have fixed it, but it would have been a lot of work and a hack that wouldn't help you when efivarfs gets mounted on a sysv/upstart/openrc system. The kernel was the best place for the fix.
      - GhotiFish 11y ago
        disagree. It's not just systemd that could mount efivars as read/write, anyone could. So anyone that does will fall prey to this. It's firmware, and failing that, the kernel protecting you is a good second.
nkurz 11y ago
For context, this is in reference to a bug that was discussed a couple weeks ago: https://news.ycombinator.com/item?id=10999335 https://news.ycombinator.com/item?id=10999335 Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm' Essentially, systemd defaulted to a configuration where the computer's motherboard could be permanently destroyed by removing a 'file' from the command line. The bug reporter argued that this was unduly dangerous, but the systemd developers thought that systemd was working as intended. Here's a reasonably impartial discussion on a FreeBSD list that gives an overview: https://forums.freebsd.org/threads/54951/ https://forums.freebsd.org/threads/54951/ And from that thread, here's a link to Matthew Garrett (the creator of efivarfs) saying that efivarfs is at fault here rather than systemd: https://twitter.com/mjg59/status/693494314941288448 https://twitter.com/mjg59/status/693494314941288448
- kbenson 11y ago
  > but the developer's thought that it was working as intended Really? Is that evidenced by Lennart's response to this, which stated "The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root."[1]? I think it implies the opposite. 1: https://github.com/systemd/systemd/issues/2402 https://github.com/systemd/systemd/issues/2402
  - loeg 11y ago
    The firmware author(s) should not brick their hardware when EFI variables are deleted. That is an invalid behavior.
    - kbenson 11y ago
      Agreed, but that's almost a non-sequitur. The systemd developers are not the firmware developers. Additionally, while preferably we would have better firmware that couldn't be bricked in this way, we live in a world where this is often not the case, so the problem does need to be mitigated in some manner.
    - pyre 11y ago
RaleyField 11y ago
It shouldn't be possible to brick UEFI if it was sanely designed. That's a bad firmware.
- protomyth 11y ago
  Yes, its bad firmware, but the OS shouldn't allow a user to brick a machine even if the hardware vendor has broken firmware. Discovering the problem is unfortunate, but the OS folks not roping that area off is just wrong.
- semi-extrinsic 11y ago
  As usual when someone mentions "UEFI" and "sane" in the same sentence, I post this quote from Matthew Garret [1] (of Linux EFI maintainer fame): """ UEFI stands for "Unified Extensible Firmware Interface", where "Firmware" is an ancient African word meaning "Why do something right when you can do it so wrong that children will weep and brave adults will cower before you", and "UEI" is Celtic for "We missed DOS so we burned it into your ROMs". """ [1] https://lwn.net/Articles/444666/ https://lwn.net/Articles/444666/
  - yuhong 11y ago
    http://linux.slashdot.org/comments.pl?sid=8693705&cid=51419159 http://linux.slashdot.org/comments.pl?sid=8693705&cid=514191...
devit 11y ago
It seems to me that the real issue is that "rm -rf" should by default not recurse into mounted filesystems, but should at most try to unmount them. In addition to clearing EFI variables, the current behavior will also attempt to clear any mounted removable drives and any mounted network drives, which is usually even more harmful than messing with EFI. Of course that would be a backwards incompatible change, although I don't think many scripts rely on this behavior.
- Etzos 11y ago
  To be fair "rm -rf /" doesn't just work. You have to confirm that you really do want to delete everything. Destroying / in itself is pretty harmful. If you're planning to do that you should already know not to have anything you want to keep mounted.
  - protomyth 11y ago
    For the few use cases where a system admin wants to "rm -rf /", there are hundreds of bad scripts that can screw up a system. I believe Solaris did the right thing and made it not work. https://www.youtube.com/watch?v=l6XQUciI-Sc&t=81m https://www.youtube.com/watch?v=l6XQUciI-Sc&t=81m
    - Etzos 11y ago
      To be clear, the problem described in the video is not something that can happen. "rm -rf $1/$2" where $1 and $2 aren't defined (therefore making it "rm -rf /") will not run. If you really want to destroy your root directory you have to specify the --no-preserve-root flag. No more accidents from scripts that assume things poorly, but it will still do exactly what the user asks.
      - protomyth 11y ago
        Yet, I can still delete my home directory by accident (e.g. Steam patch). The idea that any rm can kill the directory I'm in is just bad. A flag on rm is the wrong solution. It should just fail.
chris_wot 11y ago
Ok, so I was wrong when I said Lennart Pottering's original response was "pretty appalling". Unlikely he saw it, but my apologies nonetheless.
- coldpie 11y ago
  Poettering gets shit on a lot. While his software does often have problems, he is really well-intentioned and working on really hard things that really do need fixing. New software simply has bugs and problems, and while the transition period can be rough, I think things will be really improved when we break through to the other side.
  - icebraining 11y ago
    While systemd bugs are often cause for rejoice and schadenfreude by its critics, I think you're underestimating the argument. "The other side", that is, the vision that the Poettering et all have for the Linux environment is the issue that the critics have against systemd, not the bugs and other occasional issues. I say as someone still ambivalent, not pro nor against it.
  - cyphar 11y ago
    People don't hate systemd because it has bugs. People hate it because it's clear that it thinks it owns your system and that its manifest destiny is to contain all software that exists.
    - coldpie 11y ago
      This is obviously hyperbolic.
    - cbd1984 11y ago
      No, they hate it because they think hating it is a good way to troll people. It isn't honest hatred, it's just dancing around making ugly faces, like a six-year-old.
      - 11y ago
ktRolster 11y ago
This commit message shows why I like the Linux Kernel team: >These fixes are somewhat involved to maintain >compatibility with existing install methods >and other usage modes, while trying to turn >off the 'rm -rf' bricking vector. They go out of their way to make sure changes are backwards compatible.
- 5ilv3r 11y ago
  Like unbricking ftdi chips, the kernel team has a great track record of taking care of users where the vendors fuck them over.
- EmanueleAina 11y ago
  It's also the good reason why having systemd mount efivars read-only would have been the wrong thing to do.
gpm 11y ago
So if I understand this correctly, now instead of bricking the system it will just fuck up the bootloader, even if the bootloader is completely unrelated to the linux install you are `rm -rf /sys`ing. Since the useful efivars that set up bootloaders must be on the whitelist. It's an improvement, but it seems like we should do this in addition to default mounting read only.
- protomyth 11y ago
  It still seems to me that Linux should follow FreeBSD and not mount it as a filesystem and just use a library to manipulate the values. It clearly has some huge problems with being a filesystem. This isn't Plan 9 and everything does not have to be a file.
  - eternal_july 11y ago
    Of course everything doesn't have to be a file (it is only that way on Unices). On Linux everything is a filesystem!
  - floatboth 11y ago
    FreeBSD actually doesn't have any support for EFI variables at all! It just installs the loader into the default location (bootx64.efi) and the loader does everything.
    - protomyth 11y ago
      I guess I counted the loader as part of the system. Its installed by FreeBSD to do the job.
babarock 11y ago
A lot of people are busy arguing who to blame, I just think it's interesting that sometimes you need to support non-standard software. Actually, I think it's interesting that highly successful programs are not the ones who go "not my fault, you should just implement the spec better". Raymond Chen talked[1] about the importance of supporting that ran on Win95 but broke on WinXP, even if they weren't complying to Microsoft specs. I also remember reading that web browsers had to go to great length to render completely non-compliant web pages. In your experience, when should you decide to support "non-complying" behavior? [1]: Unfortunately I cannot find the original article by Chen but I could find extensive mentions of it in [this article by Joel Spolsky](http://www.joelonsoftware.com/articles/APIWar.html http://www.joelonsoftware.com/articles/APIWar.html)
- fpgaminer 11y ago
  This may be the Raymond Chen article you are referring to: https://blogs.msdn.microsoft.com/oldnewthing/20031224-00/?p=41363 https://blogs.msdn.microsoft.com/oldnewthing/20031224-00/?p=...
smaili 11y ago
I've never actually seen or had the courage to attempt "rm -rf /". Does anyone know what would happen if it were run?
- TazeTSchnitzel 11y ago
  You wipe your mounted disks.
  - qb45 11y ago
    ... and remote filesystems.
- floatboth 11y ago
  You wouldn't be able to run any programs from the hard drive, and when you reboot, you'll end up with no operating system. Unless you're running FreeBSD (or Illumos) with ZFS and Boot Environments, in which case you'd just select a backup boot environment and continue working :-) Probably without your home directory though, as that is usually excluded from boot environments. But you can set them up however you want. But if you're running Linux (before this update) on a laptop with terrible piece of shit firmware, you'd end up with a brick. P.S. found a cool post about rm -rf / in my bookmarks: https://lambdaops.com/rm-rf-remains/ https://lambdaops.com/rm-rf-remains/ – you can recover a running rm'd Linux machine by using a running shell and /dev/tcp :D
  - qb45 11y ago
    > P.S. found a cool post about rm -rf / in my bookmarks: https://lambdaops.com/rm-rf-remains/ https://lambdaops.com/rm-rf-remains/ – you can recover a running rm'd Linux machine by using a running shell and /dev/tcp :D Awesome. This dynamic loading of bash plugins is mad.
  - dingo_bat 11y ago
    I wanna try it out but I'm not brave enough to do it directly in my OS. WHat would happen if I did it in Ubuntu inside a VM? What if VirtualBox has mounted some directory on my system to the guest? I'm afraid to try this too :/ I once tried 'format C:' on a Windows 10 laptop I didn't care about and I just got a boring error message.
useerup 11y ago
This is a case of a leaky abstraction (https://en.wikipedia.org/wiki/Leaky_abstraction https://en.wikipedia.org/wiki/Leaky_abstraction). The "everything is a file" philosophy is the real problem here. Specifically, the way a mental model of a hierarchy is broken by mounting a higher-order ressource (UEFI variables) as a subordinate of a file system that is itself a subordinate of the OS. UEFI vars are just hardware resources. Mapping them as a file system object is just unnatural and, yes, stupid. Trying to use a permission model ("only root can do it") overlooks the real problem: The user do not expect higher order objects to be mapped as subordinates of the file system. When you delete from the file system, you expect objects to be deleted from the disk - not UEFI variables to be altered or deleted! And because the user does not expect such behavior, there's a good chance she/he will override warnings and go ahead with the operation expecting only file system objects to be affected. This is "everything is a file" taken a bridge too far.
- mjhoy 11y ago
  Where does Linux promise that files are bits on a disk? As a user I certainly don't expect that. Perhaps you have a problem with the name "file" but the abstraction itself still seems useful. (And yet I do find it quite odd when I have to do something like `echo "TPAD" > /proc/acpi/wakeup` to disable wake-on-trackpad.) That said I don't disagree with you that UEFI variables should not be delete-able, but there are many files on Linux that you can't delete.
  - jerf 11y ago
    I agree that there's no promise it's a file. After all, fuse will let you mount anything as a filesystem. But I'm trying to think of another file I can "delete" and permanently hose my computer, but I'm coming up blank. Maybe some fuse filesystem somewhere can do it, but none of the ones I've used. I mean, yeah, I've destroyed many a partition table in my day, and I've permanently lost myself some data, I've even dd'ed in the wrong direction with no recourse but to suck it up and deal with it, but I've never fried a computer with a rm command. (Contrary to what some commenters seems to be viciously defending, this does seem to be a legitimately different level of destructive possibility than has conventionally been available. This is the sort of thing that would put me off having ever installed Linux in the first place.)
deleted 11y ago
[deleted]
literally_ 11y ago
And so, when we say "permanently destroy" do we really mean that something is "destroyed" and so done with "permanence"? This motherboard... It refuses any sort of reflashing of the firmware? Taking the button cell out of the battery slot, and removing all power from the board does nothing? The motherboard won't enter BIOS, upon pressing F10 at power on? What is this... "bricking" we speak of, here?
- nkurz 11y ago
  Yes, this is one of the rare cases where "brick" is being used in the correct technical sense of rendering the motherboard permanently unusable without repairs involving a soldering iron. There is no reset option.
  - Laforet 11y ago
    Depends on the package used it may be possible to reprogram the UEFI chip in situ with test clips[1]. But of course one will still need to acquire a reprogrammer and a know good copy of firmware. [1]https://www.digikey.com/product-search/en/test-and-measurement/test-clips-ic/2294786 https://www.digikey.com/product-search/en/test-and-measureme...
milkey_mouse 11y ago
good

279 points by the_why_of_y 11y ago

chm 11y ago

Well that is a nice follow-up! However I can't remember if I read someone arguing this was a feature...

deleted 11y ago
[deleted]

tvbn 11y ago

They disabled kernel feature to prevent systemd bug? It doesn't make any sense.

cmurf 11y ago
They disabled a kernel feature to work around a firmware bug (which not all computers have). The firmware really shouldn't allow modification of things that will cause the firmware to permanently face plant.
cbd1984 11y ago
This is a firmware bug. How is it related to systemd?
Mic92 11y ago
It is not disabled, but a immutable flag is set. You can still delete it by applying `chattr -i` first
kbenson 11y ago
It's not a systemd bug, it was just exposed by systemd. This was what most everyone seemed to completely miss in the prior exchanges. Another thing that was missed was that Lennart wasn't being unreasonable, nor was he saying it wasn't a problem (he specifically stated the opposite, in fact). I had a feeling at the time (based on his responses) that the reason he wasn't specifically stating he was going to fix it or open a bug report for it in systemd was that he was going to push it up-stack to a more appropriate place, and it looks like that's what happened.
- captainmuon 11y ago
  I'd say it wasn't a bug in systemd's implementation, it was a bug in the design of systemd. Why require that evivarfs be mounted at runtime? You could easily make it so that it is only mounted at boot time if neccessary, or only when you run a tool that wants to write to EFI. I'd expect file operations to only permanently affect storage devices per default. Sure you can mount almost anything as a file in Unix, but to automatically mount more than necessary is bad design. It's like placing mystery files in the filesystem, and when a curious user deletes or modifies them, they loose their monitor's color profile, there printer's firmware, or all of their GMail attachments. You could say it was the user's fault to mess with it, but I'd say it's weird to expose such things as files (unless explicitly asked for by the user or a tool).
  - sandGorgon 11y ago
    EVERY single init system mounts it's rw. It is not specific to systemd. There are lots of situations where EFI boot variables need to be set by the OS. Systemd is as consistent as upstart in this.
    - Sanddancer 11y ago
      No. Sane operating systems don't present UEFI variables as a filesystem. Their structure, their contents, everything are not files. Period. efivarfs doesn't expose metadata regarding when variables are visible, does't expose any sort of interface to present a private key for managing secure variables, etc. It's just a bad, broken idea that should be completely removed.
      - mjg59 11y ago
        > does't expose any sort of interface to present a private key for managing secure variables Nor does UEFI. The key is just provided as part of the SetVariable() payload.
      - the_mitsuhiko 11y ago
        > No. Sane operating systems don't present UEFI variables as a filesystem Probably. But that's not systemd's fault.
pavanky 11y ago
It's not a systemd bug, it is not a kernel bug. It was a firmware bug. It is usually the Linux kernel that "fixes" these idiotic issues when vendors don't implement something correctly.

Mic92 11y ago

Instead of flaming systemd developers for mounting efivars read/write, the kernel is the right place to fix the problem for everybody!

ajross 11y ago
No, the firmware is the right place to fix the problem. A BIOS that bricks itself because of within-specification deletion of variables via a standard API is just plain broken. But in the real world no one ever fixes firmware bugs, so this is the best we can do.
- kbenson 11y ago
  I think we can all compromise on "The firmware is the right place to fix the problem, the kernel is the right place to mitigate the problem."
  - ktRolster 11y ago
    Not really. Systemd could have fixed it, but it would have been a lot of work and a hack. The Linux kernel team could have fixed it, but it would have been a lot of work and a hack. The hardware manufacturers should have fixed it, but they don't care. The Kernel team showed they are professionals by stepping up and doing the work.
    - ambrice 11y ago
      What you mean is: systemd could have fixed it, but it would have been a lot of work and a hack that wouldn't help you when efivarfs gets mounted on a sysv/upstart/openrc system. The kernel was the best place for the fix.
    - GhotiFish 11y ago
      disagree. It's not just systemd that could mount efivars as read/write, anyone could. So anyone that does will fall prey to this. It's firmware, and failing that, the kernel protecting you is a good second.

nkurz 11y ago

For context, this is in reference to a bug that was discussed a couple weeks ago: https://news.ycombinator.com/item?id=10999335 https://news.ycombinator.com/item?id=10999335 Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm' Essentially, systemd defaulted to a configuration where the computer's motherboard could be permanently destroyed by removing a 'file' from the command line. The bug reporter argued that this was unduly dangerous, but the systemd developers thought that systemd was working as intended. Here's a reasonably impartial discussion on a FreeBSD list that gives an overview: https://forums.freebsd.org/threads/54951/ https://forums.freebsd.org/threads/54951/ And from that thread, here's a link to Matthew Garrett (the creator of efivarfs) saying that efivarfs is at fault here rather than systemd: https://twitter.com/mjg59/status/693494314941288448 https://twitter.com/mjg59/status/693494314941288448

kbenson 11y ago
> but the developer's thought that it was working as intended Really? Is that evidenced by Lennart's response to this, which stated "The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root."[1]? I think it implies the opposite. 1: https://github.com/systemd/systemd/issues/2402 https://github.com/systemd/systemd/issues/2402
- loeg 11y ago
  The firmware author(s) should not brick their hardware when EFI variables are deleted. That is an invalid behavior.
  - kbenson 11y ago
    Agreed, but that's almost a non-sequitur. The systemd developers are not the firmware developers. Additionally, while preferably we would have better firmware that couldn't be bricked in this way, we live in a world where this is often not the case, so the problem does need to be mitigated in some manner.
  - pyre 11y ago

RaleyField 11y ago

It shouldn't be possible to brick UEFI if it was sanely designed. That's a bad firmware.

protomyth 11y ago
Yes, its bad firmware, but the OS shouldn't allow a user to brick a machine even if the hardware vendor has broken firmware. Discovering the problem is unfortunate, but the OS folks not roping that area off is just wrong.
semi-extrinsic 11y ago
As usual when someone mentions "UEFI" and "sane" in the same sentence, I post this quote from Matthew Garret [1] (of Linux EFI maintainer fame): """ UEFI stands for "Unified Extensible Firmware Interface", where "Firmware" is an ancient African word meaning "Why do something right when you can do it so wrong that children will weep and brave adults will cower before you", and "UEI" is Celtic for "We missed DOS so we burned it into your ROMs". """ [1] https://lwn.net/Articles/444666/ https://lwn.net/Articles/444666/
- yuhong 11y ago
  http://linux.slashdot.org/comments.pl?sid=8693705&cid=51419159 http://linux.slashdot.org/comments.pl?sid=8693705&cid=514191...

devit 11y ago

It seems to me that the real issue is that "rm -rf" should by default not recurse into mounted filesystems, but should at most try to unmount them. In addition to clearing EFI variables, the current behavior will also attempt to clear any mounted removable drives and any mounted network drives, which is usually even more harmful than messing with EFI. Of course that would be a backwards incompatible change, although I don't think many scripts rely on this behavior.

Etzos 11y ago
To be fair "rm -rf /" doesn't just work. You have to confirm that you really do want to delete everything. Destroying / in itself is pretty harmful. If you're planning to do that you should already know not to have anything you want to keep mounted.
- protomyth 11y ago
  For the few use cases where a system admin wants to "rm -rf /", there are hundreds of bad scripts that can screw up a system. I believe Solaris did the right thing and made it not work. https://www.youtube.com/watch?v=l6XQUciI-Sc&t=81m https://www.youtube.com/watch?v=l6XQUciI-Sc&t=81m
  - Etzos 11y ago
    To be clear, the problem described in the video is not something that can happen. "rm -rf $1/$2" where $1 and $2 aren't defined (therefore making it "rm -rf /") will not run. If you really want to destroy your root directory you have to specify the --no-preserve-root flag. No more accidents from scripts that assume things poorly, but it will still do exactly what the user asks.
    - protomyth 11y ago
      Yet, I can still delete my home directory by accident (e.g. Steam patch). The idea that any rm can kill the directory I'm in is just bad. A flag on rm is the wrong solution. It should just fail.

chris_wot 11y ago

Ok, so I was wrong when I said Lennart Pottering's original response was "pretty appalling". Unlikely he saw it, but my apologies nonetheless.

coldpie 11y ago
Poettering gets shit on a lot. While his software does often have problems, he is really well-intentioned and working on really hard things that really do need fixing. New software simply has bugs and problems, and while the transition period can be rough, I think things will be really improved when we break through to the other side.
- icebraining 11y ago
  While systemd bugs are often cause for rejoice and schadenfreude by its critics, I think you're underestimating the argument. "The other side", that is, the vision that the Poettering et all have for the Linux environment is the issue that the critics have against systemd, not the bugs and other occasional issues. I say as someone still ambivalent, not pro nor against it.
- cyphar 11y ago
  People don't hate systemd because it has bugs. People hate it because it's clear that it thinks it owns your system and that its manifest destiny is to contain all software that exists.
  - coldpie 11y ago
    This is obviously hyperbolic.
  - cbd1984 11y ago
    No, they hate it because they think hating it is a good way to troll people. It isn't honest hatred, it's just dancing around making ugly faces, like a six-year-old.
    - 11y ago

ktRolster 11y ago

This commit message shows why I like the Linux Kernel team: >These fixes are somewhat involved to maintain >compatibility with existing install methods >and other usage modes, while trying to turn >off the 'rm -rf' bricking vector. They go out of their way to make sure changes are backwards compatible.

5ilv3r 11y ago
Like unbricking ftdi chips, the kernel team has a great track record of taking care of users where the vendors fuck them over.
EmanueleAina 11y ago
It's also the good reason why having systemd mount efivars read-only would have been the wrong thing to do.

gpm 11y ago

So if I understand this correctly, now instead of bricking the system it will just fuck up the bootloader, even if the bootloader is completely unrelated to the linux install you are `rm -rf /sys`ing. Since the useful efivars that set up bootloaders must be on the whitelist. It's an improvement, but it seems like we should do this in addition to default mounting read only.

protomyth 11y ago
It still seems to me that Linux should follow FreeBSD and not mount it as a filesystem and just use a library to manipulate the values. It clearly has some huge problems with being a filesystem. This isn't Plan 9 and everything does not have to be a file.
- eternal_july 11y ago
  Of course everything doesn't have to be a file (it is only that way on Unices). On Linux everything is a filesystem!
- floatboth 11y ago
  FreeBSD actually doesn't have any support for EFI variables at all! It just installs the loader into the default location (bootx64.efi) and the loader does everything.
  - protomyth 11y ago
    I guess I counted the loader as part of the system. Its installed by FreeBSD to do the job.

babarock 11y ago

A lot of people are busy arguing who to blame, I just think it's interesting that sometimes you need to support non-standard software. Actually, I think it's interesting that highly successful programs are not the ones who go "not my fault, you should just implement the spec better". Raymond Chen talked[1] about the importance of supporting that ran on Win95 but broke on WinXP, even if they weren't complying to Microsoft specs. I also remember reading that web browsers had to go to great length to render completely non-compliant web pages. In your experience, when should you decide to support "non-complying" behavior? [1]: Unfortunately I cannot find the original article by Chen but I could find extensive mentions of it in [this article by Joel Spolsky](http://www.joelonsoftware.com/articles/APIWar.html http://www.joelonsoftware.com/articles/APIWar.html)

fpgaminer 11y ago
This may be the Raymond Chen article you are referring to: https://blogs.msdn.microsoft.com/oldnewthing/20031224-00/?p=41363 https://blogs.msdn.microsoft.com/oldnewthing/20031224-00/?p=...

smaili 11y ago

I've never actually seen or had the courage to attempt "rm -rf /". Does anyone know what would happen if it were run?

TazeTSchnitzel 11y ago
You wipe your mounted disks.
- qb45 11y ago
  ... and remote filesystems.
floatboth 11y ago
You wouldn't be able to run any programs from the hard drive, and when you reboot, you'll end up with no operating system. Unless you're running FreeBSD (or Illumos) with ZFS and Boot Environments, in which case you'd just select a backup boot environment and continue working :-) Probably without your home directory though, as that is usually excluded from boot environments. But you can set them up however you want. But if you're running Linux (before this update) on a laptop with terrible piece of shit firmware, you'd end up with a brick. P.S. found a cool post about rm -rf / in my bookmarks: https://lambdaops.com/rm-rf-remains/ https://lambdaops.com/rm-rf-remains/ – you can recover a running rm'd Linux machine by using a running shell and /dev/tcp :D
- qb45 11y ago
  > P.S. found a cool post about rm -rf / in my bookmarks: https://lambdaops.com/rm-rf-remains/ https://lambdaops.com/rm-rf-remains/ – you can recover a running rm'd Linux machine by using a running shell and /dev/tcp :D Awesome. This dynamic loading of bash plugins is mad.
- dingo_bat 11y ago
  I wanna try it out but I'm not brave enough to do it directly in my OS. WHat would happen if I did it in Ubuntu inside a VM? What if VirtualBox has mounted some directory on my system to the guest? I'm afraid to try this too :/ I once tried 'format C:' on a Windows 10 laptop I didn't care about and I just got a boring error message.

useerup 11y ago

This is a case of a leaky abstraction (https://en.wikipedia.org/wiki/Leaky_abstraction https://en.wikipedia.org/wiki/Leaky_abstraction). The "everything is a file" philosophy is the real problem here. Specifically, the way a mental model of a hierarchy is broken by mounting a higher-order ressource (UEFI variables) as a subordinate of a file system that is itself a subordinate of the OS. UEFI vars are just hardware resources. Mapping them as a file system object is just unnatural and, yes, stupid. Trying to use a permission model ("only root can do it") overlooks the real problem: The user do not expect higher order objects to be mapped as subordinates of the file system. When you delete from the file system, you expect objects to be deleted from the disk - not UEFI variables to be altered or deleted! And because the user does not expect such behavior, there's a good chance she/he will override warnings and go ahead with the operation expecting only file system objects to be affected. This is "everything is a file" taken a bridge too far.

mjhoy 11y ago
Where does Linux promise that files are bits on a disk? As a user I certainly don't expect that. Perhaps you have a problem with the name "file" but the abstraction itself still seems useful. (And yet I do find it quite odd when I have to do something like `echo "TPAD" > /proc/acpi/wakeup` to disable wake-on-trackpad.) That said I don't disagree with you that UEFI variables should not be delete-able, but there are many files on Linux that you can't delete.
- jerf 11y ago
  I agree that there's no promise it's a file. After all, fuse will let you mount anything as a filesystem. But I'm trying to think of another file I can "delete" and permanently hose my computer, but I'm coming up blank. Maybe some fuse filesystem somewhere can do it, but none of the ones I've used. I mean, yeah, I've destroyed many a partition table in my day, and I've permanently lost myself some data, I've even dd'ed in the wrong direction with no recourse but to suck it up and deal with it, but I've never fried a computer with a rm command. (Contrary to what some commenters seems to be viciously defending, this does seem to be a legitimately different level of destructive possibility than has conventionally been available. This is the sort of thing that would put me off having ever installed Linux in the first place.)

deleted 11y ago

[deleted]

literally_ 11y ago

And so, when we say "permanently destroy" do we really mean that something is "destroyed" and so done with "permanence"? This motherboard... It refuses any sort of reflashing of the firmware? Taking the button cell out of the battery slot, and removing all power from the board does nothing? The motherboard won't enter BIOS, upon pressing F10 at power on? What is this... "bricking" we speak of, here?

nkurz 11y ago
Yes, this is one of the rare cases where "brick" is being used in the correct technical sense of rendering the motherboard permanently unusable without repairs involving a soldering iron. There is no reset option.
- Laforet 11y ago
  Depends on the package used it may be possible to reprogram the UEFI chip in situ with test clips[1]. But of course one will still need to acquire a reprogrammer and a know good copy of firmware. [1]https://www.digikey.com/product-search/en/test-and-measurement/test-clips-ic/2294786 https://www.digikey.com/product-search/en/test-and-measureme...

milkey_mouse 11y ago

good