On Thu, 13 Jul 2017 07:54:44 -0400 Rich Freeman wrote:
[...]
> >> Presumably you'd only want to remount it if it was mounted ro to
> >> start, since it sounds like openrc will be diverging from systemd
> >> behavior here.
> >>
> >> While it seems like a good idea I'm not sure how big an improvement it
> >> is in the larger scheme.  We're worried about root accidentially
> >> modifying efivars, but we have no safeguards against root writing to
> >> /dev/sda, and the latter seems much more likely to cause harm, and is
> >> harder to fix.
> >
> > Writing to /dev/sda may kill data stored there, but hardware itself
> > will survive. Writing to efivars kills hardware and this is the
> > motivation for this change. See [1] and [2] for details. Poettering
> > says this is OK to hard brick device, well fine, this is systemd
> > way. OpenRC is smarter here and protects users from unintended
> > disaster.
> 
> Reading through those apparently bricking is considered to be a
> hardware bug.  Granted, it is still desirable to avoid.

Yes, it can be considered as a hardware bug, as well as thousands
of other issues, look at how many quirks are inside the kernel.
This is how it works: software works around hardware bugs, because
software is so much easier to update than hardware.

> In any case, tools would still need to be compatible with both
> approaches.  Apparently there are commands like systemctl reboot
> --firmware-setup that expect this to be writable.  If we aren't going
> to make the default ro under systemd then tools will need to handle
> both cases.  If we decide to change the default for systemd (or put a
> line in the default fstab) then this issue would go away.

I see no problems with compatibility. In case of software needs to
write to efivars (bootloader installation, etc) algo is simple:

flag = false;
if (mounted(efivars) == RO) { remount(efivars, RW); flag = true; }
do_usual_stuff();
if (flag) remount(efivars, RO);

Best regards,
Andrew Savchenko