Gentoo Archives: gentoo-dev

From: Greg KH <gregkh@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] UEFI secure boot and Gentoo
Date: Sat, 16 Jun 2012 03:50:13
Message-Id: 20120616034922.GA3900@kroah.com
In Reply to: Re: [gentoo-dev] UEFI secure boot and Gentoo by Rich Freeman
1 On Fri, Jun 15, 2012 at 08:41:47PM -0400, Rich Freeman wrote:
2 > On Fri, Jun 15, 2012 at 7:55 PM, Greg KH <gregkh@g.o> wrote:
3 > > On Fri, Jun 15, 2012 at 06:14:12AM -0400, Rich Freeman wrote:
4 > > The whole chain-of-trust is an interesting issue as the UEFI spec does
5 > > not require it at all, and some people on the UEFI committee have told
6 > > me that it is not required either.  But, others have.  Getting to the
7 > > root of this problem is something I'm trying to do, as it's a very
8 > > important one for anyone who is going to be trusting, and providing, a
9 > > key in the BIOS.
10 >
11 > It sounds like the UEFI committee isn't really the problem here. You
12 > can have a UEFI firmware as long as it follows the spec. However, you
13 > won't get the Windows logo certification if you don't follow the
14 > Windows rules.
15
16 That is exactly the case.
17
18 > I would think they'd basically want a chain of trust for anything that
19 > loads into kernel space. Otherwise all a malware author has to do is
20 > ship a signed linux kernel, have it boot a bash script that loads
21 > their malware via an unsigned kernel module, and then at that point
22 > they just intercept whatever they want to and then boot Windows,
23 > discarding the rest of the linux kernel.
24
25 Yes, that is the problem we are facing.
26
27 > However, even the MS requirements say that an OEM can have other keys
28 > as well, and nothing says that all of them need to be secure (other
29 > than the root key). If I published a keypair on the internet and
30 > persuaded OEMs to include it as trusted, then in theory that would
31 > pass the MS requirements as they are currently written, and would
32 > render secure boot meaningless.
33
34 The liability requirements for an OEM to accept a key into their BIOS,
35 that is something other than Microsoft's key (if there is even the room,
36 some bioses will not have extra room for lots of keys), is beyond
37 anything that any Linux company can afford, or is willing to accept.
38
39 greg k-h