3 ms·

I completely disagree. I looked at the patch above. I personally don't like. mounting efivars rw is akin to mounting boot rw by default. A sane linux distro wi

I completely disagree. I looked at the patch above. I personally don't like. mounting efivars rw is akin to mounting boot rw by default. A sane linux distro will mount it ro and switch to rw whenever need. Defaulting to rw efivars is, excuse the language stupid. I've done a fair share of efi debugging even removing some of the variables that the kernel will now protect you from breaking. If the issue is that users should be able to remount efivars as rw whenever needed then that should be addressed, not prevent you from doing stuff to it because there is a rogue init system doing crazy stuff. EDIT: BTW, i don't think systemd does anything besides write to the various Boot* variables, but I may be wrong. I don't see why that can't be addressed with a remount. If you replace the boot.efi you still have to remount the efi partition anyway. While Matthew may be right that there is an issue that needs to be addressed, but in one of his tweets he basically says the kernel should fix it because tooling isn't and bioses suck. Well, maybe tooling should be forced to fix it. or from the issue: Matthew-Jemielity commented 24 days ago What needs efivars mounted at all anyway? So far I've seen: grub systemctl --firmware-setup reboot efibootmgr Since those likely need superuser, couldn't they handle (un)mounting it themselves? @annejan annejan commented 23 days ago As long as distribution that are aimed at consumers remount it ro and on updating kernels wrap grub with remount this is a complete non-issue.

datenwolf 11y ago
> I personally don't like. mounting efivars rw is akin to mounting boot rw by default. No, it's not the same. Mounting `/boot` rw by default does not put your system in the danger of getting damaged beyond repair. If you hose the boot partition you can always start a recovery system (live Linux or similar) to repair the damage.f But if deleting efivars renders a system inoperable on a firmware level you're essentially SOL, save for rewriting the contents of the system firmware flash using an external programmer and a clean image. That is an absolutely inacceptable situation. The year is 2016 and hosing a firmware by writing malformed values into the firmware API is, simply put, a software vulnerability that allows to permanently DoS a system. As such this is a security issue that must be fixed at where the security issue happens. And in case of efivars the issue is that certain input is not properly validated and/or sanitized. If a system firmware can not properly start with certain variables being unset or removed or set to invalid valued, its should be a implementation requirement to validate input on such variables before executing the change. > Defaulting to rw efivars is, excuse the language stupid. It probably it. But it's not the responsibility of the OS to sanitize values that are not intended for being used by the OS. efivars are intended to be used by (U)EFI and hence it's the (U)EFI implementation's task to properly sanitize access to them. Essentially we're talking Bobby Tables here, just with a different API.
- capitalsigma 11y ago
  > (U)EFI implementation's task to properly sanitize access to them. If the implementation is bad (which it is), that doesn't excuse reckless userland software that refuses to acknowledge flaws in the firmware.
  - EmanueleAina 11y ago
    There's a layer between userland and firmware where those things should be handled, and indeed everyone agreed that it should be handled in the kernel Saying that Lennart is wrong has become a rather popular sport, let's not go overboard to say it even when he's right by all accounts.
- deleted 11y ago
  [deleted]
belorn 11y ago
I remember the days when a single virus destroyed practically every motherboard for my local government. They had to throw away every machine and replaced it, costing the Swedish government several millions in early 2000 (https://en.wikipedia.org/wiki/CIH_%28computer_virus%29 https://en.wikipedia.org/wiki/CIH_%28computer_virus%29), and according wikipedia caused globally something around $1 billion US dollars in commercial damages. A virus should not be able to destroy the system BIOS. The problem with efivars is illuminating a vulnerability, not a feature for "doing stuff". I would expect to see this used in the wild if left unfixed, especially the next time we hear about a remote vulnerability that permit arbitrary memory execution.

datenwolf 11y ago

> I personally don't like. mounting efivars rw is akin to mounting boot rw by default. No, it's not the same. Mounting `/boot` rw by default does not put your system in the danger of getting damaged beyond repair. If you hose the boot partition you can always start a recovery system (live Linux or similar) to repair the damage.f But if deleting efivars renders a system inoperable on a firmware level you're essentially SOL, save for rewriting the contents of the system firmware flash using an external programmer and a clean image. That is an absolutely inacceptable situation. The year is 2016 and hosing a firmware by writing malformed values into the firmware API is, simply put, a software vulnerability that allows to permanently DoS a system. As such this is a security issue that must be fixed at where the security issue happens. And in case of efivars the issue is that certain input is not properly validated and/or sanitized. If a system firmware can not properly start with certain variables being unset or removed or set to invalid valued, its should be a implementation requirement to validate input on such variables before executing the change. > Defaulting to rw efivars is, excuse the language stupid. It probably it. But it's not the responsibility of the OS to sanitize values that are not intended for being used by the OS. efivars are intended to be used by (U)EFI and hence it's the (U)EFI implementation's task to properly sanitize access to them. Essentially we're talking Bobby Tables here, just with a different API.

capitalsigma 11y ago
> (U)EFI implementation's task to properly sanitize access to them. If the implementation is bad (which it is), that doesn't excuse reckless userland software that refuses to acknowledge flaws in the firmware.
- EmanueleAina 11y ago
  There's a layer between userland and firmware where those things should be handled, and indeed everyone agreed that it should be handled in the kernel Saying that Lennart is wrong has become a rather popular sport, let's not go overboard to say it even when he's right by all accounts.
deleted 11y ago
[deleted]

belorn 11y ago

I remember the days when a single virus destroyed practically every motherboard for my local government. They had to throw away every machine and replaced it, costing the Swedish government several millions in early 2000 (https://en.wikipedia.org/wiki/CIH_%28computer_virus%29 https://en.wikipedia.org/wiki/CIH_%28computer_virus%29), and according wikipedia caused globally something around $1 billion US dollars in commercial damages. A virus should not be able to destroy the system BIOS. The problem with efivars is illuminating a vulnerability, not a feature for "doing stuff". I would expect to see this used in the wild if left unfixed, especially the next time we hear about a remote vulnerability that permit arbitrary memory execution.