Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] UEFI secure boot and Gentoo
Date: Fri, 15 Jun 2012 10:15:18
Message-Id: CAGfcS_=U5_xwGYgdF0L_yrdjMWSNkcPeqGFmZa4o6L+JtKvX9w@mail.gmail.com
In Reply to: [gentoo-dev] UEFI secure boot and Gentoo by Greg KH
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

Replies

Subject Author
Re: [gentoo-dev] UEFI secure boot and Gentoo Florian Philipp <lists@×××××××××××.net>
Re: [gentoo-dev] UEFI secure boot and Gentoo Luca Barbato <lu_zero@g.o>
Re: [gentoo-dev] UEFI secure boot and Gentoo "G.Wolfe Woodbury" <redwolfe@×××××.com>
Re: [gentoo-dev] UEFI secure boot and Gentoo Greg KH <gregkh@g.o>