1 |
On Fri, Jun 15, 2012 at 12:28 AM, Greg KH <gregkh@g.o> wrote: |
2 |
> Should I worry about this and how it affects Gentoo, or not worry about |
3 |
> Gentoo right now and just focus on the other issues? |
4 |
> |
5 |
> Minor details like, "do we have a 'company' that can pay Microsoft to |
6 |
> sign our bootloader?" is one aspect from the non-technical side that I've |
7 |
> been wondering about. |
8 |
|
9 |
So, there are 22 posts already, so I'm going to try to cover a bunch |
10 |
of topics in one post. I've been thinking about this a fair bit. |
11 |
|
12 |
1. Speaking as an individual trustee... The Gentoo Foundation |
13 |
legally speaks for Gentoo, can sign contracts, and can write checks. |
14 |
I don't really forsee any legal issues should we decide we want to |
15 |
pursue any kinds of relationships with MS or other entities associated |
16 |
with UEFI. Obviously any decision to actually pursue this would not |
17 |
be taken lightly. |
18 |
|
19 |
2. From what I've heard the cost of getting a key that would be |
20 |
recognized by UEFI firmware is as low as a $99 one-time payment, and |
21 |
we pay many times that for stuff like trademark registration, |
22 |
corporate filing fees, not to mention hardware for infrastructure. |
23 |
Cost is likely a non-issue. |
24 |
|
25 |
3. Freedom IS a big issue - my sense is that getting support from the |
26 |
powers that be for UEFI comes with a lot of strings. If we had a key |
27 |
the easiest solution would be to just write a signed GRUB stage1 that |
28 |
works exactly like the one we're all using, and it would load whatever |
29 |
you want, linux or windows or Stuxnet or otherwise. Once Malware |
30 |
writers start embedding our bootloader in their stuff I assume that |
31 |
the people issuing the keys will have the ability to revoke it (at |
32 |
least for new hardware). |
33 |
|
34 |
4. Fedora is getting around #3 by making the whole thing a big |
35 |
trusted infrastructure - signature chains for all the kernel-space |
36 |
code. That meshes well with their whole /usr move initiative - you |
37 |
just have this big blog of stuff that you trust and never touch, and |
38 |
you can be sure you're running genuine RedHat goodness, just like all |
39 |
those iPhone users out there. :) |
40 |
|
41 |
5. If somebody (perhaps under the umbrella of hardened) wanted to |
42 |
create a Gentoo project around a fully trusted Gentoo I'd be |
43 |
completely supportive of that. It would take work. In the spirit of |
44 |
Gentoo we should allow anybody to build their own signed with their |
45 |
own key, and perhaps we might have an official Gentoo-certified one |
46 |
that we would sign and the Foundation would obtain the necessary UEFI |
47 |
keys. However, that should be viewed as more of a service, and not a |
48 |
core offering - Gentoo will never depend on a piece of non-free |
49 |
software or metadata (and I'd probably lump a signing key into that |
50 |
category). The same tools (minus the private keys) used to generate |
51 |
any secure offering made by Gentoo should be available for users to |
52 |
use and sign their own systems. |
53 |
|
54 |
6. At least on x86 users can either disable secure boot, or load |
55 |
their own signing keys. We should try to support both. While the |
56 |
full secure infrastructure of #5 will undoubtedly be a significant |
57 |
effort we could at least have the handbook have a section on how to |
58 |
sign your grub when building it and install it in a way that it can be |
59 |
used to boot (installing the keys themselves might be |
60 |
firmware-dependent, but to the extent that standards exist we can be |
61 |
helpful). |
62 |
|
63 |
7. In general anybody who would be a happy Gentoo user should have no |
64 |
issues with signing their own bootloader, or disabling secure boot. |
65 |
|
66 |
8. I think the bigger issue is with ARM, and I'm not personally clear |
67 |
on what the exact policy is there. That really strikes me as |
68 |
antitrust, but MS might argue that on ARM they have no monopoly |
69 |
(instead we have a bunch of different vendors who almost universally |
70 |
lock down their hardware). I can't really see how any solution that |
71 |
didn't give the end-user the ability to run arbitrary code on their |
72 |
machine could be called "Gentoo" so our ability to distribute signed |
73 |
bootloaders there is going to be limited. Maybe we create the ability |
74 |
to sign your own as with x86, and make the users pay the $99 for their |
75 |
own keys. As long as individual users don't distribute their |
76 |
"insecure" bootloaders they shouldn't be at risk of getting them |
77 |
revoked. |
78 |
|
79 |
Well, that's a lot, but those are my impressions. In short I see this |
80 |
as more of a speed-bump for x86, but a much more fundamental problem |
81 |
for ARM. Personally I never buy a general-purpose computing device |
82 |
like a PC or smartphone unless I know in advance that I can gain full |
83 |
control over it. Hopefully that option will remain open to me a lot |
84 |
longer. |
85 |
|
86 |
I'd be personally interested in pointers to info on what the "powers |
87 |
that be" do and don't allow with UEFI. I've seen lots of |
88 |
sky-is-falling blog entries and discussion but little in the way of |
89 |
specs, and more importantly, policies. |
90 |
|
91 |
Rich |