Isn't that a vulnerability that still requires physical access to hardware?
Or is that just a protection against rootkits?
I still fail to understand what secure boot is protecting against: if a machine is compromised remotely, does secure boot prevents installing a rootkit that's invisible from virus scanners?
Secure Boot protects against booting a kernel image that's been tampered with. If the running kernel is vulnerable to root-level exploits, it can't help you, but it can prevent a malicious attacker from switching a trusted kernel for a malicious, modified copy.
Being able to enroll your own keys (or disable secure boot entirely) is a requirement for being a compliant implementation.
So sign your own kernel with your own keys and enroll them to your UEFI and you have 0 problem with installing "a free OS" (it can also just be regular EFI binaries).
Making a non-microsoft product require manual key enrollment, while Microsoft products do not require such enrollment, sounds like abusing monopoly status to give new entrants a disadvantage. The 1990s antitrust people would have a field day with that one.
Also, by the way, I am an ex Microsoft employee, bet you wouldn't guess that from these comments.
I do personally consider secure boot and TPM to have been pushed in bad faith, not for serious security concerns.
> sounds like abusing monopoly status to give new entrants a disadvantage.
It is, and it isn't something I like, I'd prefer if no keys were enrolled by default.
> I am an ex Microsoft employee, bet you wouldn't guess that from these comments.
No I wouldn't have guessed, but MS is so big that just saying your were a MS employee could mean in any one of the thousands of departments not even remotely related to Windows. But that is neither here nor there as it doesn't change anything about my statement.
> I do personally consider secure boot and TPM to have been pushed in bad faith, not for serious security concerns.
Sure, but I still prefer to have this now that I can use it, even if its introduction was in bad faith (which it was consdering IIRC there were e-mail floating around talking about if they could get away with making it only work with Windows or maybe it was some other security mechanism).
I also am not a blind MS hater or supporter. I probably do often give MS too much leeway for a lot of things where more skeptical people would basically instantly dismiss it. I guess I just try to make the best out of what is given me.
> I wasn't privy to any memorable internal discussions about secure boot.
I think it was a leaked email from Bill Gates around when UEFI or Secure Boot was becoming a thing. I wasn't able to find it after searching for a while though.
Back in the day the euphemism was "trustworthy computing". That may be a good thing to Google to find those emails. I remember then too. Another name was "palladium"
> Being able to enroll your own keys (or disable secure boot entirely) is a requirement for being a compliant implementation.
That may be true on x86, but on ARM, Microsoft specifically requires that you not be able to do either of those things:
> 13. On ARM platforms Secure Boot Custom Mode is not allowed. A physically present user cannot override Secure Boot authenticated variables (for example: PK, KEK, db, dbx).
> 18. Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable
Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via
firmware setup without possession of PKpriv. A Windows Server may also disable Secure Boot remotely
using a strongly authenticated (preferably public-key based) out-of-band management connection, such
as to a baseboard management controller or service processor. Programmatic disabling of Secure Boot
either during Boot Services or after exiting EFI Boot Services MUST NOT be possible. Disabling Secure
Boot must not be possible on ARM systems.
> Being able to enroll your own keys (or disable secure boot entirely) is a requirement for being a compliant implementation.
No, it's really not.
Currently Microsoft requires enrolling keys and disabling SB to be available to qualify for "Designed for Windows" branding on x86 PCs. No such requirement holds for ARM PCs, and Microsoft may remove this requirement at any time.
Or is that just a protection against rootkits?
I still fail to understand what secure boot is protecting against: if a machine is compromised remotely, does secure boot prevents installing a rootkit that's invisible from virus scanners?