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
pgpABpM2nsz3F.pgp
Description: PGP signature
