Assuming the key used to sign my pretty new Ubuntu,Fedora,Windows,Whatever-(pre)-bootloader finds - through whatever means of social engineering, bribing or disgruntled janitor - his way to the notorious IT-entrepreneur Mal Wareauthor, who uses it to sign boot-rootkits.

As I understood it, a key used for such nefarious purposes would be blacklisted. Now, will my platform vendor update my key-DB remotely? Will the updated DB be in the next firmware-update? That would pretty much kill the Computer for every single installation of the signed OS, until someone tells the victim how to disable secure boot.

Oh, and every install-medium with a blacklisted signature would be useless too, but that's fine. I can always recycle useless optical discs as coasters, and make new ones from Images. I guess Microsoft would provide one in such a case too.

It looks to me, as if blacklisting a leaked key isn't something I would like to be responsible for. Did I overlook something?

As I see it, he left the problem to Samsung. I mean, how can you be more blatant in saying: 'Fix this, or else....', than by posting ( supposedly ) working exploit code for the majority of the installed OS-base?

As I understood it, the reason for uefi was being able to boot from big harddisks, having prettier hardware-setting-screens, having a builtin network stack for remote maintenance, and so on. It is questionable whether it was necessary to specify pretty much a complete operating system including cli, just to run another OS, and the recent samsung brick fun, is a good hint that manufacturers will need a few years to iron even the bigger kinks out of their implementation, but uefi itself is in theory not without merits.

The reason for secure boot isn't bios-malware, but boot malware. There are a few of those around, as far as I know. The problem with boot-rootkits would be that they can play hypervisor to your OS, which hides them perfectly from software running under it. The idea with trusted boot, again as far as I understood, would be to have a trusted bootloader, which loads a trusted kernel, which in turn loads trusted drivers and trusted applications, the trust being conveyed by signatures.

Only... you have to start at the bottom, which is the bootloader, if you aim for such a chain of trust.

Mr. Garrett had the following to say on this topic here: http://mjg59.dreamwidth.org/12368.html

An alternative was producing some sort of overall Linux key. It turns out that this is also difficult, since it would mean finding an entity who was willing to take responsibility for managing signing or key distribution. That means having the ability to keep the root key absolutely secure and perform adequate validation of people asking for signing. That's expensive. Like millions of dollars expensive. It would also take a lot of time to set up, and that's not really time we had. And, finally, nobody was jumping at the opportunity to volunteer. So no generic Linux key.