1 |
On Fri, Jun 15, 2012 at 7:55 PM, Greg KH <gregkh@g.o> wrote: |
2 |
> On Fri, Jun 15, 2012 at 06:14:12AM -0400, Rich Freeman wrote: |
3 |
> The whole chain-of-trust is an interesting issue as the UEFI spec does |
4 |
> not require it at all, and some people on the UEFI committee have told |
5 |
> me that it is not required either. But, others have. Getting to the |
6 |
> root of this problem is something I'm trying to do, as it's a very |
7 |
> important one for anyone who is going to be trusting, and providing, a |
8 |
> key in the BIOS. |
9 |
|
10 |
It sounds like the UEFI committee isn't really the problem here. You |
11 |
can have a UEFI firmware as long as it follows the spec. However, you |
12 |
won't get the Windows logo certification if you don't follow the |
13 |
Windows rules. |
14 |
|
15 |
I would think they'd basically want a chain of trust for anything that |
16 |
loads into kernel space. Otherwise all a malware author has to do is |
17 |
ship a signed linux kernel, have it boot a bash script that loads |
18 |
their malware via an unsigned kernel module, and then at that point |
19 |
they just intercept whatever they want to and then boot Windows, |
20 |
discarding the rest of the linux kernel. |
21 |
|
22 |
However, even the MS requirements say that an OEM can have other keys |
23 |
as well, and nothing says that all of them need to be secure (other |
24 |
than the root key). If I published a keypair on the internet and |
25 |
persuaded OEMs to include it as trusted, then in theory that would |
26 |
pass the MS requirements as they are currently written, and would |
27 |
render secure boot meaningless. |
28 |
|
29 |
Rich |