> 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.
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
So does a password and encryption.