[Bug 1891680] Re: grub-pc needs to detect when debconf points to invalid drive and stop in preinst, before unpacking files, and also treat this as a failure in postinst
Dimitri John Ledkov
1891680 at bugs.launchpad.net
Tue Aug 18 17:35:39 UTC 2020
** Description changed:
- Currently on upgrade if the debconf variable for the drive to install
- grub-pc to point to a non-existent drive, the grub package will
- nevertheless happily carry on and the postinst will exit 0 - as a result
- leaving the /boot/grub contents and the MBR in an inconsistent state,
- which due to recent ABI changes will leave the system unbootable on
- reboot.
+ [Impact]
+
+ * grub-pc currently installs new core to MBR and installs new modules
+ to /boot in an unsafe manner, which may lead to incompatible combination
+ of MBR and modules resulting in failure to boot.
+
+ [Test Case]
+
+ * Install using old point media, of an old release. I.e. 16.04.(p-1)
+ for testing upgrades to 18.04 sru, in bios mode.
+
+ * backup the contents of /boot
+
+ * Configure invalid grub-pc/install_devices to a non existing device
+
+ * Upgrade to the package from next series-proposed, non-interactively
+
+ * Observe the package installation has failed, the grub-pc package is
+ in a broken state.
+
+ * Compare the backup of /boot with current /boot, it should have
+ remained the same, and is different to modules in /usr/lib/grub/i386-pc
+
+ * Reboot, reboot should be successful
+
+ * install /etc/apparmor.d/usr.sbin.grub-install profile
+
+ "/usr/sbin/grub-install" {
+ capability,
+ mount,
+ ptrace,
+ signal,
+ unix,
+ file,
+ deny /dev/vda w,
+ }
+
+ and load it with
+
+ sudo apparmor_parser -r usr.sbin.grub-install
+
+ * Set grub-pc/install_devices to the correct existing device
+
+ * Attempt non-interactive configuration of the grub-pc package
+
+ * Observe the package installation has failed, the grub-pc package is
+ in a broken state.
+
+ * Compare the backup of /boot with current /boot, it should have
+ remained the same, and is different to modules in /usr/lib/grub/i386-pc
+
+ * Remove the apparmor profile /etc/apparmor.d/usr.sbin.grub-install
+
+ * Reboot, reboot should be successful
+
+ * Set grub-pc/install_devices to the non-existing device
+
+ * Try to configure all the packages, interactively (i.e. using $ sudo
+ dpkg --configure -a or by using $ sudo apt install -f) and ensure to
+ select the right drive for grub installation offer
+
+ * Observe that now /boot matches /usr/lib/grub/i386-pc contents, and is
+ different from the backup taken at the start.
+
+
+ [Regression Potential]
+
+ * discussion of how regressions are most likely to manifest as a result
+ of this change.
+
+ * It is assumed that any SRU candidate patch is well-tested before
+ upload and has a low overall risk of regression, but it's important
+ to make the effort to think about what ''could'' happen in the
+ event of a regression.
+
+ * This both shows the SRU team that the risks have been considered,
+ and provides guidance to testers in regression-testing the SRU.
+
+ [Other Info]
+
+ * Anything else you think is useful to include
+ * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
+ * and address these questions in advance
+
+
+
+ Currently on upgrade if the debconf variable for the drive to install grub-pc to point to a non-existent drive, the grub package will nevertheless happily carry on and the postinst will exit 0 - as a result leaving the /boot/grub contents and the MBR in an inconsistent state, which due to recent ABI changes will leave the system unbootable on reboot.
Three changes required in order to make grub upgrades more resilient:
- exit non-zero from the postinst when the drive targets are invalid, so that we signal to the user that there is a problem BEFORE they reboot and give them the opportunity to deal with it. This is addressed by https://code.launchpad.net/~xnox/grub/+git/grub/+merge/388383
- include a check for target drive validity in the grub preinst, not just in the postinst, so that we avoid unpacking boot assets onto disk that might be incorrectly used by another package (despite grub-pc being in an unconfigured state) and still render the system unbootable; this will in general break release upgrades for affected users, but a failing postinst would do the same anyway, and failing early should leave the package manager in a more consistent state overall. This is addressed by https://code.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/+merge/388423
- modify grub-install so that it handles the flaky part of the install - updating the BIOS disks - FIRST, and aborts if this fails; instead of the current behavior, which is that /boot/grub is updated on disk first, then it attempts to install to the BIOS disk, and if this part fails, no rollback of the contents of /boot/grub is possible.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1891680
Title:
grub-pc needs to detect when debconf points to invalid drive and stop
in preinst, before unpacking files, and also treat this as a failure
in postinst
Status in grub2 package in Ubuntu:
In Progress
Status in grub2 source package in Xenial:
Confirmed
Status in grub2 source package in Bionic:
Confirmed
Status in grub2 source package in Focal:
Confirmed
Status in grub2 source package in Groovy:
In Progress
Bug description:
[Impact]
* grub-pc currently installs new core to MBR and installs new modules
to /boot in an unsafe manner, which may lead to incompatible
combination of MBR and modules resulting in failure to boot.
[Test Case]
* Install using old point media, of an old release. I.e. 16.04.(p-1)
for testing upgrades to 18.04 sru, in bios mode.
* backup the contents of /boot
* Configure invalid grub-pc/install_devices to a non existing device
* Upgrade to the package from next series-proposed, non-interactively
* Observe the package installation has failed, the grub-pc package is
in a broken state.
* Compare the backup of /boot with current /boot, it should have
remained the same, and is different to modules in
/usr/lib/grub/i386-pc
* Reboot, reboot should be successful
* install /etc/apparmor.d/usr.sbin.grub-install profile
"/usr/sbin/grub-install" {
capability,
mount,
ptrace,
signal,
unix,
file,
deny /dev/vda w,
}
and load it with
sudo apparmor_parser -r usr.sbin.grub-install
* Set grub-pc/install_devices to the correct existing device
* Attempt non-interactive configuration of the grub-pc package
* Observe the package installation has failed, the grub-pc package is
in a broken state.
* Compare the backup of /boot with current /boot, it should have
remained the same, and is different to modules in
/usr/lib/grub/i386-pc
* Remove the apparmor profile /etc/apparmor.d/usr.sbin.grub-install
* Reboot, reboot should be successful
* Set grub-pc/install_devices to the non-existing device
* Try to configure all the packages, interactively (i.e. using $ sudo
dpkg --configure -a or by using $ sudo apt install -f) and ensure to
select the right drive for grub installation offer
* Observe that now /boot matches /usr/lib/grub/i386-pc contents, and
is different from the backup taken at the start.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a
result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
Currently on upgrade if the debconf variable for the drive to install grub-pc to point to a non-existent drive, the grub package will nevertheless happily carry on and the postinst will exit 0 - as a result leaving the /boot/grub contents and the MBR in an inconsistent state, which due to recent ABI changes will leave the system unbootable on reboot.
Three changes required in order to make grub upgrades more resilient:
- exit non-zero from the postinst when the drive targets are invalid, so that we signal to the user that there is a problem BEFORE they reboot and give them the opportunity to deal with it. This is addressed by https://code.launchpad.net/~xnox/grub/+git/grub/+merge/388383
- include a check for target drive validity in the grub preinst, not just in the postinst, so that we avoid unpacking boot assets onto disk that might be incorrectly used by another package (despite grub-pc being in an unconfigured state) and still render the system unbootable; this will in general break release upgrades for affected users, but a failing postinst would do the same anyway, and failing early should leave the package manager in a more consistent state overall. This is addressed by https://code.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/+merge/388423
- modify grub-install so that it handles the flaky part of the install - updating the BIOS disks - FIRST, and aborts if this fails; instead of the current behavior, which is that /boot/grub is updated on disk first, then it attempts to install to the BIOS disk, and if this part fails, no rollback of the contents of /boot/grub is possible.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1891680/+subscriptions
More information about the foundations-bugs
mailing list