There is a new set of Grub2 vulnerabilities that are going public today. The wiki page above explains them in detail.
These updates will be released for the SecureBoot platforms that are signed by Canonical only. Which today are X64 and AA64 in UEFI terms (aka amd64/x86_64, and arm64/AAarch64).
As part of these updates, because they are that large, we have split Grub2 packaging to allow us shipping identical signed bootloader artefacts across all releases. This means that on UEFI amd64 & arm64 platforms the following releases are upgrading to 2.04 grub2 Trusty ESM, Xenial, Bionic, Focal, Groovy and Hirsute.
These updates will land in -proposed pockets soon, and will be extensively validated before eventually getting phased in -updates and -security pockets.
There is no immediate threat or urgency to apply these updates, because we still do not have new shims & dbxupdate from uefi.org as those got delayed. Meaning at this time, even with these updates downgrade attacks are possible. Thus if you have TPM you should rely on TPM measurements to monitor your estate if you cannot control physical access to the machines.
In addition to grub fixes, shim has been upgraded with support for SBAT. It means that in Hirsute shim, grub, fwupd are required to have sbat sections, and have ability for targeted revocation of particular binaries.
If you have any questions please post them here, and I will try to answer them all!
Cloud images are built daily when new updates come out. Such that daily stream of images should have been good across the board the next day the latest.
Once those pass certification and signoff from the cloud partners they are promoted to become the default images for launching via various launch methods in a given cloud platform console. I do not have exact details of image serials and dates when they became the default ones.
Note, that if one hardcodes obsolete exact AMI / serial / date one can still be launching on first boot an obsolete images without this fix. Unless one regularly looks up / launches the current default released cloud image. If obsolete image is used, apt update/full-upgrade will apply the needed fix and one will be secured from the next boot.
small update, I see https://ubuntu.com/security/notices/USN-4992-1 dated 18th of June, yet with enabled focal-security announced packages are not available neither on official apt channels, nor over cloud-providers supported apt channels
Which mirrors and clouds are you using?
What does apt-cache policy grub-efi-amd64-signed shows?
You can see exact timestamps when these were published in security pocket at https://launchpad.net/ubuntu/+source/grub2-signed/1.167.2 in the publishing portion on the right hand side. In focal-security it has been there since 2021-06-17 23:18:48 BST.
The last shim that worked on my laptop was some version installed on May 14, since then every update of shim is unable to boot Ubuntu when using dual boot with Manjaro binaries signed with custom key enrolled to secure boot DB.
I managed to chainload Ubuntu shim through Manjaro’s systemd-boot and everything seems to be fine when booting this way, however, explicit selection of Ubuntu shim entry in UEFI boot override menu (due to it being the 2nd, non-default boot option in nvram) results in indefinite black screen instead of Grub menu.
The update of Ubuntu shim “works” only, if you boot from the Ubuntu shim. If you set the Ubuntu shim as second boot option, the firmware tries to load the first bootloader.
It is possible, that the first bootloader “fails to boot indefinitely”. If you want help, please provide useful informations about your setup and ask in a support forum.
I am not seeking support, I’m just experiencing issue (strange behavior) and reporting it.
As I said above, moving Ubuntu grub/shim files to another $esp helped with starting it using custom systemd-boot entry, but for a short period a direct launch of UEFI override menu hasn’t been successful until today, when all of sudden it started to work fine due to, well, I have no idea why. Like there was no problem before but it’s not true. All in all, I’m confused. Hope this could be of help for Ubuntu developers in improving user experience.
Shim updates are not quite relevant to the subject of this grub changes discussions. There have been multiple shim regressions identified and fixes are being developed / signed / updated.