[Bug 1791370] Re: update database on each boot, not just on package install

Julian Andres Klode julian.klode at canonical.com
Mon Jul 15 13:42:22 UTC 2019


** Description changed:

- Currently the secureboot databases are only updated at the time the
- secureboot-db package is installed or upgraded, but this may not be the
- point in time that the firmware needs to be updated.
+ [Impact]
+ Currently the secureboot databases are only updated at the time the secureboot-db package is installed or upgraded, but this may not be the point in time that the firmware needs to be updated.
  
  - New OS install: the secureboot-db package was installed during the image mastering, not when Ubuntu is written to the target disk.
  - Package installed while the system is booted in BIOS mode, later switched to UEFI mode
  - Hard drive moved to a new computer which doesn't yet have the updates
  
  We should ship a systemd unit to re-apply these revocations as necessary
  on each boot.
  
  The unit should be
  ConditionPathExists=/sys/firmware/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-dad00e67656f
  
  (don't use dbx for the condition, since if dbx is empty this variable
  may be absent.)
+ 
+ [Test case]
+ - Ensure unit runs at boot
+ - Ensure unit runs in postinst on upgrade

** Description changed:

  [Impact]
  Currently the secureboot databases are only updated at the time the secureboot-db package is installed or upgraded, but this may not be the point in time that the firmware needs to be updated.
  
  - New OS install: the secureboot-db package was installed during the image mastering, not when Ubuntu is written to the target disk.
  - Package installed while the system is booted in BIOS mode, later switched to UEFI mode
  - Hard drive moved to a new computer which doesn't yet have the updates
  
  We should ship a systemd unit to re-apply these revocations as necessary
  on each boot.
  
  The unit should be
  ConditionPathExists=/sys/firmware/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-dad00e67656f
  
  (don't use dbx for the condition, since if dbx is empty this variable
  may be absent.)
  
  [Test case]
  - Ensure unit runs at boot
  - Ensure unit runs in postinst on upgrade
+ 
+ [Regression potential]
+ Biggest potential is in the postinst, which now relies on dh to start the systemd oneshot service, rather than doing all the work itself. So if that's not working, things might act differently.
+ 
+ Regression potential at boot is barely existent. If the service fails,
+ nothing bad happens except your system booting in degraded state. There
+ might be a minor slow down, but should not be much.

** Changed in: secureboot-db (Ubuntu Disco)
       Status: New => Fix Committed

** Changed in: secureboot-db (Ubuntu Bionic)
       Status: New => In Progress

** Changed in: secureboot-db (Ubuntu Disco)
       Status: Fix Committed => In Progress

** Changed in: secureboot-db (Ubuntu Xenial)
       Status: New => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to secureboot-db in Ubuntu.
https://bugs.launchpad.net/bugs/1791370

Title:
  update database on each boot, not just on package install

Status in secureboot-db package in Ubuntu:
  Fix Released
Status in secureboot-db source package in Xenial:
  In Progress
Status in secureboot-db source package in Bionic:
  In Progress
Status in secureboot-db source package in Disco:
  In Progress
Status in secureboot-db source package in Eoan:
  Fix Released

Bug description:
  [Impact]
  Currently the secureboot databases are only updated at the time the secureboot-db package is installed or upgraded, but this may not be the point in time that the firmware needs to be updated.

  - New OS install: the secureboot-db package was installed during the image mastering, not when Ubuntu is written to the target disk.
  - Package installed while the system is booted in BIOS mode, later switched to UEFI mode
  - Hard drive moved to a new computer which doesn't yet have the updates

  We should ship a systemd unit to re-apply these revocations as
  necessary on each boot.

  The unit should be
  ConditionPathExists=/sys/firmware/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-dad00e67656f

  (don't use dbx for the condition, since if dbx is empty this variable
  may be absent.)

  [Test case]
  - Ensure unit runs at boot
  - Ensure unit runs in postinst on upgrade

  [Regression potential]
  Biggest potential is in the postinst, which now relies on dh to start the systemd oneshot service, rather than doing all the work itself. So if that's not working, things might act differently.

  Regression potential at boot is barely existent. If the service fails,
  nothing bad happens except your system booting in degraded state.
  There might be a minor slow down, but should not be much.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/secureboot-db/+bug/1791370/+subscriptions



More information about the foundations-bugs mailing list