Wasn't this the original proposal for what TPMs were supposed to do? I remember that and secure attestation were considered radioactive to basically the whole free software community.

The scheme you are mentioning sounds like a hardened/serious version of those old "boot sector virus protection" things that 90s-era motherboards had. They'd checksum the boot sector and scream at you if it changed. Regardless, this scheme won't really fix the problem we're talking about - installing Linux on top of machines with Windows preinstalled.

Preinstalled systems will already have a Windows bootloader hash measured and locked before you even get at it. If it doesn't, that means you're building your own machine from an off-the-shelf motherboard, so none of this matters[0]. If you want to seamlessly[1] install Linux on a machine that's already running Windows, you need PKI that trusts both - either with Microsoft cross-signing Linux distros' bootloaders, or OEMs including both Microsoft and common Linux distro certs.

There's also a related problem here: if you are first-booting a machine without an OS, you have no chain of trust at all. This is a trust-on-first-use scheme, the problem being that it has nothing to protect against, say, NSA/TAP implants[2]. You're trusting that the machine that downloaded your Ubuntu ISO and flashed it to a USB stick hasn't already been compromised and isn't slipstreaming in more malware onto your stick. Or that your machine with Linux preinstalled wasn't opened up and stealthily modified before you got to boot it. PKI has an advantage here in that it doesn't just validate that the bootloader hasn't changed - it also carries the reputation of the signer, which can be damaged if they sign malware.

[0] Most motherboards for DIY builds don't even bother configuring Secure Boot - and the people buying them will know how to jump through whatever hoops are necessary to get Linux to run if they want it.

[1] though tbf the Asahi Linux people really did a good job of getting the installer to be seamless and easy on M1 Macs.

[2] While a government could compel Microsoft to sign malware, that would also create irrefutable evidence that Microsoft's keys had been compromised. The spooks really don't want to do this because such things could easily be traced back to them.

> The scheme you are mentioning sounds like a hardened/serious version of those old "boot sector virus protection" things that 90s-era motherboards had

Yes! In fact, I wanted to mention boot sector virus protection in my comment.

> Regardless, this scheme won't really fix the problem we're talking about - installing Linux on top of machines with Windows preinstalled. Preinstalled systems will already have a Windows bootloader hash measured and locked before you even get at it.

Part of this scheme is that the user is able to reset the bootloader hash at will, even on preinstalled and hand-me-down machines that were initialised or pre-initialised by somebody else already. So if one receives a machine with Windows preinstalled, then that shouldn't be a big deal as the bootloader hash can be reset in the firmware settings on boot. If the firmware doesn't let you do that, well... That's as bad as current Secure Boot for user hostility, but at least PKI is not injected into the mix to make it worse.

> If you want to seamlessly[1] install Linux on a machine that's already running Windows, you need PKI that trusts both

It's possible to dual-boot with chainloading, or simply update the system to support N hashes rather than just one. 1 kilobyte of storage will fit 32x 256-bit hashes, so that's not a lot of space even in NVRAM-constrained environments.

The only issue I can see with dual-booting and chainloading, is if the change to the boot process messes with some TPM registers and the OS that is already present on the machine is unhappy about that - but it seems like a tractable engineering problem.

> This is a trust-on-first-use scheme, the problem being that it has nothing to protect against, say, NSA/TAP implants[2]

Correct. But that sounds like a Trusting Trust attack on your firmware, against which Secure Boot cannot stand either.

> PKI has an advantage here in that it doesn't just validate that the bootloader hasn't changed - it also carries the reputation of the signer, which can be damaged if they sign malware.

OK, I will admit that is one advantage. Counter-argument I would propose, is that you should be installing the OS with known-clean, preferably read-only bootable media in the first place. That way you can verify the hash and authenticity beforehand in any number of ways, and remove complexity from the boot chain. This used to be the main way to install the OS before the Secure Boot era, as everyone was distributing OS installers on WORM media.

> I remember that and secure attestation were considered radioactive to basically the whole free software community.

Can you blame us? ~~Android's~~Google's SafetyNet is essentially a remote attestation API that a great number of banking apps rely on, and they refuse to launch unless they can see that SafetyNet status is intact. What good is the ability to replace a ROM or gain admin access, if half of the security-sensitive apps on your phone stop working? Remote attestation is here, and it sucks.

Totally agree with you on SafetyNet, and the fact that it's used by so many apps that don't need it feels like a betrayal of trust.

What you mentioned about read-only media is how secure boot should be implemented, too. Or at least it's how Apple does it: all the boot chain verification code lives in mask ROM so the only way to compromise it is to either find a bug (rare and expensive) or compromise the chip vendor (very "loud", spooks don't like this). The only problem with this setup is that Apple does not give two hoots about vendor neutrality[0] and this sort of scheme requires trusted roots to be burned into the chip.

Not being able to reset the boot hash is actually worse than current Secure Boot. The problem being complained about isn't dualbooting. It's that Microsoft is making you jump through additional hoops. There's still the ability to turn off Secure Boot; that's the moral equivalent of "resetting the boot hash" in your proposal. But we don't want to make users do that; we want the machine to just say, "oh this is the trusted Linux build, go on right ahead" without any extra mess or fuss. Linux distros jumped through hoops a decade ago to get a secure boot path signed by Microsoft - not to enable it to run at all, but just to make installation and usage easier.

[0] They do provide an owner-override on Macintosh-fused chips, which is actually implemented in a really cool, user-friendly way. But that's moreso for letting the user build their own kernels rather than a serious attempt at being vendor-neutral.

Presumably in the alternate world where Microsoft hadn't signed over Windows on ARM to Qualcomm, Apple would be signing a Boot Camp bootloader that validates Microsoft keys.