←back to thread

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

(git.kernel.org)
279 points the_why_of_y | 6 comments | 22 Feb 16 18:08 UTC | HN request time: 0.27s | source | bottom
Show context
tvbn ◴[22 Feb 16 19:15 UTC] No.11153444[source]▶
They disabled kernel feature to prevent systemd bug? It doesn't make any sense.
replies(5): >>11153459 #>>11153462 #>>11153477 #>>11153479 #>>11153602 #
kbenson ◴[22 Feb 16 19:20 UTC] No.11153479[source]▶
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.

replies(2): >>11153687 #>>11153716 #
captainmuon ◴[22 Feb 16 19:47 UTC] No.11153687[source]▶
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).

replies(1): >>11153810 #
sandGorgon ◴[22 Feb 16 20:02 UTC] No.11153810[source]▶
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.

replies(1): >>11153922 #
1. Sanddancer ◴[22 Feb 16 20:16 UTC] No.11153922[source]▶
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.
replies(3): >>11154072 #>>11154135 #>>11156258 #
2. mjg59 ◴[22 Feb 16 20:35 UTC] No.11154072[source]▶
> 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.

3. the_mitsuhiko ◴[22 Feb 16 20:43 UTC] No.11154135[source]▶
> No. Sane operating systems don't present UEFI variables as a filesystem

Probably. But that's not systemd's fault.

replies(1): >>11155023 #
4. Sanddancer ◴[22 Feb 16 22:54 UTC] No.11155023[source]▶
The systemd developers could have said that they wanted no part of that madness, and chosen not to automatically mount it. Someone else's bad decision doesn't absolve one from their own bad decisions.
replies(1): >>11156340 #
5. sandGorgon ◴[23 Feb 16 03:21 UTC] No.11156258[source]▶
I'm not qualified to comment on that - but this is the core of Linux: everything is a file.

You may want to call Linux as a crazy operating system , but then you are veering close to Godwins Law anyway.

6. cbd1984 ◴[23 Feb 16 03:41 UTC] No.11156340{3}[source]▶
You're really looking for a way to blame systemd.