[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:14.99,0:00:19.62,Default,,0000,0000,0000,,Herald Angel: So, most of the cloud\Nservices rely on closed source proprietary
Dialogue: 0,0:00:19.62,0:00:23.76,Default,,0000,0000,0000,,server firmware; header[?] firmware; with\Nknown security implications to[?] tenants.
Dialogue: 0,0:00:23.76,0:00:30.14,Default,,0000,0000,0000,,Imagine... So that's where LinuxBoot comes\Nto the rescue because it wants to replace
Dialogue: 0,0:00:30.14,0:00:36.20,Default,,0000,0000,0000,,this closed source firmware with an open\NLinux boot version and our next speaker
Dialogue: 0,0:00:36.20,0:00:41.03,Default,,0000,0000,0000,,Trammell Hudson he's an integral part of\Nthat project and he's here to provide you
Dialogue: 0,0:00:41.03,0:00:45.82,Default,,0000,0000,0000,,an overview of this Linux boot project.\NThank you very much and please give a warm
Dialogue: 0,0:00:45.82,0:00:48.45,Default,,0000,0000,0000,,round round of applause to Trammell\NHudson, please!
Dialogue: 0,0:00:48.45,0:00:56.25,Default,,0000,0000,0000,,{\i1}applause{\i0}\NTrammell: Thank you!
Dialogue: 0,0:00:56.25,0:01:01.64,Default,,0000,0000,0000,,Securing the boot process is really\Nfundamental to having secure systems
Dialogue: 0,0:01:01.64,0:01:09.89,Default,,0000,0000,0000,,because of the vulnerabilities in firmware\Ncan affect any security that the operating
Dialogue: 0,0:01:09.89,0:01:15.25,Default,,0000,0000,0000,,system tries to provide. And for that\Nreason I think it's really important that
Dialogue: 0,0:01:15.25,0:01:21.30,Default,,0000,0000,0000,,we replace the proprietary vendor\Nfirmwares with open source, like Linux.
Dialogue: 0,0:01:21.30,0:01:26.26,Default,,0000,0000,0000,,And this is not a new idea. My\Ncollaborator Ron Minich started a project
Dialogue: 0,0:01:26.26,0:01:31.84,Default,,0000,0000,0000,,called LinuxBIOS back in the 90s when he\Nwas at Los Alamos National Labs. They
Dialogue: 0,0:01:31.84,0:01:36.23,Default,,0000,0000,0000,,built the world's third fastest\Nsupercomputer out of a Linux cluster that
Dialogue: 0,0:01:36.23,0:01:44.81,Default,,0000,0000,0000,,used BIOS in the ROM to make it more\Nreliable. LinuxBIOS turned into coreboot
Dialogue: 0,0:01:44.81,0:01:52.61,Default,,0000,0000,0000,,in 2005 and the Linux part was removed and\Nbecame a generic bootloader, and it now
Dialogue: 0,0:01:52.61,0:01:59.14,Default,,0000,0000,0000,,powers the Chromebooks as well as projects\Nlike the Heads slightly more secure laptop
Dialogue: 0,0:01:59.14,0:02:04.83,Default,,0000,0000,0000,,firmware that I presented last year at\NCCC. Unfortunately it doesn't support any
Dialogue: 0,0:02:04.83,0:02:12.71,Default,,0000,0000,0000,,server main boards anymore. Most servers\Nare running a variant of Intel's UEFI
Dialogue: 0,0:02:12.71,0:02:19.22,Default,,0000,0000,0000,,firmware, which is a project that Intel\Nstarted to replace the somewhat aging
Dialogue: 0,0:02:19.22,0:02:24.86,Default,,0000,0000,0000,,16-bit real mode BIOS of the 80s and 90s.\NAnd, like a lot of second systems, it's
Dialogue: 0,0:02:24.86,0:02:30.00,Default,,0000,0000,0000,,pretty complicated. If you've been to any\Ntalks on firmware security you've probably
Dialogue: 0,0:02:30.00,0:02:37.07,Default,,0000,0000,0000,,seen this slide before. It goes through\Nmultiple phases as the system boots, the
Dialogue: 0,0:02:37.07,0:02:44.97,Default,,0000,0000,0000,,first phase does a cryptographic\Nverification of the pre-EFI phase this the
Dialogue: 0,0:02:44.97,0:02:49.95,Default,,0000,0000,0000,,PEI phase is responsible for bringing up\Nthe memory controller the CPU interconnect
Dialogue: 0,0:02:49.95,0:02:55.15,Default,,0000,0000,0000,,and a few other critical devices. It also\Nenables paging and long mode and then
Dialogue: 0,0:02:55.15,0:03:03.06,Default,,0000,0000,0000,,jumps into the device execution\Nenvironment or DXE phase. This is where
Dialogue: 0,0:03:03.06,0:03:07.62,Default,,0000,0000,0000,,UEFI option ROMs are executed as well, as\Nwell as all of the remaining devices are
Dialogue: 0,0:03:07.62,0:03:14.59,Default,,0000,0000,0000,,initialized. Once the PCI bus and USB\Nbuses have been walked and enumerated, it
Dialogue: 0,0:03:14.59,0:03:20.35,Default,,0000,0000,0000,,transfers to the boot device selection\Nphase, which figures out which disk or USB
Dialogue: 0,0:03:20.35,0:03:26.67,Default,,0000,0000,0000,,stick or network to boot from. That loads\Na boot loader from that device which
Dialogue: 0,0:03:26.67,0:03:32.23,Default,,0000,0000,0000,,eventually loads a real operating system,\Nwhich then is the operating system that's
Dialogue: 0,0:03:32.23,0:03:37.56,Default,,0000,0000,0000,,running on the machine. What we're\Nproposing is that we replace all of this
Dialogue: 0,0:03:37.56,0:03:45.68,Default,,0000,0000,0000,,with the Linux boot kernel and runtime. We\Ncan do all of the device enumeration in
Dialogue: 0,0:03:45.68,0:03:50.20,Default,,0000,0000,0000,,Linux, it already has support for doing\Nthis, and then we can use more
Dialogue: 0,0:03:50.20,0:03:54.84,Default,,0000,0000,0000,,sophisticated protocols and tools to\Nlocate the real kernel that we want to
Dialogue: 0,0:03:54.84,0:04:03.82,Default,,0000,0000,0000,,run, and use the kexec system call to be\Nable to start that new kernel. And the
Dialogue: 0,0:04:03.82,0:04:09.04,Default,,0000,0000,0000,,reason we want to use Linux here is\Nbecause it gives us the ability to have a
Dialogue: 0,0:04:09.04,0:04:13.54,Default,,0000,0000,0000,,more secure system. It gives us a lot more\Nflexibility and hopefully it lets us
Dialogue: 0,0:04:13.54,0:04:20.76,Default,,0000,0000,0000,,create a more resilient system out of it.\NOn the security front one of the big areas
Dialogue: 0,0:04:20.76,0:04:28.07,Default,,0000,0000,0000,,that we get some benefit is we reduced the\Nattack surface that in the DXE phase these
Dialogue: 0,0:04:28.07,0:04:35.48,Default,,0000,0000,0000,,drivers are an enormous amount of code on\Nthe Intel S2600 there are over 400 modules
Dialogue: 0,0:04:35.48,0:04:41.10,Default,,0000,0000,0000,,that get loaded. They do things like the\Noption roms that I mentioned, and if you
Dialogue: 0,0:04:41.10,0:04:44.44,Default,,0000,0000,0000,,want an example of how dangerous option\Nroms can be, you can look at my
Dialogue: 0,0:04:44.44,0:04:50.68,Default,,0000,0000,0000,,Thunderstrike talks from a few years ago.\NThey also do things like display the boot
Dialogue: 0,0:04:50.68,0:04:55.41,Default,,0000,0000,0000,,splash, the vendor logo, and this has been\Na place where quite a few buffer overflows
Dialogue: 0,0:04:55.41,0:05:00.21,Default,,0000,0000,0000,,have been found in vendor firmwares in the\Npast. They have a complete network stack
Dialogue: 0,0:05:00.21,0:05:09.77,Default,,0000,0000,0000,,IPv4 and v6 as well as HTTP and HTTPS.\NThey have legacy device drivers for things
Dialogue: 0,0:05:09.77,0:05:14.49,Default,,0000,0000,0000,,like floppy drives, and again, these sort\Nof dusty corners are where vulnerabilities
Dialogue: 0,0:05:14.49,0:05:20.54,Default,,0000,0000,0000,,in Xen have been found that allowed a\Nhypervisor break. There are also modules
Dialogue: 0,0:05:20.54,0:05:25.88,Default,,0000,0000,0000,,like the Microsoft OEM activation that we\Njust don't know what they do, or things
Dialogue: 0,0:05:25.88,0:05:35.78,Default,,0000,0000,0000,,like a y2k rollover module that probably\Nhasn't been tested in two decades. So the
Dialogue: 0,0:05:35.78,0:05:41.06,Default,,0000,0000,0000,,final OS bootloader phase is actually not\Npart of UEFI, but it's typically in, the
Dialogue: 0,0:05:41.06,0:05:46.43,Default,,0000,0000,0000,,Linux system, its GRUB, the grand unified\Nbootloader. And y'all -- many of you are
Dialogue: 0,0:05:46.43,0:05:51.16,Default,,0000,0000,0000,,probably familiar with its interface, but\Ndid you know that it has its own file
Dialogue: 0,0:05:51.16,0:05:58.90,Default,,0000,0000,0000,,system, video, and network drivers. About\Nalmost 250 thousand lines of code make up
Dialogue: 0,0:05:58.90,0:06:04.44,Default,,0000,0000,0000,,GRUB. I don't bring up the size of this to\Ncomplain about the space it takes, but
Dialogue: 0,0:06:04.44,0:06:09.54,Default,,0000,0000,0000,,because of how much it increases our\Nattack surface. You might think that
Dialogue: 0,0:06:09.54,0:06:13.77,Default,,0000,0000,0000,,having three different operating systems\Ninvolved in this boot process gives us a
Dialogue: 0,0:06:13.77,0:06:19.27,Default,,0000,0000,0000,,defense in depth, but I would argue that\Nwe are subject to the weakest link in this
Dialogue: 0,0:06:19.27,0:06:23.71,Default,,0000,0000,0000,,chain because if you can compromise UEFI,\Nyou can compromise grub, and if you can
Dialogue: 0,0:06:23.71,0:06:27.52,Default,,0000,0000,0000,,compromise grub you can compromise the\NLinux kernel that you want to run on the
Dialogue: 0,0:06:27.52,0:06:35.42,Default,,0000,0000,0000,,machine. So there are lots of ways these\Nattacks could be launched. As I mentioned
Dialogue: 0,0:06:35.42,0:06:39.78,Default,,0000,0000,0000,,UEFI has a network device driver, grub has\Na network device driver, and of course
Dialogue: 0,0:06:39.78,0:06:43.62,Default,,0000,0000,0000,,Linux has a network device driver. This\Nmeans that a remote attacker could
Dialogue: 0,0:06:43.62,0:06:48.30,Default,,0000,0000,0000,,potentially get code execution during the\Nboot process.
Dialogue: 0,0:06:48.30,0:06:56.43,Default,,0000,0000,0000,,UEFI has a USB driver, grub has a\NUSB driver, and of course Linux has a USB
Dialogue: 0,0:06:56.43,0:07:02.52,Default,,0000,0000,0000,,driver. There have been bugs found in USB\Nstacks -- which unfortunately are very
Dialogue: 0,0:07:02.52,0:07:08.06,Default,,0000,0000,0000,,complex -- and a buffer overflow in a USB\Ndescriptor handler could allow a local
Dialogue: 0,0:07:08.06,0:07:12.87,Default,,0000,0000,0000,,attacker to plug in a rogue device and\Ntake control of the firmware during the
Dialogue: 0,0:07:12.87,0:07:19.37,Default,,0000,0000,0000,,boot. Of course UEFI has a FAT driver,\NGRUB has a FAT driver, Linux has a FAT
Dialogue: 0,0:07:19.37,0:07:26.14,Default,,0000,0000,0000,,driver. This gives an attacker a place to\Ngain persistence and perhaps leverage code
Dialogue: 0,0:07:26.14,0:07:35.19,Default,,0000,0000,0000,,execution during the initial file system\Nor partition walk. So what we argue is
Dialogue: 0,0:07:35.19,0:07:39.65,Default,,0000,0000,0000,,that we should have the operating system\Nthat has the most contributors, and the
Dialogue: 0,0:07:39.65,0:07:47.07,Default,,0000,0000,0000,,most code review, and the most frequent\Nupdate schedule, for these roles. Linux
Dialogue: 0,0:07:47.07,0:07:52.79,Default,,0000,0000,0000,,has a lot more eyes on it, it undergoes a\Nmuch more rapid update schedule than
Dialogue: 0,0:07:52.79,0:08:01.18,Default,,0000,0000,0000,,pretty much any vendor firmware. You might\Nask, why do we keep the PEI and the SEC
Dialogue: 0,0:08:01.18,0:08:08.27,Default,,0000,0000,0000,,phase from the UEFI firmware? Couldn't we\Nuse coreboot in this place, and the
Dialogue: 0,0:08:08.27,0:08:12.63,Default,,0000,0000,0000,,problem is that vendors are not\Ndocumenting the memory controller or the
Dialogue: 0,0:08:12.63,0:08:18.08,Default,,0000,0000,0000,,CPU interconnect. Instead they're\Nproviding a opaque binary blob called the
Dialogue: 0,0:08:18.08,0:08:25.45,Default,,0000,0000,0000,,firmware support package, or FSP, that\Ndoes the memory controller and the CPU
Dialogue: 0,0:08:25.45,0:08:32.88,Default,,0000,0000,0000,,initialization. On most coreboot systems\N-- on most modern coreboot systems --
Dialogue: 0,0:08:32.88,0:08:38.14,Default,,0000,0000,0000,,coreboot actually calls into the FSP to do\Nthis initialization. And on a lot of the
Dialogue: 0,0:08:38.14,0:08:43.48,Default,,0000,0000,0000,,devices the FSB has grown in scope so it\Nnow includes video device drivers and
Dialogue: 0,0:08:43.48,0:08:49.16,Default,,0000,0000,0000,,power management, and it's actually larger\Nthan the PEI phase on some of the servers
Dialogue: 0,0:08:49.16,0:08:57.68,Default,,0000,0000,0000,,that we're dealing with. The other wrinkle\Nis that most modern CPUs don't come out of
Dialogue: 0,0:08:57.68,0:09:02.06,Default,,0000,0000,0000,,reset into the legacy reset vector\Nanymore. Instead, they execute an
Dialogue: 0,0:09:02.06,0:09:07.33,Default,,0000,0000,0000,,authenticated code module, called boot\Nguard, that's signed by Intel, and the CPU
Dialogue: 0,0:09:07.33,0:09:15.13,Default,,0000,0000,0000,,will not start up if that's not present.\NThe good news is that this boot guard ACM
Dialogue: 0,0:09:15.13,0:09:22.60,Default,,0000,0000,0000,,measures the PEI phase into the TPM, which\Nallows us to detect attempts to modify it
Dialogue: 0,0:09:22.60,0:09:28.46,Default,,0000,0000,0000,,from malicious attacks. The bad news is\Nthat we are not able to change it on many
Dialogue: 0,0:09:28.46,0:09:33.80,Default,,0000,0000,0000,,of these systems. But even with that in\Nplace, we still have a much, much more
Dialogue: 0,0:09:33.80,0:09:39.73,Default,,0000,0000,0000,,flexible system. If you've ever worked\Nwith the UEFI shell or with GRUBs menu
Dialogue: 0,0:09:39.73,0:09:46.62,Default,,0000,0000,0000,,config, it's really not as flexible, and\Nthe tooling is not anywhere near as
Dialogue: 0,0:09:46.62,0:09:51.49,Default,,0000,0000,0000,,mature, as being able to write things with\Nshell scripts, or with go, or with real
Dialogue: 0,0:09:51.49,0:09:57.52,Default,,0000,0000,0000,,languages. Additionally we can configure\Nat the Linux boot kernel with standard
Dialogue: 0,0:09:57.52,0:10:04.42,Default,,0000,0000,0000,,Linux config tools. UEFI supports booting\Nfrom FAT file systems, but with LinuxBoot
Dialogue: 0,0:10:04.42,0:10:09.38,Default,,0000,0000,0000,,we can boot from any of the hundreds of\Nfile systems that Linux supports. We can
Dialogue: 0,0:10:09.38,0:10:15.71,Default,,0000,0000,0000,,boot from encrypted filesystems, since we\Nhave LUKS and cryptsetup. Most UEFI
Dialogue: 0,0:10:15.71,0:10:19.79,Default,,0000,0000,0000,,firmwares can only boot from the network\Ndevice that is installed on the server
Dialogue: 0,0:10:19.79,0:10:25.03,Default,,0000,0000,0000,,motherboard. We can boot from any network\Ndevice that Linux supports, and we can use
Dialogue: 0,0:10:25.03,0:10:30.90,Default,,0000,0000,0000,,proper protocols; we're not limited to PXE\Nand TFTP. We can use SSL, we can do
Dialogue: 0,0:10:30.90,0:10:37.50,Default,,0000,0000,0000,,cryptographic measurements of the kernels\Nthat we receive. And the runtime that
Dialogue: 0,0:10:37.50,0:10:42.92,Default,,0000,0000,0000,,makes up Linux boot is also very flexible.\NLast year I presented the Heads runtime
Dialogue: 0,0:10:42.92,0:10:50.11,Default,,0000,0000,0000,,for laptops. This is a very security\Nfocused initial ram disk that attempts to
Dialogue: 0,0:10:50.11,0:10:55.17,Default,,0000,0000,0000,,provide a slightly more secure, measured,\Nand attested firmware, and this works
Dialogue: 0,0:10:55.17,0:11:00.69,Default,,0000,0000,0000,,really well with Linux boot. My\Ncollaborator Ron Minnich is working on a
Dialogue: 0,0:11:00.69,0:11:06.22,Default,,0000,0000,0000,,go based firmware, called NERF, and this\Nis written entirely in just-in-time
Dialogue: 0,0:11:06.22,0:11:10.70,Default,,0000,0000,0000,,compiled Go, which is really nice because\Nit gives you memory safety, and is very
Dialogue: 0,0:11:10.70,0:11:16.16,Default,,0000,0000,0000,,popular inside of Google. Being able to\Ntailor the device drivers that are
Dialogue: 0,0:11:16.16,0:11:21.100,Default,,0000,0000,0000,,included also allows the system to boot\Nmuch faster. UEFI on the Open Compute
Dialogue: 0,0:11:21.100,0:11:27.63,Default,,0000,0000,0000,,Winterfell takes about eight minutes to\Nstartup. With NERF, excuse me -- with
Dialogue: 0,0:11:27.63,0:11:32.87,Default,,0000,0000,0000,,with Linux boot and NERF it starts up in\Nabout 20 seconds. I found similar results
Dialogue: 0,0:11:32.87,0:11:38.51,Default,,0000,0000,0000,,on the Intel mainboard that I'm working on\Nand hopefully we will get a video there's
Dialogue: 0,0:11:38.51,0:11:45.35,Default,,0000,0000,0000,,an action this is from power-on to\Nexecutes the PEI phase out of the
Dialogue: 0,0:11:45.35,0:11:52.21,Default,,0000,0000,0000,,ROM and then jumps into a small wrapper\Naround the Linux kernel which then prints
Dialogue: 0,0:11:52.21,0:11:59.24,Default,,0000,0000,0000,,to the serial port and we now have the\NLinux print case and we have an
Dialogue: 0,0:11:59.24,0:12:03.17,Default,,0000,0000,0000,,interactive shell in about 20 seconds\Nwhich is quite a bit better than the four
Dialogue: 0,0:12:03.17,0:12:11.19,Default,,0000,0000,0000,,minutes that the system used to take it\Nscrolled by pretty fast but you might have
Dialogue: 0,0:12:11.19,0:12:15.54,Default,,0000,0000,0000,,noticed that the print case has ... - that\Nthe Linux kernel thinks it's running under
Dialogue: 0,0:12:15.54,0:12:20.09,Default,,0000,0000,0000,,EFI this because we have a small wrapper\Naround the kernel but for the most part
Dialogue: 0,0:12:20.09,0:12:26.28,Default,,0000,0000,0000,,the kernel is able to do all of the PCI\Nand device enumeration that it needs to do
Dialogue: 0,0:12:26.28,0:12:29.78,Default,,0000,0000,0000,,because it already does it since it\Ndoesn't trust the vendor BIOSes in a lot
Dialogue: 0,0:12:29.78,0:12:38.57,Default,,0000,0000,0000,,of cases so I'm really glad that the\NCongress has added a track on technical
Dialogue: 0,0:12:38.57,0:12:45.42,Default,,0000,0000,0000,,resiliency and I would encourage Congress\Nto also add a track on resiliency of our
Dialogue: 0,0:12:45.42,0:12:50.64,Default,,0000,0000,0000,,social systems because it's really vital\Nthat we deal with both online and offline
Dialogue: 0,0:12:50.64,0:12:55.53,Default,,0000,0000,0000,,harassment and I think that that will help\Nus make a safer and more secure Congress
Dialogue: 0,0:12:55.53,0:13:05.61,Default,,0000,0000,0000,,as well.\N{\i1}applause{\i0}
Dialogue: 0,0:13:05.61,0:13:12.03,Default,,0000,0000,0000,,So last year when I presented at\NHeads I proposed three criteria for a
Dialogue: 0,0:13:12.03,0:13:16.34,Default,,0000,0000,0000,,resilient technical system: that they need\Nto be built with open-source software,
Dialogue: 0,0:13:16.34,0:13:20.33,Default,,0000,0000,0000,,they need to be reproducibly built, and\Nthey need to be measured into some sort of
Dialogue: 0,0:13:20.33,0:13:26.75,Default,,0000,0000,0000,,cryptographic hardware. The open is, you\Nknow, I think, in this crowd, is not
Dialogue: 0,0:13:26.75,0:13:33.60,Default,,0000,0000,0000,,controversial. But the reason that we need\Nit is because a lot of the server vendors
Dialogue: 0,0:13:33.60,0:13:37.81,Default,,0000,0000,0000,,don't actually control their own firmware;\Nthey license it from independent BIOS
Dialogue: 0,0:13:37.81,0:13:45.23,Default,,0000,0000,0000,,vendors who then tailor it for whatever\Ncurrent model of machine the
Dialogue: 0,0:13:45.23,0:13:51.09,Default,,0000,0000,0000,,manufacturer is making. This means that\Nthey typically don't support older
Dialogue: 0,0:13:51.09,0:13:55.56,Default,,0000,0000,0000,,hardware and, if there are\Nvulnerabilities, it's necessary that we be
Dialogue: 0,0:13:55.56,0:14:00.66,Default,,0000,0000,0000,,able to make these patches on our own\Nschedule and we need to be able to self-
Dialogue: 0,0:14:00.66,0:14:07.32,Default,,0000,0000,0000,,help when it comes to our own security.\NThe other problem is that closed source
Dialogue: 0,0:14:07.32,0:14:13.21,Default,,0000,0000,0000,,systems can hide vulnerabilities for\Ndecades — this is especially true for very
Dialogue: 0,0:14:13.21,0:14:17.07,Default,,0000,0000,0000,,privileged devices like the management\Nengine. There's been several talks here at
Dialogue: 0,0:14:17.07,0:14:23.79,Default,,0000,0000,0000,,Congress about the concerns that we have\Nwith the management engine. Some vendors
Dialogue: 0,0:14:23.79,0:14:29.93,Default,,0000,0000,0000,,are even violating our trust entirely and\Nusing their place in the firmware
Dialogue: 0,0:14:29.93,0:14:38.47,Default,,0000,0000,0000,,to install malware or adware onto the\Nsystems. So for this reason we really need
Dialogue: 0,0:14:38.47,0:14:47.29,Default,,0000,0000,0000,,our own control over this firmware.\NReproducibility is becoming much more of
Dialogue: 0,0:14:47.29,0:14:53.59,Default,,0000,0000,0000,,an issue, and the goal here is to be able\Nto ensure that everyone who builds the
Dialogue: 0,0:14:53.59,0:14:59.16,Default,,0000,0000,0000,,Linux boot firmware gets exactly the same\Nresult that everyone else does. This is a
Dialogue: 0,0:14:59.16,0:15:03.76,Default,,0000,0000,0000,,requirement to be able to ensure that\Nwe're not introducing accidental
Dialogue: 0,0:15:03.76,0:15:08.65,Default,,0000,0000,0000,,vulnerabilities through picking up the\Nwrong library, or intentional ones through
Dialogue: 0,0:15:08.65,0:15:16.08,Default,,0000,0000,0000,,compiler supply chain attacks, such as Ken\NThompson's Trusting Trust article. With
Dialogue: 0,0:15:16.08,0:15:21.57,Default,,0000,0000,0000,,the Linux boot firmware, our Kernel and\NInitial Ramdisk are reproducibly built, so
Dialogue: 0,0:15:21.57,0:15:27.82,Default,,0000,0000,0000,,we get exactly the same hashes on the\Nfirmware. Unfortunately we don't control
Dialogue: 0,0:15:27.82,0:15:33.56,Default,,0000,0000,0000,,the UEFI portions that we're using — the\NPEI and the SEC phase — so those aren't
Dialogue: 0,0:15:33.56,0:15:41.92,Default,,0000,0000,0000,,included in our reproducibility\Nright now. "Measured" is a another place
Dialogue: 0,0:15:41.92,0:15:48.06,Default,,0000,0000,0000,,where we need to take into account the\Nruntime security of the system. So
Dialogue: 0,0:15:48.06,0:15:52.51,Default,,0000,0000,0000,,reproducible builds handle the compile\Ntime, but measuring what's running into
Dialogue: 0,0:15:52.51,0:15:58.59,Default,,0000,0000,0000,,cryptographic coprocessors — like the TPM\N— gives us the ability to make
Dialogue: 0,0:15:58.59,0:16:02.94,Default,,0000,0000,0000,,attestations as to what is actually\Nrunning on the system. On the Heads
Dialogue: 0,0:16:02.94,0:16:09.50,Default,,0000,0000,0000,,firmware we do this to the user that the\Nfirmware can produce a one-time secret
Dialogue: 0,0:16:09.50,0:16:14.32,Default,,0000,0000,0000,,that you can compare against your phone to\Nknow that it has not been tampered with.
Dialogue: 0,0:16:14.32,0:16:18.31,Default,,0000,0000,0000,,In the server case it uses remote\Nattestation to be able to prove to the
Dialogue: 0,0:16:18.31,0:16:25.30,Default,,0000,0000,0000,,user that the code that is running is what\Nthey expect. This is a collaboration with
Dialogue: 0,0:16:25.30,0:16:30.76,Default,,0000,0000,0000,,the Mass Open Cloud Project, out of Boston\NUniversity and MIT, that is attempting to
Dialogue: 0,0:16:30.76,0:16:37.66,Default,,0000,0000,0000,,provide a hardware root of trust for the\Nservers, so that you can know that a cloud
Dialogue: 0,0:16:37.66,0:16:45.53,Default,,0000,0000,0000,,provider has not tampered with your\Nsystem. The TPM is not invulnerable, as
Dialogue: 0,0:16:45.53,0:16:49.89,Default,,0000,0000,0000,,Christopher Tarnovsky showed at DEFCON,\Nbut the level of effort that it takes to
Dialogue: 0,0:16:49.89,0:16:55.27,Default,,0000,0000,0000,,break into a TPM, to decap it, and to read\Nout the bits with a microscope raises the
Dialogue: 0,0:16:55.27,0:17:02.29,Default,,0000,0000,0000,,bar really significantly. And part of\Nresiliency is making honest trade-offs
Dialogue: 0,0:17:02.29,0:17:09.37,Default,,0000,0000,0000,,about security threats versus the\Ndifficulty in launching the attacks, and
Dialogue: 0,0:17:09.37,0:17:14.89,Default,,0000,0000,0000,,if the TPM prevents remote attacks or\Nprevents software-only attacks, that is a
Dialogue: 0,0:17:14.89,0:17:22.71,Default,,0000,0000,0000,,sufficiently high bar for a lot of these\Napplications. We have quite a bit of
Dialogue: 0,0:17:22.71,0:17:28.55,Default,,0000,0000,0000,,ongoing research with this. As I mentioned\Nthe management engine is an area of great
Dialogue: 0,0:17:28.55,0:17:35.33,Default,,0000,0000,0000,,concern and we are working on figuring out\Nhow to remove most of its capabilities, so
Dialogue: 0,0:17:35.33,0:17:41.39,Default,,0000,0000,0000,,that it's not able to interfere with the\Nrunning system. There's another device in
Dialogue: 0,0:17:41.39,0:17:45.78,Default,,0000,0000,0000,,most server motherboards called the board\Nmanagement controller, or the BMC, that
Dialogue: 0,0:17:45.78,0:17:52.80,Default,,0000,0000,0000,,has a similar level of access to memory\Nand devices. So we're concerned about
Dialogue: 0,0:17:52.80,0:17:57.89,Default,,0000,0000,0000,,what's running on there, and there's a\Nproject out of Facebook called OpenBMC
Dialogue: 0,0:17:57.89,0:18:05.21,Default,,0000,0000,0000,,that is an open source Linux distribution\Nto run on that coprocessor, and what
Dialogue: 0,0:18:05.21,0:18:10.98,Default,,0000,0000,0000,,Facebook has done through the Open Compute\NInitiative is, they have their OEMs pre-
Dialogue: 0,0:18:10.98,0:18:19.69,Default,,0000,0000,0000,,installing that on the new open compute\Nnodes, switches, and storage systems. And
Dialogue: 0,0:18:19.69,0:18:26.55,Default,,0000,0000,0000,,this is really where we need to get with\NLinux boot as well. Right now it requires
Dialogue: 0,0:18:26.55,0:18:31.25,Default,,0000,0000,0000,,physical access to the SPI Flash and a\Nhardware programmer to be able to install.
Dialogue: 0,0:18:31.25,0:18:37.06,Default,,0000,0000,0000,,That's not a hurdle for everyone, but this\Nis not something that we want people to be
Dialogue: 0,0:18:37.06,0:18:43.56,Default,,0000,0000,0000,,doing in their server rooms. We want OEMs\Nto be providing these systems that are
Dialogue: 0,0:18:43.56,0:18:49.32,Default,,0000,0000,0000,,secure by default so that it's not\Nnecessary to break out your chip clip to
Dialogue: 0,0:18:49.32,0:18:55.26,Default,,0000,0000,0000,,make this happen. But if you do want to\Ncontribute, right now we support three
Dialogue: 0,0:18:55.26,0:19:02.79,Default,,0000,0000,0000,,different main boards: The Intel S2600,\Nwhich is a modern Wolf Pass CPU, the Mass
Dialogue: 0,0:19:02.79,0:19:09.16,Default,,0000,0000,0000,,Open Cloud is working with the Dell R630,\Nwhich is a Haswell, I believe, and then
Dialogue: 0,0:19:09.16,0:19:14.80,Default,,0000,0000,0000,,Ron Minnich and John Murrie are working on\Nthe Open Compute Hardware, and this is
Dialogue: 0,0:19:14.80,0:19:21.99,Default,,0000,0000,0000,,again a — in conjunction with OpenBMC — a\Nreal potential for having free software in
Dialogue: 0,0:19:21.99,0:19:28.26,Default,,0000,0000,0000,,our firmware again. So, if you'd like more\Ninfo, we have a website. There's some
Dialogue: 0,0:19:28.26,0:19:35.70,Default,,0000,0000,0000,,install instructions and we'd love to help\Nyou build more secure, more flexible, and
Dialogue: 0,0:19:35.70,0:19:39.62,Default,,0000,0000,0000,,more resilient systems. And I really want\Nto thank everyone for coming here today,
Dialogue: 0,0:19:39.62,0:19:42.41,Default,,0000,0000,0000,,and I'd love to answer any questions that\Nyou might have!
Dialogue: 0,0:19:42.41,0:19:51.23,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:19:51.23,0:19:53.24,Default,,0000,0000,0000,,Herald: Thank you very much Trammel Hudson
Dialogue: 0,0:19:53.24,0:19:58.70,Default,,0000,0000,0000,,for this talk. We have 10 minutes for Q&A,\Nso please line up at the microphones if
Dialogue: 0,0:19:58.70,0:20:02.88,Default,,0000,0000,0000,,you have any questions but there are no\Nquestions from the signal angel and the
Dialogue: 0,0:20:02.88,0:20:05.31,Default,,0000,0000,0000,,internet, so please, microphone number\None.
Dialogue: 0,0:20:05.31,0:20:11.76,Default,,0000,0000,0000,,Q: One quick question. Is Two Sigma using\Nthis for any of their internal systems,
Dialogue: 0,0:20:11.76,0:20:15.99,Default,,0000,0000,0000,,and B, and how much vendor outreach is in\Nthere to try and make this beyond just the
Dialogue: 0,0:20:15.99,0:20:21.02,Default,,0000,0000,0000,,Open Compute but also a lot of the vendors\Nthat were on your slides to adopt this.
Dialogue: 0,0:20:21.02,0:20:28.70,Default,,0000,0000,0000,,A: So currently, we don't have any deployed\Nsystems taking advantage of it. It's still
Dialogue: 0,0:20:28.70,0:20:33.51,Default,,0000,0000,0000,,very much at the research stage. I've\Nbeen spending quite a bit of time visiting
Dialogue: 0,0:20:33.51,0:20:40.65,Default,,0000,0000,0000,,OEMs, and one of my goals for 2018 is to\Nhave a mainstream OEM shipping it. The
Dialogue: 0,0:20:40.65,0:20:47.48,Default,,0000,0000,0000,,Heads project is shipping firmware on some\Nlaptops from Librem, and I'm hoping we can
Dialogue: 0,0:20:47.48,0:20:53.63,Default,,0000,0000,0000,,get Linux boot on servers as well.\NHerald: Microphone number 2, please.
Dialogue: 0,0:20:53.63,0:21:00.88,Default,,0000,0000,0000,,Q: The question I have is about the size\Nof Linux. So you mention that there is
Dialogue: 0,0:21:00.88,0:21:08.12,Default,,0000,0000,0000,,problems with UEFI, and it's not open\Nsource, and stuff like that. But the issue
Dialogue: 0,0:21:08.12,0:21:16.12,Default,,0000,0000,0000,,you mention is that the main part of Evo\NUEFI is EDK, which is open source and
Dialogue: 0,0:21:16.12,0:21:21.05,Default,,0000,0000,0000,,then, I mean, I just have to guess that\Nthe HTTP client and stuff that they have
Dialogue: 0,0:21:21.05,0:21:28.17,Default,,0000,0000,0000,,in the Apple boot, I assume it was, is for\Ndownloading their firmware, but how is
Dialogue: 0,0:21:28.17,0:21:33.24,Default,,0000,0000,0000,,replacing something that's huge with\Nsomething that's even bigger going to make
Dialogue: 0,0:21:33.24,0:21:37.44,Default,,0000,0000,0000,,the thing more secure? Because I think the\Nthe whole point of having a security
Dialogue: 0,0:21:37.44,0:21:42.72,Default,,0000,0000,0000,,kernel is to have it really small to be\Nverifiable and I don't see that happening
Dialogue: 0,0:21:42.72,0:21:49.14,Default,,0000,0000,0000,,with Linux, because at the same time\Npeople are coming up with other things. I
Dialogue: 0,0:21:49.14,0:21:54.37,Default,,0000,0000,0000,,don't remember the the other hypervisor,\Nwhich is supposed to be better than KVM,
Dialogue: 0,0:21:54.37,0:22:01.09,Default,,0000,0000,0000,,because KVM is not really verifiable.\NA: So that that's a great question. The
Dialogue: 0,0:22:01.09,0:22:06.96,Default,,0000,0000,0000,,concern is that Linux is a huge TCB — a\NTrusted Computing Base — and that that is
Dialogue: 0,0:22:06.96,0:22:13.03,Default,,0000,0000,0000,,a big concern. Since we're already running\Nlinux on the server, it essentially is
Dialogue: 0,0:22:13.03,0:22:21.83,Default,,0000,0000,0000,,inside our TCB already, so it is large, it\Nis difficult to verify. However the
Dialogue: 0,0:22:21.83,0:22:26.25,Default,,0000,0000,0000,,lessons that we've learned in porting\NLinux to run in this environment make it
Dialogue: 0,0:22:26.25,0:22:31.47,Default,,0000,0000,0000,,also very conceivable that we could build\Nother systems. If you want to use a
Dialogue: 0,0:22:31.47,0:22:37.29,Default,,0000,0000,0000,,certified — excuse me, a verified\Nmicrokernel, that would be a great place
Dialogue: 0,0:22:37.29,0:22:46.50,Default,,0000,0000,0000,,to bring into the firmware and I'd\Nlove to figure out some way to make that
Dialogue: 0,0:22:46.50,0:22:55.34,Default,,0000,0000,0000,,happen. The second question, just to point\Nout, that even though EDK 2 — which is the
Dialogue: 0,0:22:55.34,0:23:02.00,Default,,0000,0000,0000,,open source components of UEFI are open\Nsource — there's a huge amount of closed
Dialogue: 0,0:23:02.00,0:23:08.28,Default,,0000,0000,0000,,source that goes into building a UEFI\Nfirmware, and we can't verify the closed
Dialogue: 0,0:23:08.28,0:23:14.49,Default,,0000,0000,0000,,source part, and even the open source\Nparts don't have the level of inspection
Dialogue: 0,0:23:14.49,0:23:21.87,Default,,0000,0000,0000,,and correctness that the Linux kernel has\Ngone through, and Linux systems that are
Dialogue: 0,0:23:21.87,0:23:31.37,Default,,0000,0000,0000,,exposed on the internet. Most of the UEFI\Ndevelopment is not focused on that level
Dialogue: 0,0:23:31.37,0:23:35.07,Default,,0000,0000,0000,,of defense that Linux has to deal with\Neveryday.
Dialogue: 0,0:23:35.07,0:23:40.85,Default,,0000,0000,0000,,H: Microphone number 2, please.\NQ: Thank you for your talk. Would it be
Dialogue: 0,0:23:40.85,0:23:49.13,Default,,0000,0000,0000,,possible also to support, apart from\Nservers, to support laptops? Especially
Dialogue: 0,0:23:49.13,0:23:54.87,Default,,0000,0000,0000,,the one locked down by Boot Guard?\NA: So the issue with Boot Guard on laptops
Dialogue: 0,0:23:54.87,0:24:01.78,Default,,0000,0000,0000,,is that the CPU fuses are typically set in\Nwhat's called a Verified Boot Mode, and
Dialogue: 0,0:24:01.78,0:24:07.79,Default,,0000,0000,0000,,that will not exit the boot guard ACM if\Nthe firmware does not match the
Dialogue: 0,0:24:07.79,0:24:12.68,Default,,0000,0000,0000,,manufacturer's hash. So this doesn't give\Nus any way to take advantage– to
Dialogue: 0,0:24:12.68,0:24:18.52,Default,,0000,0000,0000,,circumvent that. Most server chipsets are\Nset in what's called Measured Boot Mode.
Dialogue: 0,0:24:18.52,0:24:24.68,Default,,0000,0000,0000,,So the Boot Guard ACM just measures the\Nnext stage into the TPM, and then jumps
Dialogue: 0,0:24:24.68,0:24:30.68,Default,,0000,0000,0000,,into it. So if an attacker has modified\Nthe firmware you will be able to detect it
Dialogue: 0,0:24:30.68,0:24:36.90,Default,,0000,0000,0000,,during the attestation phase.\NH: Microphone number one, please — just
Dialogue: 0,0:24:36.90,0:24:45.71,Default,,0000,0000,0000,,one question.\NQ: Thank you. On ARM it's much faster to
Dialogue: 0,0:24:45.71,0:24:51.51,Default,,0000,0000,0000,,boot something. It's also much simpler:\NYou have an address, you load the bin
Dialogue: 0,0:24:51.51,0:24:58.51,Default,,0000,0000,0000,,file, and it boots. On x86 is much more\Ncomplex, and the amount of codes you saw
Dialogue: 0,0:24:58.51,0:25:06.03,Default,,0000,0000,0000,,was for GRUB relates to that. So my\Nquestion: I've seen Allwinner boards,
Dialogue: 0,0:25:06.03,0:25:16.72,Default,,0000,0000,0000,,Cortex A8, booting in four seconds just to\Nget a shell, and six seconds to get a QT,
Dialogue: 0,0:25:16.72,0:25:21.99,Default,,0000,0000,0000,,so the Linux kernel pretty QT app,\Nto do a dashboard for a car — so five to
Dialogue: 0,0:25:21.99,0:25:29.51,Default,,0000,0000,0000,,six seconds. So I'm wondering why is there\Nsuch a big difference for a server to take
Dialogue: 0,0:25:29.51,0:25:37.50,Default,,0000,0000,0000,,20 or 22 seconds? Is it the peripherals\Nthat needs to be initialized or what's the
Dialogue: 0,0:25:37.50,0:25:40.98,Default,,0000,0000,0000,,reason for it?\NA: So there are several things that
Dialogue: 0,0:25:40.98,0:25:45.09,Default,,0000,0000,0000,,contribute to the 20 seconds, and one of\Nthe things that we're looking into is
Dialogue: 0,0:25:45.09,0:25:50.65,Default,,0000,0000,0000,,trying to profile that. We're able to swap\Nout the PEI core and turn on a lot of
Dialogue: 0,0:25:50.65,0:25:56.48,Default,,0000,0000,0000,,debugging. And what I've seen on the\NDell system, a lot of that time is spent
Dialogue: 0,0:25:56.48,0:26:01.70,Default,,0000,0000,0000,,waiting for the Management Engine to come\Nonline, and then there's also— it appears
Dialogue: 0,0:26:01.70,0:26:09.77,Default,,0000,0000,0000,,to be a one second timeout for every CPU\Nin the system, that they bring the CPUs on
Dialogue: 0,0:26:09.77,0:26:16.36,Default,,0000,0000,0000,,one at a time, and it takes almost\Nprecisely 1 million microseconds for each
Dialogue: 0,0:26:16.36,0:26:21.51,Default,,0000,0000,0000,,one. So there are things in the vendor\Nfirmware that we currently don't have the
Dialogue: 0,0:26:21.51,0:26:27.22,Default,,0000,0000,0000,,ability to change — that appear to be the\Nlong tent, excuse me, long poll in the
Dialogue: 0,0:26:27.22,0:26:33.32,Default,,0000,0000,0000,,tent on the boot process.\NH: Microphone 3 in the back, please.
Dialogue: 0,0:26:33.32,0:26:40.58,Default,,0000,0000,0000,,Q: You addressed a lot about security, but\Nmy question is rather, there's a lot of
Dialogue: 0,0:26:40.58,0:26:47.60,Default,,0000,0000,0000,,settings — for example BIOS, there's UEFI\Nsettings, and there's stuff like remote
Dialogue: 0,0:26:47.60,0:26:55.36,Default,,0000,0000,0000,,booting — which is a whole bunch of weird\Nprotocols, proprietary stuff, and stuff
Dialogue: 0,0:26:55.36,0:27:01.74,Default,,0000,0000,0000,,that's really hard to handle. If you have\Na large installation, for example, you
Dialogue: 0,0:27:01.74,0:27:09.65,Default,,0000,0000,0000,,can't just say: Okay deploy all my boot\Norders for the BIOS settings. Are you
Dialogue: 0,0:27:09.65,0:27:14.28,Default,,0000,0000,0000,,going to address that in some unified,\Nnice way, where I can say, okay I have
Dialogue: 0,0:27:14.28,0:27:22.05,Default,,0000,0000,0000,,this one protocol that runs on my Linux\Nfirmware that does that nicely.
Dialogue: 0,0:27:22.05,0:27:28.55,Default,,0000,0000,0000,,A: That's exactly how most sites will\Ndeploy it. That they will write their own
Dialogue: 0,0:27:28.55,0:27:34.57,Default,,0000,0000,0000,,boot scripts that use traditional — excuse\Nme — that use normal protocols. So in the
Dialogue: 0,0:27:34.57,0:27:42.38,Default,,0000,0000,0000,,Mass Open Cloud they are doing a wget over\NSSL that can then measure the received
Dialogue: 0,0:27:42.38,0:27:51.99,Default,,0000,0000,0000,,kernel into the TPM and then kexec it. And\Nthat's done without requiring changes to
Dialogue: 0,0:27:51.99,0:27:56.85,Default,,0000,0000,0000,,in-VRAM-variables, or all the sort of\Nsetup that you have to put into to
Dialogue: 0,0:27:56.85,0:28:02.47,Default,,0000,0000,0000,,configuring a UEFI system. That can be\Nreplaced with a very small shell script.
Dialogue: 0,0:28:02.47,0:28:08.80,Default,,0000,0000,0000,,H: We have time for one last question —\Nand this is from the Signal Angel, because
Dialogue: 0,0:28:08.80,0:28:13.67,Default,,0000,0000,0000,,the internet has a question.\NQ: Yes, the internet has two very simple
Dialogue: 0,0:28:13.67,0:28:17.95,Default,,0000,0000,0000,,technical questions: Do you know if\Nthere's any progress, or do you know if
Dialogue: 0,0:28:17.95,0:28:24.44,Default,,0000,0000,0000,,any ATAs on the Talus 2 project. And are\Nthere any size concerns when writing
Dialogue: 0,0:28:24.44,0:28:27.19,Default,,0000,0000,0000,,firmware in Go?
Dialogue: 0,0:28:27.19,0:28:32.69,Default,,0000,0000,0000,,A: So the Talus 2 project is\Na Power based system, and right now we're
Dialogue: 0,0:28:32.69,0:28:38.58,Default,,0000,0000,0000,,mostly focused on the x86 servers, since\Nthat's the very mainstream available sorts
Dialogue: 0,0:28:38.58,0:28:45.22,Default,,0000,0000,0000,,of boards, and the Go firmware is actually\Nquite small. I've mostly been working on
Dialogue: 0,0:28:45.22,0:28:50.69,Default,,0000,0000,0000,,the Heads side, which is based on shell\Nscripts. My understanding is that the
Dialogue: 0,0:28:50.69,0:28:55.94,Default,,0000,0000,0000,,just-in-time compiled Go does not add more\Nthan a few hundred kilobytes to the ROM
Dialogue: 0,0:28:55.94,0:29:03.19,Default,,0000,0000,0000,,image and only a few 100 milliseconds to\Nto the boot time. The advantage of Go is
Dialogue: 0,0:29:03.19,0:29:11.21,Default,,0000,0000,0000,,that it is memory safe, and it's an actual\Nprogramming language, so it allows the
Dialogue: 0,0:29:11.21,0:29:14.72,Default,,0000,0000,0000,,initialization scripts to be verified in a\Nway that shell scripts can be very
Dialogue: 0,0:29:14.72,0:29:18.84,Default,,0000,0000,0000,,difficult to do.\NH: So thank you very much for answering
Dialogue: 0,0:29:18.84,0:29:22.08,Default,,0000,0000,0000,,all these questions. Please\Ngive a warm round of applause to
Dialogue: 0,0:29:22.08,0:29:30.32,Default,,0000,0000,0000,,Trammel Hudson. Thank you very much!\N{\i1}applause{\i0}
Dialogue: 0,0:29:30.32,0:29:33.54,Default,,0000,0000,0000,,{\i1}postroll music{\i0}
Dialogue: 0,0:29:33.54,0:29:52.00,Default,,0000,0000,0000,,subtitles created by c3subtitles.de\Nin the year 2020. Join, and help us!