1 |
On Fri, Jun 15, 2012 at 06:14:12AM -0400, Rich Freeman wrote: |
2 |
> On Fri, Jun 15, 2012 at 12:28 AM, Greg KH <gregkh@g.o> wrote: |
3 |
> > Should I worry about this and how it affects Gentoo, or not worry about |
4 |
> > Gentoo right now and just focus on the other issues? |
5 |
> > |
6 |
> > Minor details like, "do we have a 'company' that can pay Microsoft to |
7 |
> > sign our bootloader?" is one aspect from the non-technical side that I've |
8 |
> > been wondering about. |
9 |
> |
10 |
> So, there are 22 posts already, so I'm going to try to cover a bunch |
11 |
> of topics in one post. I've been thinking about this a fair bit. |
12 |
> |
13 |
> 1. Speaking as an individual trustee... The Gentoo Foundation |
14 |
> legally speaks for Gentoo, can sign contracts, and can write checks. |
15 |
> I don't really forsee any legal issues should we decide we want to |
16 |
> pursue any kinds of relationships with MS or other entities associated |
17 |
> with UEFI. Obviously any decision to actually pursue this would not |
18 |
> be taken lightly. |
19 |
|
20 |
Great to know that this could work, if needed. |
21 |
|
22 |
> 2. From what I've heard the cost of getting a key that would be |
23 |
> recognized by UEFI firmware is as low as a $99 one-time payment, and |
24 |
> we pay many times that for stuff like trademark registration, |
25 |
> corporate filing fees, not to mention hardware for infrastructure. |
26 |
> Cost is likely a non-issue. |
27 |
|
28 |
Yes, it's cheap. |
29 |
|
30 |
> 3. Freedom IS a big issue - my sense is that getting support from the |
31 |
> powers that be for UEFI comes with a lot of strings. If we had a key |
32 |
> the easiest solution would be to just write a signed GRUB stage1 that |
33 |
> works exactly like the one we're all using, and it would load whatever |
34 |
> you want, linux or windows or Stuxnet or otherwise. Once Malware |
35 |
> writers start embedding our bootloader in their stuff I assume that |
36 |
> the people issuing the keys will have the ability to revoke it (at |
37 |
> least for new hardware). |
38 |
|
39 |
Yes, we need to provide some way to "secure" our key, which might prove |
40 |
impossible and foolish for Gentoo to even attempt, as it really wouldn't |
41 |
work out for us. |
42 |
|
43 |
> 4. Fedora is getting around #3 by making the whole thing a big |
44 |
> trusted infrastructure - signature chains for all the kernel-space |
45 |
> code. That meshes well with their whole /usr move initiative - you |
46 |
> just have this big blog of stuff that you trust and never touch, and |
47 |
> you can be sure you're running genuine RedHat goodness, just like all |
48 |
> those iPhone users out there. :) |
49 |
|
50 |
The whole chain-of-trust is an interesting issue as the UEFI spec does |
51 |
not require it at all, and some people on the UEFI committee have told |
52 |
me that it is not required either. But, others have. Getting to the |
53 |
root of this problem is something I'm trying to do, as it's a very |
54 |
important one for anyone who is going to be trusting, and providing, a |
55 |
key in the BIOS. |
56 |
|
57 |
> 5. If somebody (perhaps under the umbrella of hardened) wanted to |
58 |
> create a Gentoo project around a fully trusted Gentoo I'd be |
59 |
> completely supportive of that. It would take work. In the spirit of |
60 |
> Gentoo we should allow anybody to build their own signed with their |
61 |
> own key, and perhaps we might have an official Gentoo-certified one |
62 |
> that we would sign and the Foundation would obtain the necessary UEFI |
63 |
> keys. However, that should be viewed as more of a service, and not a |
64 |
> core offering - Gentoo will never depend on a piece of non-free |
65 |
> software or metadata (and I'd probably lump a signing key into that |
66 |
> category). The same tools (minus the private keys) used to generate |
67 |
> any secure offering made by Gentoo should be available for users to |
68 |
> use and sign their own systems. |
69 |
|
70 |
That would mean we would be in the business of creating binary packages, |
71 |
which is a big change from what we have been doing all of these years, |
72 |
and not to be taken lightly. |
73 |
|
74 |
> 6. At least on x86 users can either disable secure boot, or load |
75 |
> their own signing keys. We should try to support both. |
76 |
|
77 |
Yes. |
78 |
|
79 |
> While the full secure infrastructure of #5 will undoubtedly be a |
80 |
> significant effort we could at least have the handbook have a section |
81 |
> on how to sign your grub when building it and install it in a way that |
82 |
> it can be used to boot (installing the keys themselves might be |
83 |
> firmware-dependent, but to the extent that standards exist we can be |
84 |
> helpful). |
85 |
|
86 |
Yes. |
87 |
|
88 |
> |
89 |
> 7. In general anybody who would be a happy Gentoo user should have no |
90 |
> issues with signing their own bootloader, or disabling secure boot. |
91 |
|
92 |
We have not seen how most BIOSes will allow this to happen, so I can't |
93 |
agree with this statement just yet. |
94 |
|
95 |
> 8. I think the bigger issue is with ARM, and I'm not personally clear |
96 |
> on what the exact policy is there. That really strikes me as |
97 |
> antitrust, but MS might argue that on ARM they have no monopoly |
98 |
> (instead we have a bunch of different vendors who almost universally |
99 |
> lock down their hardware). I can't really see how any solution that |
100 |
> didn't give the end-user the ability to run arbitrary code on their |
101 |
> machine could be called "Gentoo" so our ability to distribute signed |
102 |
> bootloaders there is going to be limited. Maybe we create the ability |
103 |
> to sign your own as with x86, and make the users pay the $99 for their |
104 |
> own keys. As long as individual users don't distribute their |
105 |
> "insecure" bootloaders they shouldn't be at risk of getting them |
106 |
> revoked. |
107 |
|
108 |
I'm not worried about ARM just yet, things are in play to make this |
109 |
possibly a non-issue, but I can't say so for sure at this point in time. |
110 |
Just be assured that people at ARM know about the problem and are |
111 |
working to resolve it. |
112 |
|
113 |
> Well, that's a lot, but those are my impressions. In short I see this |
114 |
> as more of a speed-bump for x86, but a much more fundamental problem |
115 |
> for ARM. |
116 |
|
117 |
It's a big speed-bump for x86, it's going to be a bunch of work and |
118 |
documentation to get right. |
119 |
|
120 |
> I'd be personally interested in pointers to info on what the "powers |
121 |
> that be" do and don't allow with UEFI. I've seen lots of |
122 |
> sky-is-falling blog entries and discussion but little in the way of |
123 |
> specs, and more importantly, policies. |
124 |
|
125 |
You have pointers to the specs now, feel free to fall asleep while |
126 |
reading them :) |
127 |
|
128 |
thanks, |
129 |
|
130 |
greg k-h |