WEBVTT
00:00:14.987 --> 00:00:19.620
Herald Angel: So, most of the cloud
services rely on closed source proprietary
00:00:19.620 --> 00:00:23.760
server firmware; header[?] firmware; with
known security implications to[?] tenants.
00:00:23.760 --> 00:00:30.140
Imagine... So that's where LinuxBoot comes
to the rescue because it wants to replace
00:00:30.140 --> 00:00:36.199
this closed source firmware with an open
Linux boot version and our next speaker
00:00:36.199 --> 00:00:41.030
Trammell Hudson he's an integral part of
that project and he's here to provide you
00:00:41.030 --> 00:00:45.819
an overview of this Linux boot project.
Thank you very much and please give a warm
00:00:45.819 --> 00:00:48.448
round round of applause to Trammell
Hudson, please!
00:00:48.448 --> 00:00:56.249
applause
Trammell: Thank you!
00:00:56.249 --> 00:01:01.639
Securing the boot process is really
fundamental to having secure systems
00:01:01.639 --> 00:01:09.890
because of the vulnerabilities in firmware
can affect any security that the operating
00:01:09.890 --> 00:01:15.250
system tries to provide. And for that
reason I think it's really important that
00:01:15.250 --> 00:01:21.299
we replace the proprietary vendor
firmwares with open source, like Linux.
00:01:21.299 --> 00:01:26.259
And this is not a new idea. My
collaborator Ron Minich started a project
00:01:26.259 --> 00:01:31.840
called LinuxBIOS back in the 90s when he
was at Los Alamos National Labs. They
00:01:31.840 --> 00:01:36.230
built the world's third fastest
supercomputer out of a Linux cluster that
00:01:36.230 --> 00:01:44.810
used BIOS in the ROM to make it more
reliable. LinuxBIOS turned into coreboot
00:01:44.810 --> 00:01:52.610
in 2005 and the Linux part was removed and
became a generic bootloader, and it now
00:01:52.610 --> 00:01:59.140
powers the Chromebooks as well as projects
like the Heads slightly more secure laptop
00:01:59.140 --> 00:02:04.829
firmware that I presented last year at
CCC. Unfortunately it doesn't support any
00:02:04.829 --> 00:02:12.710
server main boards anymore. Most servers
are running a variant of Intel's UEFI
00:02:12.710 --> 00:02:19.220
firmware, which is a project that Intel
started to replace the somewhat aging
00:02:19.220 --> 00:02:24.861
16-bit real mode BIOS of the 80s and 90s.
And, like a lot of second systems, it's
00:02:24.861 --> 00:02:30.000
pretty complicated. If you've been to any
talks on firmware security you've probably
00:02:30.000 --> 00:02:37.070
seen this slide before. It goes through
multiple phases as the system boots, the
00:02:37.070 --> 00:02:44.970
first phase does a cryptographic
verification of the pre-EFI phase this the
00:02:44.970 --> 00:02:49.950
PEI phase is responsible for bringing up
the memory controller the CPU interconnect
00:02:49.950 --> 00:02:55.150
and a few other critical devices. It also
enables paging and long mode and then
00:02:55.150 --> 00:03:03.060
jumps into the device execution
environment or DXE phase. This is where
00:03:03.060 --> 00:03:07.620
UEFI option ROMs are executed as well, as
well as all of the remaining devices are
00:03:07.620 --> 00:03:14.590
initialized. Once the PCI bus and USB
buses have been walked and enumerated, it
00:03:14.590 --> 00:03:20.350
transfers to the boot device selection
phase, which figures out which disk or USB
00:03:20.350 --> 00:03:26.670
stick or network to boot from. That loads
a boot loader from that device which
00:03:26.670 --> 00:03:32.230
eventually loads a real operating system,
which then is the operating system that's
00:03:32.230 --> 00:03:37.560
running on the machine. What we're
proposing is that we replace all of this
00:03:37.560 --> 00:03:45.680
with the Linux boot kernel and runtime. We
can do all of the device enumeration in
00:03:45.680 --> 00:03:50.200
Linux, it already has support for doing
this, and then we can use more
00:03:50.200 --> 00:03:54.840
sophisticated protocols and tools to
locate the real kernel that we want to
00:03:54.840 --> 00:04:03.820
run, and use the kexec system call to be
able to start that new kernel. And the
00:04:03.820 --> 00:04:09.040
reason we want to use Linux here is
because it gives us the ability to have a
00:04:09.040 --> 00:04:13.540
more secure system. It gives us a lot more
flexibility and hopefully it lets us
00:04:13.540 --> 00:04:20.760
create a more resilient system out of it.
On the security front one of the big areas
00:04:20.760 --> 00:04:28.070
that we get some benefit is we reduced the
attack surface that in the DXE phase these
00:04:28.070 --> 00:04:35.480
drivers are an enormous amount of code on
the Intel S2600 there are over 400 modules
00:04:35.480 --> 00:04:41.100
that get loaded. They do things like the
option roms that I mentioned, and if you
00:04:41.100 --> 00:04:44.440
want an example of how dangerous option
roms can be, you can look at my
00:04:44.440 --> 00:04:50.680
Thunderstrike talks from a few years ago.
They also do things like display the boot
00:04:50.680 --> 00:04:55.410
splash, the vendor logo, and this has been
a place where quite a few buffer overflows
00:04:55.410 --> 00:05:00.210
have been found in vendor firmwares in the
past. They have a complete network stack
00:05:00.210 --> 00:05:09.770
IPv4 and v6 as well as HTTP and HTTPS.
They have legacy device drivers for things
00:05:09.770 --> 00:05:14.490
like floppy drives, and again, these sort
of dusty corners are where vulnerabilities
00:05:14.490 --> 00:05:20.540
in Xen have been found that allowed a
hypervisor break. There are also modules
00:05:20.540 --> 00:05:25.880
like the Microsoft OEM activation that we
just don't know what they do, or things
00:05:25.880 --> 00:05:35.780
like a y2k rollover module that probably
hasn't been tested in two decades. So the
00:05:35.780 --> 00:05:41.060
final OS bootloader phase is actually not
part of UEFI, but it's typically in, the
00:05:41.060 --> 00:05:46.430
Linux system, its GRUB, the grand unified
bootloader. And y'all -- many of you are
00:05:46.430 --> 00:05:51.160
probably familiar with its interface, but
did you know that it has its own file
00:05:51.160 --> 00:05:58.900
system, video, and network drivers. About
almost 250 thousand lines of code make up
00:05:58.900 --> 00:06:04.440
GRUB. I don't bring up the size of this to
complain about the space it takes, but
00:06:04.440 --> 00:06:09.540
because of how much it increases our
attack surface. You might think that
00:06:09.540 --> 00:06:13.770
having three different operating systems
involved in this boot process gives us a
00:06:13.770 --> 00:06:19.270
defense in depth, but I would argue that
we are subject to the weakest link in this
00:06:19.270 --> 00:06:23.710
chain because if you can compromise UEFI,
you can compromise grub, and if you can
00:06:23.710 --> 00:06:27.520
compromise grub you can compromise the
Linux kernel that you want to run on the
00:06:27.520 --> 00:06:35.420
machine. So there are lots of ways these
attacks could be launched. As I mentioned
00:06:35.420 --> 00:06:39.780
UEFI has a network device driver, grub has
a network device driver, and of course
00:06:39.780 --> 00:06:43.620
Linux has a network device driver. This
means that a remote attacker could
00:06:43.620 --> 00:06:48.300
potentially get code execution during the
boot process.
00:06:48.300 --> 00:06:56.430
UEFI has a USB driver, grub has a
USB driver, and of course Linux has a USB
00:06:56.430 --> 00:07:02.520
driver. There have been bugs found in USB
stacks -- which unfortunately are very
00:07:02.520 --> 00:07:08.060
complex -- and a buffer overflow in a USB
descriptor handler could allow a local
00:07:08.060 --> 00:07:12.870
attacker to plug in a rogue device and
take control of the firmware during the
00:07:12.870 --> 00:07:19.370
boot. Of course UEFI has a FAT driver,
GRUB has a FAT driver, Linux has a FAT
00:07:19.370 --> 00:07:26.139
driver. This gives an attacker a place to
gain persistence and perhaps leverage code
00:07:26.139 --> 00:07:35.190
execution during the initial file system
or partition walk. So what we argue is
00:07:35.190 --> 00:07:39.650
that we should have the operating system
that has the most contributors, and the
00:07:39.650 --> 00:07:47.070
most code review, and the most frequent
update schedule, for these roles. Linux
00:07:47.070 --> 00:07:52.790
has a lot more eyes on it, it undergoes a
much more rapid update schedule than
00:07:52.790 --> 00:08:01.180
pretty much any vendor firmware. You might
ask, why do we keep the PEI and the SEC
00:08:01.180 --> 00:08:08.270
phase from the UEFI firmware? Couldn't we
use coreboot in this place, and the
00:08:08.270 --> 00:08:12.630
problem is that vendors are not
documenting the memory controller or the
00:08:12.630 --> 00:08:18.080
CPU interconnect. Instead they're
providing a opaque binary blob called the
00:08:18.080 --> 00:08:25.450
firmware support package, or FSP, that
does the memory controller and the CPU
00:08:25.450 --> 00:08:32.879
initialization. On most coreboot systems
-- on most modern coreboot systems --
00:08:32.879 --> 00:08:38.139
coreboot actually calls into the FSP to do
this initialization. And on a lot of the
00:08:38.139 --> 00:08:43.479
devices the FSB has grown in scope so it
now includes video device drivers and
00:08:43.479 --> 00:08:49.160
power management, and it's actually larger
than the PEI phase on some of the servers
00:08:49.160 --> 00:08:57.680
that we're dealing with. The other wrinkle
is that most modern CPUs don't come out of
00:08:57.680 --> 00:09:02.059
reset into the legacy reset vector
anymore. Instead, they execute an
00:09:02.059 --> 00:09:07.329
authenticated code module, called boot
guard, that's signed by Intel, and the CPU
00:09:07.329 --> 00:09:15.129
will not start up if that's not present.
The good news is that this boot guard ACM
00:09:15.129 --> 00:09:22.600
measures the PEI phase into the TPM, which
allows us to detect attempts to modify it
00:09:22.600 --> 00:09:28.459
from malicious attacks. The bad news is
that we are not able to change it on many
00:09:28.459 --> 00:09:33.800
of these systems. But even with that in
place, we still have a much, much more
00:09:33.800 --> 00:09:39.730
flexible system. If you've ever worked
with the UEFI shell or with GRUBs menu
00:09:39.730 --> 00:09:46.619
config, it's really not as flexible, and
the tooling is not anywhere near as
00:09:46.619 --> 00:09:51.490
mature, as being able to write things with
shell scripts, or with go, or with real
00:09:51.490 --> 00:09:57.520
languages. Additionally we can configure
at the Linux boot kernel with standard
00:09:57.520 --> 00:10:04.420
Linux config tools. UEFI supports booting
from FAT file systems, but with LinuxBoot
00:10:04.420 --> 00:10:09.380
we can boot from any of the hundreds of
file systems that Linux supports. We can
00:10:09.380 --> 00:10:15.709
boot from encrypted filesystems, since we
have LUKS and cryptsetup. Most UEFI
00:10:15.709 --> 00:10:19.790
firmwares can only boot from the network
device that is installed on the server
00:10:19.790 --> 00:10:25.029
motherboard. We can boot from any network
device that Linux supports, and we can use
00:10:25.029 --> 00:10:30.899
proper protocols; we're not limited to PXE
and TFTP. We can use SSL, we can do
00:10:30.899 --> 00:10:37.500
cryptographic measurements of the kernels
that we receive. And the runtime that
00:10:37.500 --> 00:10:42.920
makes up Linux boot is also very flexible.
Last year I presented the Heads runtime
00:10:42.920 --> 00:10:50.110
for laptops. This is a very security
focused initial ram disk that attempts to
00:10:50.110 --> 00:10:55.170
provide a slightly more secure, measured,
and attested firmware, and this works
00:10:55.170 --> 00:11:00.689
really well with Linux boot. My
collaborator Ron Minnich is working on a
00:11:00.689 --> 00:11:06.220
go based firmware, called NERF, and this
is written entirely in just-in-time
00:11:06.220 --> 00:11:10.699
compiled Go, which is really nice because
it gives you memory safety, and is very
00:11:10.699 --> 00:11:16.160
popular inside of Google. Being able to
tailor the device drivers that are
00:11:16.160 --> 00:11:21.999
included also allows the system to boot
much faster. UEFI on the Open Compute
00:11:21.999 --> 00:11:27.630
Winterfell takes about eight minutes to
startup. With NERF, excuse me -- with
00:11:27.630 --> 00:11:32.869
with Linux boot and NERF it starts up in
about 20 seconds. I found similar results
00:11:32.869 --> 00:11:38.509
on the Intel mainboard that I'm working on
and hopefully we will get a video there's
00:11:38.509 --> 00:11:45.350
an action this is from power-on to
executes the PEI phase out of the
00:11:45.350 --> 00:11:52.209
ROM and then jumps into a small wrapper
around the Linux kernel which then prints
00:11:52.209 --> 00:11:59.239
to the serial port and we now have the
Linux print case and we have an
00:11:59.239 --> 00:12:03.170
interactive shell in about 20 seconds
which is quite a bit better than the four
00:12:03.170 --> 00:12:11.189
minutes that the system used to take it
scrolled by pretty fast but you might have
00:12:11.189 --> 00:12:15.540
noticed that the print case has ... - that
the Linux kernel thinks it's running under
00:12:15.540 --> 00:12:20.089
EFI this because we have a small wrapper
around the kernel but for the most part
00:12:20.089 --> 00:12:26.279
the kernel is able to do all of the PCI
and device enumeration that it needs to do
00:12:26.279 --> 00:12:29.779
because it already does it since it
doesn't trust the vendor BIOSes in a lot
00:12:29.779 --> 00:12:38.569
of cases so I'm really glad that the
Congress has added a track on technical
00:12:38.569 --> 00:12:45.420
resiliency and I would encourage Congress
to also add a track on resiliency of our
00:12:45.420 --> 00:12:50.639
social systems because it's really vital
that we deal with both online and offline
00:12:50.639 --> 00:12:55.529
harassment and I think that that will help
us make a safer and more secure Congress
00:12:55.529 --> 00:13:05.607
as well.
applause
00:13:05.607 --> 00:13:12.029
So last year when I presented at
Heads I proposed three criteria for a
00:13:12.029 --> 00:13:16.339
resilient technical system: that they need
to be built with open-source software,
00:13:16.339 --> 00:13:20.330
they need to be reproducibly built, and
they need to be measured into some sort of
00:13:20.330 --> 00:13:26.749
cryptographic hardware. The open is, you
know, I think, in this crowd, is not
00:13:26.749 --> 00:13:33.600
controversial. But the reason that we need
it is because a lot of the server vendors
00:13:33.600 --> 00:13:37.810
don't actually control their own firmware;
they license it from independent BIOS
00:13:37.810 --> 00:13:45.230
vendors who then tailor it for whatever
current model of machine the
00:13:45.230 --> 00:13:51.089
manufacturer is making. This means that
they typically don't support older
00:13:51.089 --> 00:13:55.559
hardware and, if there are
vulnerabilities, it's necessary that we be
00:13:55.559 --> 00:14:00.660
able to make these patches on our own
schedule and we need to be able to self-
00:14:00.660 --> 00:14:07.319
help when it comes to our own security.
The other problem is that closed source
00:14:07.319 --> 00:14:13.209
systems can hide vulnerabilities for
decades — this is especially true for very
00:14:13.209 --> 00:14:17.070
privileged devices like the management
engine. There's been several talks here at
00:14:17.070 --> 00:14:23.790
Congress about the concerns that we have
with the management engine. Some vendors
00:14:23.790 --> 00:14:29.929
are even violating our trust entirely and
using their place in the firmware
00:14:29.929 --> 00:14:38.470
to install malware or adware onto the
systems. So for this reason we really need
00:14:38.470 --> 00:14:47.290
our own control over this firmware.
Reproducibility is becoming much more of
00:14:47.290 --> 00:14:53.589
an issue, and the goal here is to be able
to ensure that everyone who builds the
00:14:53.589 --> 00:14:59.159
Linux boot firmware gets exactly the same
result that everyone else does. This is a
00:14:59.159 --> 00:15:03.759
requirement to be able to ensure that
we're not introducing accidental
00:15:03.759 --> 00:15:08.649
vulnerabilities through picking up the
wrong library, or intentional ones through
00:15:08.649 --> 00:15:16.079
compiler supply chain attacks, such as Ken
Thompson's Trusting Trust article. With
00:15:16.079 --> 00:15:21.569
the Linux boot firmware, our Kernel and
Initial Ramdisk are reproducibly built, so
00:15:21.569 --> 00:15:27.819
we get exactly the same hashes on the
firmware. Unfortunately we don't control
00:15:27.819 --> 00:15:33.560
the UEFI portions that we're using — the
PEI and the SEC phase — so those aren't
00:15:33.560 --> 00:15:41.920
included in our reproducibility
right now. "Measured" is a another place
00:15:41.920 --> 00:15:48.059
where we need to take into account the
runtime security of the system. So
00:15:48.059 --> 00:15:52.509
reproducible builds handle the compile
time, but measuring what's running into
00:15:52.509 --> 00:15:58.589
cryptographic coprocessors — like the TPM
— gives us the ability to make
00:15:58.589 --> 00:16:02.939
attestations as to what is actually
running on the system. On the Heads
00:16:02.939 --> 00:16:09.499
firmware we do this to the user that the
firmware can produce a one-time secret
00:16:09.499 --> 00:16:14.319
that you can compare against your phone to
know that it has not been tampered with.
00:16:14.319 --> 00:16:18.309
In the server case it uses remote
attestation to be able to prove to the
00:16:18.309 --> 00:16:25.299
user that the code that is running is what
they expect. This is a collaboration with
00:16:25.299 --> 00:16:30.759
the Mass Open Cloud Project, out of Boston
University and MIT, that is attempting to
00:16:30.759 --> 00:16:37.660
provide a hardware root of trust for the
servers, so that you can know that a cloud
00:16:37.660 --> 00:16:45.529
provider has not tampered with your
system. The TPM is not invulnerable, as
00:16:45.529 --> 00:16:49.889
Christopher Tarnovsky showed at DEFCON,
but the level of effort that it takes to
00:16:49.889 --> 00:16:55.269
break into a TPM, to decap it, and to read
out the bits with a microscope raises the
00:16:55.269 --> 00:17:02.290
bar really significantly. And part of
resiliency is making honest trade-offs
00:17:02.290 --> 00:17:09.369
about security threats versus the
difficulty in launching the attacks, and
00:17:09.369 --> 00:17:14.888
if the TPM prevents remote attacks or
prevents software-only attacks, that is a
00:17:14.888 --> 00:17:22.709
sufficiently high bar for a lot of these
applications. We have quite a bit of
00:17:22.709 --> 00:17:28.549
ongoing research with this. As I mentioned
the management engine is an area of great
00:17:28.549 --> 00:17:35.330
concern and we are working on figuring out
how to remove most of its capabilities, so
00:17:35.330 --> 00:17:41.389
that it's not able to interfere with the
running system. There's another device in
00:17:41.389 --> 00:17:45.780
most server motherboards called the board
management controller, or the BMC, that
00:17:45.780 --> 00:17:52.799
has a similar level of access to memory
and devices. So we're concerned about
00:17:52.799 --> 00:17:57.889
what's running on there, and there's a
project out of Facebook called OpenBMC
00:17:57.889 --> 00:18:05.210
that is an open source Linux distribution
to run on that coprocessor, and what
00:18:05.210 --> 00:18:10.981
Facebook has done through the Open Compute
Initiative is, they have their OEMs pre-
00:18:10.981 --> 00:18:19.690
installing that on the new open compute
nodes, switches, and storage systems. And
00:18:19.690 --> 00:18:26.549
this is really where we need to get with
Linux boot as well. Right now it requires
00:18:26.549 --> 00:18:31.250
physical access to the SPI Flash and a
hardware programmer to be able to install.
00:18:31.250 --> 00:18:37.060
That's not a hurdle for everyone, but this
is not something that we want people to be
00:18:37.060 --> 00:18:43.559
doing in their server rooms. We want OEMs
to be providing these systems that are
00:18:43.559 --> 00:18:49.320
secure by default so that it's not
necessary to break out your chip clip to
00:18:49.320 --> 00:18:55.260
make this happen. But if you do want to
contribute, right now we support three
00:18:55.260 --> 00:19:02.789
different main boards: The Intel S2600,
which is a modern Wolf Pass CPU, the Mass
00:19:02.789 --> 00:19:09.159
Open Cloud is working with the Dell R630,
which is a Haswell, I believe, and then
00:19:09.159 --> 00:19:14.799
Ron Minnich and John Murrie are working on
the Open Compute Hardware, and this is
00:19:14.799 --> 00:19:21.990
again a — in conjunction with OpenBMC — a
real potential for having free software in
00:19:21.990 --> 00:19:28.260
our firmware again. So, if you'd like more
info, we have a website. There's some
00:19:28.260 --> 00:19:35.700
install instructions and we'd love to help
you build more secure, more flexible, and
00:19:35.700 --> 00:19:39.620
more resilient systems. And I really want
to thank everyone for coming here today,
00:19:39.620 --> 00:19:42.409
and I'd love to answer any questions that
you might have!
00:19:42.409 --> 00:19:51.234
applause
00:19:51.234 --> 00:19:53.240
Herald: Thank you very much Trammel Hudson
00:19:53.240 --> 00:19:58.700
for this talk. We have 10 minutes for Q&A,
so please line up at the microphones if
00:19:58.700 --> 00:20:02.880
you have any questions but there are no
questions from the signal angel and the
00:20:02.880 --> 00:20:05.310
internet, so please, microphone number
one.
00:20:05.310 --> 00:20:11.759
Q: One quick question. Is Two Sigma using
this for any of their internal systems,
00:20:11.759 --> 00:20:15.990
and B, and how much vendor outreach is in
there to try and make this beyond just the
00:20:15.990 --> 00:20:21.020
Open Compute but also a lot of the vendors
that were on your slides to adopt this.
00:20:21.020 --> 00:20:28.700
A: So currently, we don't have any deployed
systems taking advantage of it. It's still
00:20:28.700 --> 00:20:33.509
very much at the research stage. I've
been spending quite a bit of time visiting
00:20:33.509 --> 00:20:40.650
OEMs, and one of my goals for 2018 is to
have a mainstream OEM shipping it. The
00:20:40.650 --> 00:20:47.480
Heads project is shipping firmware on some
laptops from Librem, and I'm hoping we can
00:20:47.480 --> 00:20:53.631
get Linux boot on servers as well.
Herald: Microphone number 2, please.
00:20:53.631 --> 00:21:00.880
Q: The question I have is about the size
of Linux. So you mention that there is
00:21:00.880 --> 00:21:08.120
problems with UEFI, and it's not open
source, and stuff like that. But the issue
00:21:08.120 --> 00:21:16.120
you mention is that the main part of Evo
UEFI is EDK, which is open source and
00:21:16.120 --> 00:21:21.050
then, I mean, I just have to guess that
the HTTP client and stuff that they have
00:21:21.050 --> 00:21:28.169
in the Apple boot, I assume it was, is for
downloading their firmware, but how is
00:21:28.169 --> 00:21:33.240
replacing something that's huge with
something that's even bigger going to make
00:21:33.240 --> 00:21:37.440
the thing more secure? Because I think the
the whole point of having a security
00:21:37.440 --> 00:21:42.720
kernel is to have it really small to be
verifiable and I don't see that happening
00:21:42.720 --> 00:21:49.140
with Linux, because at the same time
people are coming up with other things. I
00:21:49.140 --> 00:21:54.370
don't remember the the other hypervisor,
which is supposed to be better than KVM,
00:21:54.370 --> 00:22:01.089
because KVM is not really verifiable.
A: So that that's a great question. The
00:22:01.089 --> 00:22:06.960
concern is that Linux is a huge TCB — a
Trusted Computing Base — and that that is
00:22:06.960 --> 00:22:13.029
a big concern. Since we're already running
linux on the server, it essentially is
00:22:13.029 --> 00:22:21.830
inside our TCB already, so it is large, it
is difficult to verify. However the
00:22:21.830 --> 00:22:26.250
lessons that we've learned in porting
Linux to run in this environment make it
00:22:26.250 --> 00:22:31.470
also very conceivable that we could build
other systems. If you want to use a
00:22:31.470 --> 00:22:37.290
certified — excuse me, a verified
microkernel, that would be a great place
00:22:37.290 --> 00:22:46.500
to bring into the firmware and I'd
love to figure out some way to make that
00:22:46.500 --> 00:22:55.340
happen. The second question, just to point
out, that even though EDK 2 — which is the
00:22:55.340 --> 00:23:02.000
open source components of UEFI are open
source — there's a huge amount of closed
00:23:02.000 --> 00:23:08.280
source that goes into building a UEFI
firmware, and we can't verify the closed
00:23:08.280 --> 00:23:14.490
source part, and even the open source
parts don't have the level of inspection
00:23:14.490 --> 00:23:21.870
and correctness that the Linux kernel has
gone through, and Linux systems that are
00:23:21.870 --> 00:23:31.370
exposed on the internet. Most of the UEFI
development is not focused on that level
00:23:31.370 --> 00:23:35.070
of defense that Linux has to deal with
everyday.
00:23:35.070 --> 00:23:40.850
H: Microphone number 2, please.
Q: Thank you for your talk. Would it be
00:23:40.850 --> 00:23:49.130
possible also to support, apart from
servers, to support laptops? Especially
00:23:49.130 --> 00:23:54.870
the one locked down by Boot Guard?
A: So the issue with Boot Guard on laptops
00:23:54.870 --> 00:24:01.779
is that the CPU fuses are typically set in
what's called a Verified Boot Mode, and
00:24:01.779 --> 00:24:07.789
that will not exit the boot guard ACM if
the firmware does not match the
00:24:07.789 --> 00:24:12.679
manufacturer's hash. So this doesn't give
us any way to take advantage– to
00:24:12.679 --> 00:24:18.519
circumvent that. Most server chipsets are
set in what's called Measured Boot Mode.
00:24:18.519 --> 00:24:24.679
So the Boot Guard ACM just measures the
next stage into the TPM, and then jumps
00:24:24.679 --> 00:24:30.680
into it. So if an attacker has modified
the firmware you will be able to detect it
00:24:30.680 --> 00:24:36.900
during the attestation phase.
H: Microphone number one, please — just
00:24:36.900 --> 00:24:45.710
one question.
Q: Thank you. On ARM it's much faster to
00:24:45.710 --> 00:24:51.510
boot something. It's also much simpler:
You have an address, you load the bin
00:24:51.510 --> 00:24:58.509
file, and it boots. On x86 is much more
complex, and the amount of codes you saw
00:24:58.509 --> 00:25:06.029
was for GRUB relates to that. So my
question: I've seen Allwinner boards,
00:25:06.029 --> 00:25:16.720
Cortex A8, booting in four seconds just to
get a shell, and six seconds to get a QT,
00:25:16.720 --> 00:25:21.990
so the Linux kernel pretty QT app,
to do a dashboard for a car — so five to
00:25:21.990 --> 00:25:29.509
six seconds. So I'm wondering why is there
such a big difference for a server to take
00:25:29.509 --> 00:25:37.500
20 or 22 seconds? Is it the peripherals
that needs to be initialized or what's the
00:25:37.500 --> 00:25:40.980
reason for it?
A: So there are several things that
00:25:40.980 --> 00:25:45.090
contribute to the 20 seconds, and one of
the things that we're looking into is
00:25:45.090 --> 00:25:50.649
trying to profile that. We're able to swap
out the PEI core and turn on a lot of
00:25:50.649 --> 00:25:56.480
debugging. And what I've seen on the
Dell system, a lot of that time is spent
00:25:56.480 --> 00:26:01.700
waiting for the Management Engine to come
online, and then there's also— it appears
00:26:01.700 --> 00:26:09.769
to be a one second timeout for every CPU
in the system, that they bring the CPUs on
00:26:09.769 --> 00:26:16.360
one at a time, and it takes almost
precisely 1 million microseconds for each
00:26:16.360 --> 00:26:21.509
one. So there are things in the vendor
firmware that we currently don't have the
00:26:21.509 --> 00:26:27.220
ability to change — that appear to be the
long tent, excuse me, long poll in the
00:26:27.220 --> 00:26:33.320
tent on the boot process.
H: Microphone 3 in the back, please.
00:26:33.320 --> 00:26:40.580
Q: You addressed a lot about security, but
my question is rather, there's a lot of
00:26:40.580 --> 00:26:47.600
settings — for example BIOS, there's UEFI
settings, and there's stuff like remote
00:26:47.600 --> 00:26:55.360
booting — which is a whole bunch of weird
protocols, proprietary stuff, and stuff
00:26:55.360 --> 00:27:01.740
that's really hard to handle. If you have
a large installation, for example, you
00:27:01.740 --> 00:27:09.649
can't just say: Okay deploy all my boot
orders for the BIOS settings. Are you
00:27:09.649 --> 00:27:14.279
going to address that in some unified,
nice way, where I can say, okay I have
00:27:14.279 --> 00:27:22.050
this one protocol that runs on my Linux
firmware that does that nicely.
00:27:22.050 --> 00:27:28.549
A: That's exactly how most sites will
deploy it. That they will write their own
00:27:28.549 --> 00:27:34.570
boot scripts that use traditional — excuse
me — that use normal protocols. So in the
00:27:34.570 --> 00:27:42.380
Mass Open Cloud they are doing a wget over
SSL that can then measure the received
00:27:42.380 --> 00:27:51.990
kernel into the TPM and then kexec it. And
that's done without requiring changes to
00:27:51.990 --> 00:27:56.850
in-VRAM-variables, or all the sort of
setup that you have to put into to
00:27:56.850 --> 00:28:02.470
configuring a UEFI system. That can be
replaced with a very small shell script.
00:28:02.470 --> 00:28:08.799
H: We have time for one last question —
and this is from the Signal Angel, because
00:28:08.799 --> 00:28:13.669
the internet has a question.
Q: Yes, the internet has two very simple
00:28:13.669 --> 00:28:17.950
technical questions: Do you know if
there's any progress, or do you know if
00:28:17.950 --> 00:28:24.440
any ATAs on the Talus 2 project. And are
there any size concerns when writing
00:28:24.440 --> 00:28:27.186
firmware in Go?
00:28:27.186 --> 00:28:32.690
A: So the Talus 2 project is
a Power based system, and right now we're
00:28:32.690 --> 00:28:38.580
mostly focused on the x86 servers, since
that's the very mainstream available sorts
00:28:38.580 --> 00:28:45.220
of boards, and the Go firmware is actually
quite small. I've mostly been working on
00:28:45.220 --> 00:28:50.690
the Heads side, which is based on shell
scripts. My understanding is that the
00:28:50.690 --> 00:28:55.940
just-in-time compiled Go does not add more
than a few hundred kilobytes to the ROM
00:28:55.940 --> 00:29:03.190
image and only a few 100 milliseconds to
to the boot time. The advantage of Go is
00:29:03.190 --> 00:29:11.210
that it is memory safe, and it's an actual
programming language, so it allows the
00:29:11.210 --> 00:29:14.720
initialization scripts to be verified in a
way that shell scripts can be very
00:29:14.720 --> 00:29:18.840
difficult to do.
H: So thank you very much for answering
00:29:18.840 --> 00:29:22.080
all these questions. Please
give a warm round of applause to
00:29:22.080 --> 00:29:30.319
Trammel Hudson. Thank you very much!
applause
00:29:30.319 --> 00:29:33.539
postroll music
00:29:33.539 --> 00:29:52.000
subtitles created by c3subtitles.de
in the year 2020. Join, and help us!