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 |