On Wed, 29 Jul 2020 at 21:20, John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> wrote: > > On 7/29/20 10:12 PM, Christian Hesse wrote: > > This does not apply on top of grub 2.04. Will downstream maintainers have to > > do their cherry-picking on its own or will a maintenance branch on top of > > grub-2.04 (or what ever) be available? > > I would like to push updates to the Arch Linux repositories. > > You may want to look at the Debian package which already has the patches > applied in Debian unstable [1]. > > I'm surprised that Arch did not receive a disclosure of the vulnerabilities > under NDA since Debian and the various enterprise distributions have it > already.
Disclosures were done to a subset of binary distributions that have a trust path to shims signed with Microsoft UEFI CA 2011 db key. Arch Linux does not provide shim-signed with keys controlled by Arch Linux and it doesn't provide pre-signed secureboot kernels. Reading Arch Linux documentation it seems that Fedora's shim is used together with self-signed Mok Keys. Mitigation strategy for Arch Linux will then be quite different to everyone else: 1) Update to new shim from fedora when available, as previous ones are going to be revoked by the dbxupdate from uefi.org 2) Patch Archlinux grub 3) Patch Archilinux kernel for lockdown bypass 4) Generate new MOK key, enroll it into MOK 5) Sign patched grub/kernel with the new MOK key 6) Provide instructions for users to revoke their old key via MOKX, i.e. use mokutil --mokx --import existing cert; or for example delete the old key from MOK with --delete old-cert.der This is just a rough guideline, please analyze how signing keys are controlled and used on typical Arch Linux deployment and adjust things to taste. The key point is to rotate the signing key used for shim/grub/kernel/fwupd, only use the new key to sign fixed things, and ensure that old key is no longer trusted (removed from MOK, or added to MOKX). -- Regards, Dimitri. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
