NVIDIA to provide documentation for Nouveau

second, if you have the ability to force arbitrary microcode updates on your target then you're already root there for all intents and purposes, so you have easier ways to backdoor their system.

2. but according to local wisdom here Secure Boot is supposed to give us, well, a secure boot process if only we used our own keys. turns out we're no better off than trusting trust once again.

3. have you seen the Snowden leaks? do you know how many companies got compromised and/or compelled into cooperation by the NSA and other agencies? so yes, i'm not exactly impressed by '4 common firmware implementations', it's a very *small* industry actually (and what does building with different compilers matter? nothing?). in fact, if i were the NSA, i would have my men planted there long ago and the 'how do i compromise them' question would simply become 'when and what do you want me to do?'. as for which is more numerous, i bet there're more different vmlinux and heck, even ntoskrnl images out there than UEFI firmware updates.

4. that's not how it'd work, obviously a Windows boot despite (supposedly) not having the MS key would be a dead giveaway. however it's possible to still accept code signed by the (supposedly removed) MS key if there's an additional condition - no need for an extra key at all, just some embedded secret that only the backdoor owner would know (and whoever else reverse engineers it of course). in fact MS would not even have to be complicit here, they'd just sign such an image in good faith without being aware of the secret payload that'd trigger the 'accept this despite being signed by the removed MS key' logic in the backdoored UEFI firmware.

as for 'an exploit in something that was signed by MS' you probably didn't mean that, but rather an exploitable bug as i find it unlikely that an actual exploit embedded in the to-be-signed code would pass their processes whereas bugs (exploitable or not) slip by all the time. with this understanding it seems now that the worry about the MS key is not that someone abuses it to sign something bad (which is what i was going about before) but that otherwise well meaning code gets signed and then exploited due to its bugs. this is a legitimite concern and removing the MS key would indeed help here... except this problem applies equally well to any other key as well and considering where MS stands with its SDLC and other processes in the industry (read: mostly above everyone else) i think the users are worse off trusting anybody else's keys, key signing processes and software development capabilities than those of MS. perhaps a sad piece of truth for free software but as far as i'm concerned, this is the reality. so if the advice here is still that users should become their own CA and use their own keys for Secure Boot then my bet is that the likes of the NSA (and even less resourceful actors) will still have a field day owning their systems.

5. just a few points above you were bringing up different compilers as one of the reasons why universal backdooring would be so much harder for powerful and skilled actors (it isn't, but that's not the point here) and now you're suggesting that much less resourceful end users should try to gain confidence in their firmware by trying to second guess the exact toolchain and build environment their vendor used. sorry, this doesn't add up to a good argument ;).