touche!
but there's a new Microsoft in town! I hardly think after being the biggest contributor to OpenBSD [1], they would build a underhanded way of trying to kill Linux.
I'm trying to understand if there is an attack vector that is prevented by not allowing coreboot.
It does increase security, since for instance in spite of its complexity Secure Boot has proven to be reasonably secure, and thus it is simpler to attack the firmware.
However I agree with Garrett and disagree with aaronem: just as shown by Secure Boot on x86, you can have a reasonable choice between security and user's choice i.e. you can give freedom and security. A similar mechanism, in which a user could enroll its keys and install its signed coreboot payload, is possible. The same applies to TPM.
Given that Intel had 55 bilions in revenues last year, I see no reason to cut them any slack (same goes for Apple, Qualcomm, etc).
As far as the "new Microsoft" goes, the policy on Windows phone is the same on Windows 10 as it was on Windows RT and Windows 8: Secure Boot on ARM is locked down in such a way that the user cannot add its own keys, or send a binary to Microsoft to have its signed for 99$ (i.e. the result is functionally equivalent to Apple policy with ios). If you sell devices on which the users can't even decide which kernel to boot, you probably don't have a problem with devices in which the users can't decide which firmware to use.
It's a lot easier to escalate a binary drop into a persistent threat if it can reflash the BIOS with compromised firmware. Requiring firmware be signed prevents this, at the cost of also preventing the use of coreboot, libreboot et al.
In theory, it should be possible to support user flashing of unsigned firmware, perhaps in some sort of OS-less boot mode that malware couldn't use. But offering that capability without it being a backdoor is costly and effortful enough that I don't really blame motherboard manufacturers for declining to do so on behalf of a rather niche use case.
