4 ms·

> 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

> 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.

kmeisthax 4y ago
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.

kmeisthax 4y ago

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.