Something seems to be wrong with the whole security model.
> those versions of grub had genuine security vulnerabilities that would allow an attacker to compromise the Windows secure boot chain
This feels like a "my secure compartments are all connected together" moment.
If Microsoft want to verify that they're in an all-Microsoft boot chain, sure, whatever, fine. But somehow the compromise of any loader allows compromise of Windows? And in turn Microsoft are able to break grub installations? Why is that acceptable?
(also, I feel a bit "I told you so" about this. Back when all this was being introduced I felt that (a) secure boot increases the risk of locking you out of your machine and/or data loss and (b) a situation where Linux is dependent on the collaboration of Microsoft in order to boot is very dangerous long-term.)
This is vaguely the experience that should have been present in an Empowered User centric BIOS.
First cold boot; BIOS verifies the hardware isn't broken, checks for a boot preference, finds none.
Present the User with a set of choices: Check for BIOS Updates (manufacturer), Check for OS Choices (manufacturer), Begin installing an OS (options list). Locally cached (present with the system) choices would be listed first. Microsoft Windows (installer) is probably OEM shipped (might not be). Linux / DistroName plugged in USB device, etc... 'Local Network boot (search)', and 'Install from the Internet' (shipped by manufacturer or added by local preference).
The BIOS would also support enrolling ANY signing keys of local preference with user confirmation. This should happen even at first boot for the keys known by the manufacturer; they shouldn't just be in there for free, confirming the key with the user should be part of the flow.
The BIOS _MUST_ also support multiple bootable entries, even if one is the default (without a timeout, even with only manual selection E.G. F12 / F11 / whatever... though this too should be standardized).
The best BIOS would be no BIOS, just find a drive, check for a boot sector, then boot from it. Have an internal USB slot that always gets boot priority for service and for advanced use cases.
The point of personal computers is to make _personal_ computing easy. Everything else can just be an add on.
> find a drive, check for a boot sector, then boot from it
And how would you call the System code that does this? Would you want such a piece of code to be able to Output something to the screen in case it can't find such a boot sector? Should it be able to take user Input (e.g. in case multiple valid boot sectors are found)? These are quite Basic requirements for any early-boot phase.
> This feels like a "my secure compartments are all connected together" moment. If Microsoft want to verify that they're in an all-Microsoft boot chain, sure, whatever, fine. But somehow the compromise of any loader allows compromise of Windows?
Exactly how would you propose starting software securely from an unknown environment?
> Back when all this was being introduced I felt that (a) secure boot increases the risk of locking you out of your machine and/or data loss
What you need is source of trust and right now its signatures which are outsise of the users control.
A 5 cent hardware button which gives you a small time windows to install a new trusted bootloader could achieve the same thing without trusting microsoft.
This doesn't actually address some of the scenarios SB is intended for. I.e. you're an IT administrator, you manage a fleet of 1000 machines, you want to ensure that they are all running secure bootloaders and secure kernels and secure software, top to bottom. In that scenario, every end user having a little "security vulnerability" button they can press if they get bored (or feel like being malicious) isn't appealing.
Having to send someone out to press the button at a thousand desks in order to update the bootloader? Also not appealing.
So don't do secure boot at all rather than saying "when one step in the boot chain is compromised that can compromise all later steps"? How is that a better security model?
Giving up is certainly an option, but it is not the preferred option for some people (myself included). A partial option is definitely better than giving up, as long as it is well understood.
In this scenario, people who are ready to give up can simply stop updating their software, which will solve their issue. YMMV of course.
I have seen recommendations to not dual boot with non-obsolete Windows, because its updates would have a high risk of screwing up grub, but instead give that Windows it's own hard drive, and boot it 'manually', by selecting the boot drive at startup in the 'BIOS'. Sounds like that was good advice ?
> those versions of grub had genuine security vulnerabilities that would allow an attacker to compromise the Windows secure boot chain
This feels like a "my secure compartments are all connected together" moment. If Microsoft want to verify that they're in an all-Microsoft boot chain, sure, whatever, fine. But somehow the compromise of any loader allows compromise of Windows? And in turn Microsoft are able to break grub installations? Why is that acceptable?
(also, I feel a bit "I told you so" about this. Back when all this was being introduced I felt that (a) secure boot increases the risk of locking you out of your machine and/or data loss and (b) a situation where Linux is dependent on the collaboration of Microsoft in order to boot is very dangerous long-term.)