Disabling secure boot means you can easily lie to the OS about whether or not secure boot is enabled.

If it were an anti-piracy measure then there wouldn't be a requirement for you to be able to disable it.

The kernel can execute ring 0 instructions. Your initrd can't. The difference is that you could construct an appropriately modified hibernation image that booted an arbitrary kernel - or even an entirely separate OS. In that scenario, your kernel is effectively a new bootloader, except unlike the signed bootloaders it'll happily boot an entirely unsigned OS. That's unlikely to end well.

But, conceptually, you're right. Secure Boot doesn't magically make a system secure, but it *is* a vital part of system security - if you can't trust your kernel, any other security you attempt to build is pretty much pointless.

You don't need an exploit or a kernel patch. You just need to replace the firmware's function pointer to GetVariable(), which is a thing you can do because you're running untrusted code in the firmware context. The OS has no way of knowing that you're doing that.

"The GetVariable() call returns a decryption key that the hardware calculated"

No it doesn't. It returns a 1 if the firmware claims to have booted securely, and a 0 if not. You're thinking of Measured Boot, not Secure Boot.

Please describe how Windows can accurately determine whether it was booted in Secure Boot mode or not. For an encore, describe how Trusted Computing can limit the code you can boot. As far as I know, single machine local attestation is an unsolved problem.

How does Windows know whether it was booted in secure mode? It makes the EFI GetVariable() call. Which is a function pointer handed to it by the firmware. Which you can modify if you're running untrusted code. So, no, Windows can't tell.

If you were a serious virus writer you'd already want to use the Microsoft CA to sign your rootkit so you can install it as a signed driver in Windows. Secure Boot moves the vulnerability down the stack, but even now a compromised Microsoft signing key is still massively desirable to virus authors.

Microsoft have told me that they'll revoke certification for any vendor who doesn't provide the appropriate options. If you have examples of machines that have certification and which don't allow any modification of the key database, let me know so we can find out if they were telling the truth.

You've linked to a story about a traditional MBR bootkit that doesn't even run under UEFI. Secure Boot is, as far as anyone knows, not yet cracked.

It's not DRM. You can turn it off in the firmware and there's no way for the OS to know that you did.

BIOS boot sector protection has never prevented writes to the MBR unless you're running DOS - any actual OS uses direct hardware access instead of using the BIOS, and so it can't be blocked. It'd be possible for the BIOS to complain that the MBR's been modified, but it has no way of verifying that the partition boot code or the actual bootloader are still secure. Unsurprisingly, malware authors take advantage of this - https://support.kaspersky.com/viruses/solutions?qid=208280748 has a list of modern bootkits.

Sure. The user shouldn't enrol keys unless they trust whoever provided it and the chain of trust that they assert exists.

Well, that's the point. Nothing you run before reboot will be able to run in the firmware, because it doesn't have the right signature.

No, only the first time you install a given key.