On Fri, Jun 15, 2012 at 7:55 PM, Greg KH <email@example.com> 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
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.
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.