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: Fri, 15 Jun 2012 23:57:26
Message-Id: 20120615235553.GB9885@kroah.com
In Reply to: Re: [gentoo-dev] UEFI secure boot and Gentoo by Rich Freeman
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

Replies

Subject Author
Re: [gentoo-dev] UEFI secure boot and Gentoo Rich Freeman <rich0@g.o>