On Thu, 13 Jul 2017 07:09:45 -0400 Rich Freeman wrote:
> On Thu, Jul 13, 2017 at 2:30 AM, Andrew Savchenko <birc...@gentoo.org> wrote:
> > On Wed, 12 Jul 2017 17:42:50 -0700 Matt Turner wrote:
> >> On Wed, Jul 12, 2017 at 5:29 PM, Lucas Ramage <ramage.luca...@gmail.com> 
> >> wrote:
> >> > What needs to be changed for the bootloaders? I may be able to assist.
> >>
> >> The documentation should be updated to say that with OpenRC 0.28 that
> >> you'll have to remount efivars as RW before you can install the
> >> bootloader (e.g., grub-install)
> >>
> >> The command I use locally to remount rw (since I have configured
> >> efivars to be mounted read-only in fstab) is
> >>
> >> mount -o remount,rw /sys/firmware/efi/efivars
> >
> > We don't have that much efi bootloaders. Maybe it will be better
> > to update their scripting to remount efivars rw and back ro when
> > needed? The same way we have non-efi bootloaders to mount /boot
> > partition when needed.
> >
> 
> 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.

Data can be restored from backup, but hard bricked hardware may
become completely dead beyond repair or require a very complicated
soldering. So I see this issue much more serious than writing
to /dev/sda.

[1] https://github.com/openrc/openrc/issues/134
[2] https://github.com/systemd/systemd/issues/2402

Best regards,
Andrew Savchenko

Attachment: pgpTuFWVf3Gda.pgp
Description: PGP signature

Reply via email to