They updated the system key store to invalidate known vulnerable boot configurations. One of those configurations was old versions of Grub, which had a pre-boot exploit a couple of years ago.
The issue has already been patched for years, but it appears some Linux distros never bothered to update their system configuration. Not sure if this is a shortcoming of Grub or one of the distro maintainers that were affected, though.
In fact, Microsoft tried to not apply this patch on dual boot systems, leaving them vulnerable but working, but clearly their detection failed. I think their detection required chainloading the Windows bootloader or something?
Either way, the only Linux file that Windows will ever touch with updates is the “fallback for when the boot configuration is completely fucked” bootloader, which both Linux and Windows overwrite after installation, incase the boot configuration gets completely fucked. If you’re relying on that bootloader, you were always going to get fucked by some update eventually; either your installation failed or your motherboard is broken.
What is that latter fallback called? I set up my boot manually using an EFI stub last time I installed arch but wasn’t aware of any fallback bootloader
I don’t know what systemd-boot does, but the normal way to install a bootloader is to copy an efi file to the right folder (/EFI/archlinux/grubx64.efi or whatever) and register the bootloader in the boot configuration store. This allows you to pick the OS from a list by hitting the boot menu key for your device (f8/f12 usually I think?) rather than having to rely on something like systemd-boot or Grub to list all of your operating systems. This way, you can also boot UKIs and other Linux kernels compiled to simple EFI files, without ever even touching an independent bootloader.
As a fallback, both Windows and some Linux bootloaders copy their files to the /EFI/Boot/bootx64.efi directory. This makes the drive bootable in cases where the boot configuration store is broken, or if the drive wasn’t hooked up to the same motherboard when the installation was done. This is particularly important for installer drives, because you don’t want to add a boot entry to your motherboard for every installer you plug in.
The downside of this fallback file is that it’s just one single file in a preset directory, like the MBR of old. Some motherboards come with a file browser to select the EFI application you want to boot, but many will just give you a boot menu and nothing more. Because it’s a single file, that bootloader can either be Windows or it can be Linux. This isn’t a problem normally, but on broken motherboards this can render a system Windows-bootloader only or Linux-bootloader only. You can add both Linux and Windows to either, but the file being booted it always the last one that got updated.
There’s also a weird edge case for when you install Linux on a GPT disk from CSM mode, where the GPT disk will have an MBR. That makes the Linux system incapable of using any UEFI features and it has the same problem: if Windows puts its bootloader there, the drive will boot Windows.
As for bootloaders themselves, you generally only install one (though there’s nothing preventing you from installing both and having both be bootable, because they’re just entries in the UEFI menu!). If you want, you can install bootable Linux kernels as well, without any bootloader, though those don’t let you pick your boot options.
Thanks for the detailed explanation, makes a lot of sense! I guess what I did was set up a UEFI entry that specifies the location of the Linux kernel without any intermediate bootloader. Pretty sure I didn’t set the fallback, so I’m guessing that’s still owned by windows.
Yes, I think you did. In that case, I don’t think Linux will claim the fallback loader entry. Windows doesn’t always copy its files there, so the file may not even exist. If that’s the case, you’ll only ever encounter the fallback paths on an installer/recovery disk.
They updated the system key store to invalidate known vulnerable boot configurations. One of those configurations was old versions of Grub, which had a pre-boot exploit a couple of years ago.
The issue has already been patched for years, but it appears some Linux distros never bothered to update their system configuration. Not sure if this is a shortcoming of Grub or one of the distro maintainers that were affected, though.
In fact, Microsoft tried to not apply this patch on dual boot systems, leaving them vulnerable but working, but clearly their detection failed. I think their detection required chainloading the Windows bootloader or something?
Either way, the only Linux file that Windows will ever touch with updates is the “fallback for when the boot configuration is completely fucked” bootloader, which both Linux and Windows overwrite after installation, incase the boot configuration gets completely fucked. If you’re relying on that bootloader, you were always going to get fucked by some update eventually; either your installation failed or your motherboard is broken.
What is that latter fallback called? I set up my boot manually using an EFI stub last time I installed arch but wasn’t aware of any fallback bootloader
I don’t know what systemd-boot does, but the normal way to install a bootloader is to copy an efi file to the right folder (/EFI/archlinux/grubx64.efi or whatever) and register the bootloader in the boot configuration store. This allows you to pick the OS from a list by hitting the boot menu key for your device (f8/f12 usually I think?) rather than having to rely on something like systemd-boot or Grub to list all of your operating systems. This way, you can also boot UKIs and other Linux kernels compiled to simple EFI files, without ever even touching an independent bootloader.
As a fallback, both Windows and some Linux bootloaders copy their files to the /EFI/Boot/bootx64.efi directory. This makes the drive bootable in cases where the boot configuration store is broken, or if the drive wasn’t hooked up to the same motherboard when the installation was done. This is particularly important for installer drives, because you don’t want to add a boot entry to your motherboard for every installer you plug in.
The downside of this fallback file is that it’s just one single file in a preset directory, like the MBR of old. Some motherboards come with a file browser to select the EFI application you want to boot, but many will just give you a boot menu and nothing more. Because it’s a single file, that bootloader can either be Windows or it can be Linux. This isn’t a problem normally, but on broken motherboards this can render a system Windows-bootloader only or Linux-bootloader only. You can add both Linux and Windows to either, but the file being booted it always the last one that got updated.
There’s also a weird edge case for when you install Linux on a GPT disk from CSM mode, where the GPT disk will have an MBR. That makes the Linux system incapable of using any UEFI features and it has the same problem: if Windows puts its bootloader there, the drive will boot Windows.
As for bootloaders themselves, you generally only install one (though there’s nothing preventing you from installing both and having both be bootable, because they’re just entries in the UEFI menu!). If you want, you can install bootable Linux kernels as well, without any bootloader, though those don’t let you pick your boot options.
Thanks for the detailed explanation, makes a lot of sense! I guess what I did was set up a UEFI entry that specifies the location of the Linux kernel without any intermediate bootloader. Pretty sure I didn’t set the fallback, so I’m guessing that’s still owned by windows.
Yes, I think you did. In that case, I don’t think Linux will claim the fallback loader entry. Windows doesn’t always copy its files there, so the file may not even exist. If that’s the case, you’ll only ever encounter the fallback paths on an installer/recovery disk.