On Fri, Jun 15, 2012 at 08:41:47PM -0400, Rich Freeman wrote: > On Fri, Jun 15, 2012 at 7:55 PM, Greg KH <gre...@gentoo.org> wrote: > > On Fri, Jun 15, 2012 at 06:14:12AM -0400, Rich Freeman wrote: > > The whole chain-of-trust is an interesting issue as the UEFI spec does > > not require it at all, and some people on the UEFI committee have told > > me that it is not required either. But, others have. Getting to the > > root of this problem is something I'm trying to do, as it's a very > > important one for anyone who is going to be trusting, and providing, a > > key in the BIOS. > > It sounds like the UEFI committee isn't really the problem here. You > can have a UEFI firmware as long as it follows the spec. However, you > won't get the Windows logo certification if you don't follow the > Windows rules.
That is exactly the case. > I would think they'd basically want a chain of trust for anything that > loads into kernel space. Otherwise all a malware author has to do is > ship a signed linux kernel, have it boot a bash script that loads > their malware via an unsigned kernel module, and then at that point > they just intercept whatever they want to and then boot Windows, > discarding the rest of the linux kernel. Yes, that is the problem we are facing. > However, even the MS requirements say that an OEM can have other keys > as well, and nothing says that all of them need to be secure (other > than the root key). If I published a keypair on the internet and > persuaded OEMs to include it as trusted, then in theory that would > pass the MS requirements as they are currently written, and would > render secure boot meaningless. The liability requirements for an OEM to accept a key into their BIOS, that is something other than Microsoft's key (if there is even the room, some bioses will not have extra room for lots of keys), is beyond anything that any Linux company can afford, or is willing to accept. greg k-h
