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