1
00:00:00,000 --> 00:00:13,009
33c3 preroll music
2
00:00:13,009 --> 00:00:16,870
Herald: So, the last speaker for this
morning is Trammell. He is doing
3
00:00:16,870 --> 00:00:21,510
awesome research on "Bootstrapping
more secure laptops or servers" and
4
00:00:21,510 --> 00:00:27,480
he is doing that basically by moving the
root of trust into the write-protected room.
5
00:00:27,480 --> 00:00:32,829
He is building an open-source custom
firmware, so big ups for that, and also
6
00:00:32,829 --> 00:00:36,759
encouraging the research on this field
which I believe it's super interesting.
7
00:00:36,759 --> 00:00:42,199
Thanks!
applause
8
00:00:42,199 --> 00:00:46,979
applause
9
00:00:46,979 --> 00:00:49,790
Trammel Hudson: So I'm Trammell Hudson
with Two Sigma Investments, and for the
10
00:00:49,790 --> 00:00:54,310
past several years I've been researching
firmware security vulnerabilities
11
00:00:54,310 --> 00:00:59,420
and looked at how they affect systems.
Two years ago, I presented my work
12
00:00:59,420 --> 00:01:05,030
on Thunderstrike here at CCC. And this was
the first firmware attack against MacBooks
13
00:01:05,030 --> 00:01:09,249
that allowed an attacker to override
the motherboard bootrom.
14
00:01:09,249 --> 00:01:14,310
The year after that, I collaborated with
Xeno Kovah and Corey Kallenberg
15
00:01:14,310 --> 00:01:19,200
from LegbaCore - both of whom
are now at Apple, doing firmware work.
16
00:01:19,200 --> 00:01:24,990
And we ported a bunch of Windows UEFI
vulnerabilities over to the Mac, and
17
00:01:24,990 --> 00:01:29,640
showed that the software platform - the
UEFI software platform, you know - allowed
18
00:01:29,640 --> 00:01:35,659
very portable attacks to be done. This
also allowed a remote attacker with code
19
00:01:35,659 --> 00:01:41,689
execution on your machine to override the
motherboard bootrom. But, more than just
20
00:01:41,689 --> 00:01:46,530
breaking things, what we like to do is
take the things apart and understand how
21
00:01:46,530 --> 00:01:51,360
they work and document them, so that other
people can build systems on top of them.
22
00:01:51,360 --> 00:01:55,370
And that's why I'm really excited to be
talking to you all about my project
23
00:01:55,370 --> 00:02:00,630
"Heads", which is a open source
firmware and boot loader
24
00:02:00,630 --> 00:02:06,429
for laptops and servers.
The name is kind of a play
25
00:02:06,429 --> 00:02:11,239
on the popular 'Tails' distribution
which is a stateless Linux
26
00:02:11,239 --> 00:02:15,070
for when you don't want to leave any traces
of what you're doing on your machine.
27
00:02:15,070 --> 00:02:18,680
Heads is for the opposite case: it's where
you want to be able to trust the machine,
28
00:02:18,680 --> 00:02:23,570
and you want to be able to trust that the
data you store on the machine is safe
29
00:02:23,570 --> 00:02:28,640
and unmodified. And, let's back up
for a quick minute and just talk about
30
00:02:28,640 --> 00:02:34,380
why firmware security is so important,
that this is the code that is
31
00:02:34,380 --> 00:02:39,490
executed by the CPU when it comes out of
reset. This is the first instruction that
32
00:02:39,490 --> 00:02:43,840
the CPU executes. And so it's in a really
privileged position to be able to
33
00:02:43,840 --> 00:02:50,680
circumvent any sort of OS or other
policies. And there's no shortage of talks
34
00:02:50,680 --> 00:02:55,820
that you can watch on interesting
attack vectors using firmware-based
35
00:02:55,820 --> 00:03:01,300
malware. One that I really liked
was last year at DEFCON. The
36
00:03:01,300 --> 00:03:06,050
Intel Advanced Threat Research
presented an attack that showed
37
00:03:06,050 --> 00:03:11,830
how firmware could - malicious firmware -
could circumvent the hypervisors. They
38
00:03:11,830 --> 00:03:17,920
then went further and showed how buggy
firmware allowed a unprivileged guest
39
00:03:17,920 --> 00:03:25,200
inside a virtual machine to escalate into
privileges inside the hypervisor. And for
40
00:03:25,200 --> 00:03:29,750
that reason, it's really important that
firmware vulnerabilities and firmware bugs
41
00:03:29,750 --> 00:03:36,370
have a way to get patched. These aren't
just theoretical research vulnerabilities,
42
00:03:36,370 --> 00:03:41,420
either. We know that there are malicious
organizations and hacking groups that are
43
00:03:41,420 --> 00:03:48,269
selling firmware rootkits to whoever will
pay - including nation-state adversaries,
44
00:03:48,269 --> 00:03:55,590
that are using them for their persistent
threats. And they are very persistent,
45
00:03:55,590 --> 00:04:00,560
because they are in the motherboard
bootrom So you've reinstalled the OS -
46
00:04:00,560 --> 00:04:06,959
they're still there, you swap out the hard
drive - they're still there. And some
47
00:04:06,959 --> 00:04:14,890
vendors are even bundling these rootkits
into their official ROMs. That they are
48
00:04:14,890 --> 00:04:22,019
using them to install the bloatware, or
whatever adware they want to put into the
49
00:04:22,019 --> 00:04:28,189
OS. So even after you reinstall a clean
version of the OS, this particular vendors
50
00:04:28,189 --> 00:04:34,840
system would install its own additions.
Some of those had vulnerabilities that
51
00:04:34,840 --> 00:04:41,139
could then be exploited by attackers. This
particular case, the vendor received
52
00:04:41,139 --> 00:04:46,450
enough bad press, that they released a
firmware update that patched this
53
00:04:46,450 --> 00:04:50,919
vulnerability. And they had to do that.
This wasn't something that the users could
54
00:04:50,919 --> 00:04:55,689
do on their own - they couldn't update the
the firmware in their machine the
55
00:04:55,689 --> 00:05:02,389
way they do with their operating system or
an application. And in fact, most firmware
56
00:05:02,389 --> 00:05:08,780
vulnerabilities never see patches get
deployed out to the end-user.
57
00:05:08,780 --> 00:05:15,499
Part of the reason for that is that the
the firmware is usually four or five
58
00:05:15,499 --> 00:05:21,699
companies, removed from the end-user. That
there's the open source reference
59
00:05:21,699 --> 00:05:28,100
implementation from Intel, called eh
TianoCore or EDK II. When vulnerabilities
60
00:05:28,100 --> 00:05:33,689
are patched in there, they have to get
pulled by the independent BIOS vendor, and
61
00:05:33,689 --> 00:05:39,499
merged into the IBV tree, and then the
BIOS vendor sells that to the device
62
00:05:39,499 --> 00:05:44,710
manufacturers. So they have to package up
a release the thing gets pulled by the
63
00:05:44,710 --> 00:05:49,389
device manufacturer. It has to get QA'd it
against however many motherboards they
64
00:05:49,389 --> 00:05:55,550
want to test it on. And then it has to get
again pulled by the original equipment
65
00:05:55,550 --> 00:06:00,830
manufacturer to get rebranded and whatever
value they want to add. And then sometimes
66
00:06:00,830 --> 00:06:05,479
it has to go through the operating system
vendor to even make it out to the end-
67
00:06:05,479 --> 00:06:10,400
user. And as a result of this, most of the
time, products do not receive any updates
68
00:06:10,400 --> 00:06:15,409
after they've been sold. There's one
exception: in this chart you can see that
69
00:06:15,409 --> 00:06:21,249
Apple builds their own firmware, and in my
work with them, I've been really pleased
70
00:06:21,249 --> 00:06:26,179
that they've rolled out patches for eight
years of hardware. Which is above and
71
00:06:26,179 --> 00:06:34,939
beyond what any other firmware vendor is
doing right now. When EFI was introduced,
72
00:06:34,939 --> 00:06:43,599
it brought a lot of complexity, and the
Linux community was very skeptical as to
73
00:06:43,599 --> 00:06:48,300
what the value was going to be provided by
all this complexity. It's basically an
74
00:06:48,300 --> 00:06:54,199
entire operating systems worth of code.
And it's not, that the 16-bit real-mode
75
00:06:54,199 --> 00:07:01,289
BIOS was all that much better. In fact, it
had its own set of issues. But it was
76
00:07:01,289 --> 00:07:08,590
small, it was simple, it did one thing, it
did it okay. And it took a long time for
77
00:07:08,590 --> 00:07:15,259
UEFI to even become widely supported. But
even now most systems ship with both the
78
00:07:15,259 --> 00:07:19,999
UEFI and a BIOS compatibility module. So
they've basically doubled their attack
79
00:07:19,999 --> 00:07:25,369
surface for potential bugs and
vulnerabilities. So the state of the
80
00:07:25,369 --> 00:07:33,110
firmware world today is that updates are
rare, patches, if they ever come out, take
81
00:07:33,110 --> 00:07:35,599
a long time to make it through the
process.
82
00:07:35,599 --> 00:07:41,449
Users can't fix things on their own, and
we can't see what's inside, since most of
83
00:07:41,449 --> 00:07:45,339
them are built with closed source
components - and that's not a great state
84
00:07:45,339 --> 00:07:52,649
for something that is as privileged as a
firmware. So it's my belief, that firmware
85
00:07:52,649 --> 00:07:57,050
needs to be built with open source. It
must be flexible, so we can adapt it to
86
00:07:57,050 --> 00:08:02,580
our needs for our systems. It needs to be
built with software that we understand and
87
00:08:02,580 --> 00:08:08,770
we use for, in, other applications, so
that it can get widely tested and well
88
00:08:08,770 --> 00:08:12,869
tested. It needs to be built in a
reproducible manner, so that we can be
89
00:08:12,869 --> 00:08:18,330
secure against that build chain attacks.
And it needs to be cryptographically
90
00:08:18,330 --> 00:08:23,189
measured, so that we can be sure that
this, what we flash on the system, is what
91
00:08:23,189 --> 00:08:30,159
is actually running on the system. And
that's the philosophy behind Heads - it's
92
00:08:30,159 --> 00:08:36,429
built on the free software coreboot
firmware, plus a Linux kernel in ROM, that
93
00:08:36,429 --> 00:08:44,959
acts as a bootloader, and then a lot of
security research and tools, that help us
94
00:08:44,959 --> 00:08:52,420
try to build slightly more secure systems.
Using Linux as a bootloader is not a
95
00:08:52,420 --> 00:08:58,370
particularly new idea. Back in the 1990s
when we started building large scale Linux
96
00:08:58,370 --> 00:09:07,840
clusters, we were very frustrated with the
inflexibility of DHCP and PXE booting
97
00:09:07,840 --> 00:09:13,230
large machines, that even with those
frustrations, we built one, that was about
98
00:09:13,230 --> 00:09:21,060
the 30th fastest in the world on the top
500. Meanwhile, my colleague Ron Minich at
99
00:09:21,060 --> 00:09:25,960
Los Alamos was also building large
clusters, and had the observation that the
100
00:09:25,960 --> 00:09:33,489
BIOS enumerates all the buses, initializes
a bunch of devices, finds the Linux kernel
101
00:09:33,489 --> 00:09:38,680
and in the Linux kernel, enumerates all
the buses, initializes all the devices,
102
00:09:38,680 --> 00:09:43,640
and he thought: "This is this is silly,
why are we doing this twice?".
103
00:09:43,640 --> 00:09:49,730
So he had the idea to build a version of
Linux, that ran in the ROM. He called this
104
00:09:49,730 --> 00:09:56,459
project "Linux BIOS" and it went on to
power the MRC cluster, which was the third
105
00:09:56,459 --> 00:10:04,850
fastest machine in the world in 2003. In
2008 Linux BIOS underwent a major
106
00:10:04,850 --> 00:10:10,100
refactoring and it was renamed to
"Coreboot". And Google chose to use
107
00:10:10,100 --> 00:10:14,690
Coreboot as the firmware on their
Chromebooks - which are at this point the
108
00:10:14,690 --> 00:10:24,190
only non-UEFI x86-based laptops that you
can buy. And they've done some really some
109
00:10:24,190 --> 00:10:28,280
great work in trying to lock down the
configuration and the firmware on the
110
00:10:28,280 --> 00:10:35,779
Chromebooks. Ron, who has only moved to
Google in 2011 and is continuing to work
111
00:10:35,779 --> 00:10:47,350
on the Coreboot project there. So Coreboot
has three stages that it goes through as
112
00:10:47,350 --> 00:10:53,820
it starts up the machine: the first one is
a very small amount of real-mode assembly,
113
00:10:53,820 --> 00:11:00,699
because your modern 64-bit laptop still
boots up in real mode with 16-bit just
114
00:11:00,699 --> 00:11:08,389
like its 1970's. So that's a very small
amount of code - about 1.5K. That in turn
115
00:11:08,389 --> 00:11:14,170
sets up a C runtime environment with
what's called "Cache-as-RAM mode" and it
116
00:11:14,170 --> 00:11:20,330
calls into the ROM stage which is about
70K. "Heads" has moved the TPM
117
00:11:20,330 --> 00:11:26,800
initialization early in the ROM stage
before DRAM is set up to help measure the
118
00:11:26,800 --> 00:11:33,069
boot block and provide a static route of
trust that's hopefully a little bit more
119
00:11:33,069 --> 00:11:38,279
secure. And because that measurement is
done early on, our trusted computing base
120
00:11:38,279 --> 00:11:44,660
is actually quite small. This is a
fraction of 1% of the size of a UEFI
121
00:11:44,660 --> 00:11:50,339
firmware, which is usually about 16 MB
once it's uncompressed.
122
00:11:50,339 --> 00:11:55,730
The ROM stage then measures and executes
the RAM stage, which does the more
123
00:11:55,730 --> 00:12:01,120
traditional "walk the bus, find / figure
out what devices are on there", but it
124
00:12:01,120 --> 00:12:04,269
doesn't initialize them: it just
enumerates them and generates the
125
00:12:04,269 --> 00:12:09,320
descriptors for Linux. It also installs
the SMM handler for system management
126
00:12:09,320 --> 00:12:16,710
mode. It then measures and jumps into the
payload - and that whole process takes
127
00:12:16,710 --> 00:12:23,669
less than a second. So it is able to get
into the payload and actually get to the
128
00:12:23,669 --> 00:12:30,730
user code very, very quickly. On something
like the X230 it's able to go from power
129
00:12:30,730 --> 00:12:36,720
on to a interactive recovery shell in less
than 2 seconds. And that includes bring up
130
00:12:36,720 --> 00:12:42,560
the TPM, doing cryptographic measurements
and assessing the state of the system.
131
00:12:42,560 --> 00:12:46,790
Because we now have Linux at this point,
we have all the flexibility that comes
132
00:12:46,790 --> 00:12:53,550
with that. We can implement boot scripts
with the full power of the shell or the C
133
00:12:53,550 --> 00:12:57,600
language runtime:
we're not stuck with the limited functions
134
00:12:57,600 --> 00:13:02,889
of UEFI. Linux supports lots of different
file systems. It supports lots of
135
00:13:02,889 --> 00:13:07,139
different devices. It supports lots of
different encryption methods. And this
136
00:13:07,139 --> 00:13:12,830
gives us the ability to use any of them
for your specific application. In
137
00:13:12,830 --> 00:13:19,850
contrast, UEFI, which supports unencrypted
FAT file systems on the first drive that
138
00:13:19,850 --> 00:13:23,589
have to be in the first 1 GiB or
something, it's really, really limited as
139
00:13:23,589 --> 00:13:31,810
to how it can find its boot device.
There's a saying in the in the Open Source
140
00:13:31,810 --> 00:13:35,889
community that with enough eyes all bugs
are shallow.
141
00:13:35,889 --> 00:13:42,610
And Linux has a lot more eyes looking at
it. That the device drivers and the file
142
00:13:42,610 --> 00:13:50,249
systems and the encryption have been
reviewed by both white hat and black hat
143
00:13:50,249 --> 00:13:56,709
people around the world. The UEFI versions
of these do not have that same level of
144
00:13:56,709 --> 00:14:03,160
scrutiny, so we're using both the UEFI
drivers and then having to run whatever on
145
00:14:03,160 --> 00:14:08,079
top of it, increases the attack surface.
But by putting Linux in the ROM and
146
00:14:08,079 --> 00:14:15,480
depending on its drivers we've reduced our
attack surface very dramatically. More
147
00:14:15,480 --> 00:14:21,240
importantly though, Coreboot and Linux are
Open Source, so it is possible to build
148
00:14:21,240 --> 00:14:25,480
custom versions for the device drivers
that you need, for the file systems that
149
00:14:25,480 --> 00:14:30,839
you need. It's possible to fix bugs when
they come out, and sign and install your
150
00:14:30,839 --> 00:14:37,089
own kernels. You don't have to wait for
the vendor to get around to doing it.
151
00:14:37,089 --> 00:14:44,889
And the third major component of heads is
a tool called "kexec", which is a system
152
00:14:44,889 --> 00:14:50,269
call that was added for the Linux BIOS
project back in 2003 by Eric Peterman,
153
00:14:50,269 --> 00:14:56,230
that allows a running kernel to do a
graceful shutdown and start a new kernel
154
00:14:56,230 --> 00:15:01,060
without having to go through the reboot
process. So this allowed, on their
155
00:15:01,060 --> 00:15:06,510
application, it allowed them to do very
fast reboots of their cluster nodes. And
156
00:15:06,510 --> 00:15:11,939
in the "Heads" case, it allows us to act
as a bootloader where we can find the real
157
00:15:11,939 --> 00:15:16,149
kernel, that you want to run, and exec it.
Because "Heads" is quite small. It has to
158
00:15:16,149 --> 00:15:22,689
fit in 4 MB of ROM. So it's not something
that you learn to run as a day-to-day sort
159
00:15:22,689 --> 00:15:31,229
of OS. Hopefully this won't explode on me
again.
160
00:15:36,269 --> 00:15:40,799
Because we have the Bourne Shell, most of
the policies and the startup scripts in
161
00:15:40,799 --> 00:15:47,779
"Heads" are implemented as as shell
scripts. In this case we were able to pass
162
00:15:47,779 --> 00:15:52,939
in a new set of command line parameters, a
new initial RAM disk, and in this case we
163
00:15:52,939 --> 00:15:58,620
can even start a hypervisor. And all of
that can happen very very quickly, as well
164
00:15:58,620 --> 00:16:07,269
as with with a good degree of security.
So, those are the building blocks that
165
00:16:07,269 --> 00:16:12,980
"Heads" is built on: Coreboot, Linux and
tools like "kexec". But it now gives us a
166
00:16:12,980 --> 00:16:16,710
really nice platform to begin
experimenting with additional security
167
00:16:16,710 --> 00:16:23,240
features. And before we go too deep down
the rabbit hole of, you know, security and
168
00:16:23,240 --> 00:16:27,509
threat models, I want to quote my friend
Steph, who said that, "Your threat model
169
00:16:27,509 --> 00:16:31,019
is not my threat model."
But you know your threat model is okay as
170
00:16:31,019 --> 00:16:35,730
well, that we all have different things we
want to protect, from different attackers,
171
00:16:35,730 --> 00:16:40,389
who are willing to spend different amounts
of effort to go after them. And the nice
172
00:16:40,389 --> 00:16:46,129
thing about having an open source is: We
can build systems tailored to your
173
00:16:46,129 --> 00:16:50,930
individual threat model. So a lot of these
things may not actually apply to your
174
00:16:50,930 --> 00:16:59,060
specific threats, but the fact that we can
build them is a great capability. Last
175
00:16:59,060 --> 00:17:05,990
year Joanna Rutkowska reminded us that
firmware is not just in our CPU. Firmware
176
00:17:05,990 --> 00:17:12,809
is in our Wi-Fi card. It is in our GPU. It
is in our SSD. It is in our keyboards. And
177
00:17:12,809 --> 00:17:19,189
all of these devices might be trying to
subvert the boot process.
178
00:17:19,189 --> 00:17:25,500
One way to handle that is to take Peter
Stuge's advice of disassembling the
179
00:17:25,500 --> 00:17:30,401
machine and ripping out anything we can't
control. If this is your threat model, his
180
00:17:30,401 --> 00:17:35,090
instructions are really worth following.
They're really thorough about what pieces
181
00:17:35,090 --> 00:17:41,070
are potentially of concern. And you're
going, right now, you'll have to open up
182
00:17:41,070 --> 00:17:46,560
your laptop to install "Heads." It's not
quite as easy as it is to install most
183
00:17:46,560 --> 00:17:52,660
Linux distributions, because we have to
flash it into the motherboard boot ROM.
184
00:17:52,660 --> 00:17:56,659
While we're in there, now, we take
advantage of some features that, to the
185
00:17:56,659 --> 00:18:02,279
best of my knowledge, no UEFI system is
using. These flash chips have a hardware
186
00:18:02,279 --> 00:18:09,610
write-protect mode, where you can specify
part of the chip is write-only. Excuse me.
187
00:18:09,610 --> 00:18:15,480
Is read-only, write-once. And this gives
us our immutable boot block in which to
188
00:18:15,480 --> 00:18:20,340
store the trusted computing base, the TCB,
so that we can measure the rest of the
189
00:18:20,340 --> 00:18:26,270
system. We also then suggest disconnecting
the write-protect PIN from the
190
00:18:26,270 --> 00:18:32,940
motherboard, which protects against
certain classes of attacks, like the Intel
191
00:18:32,940 --> 00:18:38,899
close chassis adapter, that allows
external JTAG of the CPU.
192
00:18:38,899 --> 00:18:42,440
Depending on your threat model you might
want to cover that chip in epoxy as well,
193
00:18:42,440 --> 00:18:48,499
to frustrate Evil Maid attacks that want
to do a physical programming on it.
194
00:18:48,499 --> 00:18:53,490
Disconnecting the write-protect PIN also
serves to protect from other devices on
195
00:18:53,490 --> 00:18:58,890
the machine that have access to those
PINs. Devices like the Management Engine,
196
00:18:58,890 --> 00:19:08,630
which is a really scary CPU inside the
CPU. Rudolf Marek two years ago at CCC
197
00:19:08,630 --> 00:19:17,610
called it the "Matroyshka CPU".
And Igor Skochinsky detailed what are the
198
00:19:17,610 --> 00:19:23,549
capabilities of the management engine. And
they're really worrisome, that it runs a
199
00:19:23,549 --> 00:19:31,060
opaque obfuscated blob of code about 5 MiB
that the CPU can't see. The management
200
00:19:31,060 --> 00:19:35,980
engine can read and write all of main
memory. It can read from the keyboard and
201
00:19:35,980 --> 00:19:42,059
video. It can receive Java bytecodes over
the network and execute them on behalf of
202
00:19:42,059 --> 00:19:46,510
someone outside the machine. And it's
listening on the network even when the
203
00:19:46,510 --> 00:19:51,530
system is powered off.
So this is basically a rootkit inside the
204
00:19:51,530 --> 00:19:58,480
chipset, as some folks have called it. So
that concerned me a lot, and I spent some
205
00:19:58,480 --> 00:20:03,500
time looking at how its firmware images
are built, and realized that we can build
206
00:20:03,500 --> 00:20:10,059
modified, reduced functionality firmware
for it that removes all of the rootkit
207
00:20:10,059 --> 00:20:16,150
functions, and just leaves the "CPU bring
up" module. This takes that 5 MiB and
208
00:20:16,150 --> 00:20:23,720
shrinks it down to about about 40 KiB of
space. So we don't know exactly what it's
209
00:20:23,720 --> 00:20:28,460
doing in that 40 KiB, but we at least know
it doesn't have a device driver, or a Java
210
00:20:28,460 --> 00:20:31,719
Virtual Machine, or a lot of the other
functions.
211
00:20:31,719 --> 00:20:37,710
And we've successfully done this on both
Sandy Bridge and Ivy Bridge like the X230
212
00:20:37,710 --> 00:20:43,380
ThinkPads as well as modern Skylake CPUs
like the Chell Chromebook. And that's
213
00:20:43,380 --> 00:20:47,809
really encouraging, that if we can apply
this to more modern hardware, that allows
214
00:20:47,809 --> 00:20:53,570
us to, you know, move away from our five-
year-old ThinkPads to something a little
215
00:20:53,570 --> 00:21:01,580
shinier. The management engine isn't the
only device that might be trying subvert
216
00:21:01,580 --> 00:21:05,799
the boot process. Again Johanna showed us
there are lots of things to be worried
217
00:21:05,799 --> 00:21:12,159
about. Intel's UEFI architects, Yao and
Zimmer, recommend that firmware turn on
218
00:21:12,159 --> 00:21:19,630
the IOMMU, now called VTD, to protect
against rogue devices. To the best of my
219
00:21:19,630 --> 00:21:24,409
knowledge, since they've written this
guide, no UEFI firmware is taking
220
00:21:24,409 --> 00:21:29,200
advantage of the IOMMU. So, it's a great
piece of hardware to have, but it doesn't
221
00:21:29,200 --> 00:21:35,720
help if you don't turn it on. Linux,
meanwhile has no problem taking advantage
222
00:21:35,720 --> 00:21:40,220
of it, so we use it, what we get
essentially - we get that DMA protection
223
00:21:40,220 --> 00:21:48,120
for free by using Linux as our bootloader
in the ROM. Another way devices, rogue
224
00:21:48,120 --> 00:21:52,360
devices, can try to interfere with the
boot process is by providing option ROMs,
225
00:21:52,360 --> 00:21:59,169
which are executable code to be run by the
BIOS, that have a sort of a device driver.
226
00:21:59,169 --> 00:22:03,630
And this code can do things like about log
keystrokes and then try to exfiltrate
227
00:22:03,630 --> 00:22:11,909
passwords as we see here. That problem was
initially reported in 2007 by John Heasman
228
00:22:11,909 --> 00:22:18,919
at BlackHat, again by Snare in 2012, and
again by my work on Thunderstrike. And as
229
00:22:18,919 --> 00:22:24,290
of last week a official fix has finally
rolled out for it to close that particular
230
00:22:24,290 --> 00:22:29,950
vulnerability.
Folks who are using coreboot have this as
231
00:22:29,950 --> 00:22:35,600
a option that they can say, this, I am
concerned about this threat, let me let me
232
00:22:35,600 --> 00:22:40,470
fix this, let me disable this function.
And they point out that it might cause
233
00:22:40,470 --> 00:22:45,990
degraded functionality, but that's
something you can QA on your own system.
234
00:22:45,990 --> 00:22:51,240
And in practice with Linux as your
bootloader in the ROM, you don't use the
235
00:22:51,240 --> 00:22:56,610
option ROMs for anything. Everything is
done with with Linux's own device drivers,
236
00:22:56,610 --> 00:23:02,750
so you're not dependent on the whatever
limited functionality the option ROM
237
00:23:02,750 --> 00:23:07,830
provided.
So, now that we have we've taken our
238
00:23:07,830 --> 00:23:12,220
building blocks and we hopefully have
protected the boot process, and hopefully
239
00:23:12,220 --> 00:23:16,659
the code that's running is what we think
it is, we need to turn to how do we secure
240
00:23:16,659 --> 00:23:22,780
the secrets on the machine. And I'm a huge
fan of the TPM, the Trusted Platform
241
00:23:22,780 --> 00:23:28,590
Module, now I know in the free software
community it's been largely unwelcome. It
242
00:23:28,590 --> 00:23:34,840
has not received a very welcome reception,
because of the way it's been used for DRM
243
00:23:34,840 --> 00:23:41,530
and other other user-hostile things. Since
we control the TPM from the first
244
00:23:41,530 --> 00:23:47,260
instruction in the in the boot block,
we're able to use it in ways that we want
245
00:23:47,260 --> 00:23:55,140
to, so we don't have to enable DRM, but we
can use it to protect our secrets. And the
246
00:23:55,140 --> 00:23:59,289
the way that it does that, is it keeps
track of what code is executed as the
247
00:23:59,289 --> 00:24:06,049
system boots, and it hashes that code into
special registers called PCRs. And the
248
00:24:06,049 --> 00:24:11,230
idea is that, you can extend the PCR by
hashing the next module of code, and then
249
00:24:11,230 --> 00:24:17,460
hashing that with the previous hash, and
this creates a chain of trust that allows
250
00:24:17,460 --> 00:24:24,690
to say: If these hashes match the expected
values, only the code, that we want to
251
00:24:24,690 --> 00:24:34,040
have run, has run. And then the TPM will
only decrypt the the disk encryption key
252
00:24:34,040 --> 00:24:40,260
if those PCRs match, which means that the
code that we want to have run, is what has
253
00:24:40,260 --> 00:24:47,049
been executed. This means if someone
manages to overwrite the, the non-write
254
00:24:47,049 --> 00:24:51,500
protected part of the ROM, that would
change those measurements and the TPM
255
00:24:51,500 --> 00:24:59,019
won't reveal the key to them. It also
takes a user password and that password is
256
00:24:59,019 --> 00:25:04,929
validated by the TPM hardware itself,
which gives us hardware rate-limiting on
257
00:25:04,929 --> 00:25:10,850
how often an attacker can try. It also
gives us the ability to do hardware-based
258
00:25:10,850 --> 00:25:15,820
retry limits, so that the TPM will flush
the key, if they if an attacker in
259
00:25:15,820 --> 00:25:21,980
possession of your machine tries too long.
That does mean there's now another way to
260
00:25:21,980 --> 00:25:27,299
lose your disk encryption key.
And there's the the old joke about there
261
00:25:27,299 --> 00:25:31,149
are two types of people with encrypted
drives - those who have lost data due to
262
00:25:31,149 --> 00:25:36,750
forgetting their key, and and those who
will. So what "Heads" does, when you
263
00:25:36,750 --> 00:25:41,810
generate your key, is, it takes that key
and splits it into multiple pieces, that
264
00:25:41,810 --> 00:25:46,789
you can then share either to friends or to
backup services, where each piece doesn't
265
00:25:46,789 --> 00:25:53,030
let you decrypt it. But you can combine
them with Shamir secret sharing to
266
00:25:53,030 --> 00:25:58,169
regenerate the cryptographic disk
encryption key.
267
00:25:58,169 --> 00:26:05,019
We're also able to take advantage of best
practices like using the, including the
268
00:26:05,019 --> 00:26:11,889
disk encryption key headers in the PCRs
that we use to seal the disks. This avoids
269
00:26:11,889 --> 00:26:15,769
a certain class of Evil Maid attack, where
someone swaps out your drive; may not be
270
00:26:15,769 --> 00:26:19,100
in your threat model, but it is easy to
deal with just a few lines of shell
271
00:26:19,100 --> 00:26:28,309
script. So we hopefully we now trust that
the system is running the code we think it
272
00:26:28,309 --> 00:26:33,690
is, but how does it prove to us that it is
actually our machine, that someone hasn't
273
00:26:33,690 --> 00:26:38,889
snuck into our hotel room and swapped out
everything and left, left up, carefully
274
00:26:38,889 --> 00:26:43,539
replaced our stickers to make us believe
we're typing our password into to our own
275
00:26:43,539 --> 00:26:51,929
computer. Some anti-Evil Maid toolkits
will encrypt a secret, secret phrase, and
276
00:26:51,929 --> 00:26:56,419
then display it to you if and only if the
PCR is match, but that's subject to a
277
00:26:56,419 --> 00:27:03,970
replay attack. What Matthew Garrett
demonstrated last year at 32C3, was, using
278
00:27:03,970 --> 00:27:10,840
the time, a time-based one-time password
used by Google Authenticator to protect
279
00:27:10,840 --> 00:27:16,760
the firmware and have it attest to the
user, that it is unmodified. So when the
280
00:27:16,760 --> 00:27:21,710
system boots, and it goes through
measuring all of the various components
281
00:27:21,710 --> 00:27:29,960
the, the TPM will only release the secret
if those PCRs match. The firmware then
282
00:27:29,960 --> 00:27:33,550
hashes that along with the current time
and generates a six digit value that it
283
00:27:33,550 --> 00:27:38,519
prints on the screen. You compare that to
what's on your phone and that tells you
284
00:27:38,519 --> 00:27:46,791
whether or not you can trust the machine.
It's a, it's a great idea, and it's
285
00:27:46,791 --> 00:27:51,780
implemented again as a very small shell
script to read, read the value from the
286
00:27:51,780 --> 00:27:58,630
TPM, unseal it and then compute the
the hash of it.
287
00:27:58,630 --> 00:28:04,390
This also allows us to start making a
transition from the TPM-rooted, a TPM
288
00:28:04,390 --> 00:28:10,031
static route of trust to a PGP-based
trust, where most importantly, this is a
289
00:28:10,031 --> 00:28:14,540
TPM key - excuse me, this is a PGP key,
that you, the owner of the computer
290
00:28:14,540 --> 00:28:19,820
control, not some random vendor or some
random hardware device manufacturer that's
291
00:28:19,820 --> 00:28:25,659
going to lose the key and allow malware
like Stuxnet to use it to circumvent
292
00:28:25,659 --> 00:28:30,940
security. The boot script
in "Heads", again, it's a
293
00:28:30,940 --> 00:28:37,200
small shell script, is able to use a GPG
to verify the next stages of the, the
294
00:28:37,200 --> 00:28:45,010
hypervisor, the initial RAM disk and the
kernel. And it also then uses the the
295
00:28:45,010 --> 00:28:50,820
TPM's counters to help prevent against
rollback, where someone takes your drive
296
00:28:50,820 --> 00:28:54,660
and rolls it back to a previous version,
perhaps with a vulnerability that they can
297
00:28:54,660 --> 00:28:59,380
exploit. So this, this
allows the, allows us to be
298
00:28:59,380 --> 00:29:03,679
sure, that not only are we running the
firmware, the OS that we think we should
299
00:29:03,679 --> 00:29:10,799
be running, it ensures us that someone
hasn't been able to substitute one that, a
300
00:29:10,799 --> 00:29:16,700
vulnerable version. Having the
PGP key also allows us to take
301
00:29:16,700 --> 00:29:24,720
advantage of an idea from Android and
Chrome OS which is the the dm-verity read-
302
00:29:24,720 --> 00:29:31,010
only root filesystem - this hashes all of
the blocks and that hashes all of the the
303
00:29:31,010 --> 00:29:38,320
hashes and so on up until it gets to a
root hash in the tree that is then signed.
304
00:29:38,320 --> 00:29:45,029
This allows the kernel, on every read
access, in logarithmic time to verify the
305
00:29:45,029 --> 00:29:51,580
essentially a signature on that data. This
does require a read-only root filesystem,
306
00:29:51,580 --> 00:29:59,719
but it gives us even more confidence that
the system has been untampered with. Once
307
00:29:59,719 --> 00:30:05,100
you're running your OS, it's good to have
you know some security conscious thoughts
308
00:30:05,100 --> 00:30:10,990
as well, you know. Heads is mostly focused
on, "how do we securely transition to an
309
00:30:10,990 --> 00:30:17,529
OS" and that OS you run is up to you. I
like Qubes - it's reasonably secure, it's
310
00:30:17,529 --> 00:30:23,630
highly recommended by people who know
about endpoint security. And the Qubes
311
00:30:23,630 --> 00:30:30,480
team recognizes that firmware security is
a vital piece of system security. For
312
00:30:30,480 --> 00:30:35,149
their next release, Qubes are for -
they're going to require the machines have
313
00:30:35,149 --> 00:30:39,101
open source firmware, such as coreboot.
And I hope that Heads is going to be a
314
00:30:39,101 --> 00:30:46,330
piece of that. I've also been working with
with the Qubes software and have modified
315
00:30:46,330 --> 00:30:53,000
it to work with things like the dm-verity
read-only root filesystem. This now allows
316
00:30:53,000 --> 00:30:58,809
the user to lock down the configuration,
so that someone can't tamper with their
317
00:30:58,809 --> 00:31:05,850
their setup. It also gives you a recovery
mode that allows you to fix things up and
318
00:31:05,850 --> 00:31:12,139
re-sign the OS. Reproducible builds are
really important so that everyone can
319
00:31:12,139 --> 00:31:19,490
verify what that the builds match what
they should. In the case of of Heads we
320
00:31:19,490 --> 00:31:22,429
have a lot of upstream dependencies that
aren't reproducible so we're working with
321
00:31:22,429 --> 00:31:28,190
them to try to patch them. We've patched
Xen - they've accepted that commit. We've
322
00:31:28,190 --> 00:31:33,669
also built some tools to let you build
initial RAM disks in a reproducible way.
323
00:31:33,669 --> 00:31:37,389
This works with Qubes, with Heads, and
we're hoping to other Linux distributions
324
00:31:37,389 --> 00:31:41,960
pick it up as well.
All of our tree is cryptographically
325
00:31:41,960 --> 00:31:48,230
signed, so hopefully GitHub is not trying
to slip in any patches. And it is open
326
00:31:48,230 --> 00:31:52,890
source so we encourage anyone to read
through it. No NDA is required, unlike most
327
00:31:52,890 --> 00:31:59,570
of the UEFI sources. So that's sort of the
state of where things are - it's pretty
328
00:31:59,570 --> 00:32:04,679
much in very beta, but it is usable. But
there are a lot of areas where we could
329
00:32:04,679 --> 00:32:08,679
continue to do research - things like the
embedded controllers on Chromebooks are
330
00:32:08,679 --> 00:32:14,359
open source. We can use those to help with
our root of trust as well. Porting
331
00:32:14,359 --> 00:32:17,070
coreboot to more modern platforms would
let us take advantage of things like
332
00:32:17,070 --> 00:32:23,440
tamper switches and Intel Boot Guard. I'm
also working on porting coreboot over to
333
00:32:23,440 --> 00:32:30,029
server platforms so that we can use it for
more secure cloud hosting. Servers have a
334
00:32:30,029 --> 00:32:36,480
very different threat model from from
laptops, and a lot of things have firmware
335
00:32:36,480 --> 00:32:41,090
that we have to be concerned about. One
collaboration I'm looking at there is with
336
00:32:41,090 --> 00:32:45,989
the open BMC project to be able to take
advantage of the open source in the
337
00:32:45,989 --> 00:32:54,159
management controller for the servers. And
I'm also collaborating with the Mass Open
338
00:32:54,159 --> 00:33:01,129
Cloud project that's trying to build
secure bare metal clouds. I'm cautiously
339
00:33:01,129 --> 00:33:06,590
optimistic about enclaves and how they
will help us with the security, especially
340
00:33:06,590 --> 00:33:10,269
in a environment where we control the
firmware and we can ensure that the
341
00:33:10,269 --> 00:33:17,270
enclaves are set up in a safe way. There
are a lot of issues on GitHub, again,
342
00:33:17,270 --> 00:33:25,150
please welcome contributions. I hope
everyone gets inspired to to work on the
343
00:33:25,150 --> 00:33:31,080
installing this on their laptop. And if if
you are interested I'll be hanging out at
344
00:33:31,080 --> 00:33:38,220
the coreboot assembly later today and
occasionally this week. The coreboot team
345
00:33:38,220 --> 00:33:42,610
has a bunch of people here. They have
flash programmers and can help you install
346
00:33:42,610 --> 00:33:50,990
coreboot on your laptop. The source code
for Heads is available on GitHub, and a
347
00:33:50,990 --> 00:33:56,419
annotated version of this talk is up on my
website, and welcome comments and feedback
348
00:33:56,419 --> 00:34:02,340
on it. So thank you all for coming to hear
about this project I hope that everyone is
349
00:34:02,340 --> 00:34:06,899
and you know as excited about open source
firmware as I am and I'd love to take any
350
00:34:06,899 --> 00:34:09,918
questions that you all have.
351
00:34:09,918 --> 00:34:21,739
Applause
352
00:34:28,549 --> 00:34:31,730
Question: Thanks for your great talk -
this is very interesting. Do you have any
353
00:34:31,730 --> 00:34:39,009
advice for the 95% of us who are stuck on
non coreboot compatible laptops.
354
00:34:39,009 --> 00:34:42,890
Trammell: Buy a Chromebook?
Laughter
355
00:34:42,890 --> 00:34:52,951
Trammell: It's hard to trust the closed-
source firmware. It certainly; there are
356
00:34:52,951 --> 00:34:55,920
people we have to trust - there are
institutions we have to trust. We have to
357
00:34:55,920 --> 00:35:01,620
trust Intel to some extent, and Intel is
responsible for, you know, both our CPUs
358
00:35:01,620 --> 00:35:09,370
and a lot of the firmware. Depending on
your threat model, firmware attacks may
359
00:35:09,370 --> 00:35:15,280
not be a huge concern for your particular
machine. Or they might be, you know, of
360
00:35:15,280 --> 00:35:20,470
grave concern, in which case even just
doing some of the things that Peter Stuge
361
00:35:20,470 --> 00:35:30,020
suggested of clipping the write-protect
pin on the on the chip, removing things
362
00:35:30,020 --> 00:35:35,200
that might be hostile and attacking your
system. His guides are really good one to
363
00:35:35,200 --> 00:35:43,100
follow for the hardware security.
Question: I was wondering if you also
364
00:35:43,100 --> 00:35:49,610
support ARM - I just saw Intel laptops so
I was just wondering.
365
00:35:49,610 --> 00:35:55,231
Trammell: So ARM it has a lot of
advantages as a CPU. It only has 20 years
366
00:35:55,231 --> 00:36:00,750
of legacy baggage rather than 40. And the
boot process on it is much much simpler
367
00:36:00,750 --> 00:36:06,820
since it doesn't have to go through real
mode to long mode to paging and all the
368
00:36:06,820 --> 00:36:15,140
other steps. The downside to a lot of ARMs
is that they their boot code is a few is
369
00:36:15,140 --> 00:36:22,190
on die and outside of the control of the
user. Luckily, most of that boot code is
370
00:36:22,190 --> 00:36:29,280
fairly simple, and can establish - and
some of them will establish a hardware
371
00:36:29,280 --> 00:36:37,490
root of trust. But in general, yeah that
the ARM to U-Boot to whatever seems to
372
00:36:37,490 --> 00:36:44,090
work out pretty well. I know there's been
some interest in, "can U-Boot be replaced
373
00:36:44,090 --> 00:36:49,920
with a Linux BIOS or coreboot like thing",
and I suspect the folks at the booth would
374
00:36:49,920 --> 00:36:54,700
be able to talk more about that.
Question: And then just a followup - so if
375
00:36:54,700 --> 00:37:00,510
coreboot or Libreboot supports the
platform - Heads will work too right?
376
00:37:00,510 --> 00:37:05,590
Trammell: Essentially yes, yeah.
Heads is a payload for coreboot.
377
00:37:05,590 --> 00:37:13,030
Question: OK.
Herald: It's there on the left.
378
00:37:13,030 --> 00:37:17,960
Signal Angel: Thank you - there's a
question from the Internet about coreboot.
379
00:37:17,960 --> 00:37:23,430
Coreboot has blobs included and, for
example, binary blobs from Intel with all
380
00:37:23,430 --> 00:37:28,750
the firmware support package and all that
stuff. How can we call coreboot secure,
381
00:37:28,750 --> 00:37:33,060
then, in the light of this - let alone
open source?
382
00:37:33,060 --> 00:37:37,890
Trammell: So the intel FSP is a
significant concern. This is the firmware
383
00:37:37,890 --> 00:37:42,010
support package that is required to
initialize the memory controllers on on
384
00:37:42,010 --> 00:37:52,200
modern Intel cpus. On older CPUs, such as
the the Sandy Bridge and Ivy Bridge, the
385
00:37:52,200 --> 00:37:57,040
coreboot and Libreboot are able to
initialize the memory natively without
386
00:37:57,040 --> 00:38:05,870
having to go into the FSB. However, if you
look at what coreboot is doing in the MRC
387
00:38:05,870 --> 00:38:10,930
on those platforms, it tends to just be
poking a bunch of registers with values
388
00:38:10,930 --> 00:38:20,170
that seem to work. And it's modern memory
controllers are so complex that, and Intel
389
00:38:20,170 --> 00:38:26,700
is unwilling to document them, that
without extensive NDA's that it's very
390
00:38:26,700 --> 00:38:32,330
hard to build any sort of memory
initialization. So what we can't say it's
391
00:38:32,330 --> 00:38:38,610
a hundred percent free software, we can at
least we can ensure that the FSP is
392
00:38:38,610 --> 00:38:47,200
measured and it's unchanging. We can also
look at the state of things that it sets
393
00:38:47,200 --> 00:38:52,210
up and include those in our measurements.
So even if it doesn't get us one hundred
394
00:38:52,210 --> 00:38:57,850
percent open source - and as far as I know
the only system that does that right now
395
00:38:57,850 --> 00:39:05,280
is bunnies' Novena laptop. At least we can
measure it and we can know that it hasn't
396
00:39:05,280 --> 00:39:10,810
been tampered with from
what we initially installed.
397
00:39:10,810 --> 00:39:17,260
Question: And before so this is a great
project and I'd like to ask why you did
398
00:39:17,260 --> 00:39:23,650
certain architectural decisions. The
specific combination of Linux and shell.
399
00:39:23,650 --> 00:39:29,840
So why didn't you choose a BSD kernel which
are usually perceived to be more secure
400
00:39:29,840 --> 00:39:34,720
and of a higher quality, and why did you
choose a shell over let's say, Python
401
00:39:34,720 --> 00:39:41,230
or Haskell, which are also often
perceived of higher quality?
402
00:39:41,230 --> 00:39:45,400
Trammell: There is a lot of desire to
support Python in Heads. The downside is
403
00:39:45,400 --> 00:39:51,910
that there's a very limited space: the
X230 bootrom, for instance, has 4
404
00:39:51,910 --> 00:40:02,070
megabytes of available space. The Python
interpreter is a couple megs already. In
405
00:40:02,070 --> 00:40:09,080
terms of why Linux over BSD - the kexec
system call is a core component of this:
406
00:40:09,080 --> 00:40:14,940
to be able to do a graceful shut down and
transfer from the Linux kernel to another
407
00:40:14,940 --> 00:40:22,370
kernel or - to any multi-boot compliant
kernels, which includes BSD. It is a
408
00:40:22,370 --> 00:40:31,010
necessary feature if it, if BSD had such
functionality, that it would be a fine
409
00:40:31,010 --> 00:40:37,225
just a choice for the the internal boot
ROM/boot loader.
410
00:40:45,700 --> 00:40:53,601
Question: Thanks for great work. How to
perform updates of coreboot and its
411
00:40:53,601 --> 00:41:00,391
payload when it's binaries used in
measurement for releasing encryption key
412
00:41:00,391 --> 00:41:07,150
then when you update coreboot this
measurement will change and you will know
413
00:41:07,150 --> 00:41:12,250
no longer will be able to boot the system
- how to solve that problem?
414
00:41:12,250 --> 00:41:19,180
Trammell: So migrating encryption keys
with TPM requires a explicit step of
415
00:41:19,180 --> 00:41:24,060
retrieving the key from the TPM with the
current configuration and then resealing
416
00:41:24,060 --> 00:41:30,210
it with the new configuration. One
advantage of a reproducible build is the
417
00:41:30,210 --> 00:41:37,240
hashes of the of all the firmware stages
can be published - it can be pre-computed,
418
00:41:37,240 --> 00:41:41,460
and then the PCR values can be pre-
computed so you can read you can seal the
419
00:41:41,460 --> 00:41:52,170
keys for the new values. In terms of the
update process for the Heads payload - one
420
00:41:52,170 --> 00:41:56,550
of the things that we're working on is
being able to have an even more minimal
421
00:41:56,550 --> 00:42:03,500
heads that has just a USB device driver
that you can boot into, copy your new
422
00:42:03,500 --> 00:42:08,830
payload, and then install that elsewhere
on the chip. And part of that process
423
00:42:08,830 --> 00:42:15,200
would involve resealing any of the keys
that you need to transfer.
424
00:42:15,200 --> 00:42:17,270
Herald: Another question from the
Internet.
425
00:42:17,270 --> 00:42:21,570
Signal Angel: Thank you. On your webpage
you implemented Heads on ThinkPads only.
426
00:42:21,570 --> 00:42:28,250
How much work is still needed to translate
this to, let's say, non-ThinkPads?
427
00:42:28,250 --> 00:42:32,890
Trammell: ThinkPads are really popular
with the security community. It's quite
428
00:42:32,890 --> 00:42:36,280
interesting to look out at you know the
hall here and see how many ThinkPads there
429
00:42:36,280 --> 00:42:41,520
are. And as a result the coreboot
community has been very supportive of
430
00:42:41,520 --> 00:42:48,820
ThinkPads. There's, other than the
ThinkPads and the Chromebooks, there
431
00:42:48,820 --> 00:42:53,270
aren't a lot of devices that support
coreboot out of the box. And that's
432
00:42:53,270 --> 00:42:58,050
something that I hope would change - I
hope that some OEMs would realize there's
433
00:42:58,050 --> 00:43:04,560
value in provide an open source firmware
and move to move to using it. Both as a
434
00:43:04,560 --> 00:43:10,590
cost-saving measure as well as a freedom
measure. In terms of the difficulty
435
00:43:10,590 --> 00:43:15,780
important coreboot to a platform - I
haven't successfully done that yet, but I
436
00:43:15,780 --> 00:43:23,350
suspect the people at the assembly would
be happy to discuss that further.
437
00:43:23,350 --> 00:43:29,400
Question: Would you plan to rework
embedded controller firmware on ThinkPads
438
00:43:29,400 --> 00:43:38,420
because it's remain close at birth which
still has an access to PC bus and probably
439
00:43:38,420 --> 00:43:43,440
couldn't be trusted.
Trammell: So your question is how do we
440
00:43:43,440 --> 00:43:48,520
how do we replace the EC?
Question: Yes do plan to replace EC with
441
00:43:48,520 --> 00:43:52,150
open source firmware as in the
Chromebooks?
442
00:43:52,150 --> 00:43:57,530
Trammell: So the Chromebook has open
source EC. The part of building coreboot
443
00:43:57,530 --> 00:44:03,190
for Chromebook involves installing the ARM
cross compiler to build the EC firmware.
444
00:44:03,190 --> 00:44:08,790
And the Chromebooks actually have a really
elegant protocol for the EC to attest to
445
00:44:08,790 --> 00:44:14,430
the CPU that is running the firmware that
you think it is running. On other
446
00:44:14,430 --> 00:44:23,700
platforms, this would require a lot more
research. The doc; many of the EC chipsets
447
00:44:23,700 --> 00:44:27,840
have data sheets available, so it's
possible to read through and see how they
448
00:44:27,840 --> 00:44:33,070
work. And most of them have updatable
firmware. In case of the ThinkPads,
449
00:44:33,070 --> 00:44:37,410
there's a module in the ThinkPad BIOS that
will do that update. There's, we would
450
00:44:37,410 --> 00:44:41,480
need to figure out what that protocol
looks like.
451
00:44:41,480 --> 00:44:47,810
Question: Sorry yes I mean if you have
working prototype on ThinkPads probably
452
00:44:47,810 --> 00:44:56,870
want to add remaining business open
sources EC on ThinkPads as well in the
453
00:44:56,870 --> 00:45:00,550
first place.
Trammell: I'm sorry, I don't think I
454
00:45:00,550 --> 00:45:09,540
understood your follow-up.
Question: Okay. So if you if you have a
455
00:45:09,540 --> 00:45:18,240
working prototype on ThinkPads and only on
ThinkPads, will you finish somewhat soon
456
00:45:18,240 --> 00:45:28,711
current existing prototype of open source
EC exists in college shade by Lincoln's or
457
00:45:28,711 --> 00:45:36,830
you are playing to extend your work on
other platforms and finish this bits
458
00:45:36,830 --> 00:45:39,700
later.
Trammell: Yeah right now I have not
459
00:45:39,700 --> 00:45:46,910
personally made any progress on the
ThinkPad EC. I was looking into it because
460
00:45:46,910 --> 00:45:51,700
I have a modified keyboard on my ThinkPad
that that needs to updated EC firmware,
461
00:45:51,700 --> 00:46:00,740
but I haven't actually gotten into that.
This is a area of open research
462
00:46:00,740 --> 00:46:03,900
Signal Angel: Thank you, two quick
questions from the IRC - are you planning
463
00:46:03,900 --> 00:46:07,690
to use systemd in the boot process
is the first one
464
00:46:07,690 --> 00:46:11,030
Laughter
Signal Angel: And the second one let's say
465
00:46:11,030 --> 00:46:16,110
you flash your firmware at the Congress
right here with the help of a hardware
466
00:46:16,110 --> 00:46:22,900
programmer. Can you update when there's a
new version or do you have to currently
467
00:46:22,900 --> 00:46:29,620
need the hardware access to update?
Trammell: Right now you can update
468
00:46:29,620 --> 00:46:40,030
afterwards at great risk, because you can
leave the flash writeable, which would
469
00:46:40,030 --> 00:46:45,710
allow you to flash after the fact. We are
still working on a good procedure for
470
00:46:45,710 --> 00:46:53,540
doing software-only firmware updates once
the immutable boot block is installed. And
471
00:46:53,540 --> 00:46:58,950
to the other question - did I mention that
we are really short on space and we don't
472
00:46:58,950 --> 00:47:07,712
want to put any large applications like
systemd on there.
473
00:47:07,712 --> 00:47:11,292
Questioner: It was like good one, thanks.
474
00:47:11,292 --> 00:47:19,242
applause
475
00:47:19,242 --> 00:47:28,159
postroll music
476
00:47:28,159 --> 00:47:42,811
subtitles created by c3subtitles.de
in the year 2018