On Thu, 24 Aug 2023 at 15:54, Paul Menzel <pmen...@molgen.mpg.de> wrote: > > Dear Dimitri, > > > Thank you for your answer. > > Am 08.08.23 um 17:25 schrieb Dimitri John Ledkov: > > On Sat, 29 Jul 2023 at 06:54, Paul Menzel wrote: > > >> On x86 microcode updates often are recommended to be applied to fix > >> bugs. Just recently new microcode updates where published for AMD Zen 2 > >> processors to fix “Zenbleed” [1]. > >> > >> Currently, these updates are shipped and applied by the firmware, and – > >> mainly due to the proprietary and closed source x86 firmware ecosystem > >> is slow to ship these updates and firmware updates are cumbersome to > >> apply in this ecosystem – the operating systems like the Linux kernel > >> [2] (but I believe also Microsoft Windows) also support to apply these > >> updates. > >> > >> Should boot loaders be able to apply these updates, so these can be > >> applied on systems for operating systems without such a feature? > > > > Most distributions already do this via early-initrd. For example, on > > all ubuntu systems if you unpack initramfs with `unmkinitramfs` > > command you will notice early1 and early2 uncompressed initrd portions > > that contain Intel and AMD microcode. these are loaded and applied by > > kernel early on, before unpacking the rest of the initrd or > > initialising the system. > > > > Specifically for Zenbleed, Ubuntu Security team has shipped > > amd64-microcode package at CRD time, which is automatically installed > > by all systems and thus a reboot has already applied those. > > Does CRD mean Cargo Ready Date?
Coordinated Release Date of security vulnerability details, reproducers, fixes, patches, research paper and binary builds for stable distributions to release things https://www.kernel.org/doc/html/v4.18/admin-guide/security-bugs.html#coordination > > > Thank you for the explanation. I was well aware of that. It is very > GNU/Linux focused though, and GRUB also loads other programs. If the > boot loader would do that, not all operating systems would need to > implement that. Anyway, it’s present in the Linux kernel, so – as a > Linux user – I can still use that. > > > This is a standard mechanism that is already implemented by all > > distributions (i.e. Ubuntu, Ubuntu Core, Fedora, etc). If your > > distribution/device doesn't install and doesn't generate early initrd, > > please implement that. Reference implementations are available in > > initramfs-tools (debian/ubuntu), core-initrd (ubuntu core), dracut, > > and likely many others. > > Back then, reading up on the choices, I do not like this, as you need > the wrappers `lsinitramfs` and `unmkinitramfs` to easily deal with these > files. For our distribution MarIuX we went the separate files for the > microcode update archives, and let GRUB load them and pass to the Linux > kernel [3]. You don't need to patch grub. And you can build things stand alone already..... For example, on Ubuntu instead of having a fat initrd that contains early-initrd components and main ones, you can do them as separate files.... already..... as supported by stock grub.... ``` linux /boot/vmlinuz initrd /boot/microcode-intel.cpio /boot/microcode-amd.cpio /boot/initrd.img ``` Is already supported by grub and will cause to load all of these separate cpio archives separately, which the linux kernel correctly apply microcode from. For a working implementation you can see src:microcode-initrd package in Ubuntu and Debian that does that. > > It is a nice property to bundle this in the initrd, as sometimes there > > are microcode regressions, thus booting old kernel abi, with an old > > initrd, with an old microcode is desirable. > > It’s a two-edged sword, as people do not know what microcode updates are > going to be applied using older boot entries. > As a distribution integrator, one can make appropraite choices and documentation as needed. In ubuntu we provide alternative boot entries that include booting without microcode update being applied as a debugging and recovery fallback boot entry. Because sometimes microcode updates crash the OS and we provide that failsafe to the end user to discover in the grub menu. > > > Kind regards, > > Paul > > > >> [1]: https://lock.cmpxchg8b.com/zenbleed.html > >> [2]: https://docs.kernel.org/arch/x86/microcode.html[3]: > >> https://github.molgen.mpg.de/mariux64/mxtools/pull/342 > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel -- okurrr, Dimitri _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
