Gentoo Archives: gentoo-dev

From: Peter Stuge <peter@×××××.se>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Killing UEFI Secure Boot
Date: Wed, 20 Jun 2012 03:28:37
Message-Id: 20120620032752.21614.qmail@stuge.se
In Reply to: Re: [gentoo-dev] Killing UEFI Secure Boot by Richard Yao
1 Hi, I have about 11 years of experience with coreboot. I got
2 involved while developing a custom BIOS for an embedded system.
3
4 You may already have caught some presentation I or one of the other
5 developers have made about the project. There's a bunch of links
6 over at http://www.coreboot.org/Screenshots
7
8
9 Richard Yao wrote:
10 > Core Boot is a Linux distribution.
11
12 Sorry sir, but no.
13
14 coreboot (one word, lowercase) is an open source BIOS replacement.
15
16 Proprietary BIOSes do two things:
17
18 1. hardware initialization
19 on http://stuge.se/pc2010.png everything red requires init by firmware
20
21 2. starts an operating system
22 this means implementing the BIOS Boot Specification, running
23 master boot record code into real mode segment 7c00h, eltorito
24 CD-ROM extensions and all of that crap
25
26 coreboot does step 1. and nothign else, and significantly faster than
27 common proprietary BIOSes.
28
29 When coreboot is done it starts another, separate, program, we call
30 that program "the payload."
31
32 The payload and coreboot are stored together in the boot flash, but
33 are not linked together. The payload can be any bare-metal program.
34
35 There are many legacy-free bootloader payloads, including GRUB2 and
36 gPXE/iPXE/whateverit'scalledtoday, but it can just as easily be an
37 operating system kernel or an embedded application if no OS is
38 needed. Boot flash are often 32Mbit today, so Linux and a small
39 initramfs fits comfortably.
40
41 The default payload is SeaBIOS, which is also the firmware QEMU uses.
42
43 SeaBIOS is an open source legacy BIOS implementation, and the
44 combination of coreboot and SeaBIOS provides a legacy-compatible
45 boot environment that starts your system exactly like an
46 old-fashioned proprietary BIOS.
47
48 With coreboot my laptop boots from power button to firefox in a
49 little over 8 seconds. Out of that time, coreboot runs for about
50 600 milliseconds. This is a fairly typical number.
51
52
53 > The 80386's RESET state is emulated uniformly across all x86 and amd64,
54 > so it should not take much effort to support the basic functions of
55 > setting up the CPU, loading the kernel (from the EEPROM) and jumping
56 > into it.
57
58 This is word for word what the founders of the coreboot project (then
59 called LinuxBIOS) thought back in 1999, and it blew up in their face.
60
61 In the following 15 years hardware has gotten significantly more
62 complex, and significantly more closed, again please have a look
63 at http://stuge.se/pc2010.png
64
65 The closer you are to the CPU the more impossible it is to acquire
66 reliable documentation for how to program the hardware.
67
68
69 > Those are the only things that a BIOS replacement needs to do.
70
71 Please join the project! If you find lowlevel programming interesting
72 it is an amazing good time, even if progress is slow at times. Now is
73 a fantastic time to get involved! For the first time in the history
74 of the project, there is code in the repository for all current
75 hardware platforms from both AMD and Intel.
76
77
78 > they are doing far more than those basic functions
79
80 I hope I've been able to clarify that actually coreboot does nothing
81 other than what is neccessary. This is the very essence of coreboot.
82
83
84 > Basic functionality would only require the work of a few people.
85
86 I'm afraid that this is rather naive.
87
88 An experienced coreboot developer given all required documentation[1]
89 (and ideally some 100-1000k EUR/USD worth of test equipment) can
90 possibly do a port to a new hardware platform (new CPU and chipset)
91 in twelve to eighteen months full time.
92
93 A hard core developer but without previous experience from PC
94 firmware and coreboot should add some six months for loading the
95 domain into her head.
96
97 [1] For Intel this requires two stages of NDAs and a decent business
98 case where Intel will sell five-six figure amounts of chips, or fewer
99 chips but to an important customer.
100
101 In contrast, AMD put the documentation on their webpage.
102
103 NVIDIA did not give the documentation to anyone no matter what the
104 business case. VIA doesn't publish documentation on the web, but
105 some coreboot developers do have good relations with them.
106
107
108 Over the last couple years Google have hired most of the active
109 coreboot developers including the project founder, and they've been
110 working on support for Intel's Sandy Bridge and Ivy Bridge platforms,
111 which powers the new Chromebook. I do not know how much time they've
112 spent, but from my outside view I estimate that it took this amazing
113 team of engineers between 25 and 30 man-months. This may be a very
114 optimistic estimate.
115
116 These new Intel platforms require a blob, firmware for a
117 microcontroller in the chipset, which runs while the main CPU is
118 still held in reset, in order to do some early prepararation of the
119 system.
120
121 The firmware blob is signed by Intel. I don't know if the signature
122 scheme has been broken, I guess it might at some point, but that will
123 likely be by the usual IT security crowd suspects.
124
125 In Google's coreboot code they are using Intel's reference code for
126 initializing the memory controller. This is so far also a blob, again
127 as opposed to AMD who have released their reference code under dual
128 BSD and GPL license, and although it is theoretically possible to
129 replace this with self-written code that is not really economical.
130
131 Please look through the SDRAM, DDR and DDR2 self-written init code
132 in coreboot for the various platforms, and then think about the
133 complexity added by DDR3, and I expect that hardware vendors and
134 JEDEC are hard at work on DDR4.
135
136 Memory controller init involves among other things a brute force
137 search of electrical signal drive strengths to find the correct
138 setting for stable operation.
139
140
141 > Linux already has thousands of developers working on hardware support,
142 > including developers from Intel. We should be able to leverage that.
143
144 Forget about that. Everything that happens on the Linux level is
145 really a different matter.
146
147
148 > Did I miss any technical obstacles?
149
150 PCs have 35 years of hardware legacy. It's quite possibly the worst
151 pile of hardware crap on top of hardware crap you can imagine. It's
152 a feat that anything works at all.
153
154 You mention 80386, but all PCs still start in real mode, 8086 style.
155 In another five or ten years maybe that will change, and (some)
156 hardware will become much more locked down. But I'm not sure, DOS
157 remains a significant market.
158
159 Someone said "Intel make the best x86 emulators." and that is spot
160 on. Besides that microcontroller inside your CPU there's of course
161 also the CPU microcode. There are no modern x86 machines.
162
163
164 FSF has long considered coreboot a high priority project, because it
165 makes UEFI irrelevant, and it very much puts users in full control,
166 while at the same time being transparent thanks to the open source.
167
168 They don't do much in terms of contributions though. I can understand
169 that. The way for coreboot to become relevant is to ship from factory.
170 Everyone with experience from the IBV (Independent BIOS Vendor)
171 industry knows what a special marketplace this is. It's very
172 interesting, but don't let anyone tell you that anything is easy.
173
174 The technical obstacles are the least of the problems.
175
176
177 //Peter