4 ms·

If you mount to r/o, a bunch of userspace applications break. Mounting it r/w is correct.

• captainmuon 11y ago
  I'm curious, what kind of userspace application needs r/w access to EFI vars? I would think a) this are mostly system tools like boot managers and b) these tools need root (or setuid root) anyway, so why can't they just mount it themselves temporarily? Edit: It seems it is mostly grub-install, efibootmgr, and `systemctl reboot --firmware` that need this mounted rw. The first two aren't something that a casual user uses very often, and if someone does, a "Filesystem is mounted read-only" message will point them in the right direction. The latter is part of systemd and could easily be changed to mount efivarfs itself, no third party involved.
  • sandGorgon 11y ago
    Each time boot variables need to be written, etc.
  • mjg59 11y ago
    They could remount it read-write, but they don't. If systemd had made a unilateral change that broke existing userspace people would have been unhappy for a different reason. Doing this in-kernel means that the issue could be fixed without breaking existing userspace, so it's clearly the better solution.
  • zanny 11y ago
    The EFI spec is a horrible disastrous mess, but in theory you could be reading and writing EFIvars at runtime to dynamically configure boots - ie, "reboot to safe mode" would set the evifar next boot parameter to your initram-fs fallback. It would not be complicated to implement pam / polkit support for unprivlidged users to set such things without authenticating root. It does not change the fact the fault lies with shitty proprietary UEFI implementations, and nobody writing free software is at fault here.
  • EmanueleAina 11y ago
    What happens if a stray `rm` runs while `grub-install` runs? The kernel fix prevents that, using mount flags alone only restrict the vulnerability but it doesn't make it go away.