Shouldn't this be an non-issue in any sane setup (ie. secureboot + TPM + FDE)? If the TPM is doing its job, it should be measuring the signature of the bootloader, so whether it's signed or not is irrelevant. Even if you could get stuff to boot, it wouldn't do you any good because you can't access the decryption keys. On the off chance that you're using secureboot without TPM + FDE, you'd be screwed anyways, because a bad guy could easily disable secureboot inside bios settings, or use shim loader to bypass it.
Part of the issue with this MSI problem, is that the firmware also measures TPM events that say "Secure Boot is enabled with this configuration" even when it's not. These events are (almost always) used for FDE (via PCR 7) with a TPM.
This means that even if you setup FDE correctly (binding to say PCRs 0, 7, and 11), you would be able to bypass FDE using this MSI bug. For example, BitLocker binds to PCR 7.
You could get around this bug by sealing to PCR 4 (which contains the _hash_ of the bootloader). But then you have to redo FDE sealing every time your bootloader updates.
>On the off chance that you're using secureboot without TPM + FDE, you'd be screwed anyways, because a bad guy could easily disable secureboot inside bios settings, or use shim loader to bypass it.
You can defend against the bad guy disabling SB in the UEFI settings by password locking the UEFI setup. I don't know how common it is but all the mobos I've used for home PCs have such an option. Of course whether mobo manufacturers implement password locking correctly is another matter.
Another line of defence is a chassis intrusion alarm to prevent the attacker from switching to alternate BIOSes and such, but those are normally only found in enterprise cases in my experience, and of course are not completely attacker-proof either.
It's the standard bike lock tradeoff - perfect security is unattainable so you just put more and more roadblocks in the attacker's way to deter them hoping that they give up and go for an easier target. Although, unlike a bike lock, someone attacking your PC is probably doing a targeted attack anyway.
So is there any reason for secure boot to exist, other than to make it harder to boot an operating system other than Windows? I am all for verified boot (like implemented on some smartphones like Pixels), but UEFI secure boot doesn't seem particularly useful to me.
One thing that makes Secure Boot nice is how it (in theory) works _with_ measured boot. You get a measurement into the TPM that contains the public signing key that was used to verify the signature on your bootloader. This means if you update from one signed bootloader to a newer signed bootloader, you don't need to change any disk encryption or sealing.
Of course blocking execution is orthogonal to verifying the boot chain, but unfortunately those issues are conflated in the UEFI spec.
The fundamental problem is that someone somewhere decided that setting up signing keys was too hard, and that because of this the manufacturer should be in charge of setting up the keys. so now instead of you owning your hardware and setting up the keys on first boot, Microsoft owns your hardware and the keys are theirs. And in a case of self fulfilling prophecy, because they decided that initializing and owning your own keys was not going to be a normal part of the user experience, it is now hard(almost impossible) to do.
If instead the decision had been made to have the user set up some keys and authorize the OS, the process would have to be streamlined and easy.
In conclusion, signing your operating system is too hard, unless you are in the happy path where your OS is signed by Microsoft it is far easier to just disable the infernal subsystem as it gets in the way.
> And in a case of self fulfilling prophecy, because they decided that initializing and owning your own keys was not going to be a normal part of the user experience, it is now hard(almost impossible) to do.
This is false.
The issue is that nobody has written user-friendly tooling to manage keys and sign stuff. Not that actually implementing this is hard.
It's part of killing plaintext exe's, Secure boot is anti piracy tech they are killing win32/Dos16 EXE model that enabled mass piracy, it's all about anti-piracy you can read about it here:
Windows 11 and TPM are about locking down the PC and turning it into a mobile device.
What do you think MMO's and steam were for the last 23 years? There's been a war on local exe's and your file system, driver signing in hte windows 2000 and XP days was Microsoft and hardware vendors working out the bugs of moving us to encrpyted input output.
They are selling it as "trusted computing" but its all for enforcing software licenses so you can't access the files. That's what NTFS was for in reality, it was about the return of mainframe computing, that's why windows 10/11 is a client-server OS and why windows 10 has forced updates.
The whole thing is to turn the PC into a console where app developers can update the firmware/bios with new encrpytion keys if the exe's get cracked.
That was the whole point of Secure boot, it was first used in consoles and the same tech in phones.
Apple, google, and the entire industry has wanted to kill piracy and enforce copyright ruthlessy.
Ever notice the rental ad on Youtube? Google would like to turn files into bits of property you can sell via encrpytion and can't accesss.
The big lockdown is coming because they saw the profits of locked down computing devices.
So no Secure boot is about killing Win32 EXE's and moving us to win 3, with Denuo levels of protection on executables.
With Trusted computing microsoft can force update security policy over all EXE's with the new exectuable model and the mmo/steam generaiton enabled all this over the last 23+ years starting from 1997 with ultima online and everquest in 1999.
That's why basic features like multiplayer game hosting inside local apps (like quake 3 and Unreal tournament 2004) disappeared.
The whole point was to move us back to mainframe computing of the 60's with draconian copyright enforcement.
In theory it would make bootkits (ie. malware that installs themselves as the bootloader, thereby being able to compromise/remain undetected for every subsequent step) harder to pull off. It's not part of my threat model though, because if malware made it onto my machine I'd be doing a full wipe. Also, this xkcd is pertinent: https://xkcd.com/1200/
Are you confusing a bootkit (ie. malware that's in the boot loader) with malware that's in the firmware itself? If it's just in the boot loader, that's still stored on the hdd/ssd itself, and therefore can be wiped.
I said "can be made to persist" and I meant, yes, that the malware could be compromising the firmware. And by "can" I implied that not all of it does, but the possibility of it doing it does exist.
Secure boot is indeed designed to protect against bootkits too.
