[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:13.01,Default,,0000,0000,0000,,{\i1}33c3 preroll music{\i0}
Dialogue: 0,0:00:13.01,0:00:16.87,Default,,0000,0000,0000,,Herald: So, the last speaker for this\Nmorning is Trammell. He is doing
Dialogue: 0,0:00:16.87,0:00:21.51,Default,,0000,0000,0000,,awesome research on "Bootstrapping\Nmore secure laptops or servers" and
Dialogue: 0,0:00:21.51,0:00:27.48,Default,,0000,0000,0000,,he is doing that basically by moving the\Nroot of trust into the write-protected room.
Dialogue: 0,0:00:27.48,0:00:32.83,Default,,0000,0000,0000,,He is building an open-source custom\Nfirmware, so big ups for that, and also
Dialogue: 0,0:00:32.83,0:00:36.76,Default,,0000,0000,0000,,encouraging the research on this field\Nwhich I believe it's super interesting.
Dialogue: 0,0:00:36.76,0:00:42.20,Default,,0000,0000,0000,,Thanks!\N{\i1}applause{\i0}
Dialogue: 0,0:00:42.20,0:00:46.98,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:00:46.98,0:00:49.79,Default,,0000,0000,0000,,Trammel Hudson: So I'm Trammell Hudson\Nwith Two Sigma Investments, and for the
Dialogue: 0,0:00:49.79,0:00:54.31,Default,,0000,0000,0000,,past several years I've been researching\Nfirmware security vulnerabilities
Dialogue: 0,0:00:54.31,0:00:59.42,Default,,0000,0000,0000,,and looked at how they affect systems.\NTwo years ago, I presented my work
Dialogue: 0,0:00:59.42,0:01:05.03,Default,,0000,0000,0000,,on Thunderstrike here at CCC. And this was\Nthe first firmware attack against MacBooks
Dialogue: 0,0:01:05.03,0:01:09.25,Default,,0000,0000,0000,,that allowed an attacker to override\Nthe motherboard bootrom.
Dialogue: 0,0:01:09.25,0:01:14.31,Default,,0000,0000,0000,,The year after that, I collaborated with\NXeno Kovah and Corey Kallenberg
Dialogue: 0,0:01:14.31,0:01:19.20,Default,,0000,0000,0000,,from LegbaCore - both of whom\Nare now at Apple, doing firmware work.
Dialogue: 0,0:01:19.20,0:01:24.99,Default,,0000,0000,0000,,And we ported a bunch of Windows UEFI\Nvulnerabilities over to the Mac, and
Dialogue: 0,0:01:24.99,0:01:29.64,Default,,0000,0000,0000,,showed that the software platform - the\NUEFI software platform, you know - allowed
Dialogue: 0,0:01:29.64,0:01:35.66,Default,,0000,0000,0000,,very portable attacks to be done. This\Nalso allowed a remote attacker with code
Dialogue: 0,0:01:35.66,0:01:41.69,Default,,0000,0000,0000,,execution on your machine to override the\Nmotherboard bootrom. But, more than just
Dialogue: 0,0:01:41.69,0:01:46.53,Default,,0000,0000,0000,,breaking things, what we like to do is\Ntake the things apart and understand how
Dialogue: 0,0:01:46.53,0:01:51.36,Default,,0000,0000,0000,,they work and document them, so that other\Npeople can build systems on top of them.
Dialogue: 0,0:01:51.36,0:01:55.37,Default,,0000,0000,0000,,And that's why I'm really excited to be\Ntalking to you all about my project
Dialogue: 0,0:01:55.37,0:02:00.63,Default,,0000,0000,0000,,"Heads", which is a open source\Nfirmware and boot loader
Dialogue: 0,0:02:00.63,0:02:06.43,Default,,0000,0000,0000,,for laptops and servers.\NThe name is kind of a play
Dialogue: 0,0:02:06.43,0:02:11.24,Default,,0000,0000,0000,,on the popular 'Tails' distribution\Nwhich is a stateless Linux
Dialogue: 0,0:02:11.24,0:02:15.07,Default,,0000,0000,0000,,for when you don't want to leave any traces\Nof what you're doing on your machine.
Dialogue: 0,0:02:15.07,0:02:18.68,Default,,0000,0000,0000,,Heads is for the opposite case: it's where\Nyou want to be able to trust the machine,
Dialogue: 0,0:02:18.68,0:02:23.57,Default,,0000,0000,0000,,and you want to be able to trust that the\Ndata you store on the machine is safe
Dialogue: 0,0:02:23.57,0:02:28.64,Default,,0000,0000,0000,,and unmodified. And, let's back up\Nfor a quick minute and just talk about
Dialogue: 0,0:02:28.64,0:02:34.38,Default,,0000,0000,0000,,why firmware security is so important,\Nthat this is the code that is
Dialogue: 0,0:02:34.38,0:02:39.49,Default,,0000,0000,0000,,executed by the CPU when it comes out of\Nreset. This is the first instruction that
Dialogue: 0,0:02:39.49,0:02:43.84,Default,,0000,0000,0000,,the CPU executes. And so it's in a really\Nprivileged position to be able to
Dialogue: 0,0:02:43.84,0:02:50.68,Default,,0000,0000,0000,,circumvent any sort of OS or other\Npolicies. And there's no shortage of talks
Dialogue: 0,0:02:50.68,0:02:55.82,Default,,0000,0000,0000,,that you can watch on interesting\Nattack vectors using firmware-based
Dialogue: 0,0:02:55.82,0:03:01.30,Default,,0000,0000,0000,,malware. One that I really liked\Nwas last year at DEFCON. The
Dialogue: 0,0:03:01.30,0:03:06.05,Default,,0000,0000,0000,,Intel Advanced Threat Research\Npresented an attack that showed
Dialogue: 0,0:03:06.05,0:03:11.83,Default,,0000,0000,0000,,how firmware could - malicious firmware -\Ncould circumvent the hypervisors. They
Dialogue: 0,0:03:11.83,0:03:17.92,Default,,0000,0000,0000,,then went further and showed how buggy\Nfirmware allowed a unprivileged guest
Dialogue: 0,0:03:17.92,0:03:25.20,Default,,0000,0000,0000,,inside a virtual machine to escalate into\Nprivileges inside the hypervisor. And for
Dialogue: 0,0:03:25.20,0:03:29.75,Default,,0000,0000,0000,,that reason, it's really important that\Nfirmware vulnerabilities and firmware bugs
Dialogue: 0,0:03:29.75,0:03:36.37,Default,,0000,0000,0000,,have a way to get patched. These aren't\Njust theoretical research vulnerabilities,
Dialogue: 0,0:03:36.37,0:03:41.42,Default,,0000,0000,0000,,either. We know that there are malicious\Norganizations and hacking groups that are
Dialogue: 0,0:03:41.42,0:03:48.27,Default,,0000,0000,0000,,selling firmware rootkits to whoever will\Npay - including nation-state adversaries,
Dialogue: 0,0:03:48.27,0:03:55.59,Default,,0000,0000,0000,,that are using them for their persistent\Nthreats. And they are very persistent,
Dialogue: 0,0:03:55.59,0:04:00.56,Default,,0000,0000,0000,,because they are in the motherboard\Nbootrom So you've reinstalled the OS -
Dialogue: 0,0:04:00.56,0:04:06.96,Default,,0000,0000,0000,,they're still there, you swap out the hard\Ndrive - they're still there. And some
Dialogue: 0,0:04:06.96,0:04:14.89,Default,,0000,0000,0000,,vendors are even bundling these rootkits\Ninto their official ROMs. That they are
Dialogue: 0,0:04:14.89,0:04:22.02,Default,,0000,0000,0000,,using them to install the bloatware, or\Nwhatever adware they want to put into the
Dialogue: 0,0:04:22.02,0:04:28.19,Default,,0000,0000,0000,,OS. So even after you reinstall a clean\Nversion of the OS, this particular vendors
Dialogue: 0,0:04:28.19,0:04:34.84,Default,,0000,0000,0000,,system would install its own additions.\NSome of those had vulnerabilities that
Dialogue: 0,0:04:34.84,0:04:41.14,Default,,0000,0000,0000,,could then be exploited by attackers. This\Nparticular case, the vendor received
Dialogue: 0,0:04:41.14,0:04:46.45,Default,,0000,0000,0000,,enough bad press, that they released a\Nfirmware update that patched this
Dialogue: 0,0:04:46.45,0:04:50.92,Default,,0000,0000,0000,,vulnerability. And they had to do that.\NThis wasn't something that the users could
Dialogue: 0,0:04:50.92,0:04:55.69,Default,,0000,0000,0000,,do on their own - they couldn't update the\Nthe firmware in their machine the
Dialogue: 0,0:04:55.69,0:05:02.39,Default,,0000,0000,0000,,way they do with their operating system or\Nan application. And in fact, most firmware
Dialogue: 0,0:05:02.39,0:05:08.78,Default,,0000,0000,0000,,vulnerabilities never see patches get\Ndeployed out to the end-user.
Dialogue: 0,0:05:08.78,0:05:15.50,Default,,0000,0000,0000,,Part of the reason for that is that the\Nthe firmware is usually four or five
Dialogue: 0,0:05:15.50,0:05:21.70,Default,,0000,0000,0000,,companies, removed from the end-user. That\Nthere's the open source reference
Dialogue: 0,0:05:21.70,0:05:28.10,Default,,0000,0000,0000,,implementation from Intel, called eh\NTianoCore or EDK II. When vulnerabilities
Dialogue: 0,0:05:28.10,0:05:33.69,Default,,0000,0000,0000,,are patched in there, they have to get\Npulled by the independent BIOS vendor, and
Dialogue: 0,0:05:33.69,0:05:39.50,Default,,0000,0000,0000,,merged into the IBV tree, and then the\NBIOS vendor sells that to the device
Dialogue: 0,0:05:39.50,0:05:44.71,Default,,0000,0000,0000,,manufacturers. So they have to package up\Na release the thing gets pulled by the
Dialogue: 0,0:05:44.71,0:05:49.39,Default,,0000,0000,0000,,device manufacturer. It has to get QA'd it\Nagainst however many motherboards they
Dialogue: 0,0:05:49.39,0:05:55.55,Default,,0000,0000,0000,,want to test it on. And then it has to get\Nagain pulled by the original equipment
Dialogue: 0,0:05:55.55,0:06:00.83,Default,,0000,0000,0000,,manufacturer to get rebranded and whatever\Nvalue they want to add. And then sometimes
Dialogue: 0,0:06:00.83,0:06:05.48,Default,,0000,0000,0000,,it has to go through the operating system\Nvendor to even make it out to the end-
Dialogue: 0,0:06:05.48,0:06:10.40,Default,,0000,0000,0000,,user. And as a result of this, most of the\Ntime, products do not receive any updates
Dialogue: 0,0:06:10.40,0:06:15.41,Default,,0000,0000,0000,,after they've been sold. There's one\Nexception: in this chart you can see that
Dialogue: 0,0:06:15.41,0:06:21.25,Default,,0000,0000,0000,,Apple builds their own firmware, and in my\Nwork with them, I've been really pleased
Dialogue: 0,0:06:21.25,0:06:26.18,Default,,0000,0000,0000,,that they've rolled out patches for eight\Nyears of hardware. Which is above and
Dialogue: 0,0:06:26.18,0:06:34.94,Default,,0000,0000,0000,,beyond what any other firmware vendor is\Ndoing right now. When EFI was introduced,
Dialogue: 0,0:06:34.94,0:06:43.60,Default,,0000,0000,0000,,it brought a lot of complexity, and the\NLinux community was very skeptical as to
Dialogue: 0,0:06:43.60,0:06:48.30,Default,,0000,0000,0000,,what the value was going to be provided by\Nall this complexity. It's basically an
Dialogue: 0,0:06:48.30,0:06:54.20,Default,,0000,0000,0000,,entire operating systems worth of code.\NAnd it's not, that the 16-bit real-mode
Dialogue: 0,0:06:54.20,0:07:01.29,Default,,0000,0000,0000,,BIOS was all that much better. In fact, it\Nhad its own set of issues. But it was
Dialogue: 0,0:07:01.29,0:07:08.59,Default,,0000,0000,0000,,small, it was simple, it did one thing, it\Ndid it okay. And it took a long time for
Dialogue: 0,0:07:08.59,0:07:15.26,Default,,0000,0000,0000,,UEFI to even become widely supported. But\Neven now most systems ship with both the
Dialogue: 0,0:07:15.26,0:07:19.100,Default,,0000,0000,0000,,UEFI and a BIOS compatibility module. So\Nthey've basically doubled their attack
Dialogue: 0,0:07:19.100,0:07:25.37,Default,,0000,0000,0000,,surface for potential bugs and\Nvulnerabilities. So the state of the
Dialogue: 0,0:07:25.37,0:07:33.11,Default,,0000,0000,0000,,firmware world today is that updates are\Nrare, patches, if they ever come out, take
Dialogue: 0,0:07:33.11,0:07:35.60,Default,,0000,0000,0000,,a long time to make it through the\Nprocess.
Dialogue: 0,0:07:35.60,0:07:41.45,Default,,0000,0000,0000,,Users can't fix things on their own, and\Nwe can't see what's inside, since most of
Dialogue: 0,0:07:41.45,0:07:45.34,Default,,0000,0000,0000,,them are built with closed source\Ncomponents - and that's not a great state
Dialogue: 0,0:07:45.34,0:07:52.65,Default,,0000,0000,0000,,for something that is as privileged as a\Nfirmware. So it's my belief, that firmware
Dialogue: 0,0:07:52.65,0:07:57.05,Default,,0000,0000,0000,,needs to be built with open source. It\Nmust be flexible, so we can adapt it to
Dialogue: 0,0:07:57.05,0:08:02.58,Default,,0000,0000,0000,,our needs for our systems. It needs to be\Nbuilt with software that we understand and
Dialogue: 0,0:08:02.58,0:08:08.77,Default,,0000,0000,0000,,we use for, in, other applications, so\Nthat it can get widely tested and well
Dialogue: 0,0:08:08.77,0:08:12.87,Default,,0000,0000,0000,,tested. It needs to be built in a\Nreproducible manner, so that we can be
Dialogue: 0,0:08:12.87,0:08:18.33,Default,,0000,0000,0000,,secure against that build chain attacks.\NAnd it needs to be cryptographically
Dialogue: 0,0:08:18.33,0:08:23.19,Default,,0000,0000,0000,,measured, so that we can be sure that\Nthis, what we flash on the system, is what
Dialogue: 0,0:08:23.19,0:08:30.16,Default,,0000,0000,0000,,is actually running on the system. And\Nthat's the philosophy behind Heads - it's
Dialogue: 0,0:08:30.16,0:08:36.43,Default,,0000,0000,0000,,built on the free software coreboot\Nfirmware, plus a Linux kernel in ROM, that
Dialogue: 0,0:08:36.43,0:08:44.96,Default,,0000,0000,0000,,acts as a bootloader, and then a lot of\Nsecurity research and tools, that help us
Dialogue: 0,0:08:44.96,0:08:52.42,Default,,0000,0000,0000,,try to build slightly more secure systems.\NUsing Linux as a bootloader is not a
Dialogue: 0,0:08:52.42,0:08:58.37,Default,,0000,0000,0000,,particularly new idea. Back in the 1990s\Nwhen we started building large scale Linux
Dialogue: 0,0:08:58.37,0:09:07.84,Default,,0000,0000,0000,,clusters, we were very frustrated with the\Ninflexibility of DHCP and PXE booting
Dialogue: 0,0:09:07.84,0:09:13.23,Default,,0000,0000,0000,,large machines, that even with those\Nfrustrations, we built one, that was about
Dialogue: 0,0:09:13.23,0:09:21.06,Default,,0000,0000,0000,,the 30th fastest in the world on the top\N500. Meanwhile, my colleague Ron Minich at
Dialogue: 0,0:09:21.06,0:09:25.96,Default,,0000,0000,0000,,Los Alamos was also building large\Nclusters, and had the observation that the
Dialogue: 0,0:09:25.96,0:09:33.49,Default,,0000,0000,0000,,BIOS enumerates all the buses, initializes\Na bunch of devices, finds the Linux kernel
Dialogue: 0,0:09:33.49,0:09:38.68,Default,,0000,0000,0000,,and in the Linux kernel, enumerates all\Nthe buses, initializes all the devices,
Dialogue: 0,0:09:38.68,0:09:43.64,Default,,0000,0000,0000,,and he thought: "This is this is silly,\Nwhy are we doing this twice?".
Dialogue: 0,0:09:43.64,0:09:49.73,Default,,0000,0000,0000,,So he had the idea to build a version of\NLinux, that ran in the ROM. He called this
Dialogue: 0,0:09:49.73,0:09:56.46,Default,,0000,0000,0000,,project "Linux BIOS" and it went on to\Npower the MRC cluster, which was the third
Dialogue: 0,0:09:56.46,0:10:04.85,Default,,0000,0000,0000,,fastest machine in the world in 2003. In\N2008 Linux BIOS underwent a major
Dialogue: 0,0:10:04.85,0:10:10.10,Default,,0000,0000,0000,,refactoring and it was renamed to\N"Coreboot". And Google chose to use
Dialogue: 0,0:10:10.10,0:10:14.69,Default,,0000,0000,0000,,Coreboot as the firmware on their\NChromebooks - which are at this point the
Dialogue: 0,0:10:14.69,0:10:24.19,Default,,0000,0000,0000,,only non-UEFI x86-based laptops that you\Ncan buy. And they've done some really some
Dialogue: 0,0:10:24.19,0:10:28.28,Default,,0000,0000,0000,,great work in trying to lock down the\Nconfiguration and the firmware on the
Dialogue: 0,0:10:28.28,0:10:35.78,Default,,0000,0000,0000,,Chromebooks. Ron, who has only moved to\NGoogle in 2011 and is continuing to work
Dialogue: 0,0:10:35.78,0:10:47.35,Default,,0000,0000,0000,,on the Coreboot project there. So Coreboot\Nhas three stages that it goes through as
Dialogue: 0,0:10:47.35,0:10:53.82,Default,,0000,0000,0000,,it starts up the machine: the first one is\Na very small amount of real-mode assembly,
Dialogue: 0,0:10:53.82,0:11:00.70,Default,,0000,0000,0000,,because your modern 64-bit laptop still\Nboots up in real mode with 16-bit just
Dialogue: 0,0:11:00.70,0:11:08.39,Default,,0000,0000,0000,,like its 1970's. So that's a very small\Namount of code - about 1.5K. That in turn
Dialogue: 0,0:11:08.39,0:11:14.17,Default,,0000,0000,0000,,sets up a C runtime environment with\Nwhat's called "Cache-as-RAM mode" and it
Dialogue: 0,0:11:14.17,0:11:20.33,Default,,0000,0000,0000,,calls into the ROM stage which is about\N70K. "Heads" has moved the TPM
Dialogue: 0,0:11:20.33,0:11:26.80,Default,,0000,0000,0000,,initialization early in the ROM stage\Nbefore DRAM is set up to help measure the
Dialogue: 0,0:11:26.80,0:11:33.07,Default,,0000,0000,0000,,boot block and provide a static route of\Ntrust that's hopefully a little bit more
Dialogue: 0,0:11:33.07,0:11:38.28,Default,,0000,0000,0000,,secure. And because that measurement is\Ndone early on, our trusted computing base
Dialogue: 0,0:11:38.28,0:11:44.66,Default,,0000,0000,0000,,is actually quite small. This is a\Nfraction of 1% of the size of a UEFI
Dialogue: 0,0:11:44.66,0:11:50.34,Default,,0000,0000,0000,,firmware, which is usually about 16 MB\Nonce it's uncompressed.
Dialogue: 0,0:11:50.34,0:11:55.73,Default,,0000,0000,0000,,The ROM stage then measures and executes\Nthe RAM stage, which does the more
Dialogue: 0,0:11:55.73,0:12:01.12,Default,,0000,0000,0000,,traditional "walk the bus, find / figure\Nout what devices are on there", but it
Dialogue: 0,0:12:01.12,0:12:04.27,Default,,0000,0000,0000,,doesn't initialize them: it just\Nenumerates them and generates the
Dialogue: 0,0:12:04.27,0:12:09.32,Default,,0000,0000,0000,,descriptors for Linux. It also installs\Nthe SMM handler for system management
Dialogue: 0,0:12:09.32,0:12:16.71,Default,,0000,0000,0000,,mode. It then measures and jumps into the\Npayload - and that whole process takes
Dialogue: 0,0:12:16.71,0:12:23.67,Default,,0000,0000,0000,,less than a second. So it is able to get\Ninto the payload and actually get to the
Dialogue: 0,0:12:23.67,0:12:30.73,Default,,0000,0000,0000,,user code very, very quickly. On something\Nlike the X230 it's able to go from power
Dialogue: 0,0:12:30.73,0:12:36.72,Default,,0000,0000,0000,,on to a interactive recovery shell in less\Nthan 2 seconds. And that includes bring up
Dialogue: 0,0:12:36.72,0:12:42.56,Default,,0000,0000,0000,,the TPM, doing cryptographic measurements\Nand assessing the state of the system.
Dialogue: 0,0:12:42.56,0:12:46.79,Default,,0000,0000,0000,,Because we now have Linux at this point,\Nwe have all the flexibility that comes
Dialogue: 0,0:12:46.79,0:12:53.55,Default,,0000,0000,0000,,with that. We can implement boot scripts\Nwith the full power of the shell or the C
Dialogue: 0,0:12:53.55,0:12:57.60,Default,,0000,0000,0000,,language runtime:\Nwe're not stuck with the limited functions
Dialogue: 0,0:12:57.60,0:13:02.89,Default,,0000,0000,0000,,of UEFI. Linux supports lots of different\Nfile systems. It supports lots of
Dialogue: 0,0:13:02.89,0:13:07.14,Default,,0000,0000,0000,,different devices. It supports lots of\Ndifferent encryption methods. And this
Dialogue: 0,0:13:07.14,0:13:12.83,Default,,0000,0000,0000,,gives us the ability to use any of them\Nfor your specific application. In
Dialogue: 0,0:13:12.83,0:13:19.85,Default,,0000,0000,0000,,contrast, UEFI, which supports unencrypted\NFAT file systems on the first drive that
Dialogue: 0,0:13:19.85,0:13:23.59,Default,,0000,0000,0000,,have to be in the first 1 GiB or\Nsomething, it's really, really limited as
Dialogue: 0,0:13:23.59,0:13:31.81,Default,,0000,0000,0000,,to how it can find its boot device.\NThere's a saying in the in the Open Source
Dialogue: 0,0:13:31.81,0:13:35.89,Default,,0000,0000,0000,,community that with enough eyes all bugs\Nare shallow.
Dialogue: 0,0:13:35.89,0:13:42.61,Default,,0000,0000,0000,,And Linux has a lot more eyes looking at\Nit. That the device drivers and the file
Dialogue: 0,0:13:42.61,0:13:50.25,Default,,0000,0000,0000,,systems and the encryption have been\Nreviewed by both white hat and black hat
Dialogue: 0,0:13:50.25,0:13:56.71,Default,,0000,0000,0000,,people around the world. The UEFI versions\Nof these do not have that same level of
Dialogue: 0,0:13:56.71,0:14:03.16,Default,,0000,0000,0000,,scrutiny, so we're using both the UEFI\Ndrivers and then having to run whatever on
Dialogue: 0,0:14:03.16,0:14:08.08,Default,,0000,0000,0000,,top of it, increases the attack surface.\NBut by putting Linux in the ROM and
Dialogue: 0,0:14:08.08,0:14:15.48,Default,,0000,0000,0000,,depending on its drivers we've reduced our\Nattack surface very dramatically. More
Dialogue: 0,0:14:15.48,0:14:21.24,Default,,0000,0000,0000,,importantly though, Coreboot and Linux are\NOpen Source, so it is possible to build
Dialogue: 0,0:14:21.24,0:14:25.48,Default,,0000,0000,0000,,custom versions for the device drivers\Nthat you need, for the file systems that
Dialogue: 0,0:14:25.48,0:14:30.84,Default,,0000,0000,0000,,you need. It's possible to fix bugs when\Nthey come out, and sign and install your
Dialogue: 0,0:14:30.84,0:14:37.09,Default,,0000,0000,0000,,own kernels. You don't have to wait for\Nthe vendor to get around to doing it.
Dialogue: 0,0:14:37.09,0:14:44.89,Default,,0000,0000,0000,,And the third major component of heads is\Na tool called "kexec", which is a system
Dialogue: 0,0:14:44.89,0:14:50.27,Default,,0000,0000,0000,,call that was added for the Linux BIOS\Nproject back in 2003 by Eric Peterman,
Dialogue: 0,0:14:50.27,0:14:56.23,Default,,0000,0000,0000,,that allows a running kernel to do a\Ngraceful shutdown and start a new kernel
Dialogue: 0,0:14:56.23,0:15:01.06,Default,,0000,0000,0000,,without having to go through the reboot\Nprocess. So this allowed, on their
Dialogue: 0,0:15:01.06,0:15:06.51,Default,,0000,0000,0000,,application, it allowed them to do very\Nfast reboots of their cluster nodes. And
Dialogue: 0,0:15:06.51,0:15:11.94,Default,,0000,0000,0000,,in the "Heads" case, it allows us to act\Nas a bootloader where we can find the real
Dialogue: 0,0:15:11.94,0:15:16.15,Default,,0000,0000,0000,,kernel, that you want to run, and exec it.\NBecause "Heads" is quite small. It has to
Dialogue: 0,0:15:16.15,0:15:22.69,Default,,0000,0000,0000,,fit in 4 MB of ROM. So it's not something\Nthat you learn to run as a day-to-day sort
Dialogue: 0,0:15:22.69,0:15:31.23,Default,,0000,0000,0000,,of OS. Hopefully this won't explode on me\Nagain.
Dialogue: 0,0:15:36.27,0:15:40.80,Default,,0000,0000,0000,,Because we have the Bourne Shell, most of\Nthe policies and the startup scripts in
Dialogue: 0,0:15:40.80,0:15:47.78,Default,,0000,0000,0000,,"Heads" are implemented as as shell\Nscripts. In this case we were able to pass
Dialogue: 0,0:15:47.78,0:15:52.94,Default,,0000,0000,0000,,in a new set of command line parameters, a\Nnew initial RAM disk, and in this case we
Dialogue: 0,0:15:52.94,0:15:58.62,Default,,0000,0000,0000,,can even start a hypervisor. And all of\Nthat can happen very very quickly, as well
Dialogue: 0,0:15:58.62,0:16:07.27,Default,,0000,0000,0000,,as with with a good degree of security.\NSo, those are the building blocks that
Dialogue: 0,0:16:07.27,0:16:12.98,Default,,0000,0000,0000,,"Heads" is built on: Coreboot, Linux and\Ntools like "kexec". But it now gives us a
Dialogue: 0,0:16:12.98,0:16:16.71,Default,,0000,0000,0000,,really nice platform to begin\Nexperimenting with additional security
Dialogue: 0,0:16:16.71,0:16:23.24,Default,,0000,0000,0000,,features. And before we go too deep down\Nthe rabbit hole of, you know, security and
Dialogue: 0,0:16:23.24,0:16:27.51,Default,,0000,0000,0000,,threat models, I want to quote my friend\NSteph, who said that, "Your threat model
Dialogue: 0,0:16:27.51,0:16:31.02,Default,,0000,0000,0000,,is not my threat model."\NBut you know your threat model is okay as
Dialogue: 0,0:16:31.02,0:16:35.73,Default,,0000,0000,0000,,well, that we all have different things we\Nwant to protect, from different attackers,
Dialogue: 0,0:16:35.73,0:16:40.39,Default,,0000,0000,0000,,who are willing to spend different amounts\Nof effort to go after them. And the nice
Dialogue: 0,0:16:40.39,0:16:46.13,Default,,0000,0000,0000,,thing about having an open source is: We\Ncan build systems tailored to your
Dialogue: 0,0:16:46.13,0:16:50.93,Default,,0000,0000,0000,,individual threat model. So a lot of these\Nthings may not actually apply to your
Dialogue: 0,0:16:50.93,0:16:59.06,Default,,0000,0000,0000,,specific threats, but the fact that we can\Nbuild them is a great capability. Last
Dialogue: 0,0:16:59.06,0:17:05.99,Default,,0000,0000,0000,,year Joanna Rutkowska reminded us that\Nfirmware is not just in our CPU. Firmware
Dialogue: 0,0:17:05.99,0:17:12.81,Default,,0000,0000,0000,,is in our Wi-Fi card. It is in our GPU. It\Nis in our SSD. It is in our keyboards. And
Dialogue: 0,0:17:12.81,0:17:19.19,Default,,0000,0000,0000,,all of these devices might be trying to\Nsubvert the boot process.
Dialogue: 0,0:17:19.19,0:17:25.50,Default,,0000,0000,0000,,One way to handle that is to take Peter\NStuge's advice of disassembling the
Dialogue: 0,0:17:25.50,0:17:30.40,Default,,0000,0000,0000,,machine and ripping out anything we can't\Ncontrol. If this is your threat model, his
Dialogue: 0,0:17:30.40,0:17:35.09,Default,,0000,0000,0000,,instructions are really worth following.\NThey're really thorough about what pieces
Dialogue: 0,0:17:35.09,0:17:41.07,Default,,0000,0000,0000,,are potentially of concern. And you're\Ngoing, right now, you'll have to open up
Dialogue: 0,0:17:41.07,0:17:46.56,Default,,0000,0000,0000,,your laptop to install "Heads." It's not\Nquite as easy as it is to install most
Dialogue: 0,0:17:46.56,0:17:52.66,Default,,0000,0000,0000,,Linux distributions, because we have to\Nflash it into the motherboard boot ROM.
Dialogue: 0,0:17:52.66,0:17:56.66,Default,,0000,0000,0000,,While we're in there, now, we take\Nadvantage of some features that, to the
Dialogue: 0,0:17:56.66,0:18:02.28,Default,,0000,0000,0000,,best of my knowledge, no UEFI system is\Nusing. These flash chips have a hardware
Dialogue: 0,0:18:02.28,0:18:09.61,Default,,0000,0000,0000,,write-protect mode, where you can specify\Npart of the chip is write-only. Excuse me.
Dialogue: 0,0:18:09.61,0:18:15.48,Default,,0000,0000,0000,,Is read-only, write-once. And this gives\Nus our immutable boot block in which to
Dialogue: 0,0:18:15.48,0:18:20.34,Default,,0000,0000,0000,,store the trusted computing base, the TCB,\Nso that we can measure the rest of the
Dialogue: 0,0:18:20.34,0:18:26.27,Default,,0000,0000,0000,,system. We also then suggest disconnecting\Nthe write-protect PIN from the
Dialogue: 0,0:18:26.27,0:18:32.94,Default,,0000,0000,0000,,motherboard, which protects against\Ncertain classes of attacks, like the Intel
Dialogue: 0,0:18:32.94,0:18:38.90,Default,,0000,0000,0000,,close chassis adapter, that allows\Nexternal JTAG of the CPU.
Dialogue: 0,0:18:38.90,0:18:42.44,Default,,0000,0000,0000,,Depending on your threat model you might\Nwant to cover that chip in epoxy as well,
Dialogue: 0,0:18:42.44,0:18:48.50,Default,,0000,0000,0000,,to frustrate Evil Maid attacks that want\Nto do a physical programming on it.
Dialogue: 0,0:18:48.50,0:18:53.49,Default,,0000,0000,0000,,Disconnecting the write-protect PIN also\Nserves to protect from other devices on
Dialogue: 0,0:18:53.49,0:18:58.89,Default,,0000,0000,0000,,the machine that have access to those\NPINs. Devices like the Management Engine,
Dialogue: 0,0:18:58.89,0:19:08.63,Default,,0000,0000,0000,,which is a really scary CPU inside the\NCPU. Rudolf Marek two years ago at CCC
Dialogue: 0,0:19:08.63,0:19:17.61,Default,,0000,0000,0000,,called it the "Matroyshka CPU".\NAnd Igor Skochinsky detailed what are the
Dialogue: 0,0:19:17.61,0:19:23.55,Default,,0000,0000,0000,,capabilities of the management engine. And\Nthey're really worrisome, that it runs a
Dialogue: 0,0:19:23.55,0:19:31.06,Default,,0000,0000,0000,,opaque obfuscated blob of code about 5 MiB\Nthat the CPU can't see. The management
Dialogue: 0,0:19:31.06,0:19:35.98,Default,,0000,0000,0000,,engine can read and write all of main\Nmemory. It can read from the keyboard and
Dialogue: 0,0:19:35.98,0:19:42.06,Default,,0000,0000,0000,,video. It can receive Java bytecodes over\Nthe network and execute them on behalf of
Dialogue: 0,0:19:42.06,0:19:46.51,Default,,0000,0000,0000,,someone outside the machine. And it's\Nlistening on the network even when the
Dialogue: 0,0:19:46.51,0:19:51.53,Default,,0000,0000,0000,,system is powered off.\NSo this is basically a rootkit inside the
Dialogue: 0,0:19:51.53,0:19:58.48,Default,,0000,0000,0000,,chipset, as some folks have called it. So\Nthat concerned me a lot, and I spent some
Dialogue: 0,0:19:58.48,0:20:03.50,Default,,0000,0000,0000,,time looking at how its firmware images\Nare built, and realized that we can build
Dialogue: 0,0:20:03.50,0:20:10.06,Default,,0000,0000,0000,,modified, reduced functionality firmware\Nfor it that removes all of the rootkit
Dialogue: 0,0:20:10.06,0:20:16.15,Default,,0000,0000,0000,,functions, and just leaves the "CPU bring\Nup" module. This takes that 5 MiB and
Dialogue: 0,0:20:16.15,0:20:23.72,Default,,0000,0000,0000,,shrinks it down to about about 40 KiB of\Nspace. So we don't know exactly what it's
Dialogue: 0,0:20:23.72,0:20:28.46,Default,,0000,0000,0000,,doing in that 40 KiB, but we at least know\Nit doesn't have a device driver, or a Java
Dialogue: 0,0:20:28.46,0:20:31.72,Default,,0000,0000,0000,,Virtual Machine, or a lot of the other\Nfunctions.
Dialogue: 0,0:20:31.72,0:20:37.71,Default,,0000,0000,0000,,And we've successfully done this on both\NSandy Bridge and Ivy Bridge like the X230
Dialogue: 0,0:20:37.71,0:20:43.38,Default,,0000,0000,0000,,ThinkPads as well as modern Skylake CPUs\Nlike the Chell Chromebook. And that's
Dialogue: 0,0:20:43.38,0:20:47.81,Default,,0000,0000,0000,,really encouraging, that if we can apply\Nthis to more modern hardware, that allows
Dialogue: 0,0:20:47.81,0:20:53.57,Default,,0000,0000,0000,,us to, you know, move away from our five-\Nyear-old ThinkPads to something a little
Dialogue: 0,0:20:53.57,0:21:01.58,Default,,0000,0000,0000,,shinier. The management engine isn't the\Nonly device that might be trying subvert
Dialogue: 0,0:21:01.58,0:21:05.80,Default,,0000,0000,0000,,the boot process. Again Johanna showed us\Nthere are lots of things to be worried
Dialogue: 0,0:21:05.80,0:21:12.16,Default,,0000,0000,0000,,about. Intel's UEFI architects, Yao and\NZimmer, recommend that firmware turn on
Dialogue: 0,0:21:12.16,0:21:19.63,Default,,0000,0000,0000,,the IOMMU, now called VTD, to protect\Nagainst rogue devices. To the best of my
Dialogue: 0,0:21:19.63,0:21:24.41,Default,,0000,0000,0000,,knowledge, since they've written this\Nguide, no UEFI firmware is taking
Dialogue: 0,0:21:24.41,0:21:29.20,Default,,0000,0000,0000,,advantage of the IOMMU. So, it's a great\Npiece of hardware to have, but it doesn't
Dialogue: 0,0:21:29.20,0:21:35.72,Default,,0000,0000,0000,,help if you don't turn it on. Linux,\Nmeanwhile has no problem taking advantage
Dialogue: 0,0:21:35.72,0:21:40.22,Default,,0000,0000,0000,,of it, so we use it, what we get\Nessentially - we get that DMA protection
Dialogue: 0,0:21:40.22,0:21:48.12,Default,,0000,0000,0000,,for free by using Linux as our bootloader\Nin the ROM. Another way devices, rogue
Dialogue: 0,0:21:48.12,0:21:52.36,Default,,0000,0000,0000,,devices, can try to interfere with the\Nboot process is by providing option ROMs,
Dialogue: 0,0:21:52.36,0:21:59.17,Default,,0000,0000,0000,,which are executable code to be run by the\NBIOS, that have a sort of a device driver.
Dialogue: 0,0:21:59.17,0:22:03.63,Default,,0000,0000,0000,,And this code can do things like about log\Nkeystrokes and then try to exfiltrate
Dialogue: 0,0:22:03.63,0:22:11.91,Default,,0000,0000,0000,,passwords as we see here. That problem was\Ninitially reported in 2007 by John Heasman
Dialogue: 0,0:22:11.91,0:22:18.92,Default,,0000,0000,0000,,at BlackHat, again by Snare in 2012, and\Nagain by my work on Thunderstrike. And as
Dialogue: 0,0:22:18.92,0:22:24.29,Default,,0000,0000,0000,,of last week a official fix has finally\Nrolled out for it to close that particular
Dialogue: 0,0:22:24.29,0:22:29.95,Default,,0000,0000,0000,,vulnerability.\NFolks who are using coreboot have this as
Dialogue: 0,0:22:29.95,0:22:35.60,Default,,0000,0000,0000,,a option that they can say, this, I am\Nconcerned about this threat, let me let me
Dialogue: 0,0:22:35.60,0:22:40.47,Default,,0000,0000,0000,,fix this, let me disable this function.\NAnd they point out that it might cause
Dialogue: 0,0:22:40.47,0:22:45.99,Default,,0000,0000,0000,,degraded functionality, but that's\Nsomething you can QA on your own system.
Dialogue: 0,0:22:45.99,0:22:51.24,Default,,0000,0000,0000,,And in practice with Linux as your\Nbootloader in the ROM, you don't use the
Dialogue: 0,0:22:51.24,0:22:56.61,Default,,0000,0000,0000,,option ROMs for anything. Everything is\Ndone with with Linux's own device drivers,
Dialogue: 0,0:22:56.61,0:23:02.75,Default,,0000,0000,0000,,so you're not dependent on the whatever\Nlimited functionality the option ROM
Dialogue: 0,0:23:02.75,0:23:07.83,Default,,0000,0000,0000,,provided.\NSo, now that we have we've taken our
Dialogue: 0,0:23:07.83,0:23:12.22,Default,,0000,0000,0000,,building blocks and we hopefully have\Nprotected the boot process, and hopefully
Dialogue: 0,0:23:12.22,0:23:16.66,Default,,0000,0000,0000,,the code that's running is what we think\Nit is, we need to turn to how do we secure
Dialogue: 0,0:23:16.66,0:23:22.78,Default,,0000,0000,0000,,the secrets on the machine. And I'm a huge\Nfan of the TPM, the Trusted Platform
Dialogue: 0,0:23:22.78,0:23:28.59,Default,,0000,0000,0000,,Module, now I know in the free software\Ncommunity it's been largely unwelcome. It
Dialogue: 0,0:23:28.59,0:23:34.84,Default,,0000,0000,0000,,has not received a very welcome reception,\Nbecause of the way it's been used for DRM
Dialogue: 0,0:23:34.84,0:23:41.53,Default,,0000,0000,0000,,and other other user-hostile things. Since\Nwe control the TPM from the first
Dialogue: 0,0:23:41.53,0:23:47.26,Default,,0000,0000,0000,,instruction in the in the boot block,\Nwe're able to use it in ways that we want
Dialogue: 0,0:23:47.26,0:23:55.14,Default,,0000,0000,0000,,to, so we don't have to enable DRM, but we\Ncan use it to protect our secrets. And the
Dialogue: 0,0:23:55.14,0:23:59.29,Default,,0000,0000,0000,,the way that it does that, is it keeps\Ntrack of what code is executed as the
Dialogue: 0,0:23:59.29,0:24:06.05,Default,,0000,0000,0000,,system boots, and it hashes that code into\Nspecial registers called PCRs. And the
Dialogue: 0,0:24:06.05,0:24:11.23,Default,,0000,0000,0000,,idea is that, you can extend the PCR by\Nhashing the next module of code, and then
Dialogue: 0,0:24:11.23,0:24:17.46,Default,,0000,0000,0000,,hashing that with the previous hash, and\Nthis creates a chain of trust that allows
Dialogue: 0,0:24:17.46,0:24:24.69,Default,,0000,0000,0000,,to say: If these hashes match the expected\Nvalues, only the code, that we want to
Dialogue: 0,0:24:24.69,0:24:34.04,Default,,0000,0000,0000,,have run, has run. And then the TPM will\Nonly decrypt the the disk encryption key
Dialogue: 0,0:24:34.04,0:24:40.26,Default,,0000,0000,0000,,if those PCRs match, which means that the\Ncode that we want to have run, is what has
Dialogue: 0,0:24:40.26,0:24:47.05,Default,,0000,0000,0000,,been executed. This means if someone\Nmanages to overwrite the, the non-write
Dialogue: 0,0:24:47.05,0:24:51.50,Default,,0000,0000,0000,,protected part of the ROM, that would\Nchange those measurements and the TPM
Dialogue: 0,0:24:51.50,0:24:59.02,Default,,0000,0000,0000,,won't reveal the key to them. It also\Ntakes a user password and that password is
Dialogue: 0,0:24:59.02,0:25:04.93,Default,,0000,0000,0000,,validated by the TPM hardware itself,\Nwhich gives us hardware rate-limiting on
Dialogue: 0,0:25:04.93,0:25:10.85,Default,,0000,0000,0000,,how often an attacker can try. It also\Ngives us the ability to do hardware-based
Dialogue: 0,0:25:10.85,0:25:15.82,Default,,0000,0000,0000,,retry limits, so that the TPM will flush\Nthe key, if they if an attacker in
Dialogue: 0,0:25:15.82,0:25:21.98,Default,,0000,0000,0000,,possession of your machine tries too long.\NThat does mean there's now another way to
Dialogue: 0,0:25:21.98,0:25:27.30,Default,,0000,0000,0000,,lose your disk encryption key.\NAnd there's the the old joke about there
Dialogue: 0,0:25:27.30,0:25:31.15,Default,,0000,0000,0000,,are two types of people with encrypted\Ndrives - those who have lost data due to
Dialogue: 0,0:25:31.15,0:25:36.75,Default,,0000,0000,0000,,forgetting their key, and and those who\Nwill. So what "Heads" does, when you
Dialogue: 0,0:25:36.75,0:25:41.81,Default,,0000,0000,0000,,generate your key, is, it takes that key\Nand splits it into multiple pieces, that
Dialogue: 0,0:25:41.81,0:25:46.79,Default,,0000,0000,0000,,you can then share either to friends or to\Nbackup services, where each piece doesn't
Dialogue: 0,0:25:46.79,0:25:53.03,Default,,0000,0000,0000,,let you decrypt it. But you can combine\Nthem with Shamir secret sharing to
Dialogue: 0,0:25:53.03,0:25:58.17,Default,,0000,0000,0000,,regenerate the cryptographic disk\Nencryption key.
Dialogue: 0,0:25:58.17,0:26:05.02,Default,,0000,0000,0000,,We're also able to take advantage of best\Npractices like using the, including the
Dialogue: 0,0:26:05.02,0:26:11.89,Default,,0000,0000,0000,,disk encryption key headers in the PCRs\Nthat we use to seal the disks. This avoids
Dialogue: 0,0:26:11.89,0:26:15.77,Default,,0000,0000,0000,,a certain class of Evil Maid attack, where\Nsomeone swaps out your drive; may not be
Dialogue: 0,0:26:15.77,0:26:19.10,Default,,0000,0000,0000,,in your threat model, but it is easy to\Ndeal with just a few lines of shell
Dialogue: 0,0:26:19.10,0:26:28.31,Default,,0000,0000,0000,,script. So we hopefully we now trust that\Nthe system is running the code we think it
Dialogue: 0,0:26:28.31,0:26:33.69,Default,,0000,0000,0000,,is, but how does it prove to us that it is\Nactually our machine, that someone hasn't
Dialogue: 0,0:26:33.69,0:26:38.89,Default,,0000,0000,0000,,snuck into our hotel room and swapped out\Neverything and left, left up, carefully
Dialogue: 0,0:26:38.89,0:26:43.54,Default,,0000,0000,0000,,replaced our stickers to make us believe\Nwe're typing our password into to our own
Dialogue: 0,0:26:43.54,0:26:51.93,Default,,0000,0000,0000,,computer. Some anti-Evil Maid toolkits\Nwill encrypt a secret, secret phrase, and
Dialogue: 0,0:26:51.93,0:26:56.42,Default,,0000,0000,0000,,then display it to you if and only if the\NPCR is match, but that's subject to a
Dialogue: 0,0:26:56.42,0:27:03.97,Default,,0000,0000,0000,,replay attack. What Matthew Garrett\Ndemonstrated last year at 32C3, was, using
Dialogue: 0,0:27:03.97,0:27:10.84,Default,,0000,0000,0000,,the time, a time-based one-time password\Nused by Google Authenticator to protect
Dialogue: 0,0:27:10.84,0:27:16.76,Default,,0000,0000,0000,,the firmware and have it attest to the\Nuser, that it is unmodified. So when the
Dialogue: 0,0:27:16.76,0:27:21.71,Default,,0000,0000,0000,,system boots, and it goes through\Nmeasuring all of the various components
Dialogue: 0,0:27:21.71,0:27:29.96,Default,,0000,0000,0000,,the, the TPM will only release the secret\Nif those PCRs match. The firmware then
Dialogue: 0,0:27:29.96,0:27:33.55,Default,,0000,0000,0000,,hashes that along with the current time\Nand generates a six digit value that it
Dialogue: 0,0:27:33.55,0:27:38.52,Default,,0000,0000,0000,,prints on the screen. You compare that to\Nwhat's on your phone and that tells you
Dialogue: 0,0:27:38.52,0:27:46.79,Default,,0000,0000,0000,,whether or not you can trust the machine.\NIt's a, it's a great idea, and it's
Dialogue: 0,0:27:46.79,0:27:51.78,Default,,0000,0000,0000,,implemented again as a very small shell\Nscript to read, read the value from the
Dialogue: 0,0:27:51.78,0:27:58.63,Default,,0000,0000,0000,,TPM, unseal it and then compute the\Nthe hash of it.
Dialogue: 0,0:27:58.63,0:28:04.39,Default,,0000,0000,0000,,This also allows us to start making a\Ntransition from the TPM-rooted, a TPM
Dialogue: 0,0:28:04.39,0:28:10.03,Default,,0000,0000,0000,,static route of trust to a PGP-based\Ntrust, where most importantly, this is a
Dialogue: 0,0:28:10.03,0:28:14.54,Default,,0000,0000,0000,,TPM key - excuse me, this is a PGP key,\Nthat you, the owner of the computer
Dialogue: 0,0:28:14.54,0:28:19.82,Default,,0000,0000,0000,,control, not some random vendor or some\Nrandom hardware device manufacturer that's
Dialogue: 0,0:28:19.82,0:28:25.66,Default,,0000,0000,0000,,going to lose the key and allow malware\Nlike Stuxnet to use it to circumvent
Dialogue: 0,0:28:25.66,0:28:30.94,Default,,0000,0000,0000,,security. The boot script\Nin "Heads", again, it's a
Dialogue: 0,0:28:30.94,0:28:37.20,Default,,0000,0000,0000,,small shell script, is able to use a GPG\Nto verify the next stages of the, the
Dialogue: 0,0:28:37.20,0:28:45.01,Default,,0000,0000,0000,,hypervisor, the initial RAM disk and the\Nkernel. And it also then uses the the
Dialogue: 0,0:28:45.01,0:28:50.82,Default,,0000,0000,0000,,TPM's counters to help prevent against\Nrollback, where someone takes your drive
Dialogue: 0,0:28:50.82,0:28:54.66,Default,,0000,0000,0000,,and rolls it back to a previous version,\Nperhaps with a vulnerability that they can
Dialogue: 0,0:28:54.66,0:28:59.38,Default,,0000,0000,0000,,exploit. So this, this\Nallows the, allows us to be
Dialogue: 0,0:28:59.38,0:29:03.68,Default,,0000,0000,0000,,sure, that not only are we running the\Nfirmware, the OS that we think we should
Dialogue: 0,0:29:03.68,0:29:10.80,Default,,0000,0000,0000,,be running, it ensures us that someone\Nhasn't been able to substitute one that, a
Dialogue: 0,0:29:10.80,0:29:16.70,Default,,0000,0000,0000,,vulnerable version. Having the\NPGP key also allows us to take
Dialogue: 0,0:29:16.70,0:29:24.72,Default,,0000,0000,0000,,advantage of an idea from Android and\NChrome OS which is the the dm-verity read-
Dialogue: 0,0:29:24.72,0:29:31.01,Default,,0000,0000,0000,,only root filesystem - this hashes all of\Nthe blocks and that hashes all of the the
Dialogue: 0,0:29:31.01,0:29:38.32,Default,,0000,0000,0000,,hashes and so on up until it gets to a\Nroot hash in the tree that is then signed.
Dialogue: 0,0:29:38.32,0:29:45.03,Default,,0000,0000,0000,,This allows the kernel, on every read\Naccess, in logarithmic time to verify the
Dialogue: 0,0:29:45.03,0:29:51.58,Default,,0000,0000,0000,,essentially a signature on that data. This\Ndoes require a read-only root filesystem,
Dialogue: 0,0:29:51.58,0:29:59.72,Default,,0000,0000,0000,,but it gives us even more confidence that\Nthe system has been untampered with. Once
Dialogue: 0,0:29:59.72,0:30:05.10,Default,,0000,0000,0000,,you're running your OS, it's good to have\Nyou know some security conscious thoughts
Dialogue: 0,0:30:05.10,0:30:10.99,Default,,0000,0000,0000,,as well, you know. Heads is mostly focused\Non, "how do we securely transition to an
Dialogue: 0,0:30:10.99,0:30:17.53,Default,,0000,0000,0000,,OS" and that OS you run is up to you. I\Nlike Qubes - it's reasonably secure, it's
Dialogue: 0,0:30:17.53,0:30:23.63,Default,,0000,0000,0000,,highly recommended by people who know\Nabout endpoint security. And the Qubes
Dialogue: 0,0:30:23.63,0:30:30.48,Default,,0000,0000,0000,,team recognizes that firmware security is\Na vital piece of system security. For
Dialogue: 0,0:30:30.48,0:30:35.15,Default,,0000,0000,0000,,their next release, Qubes are for -\Nthey're going to require the machines have
Dialogue: 0,0:30:35.15,0:30:39.10,Default,,0000,0000,0000,,open source firmware, such as coreboot.\NAnd I hope that Heads is going to be a
Dialogue: 0,0:30:39.10,0:30:46.33,Default,,0000,0000,0000,,piece of that. I've also been working with\Nwith the Qubes software and have modified
Dialogue: 0,0:30:46.33,0:30:53.00,Default,,0000,0000,0000,,it to work with things like the dm-verity\Nread-only root filesystem. This now allows
Dialogue: 0,0:30:53.00,0:30:58.81,Default,,0000,0000,0000,,the user to lock down the configuration,\Nso that someone can't tamper with their
Dialogue: 0,0:30:58.81,0:31:05.85,Default,,0000,0000,0000,,their setup. It also gives you a recovery\Nmode that allows you to fix things up and
Dialogue: 0,0:31:05.85,0:31:12.14,Default,,0000,0000,0000,,re-sign the OS. Reproducible builds are\Nreally important so that everyone can
Dialogue: 0,0:31:12.14,0:31:19.49,Default,,0000,0000,0000,,verify what that the builds match what\Nthey should. In the case of of Heads we
Dialogue: 0,0:31:19.49,0:31:22.43,Default,,0000,0000,0000,,have a lot of upstream dependencies that\Naren't reproducible so we're working with
Dialogue: 0,0:31:22.43,0:31:28.19,Default,,0000,0000,0000,,them to try to patch them. We've patched\NXen - they've accepted that commit. We've
Dialogue: 0,0:31:28.19,0:31:33.67,Default,,0000,0000,0000,,also built some tools to let you build\Ninitial RAM disks in a reproducible way.
Dialogue: 0,0:31:33.67,0:31:37.39,Default,,0000,0000,0000,,This works with Qubes, with Heads, and\Nwe're hoping to other Linux distributions
Dialogue: 0,0:31:37.39,0:31:41.96,Default,,0000,0000,0000,,pick it up as well.\NAll of our tree is cryptographically
Dialogue: 0,0:31:41.96,0:31:48.23,Default,,0000,0000,0000,,signed, so hopefully GitHub is not trying\Nto slip in any patches. And it is open
Dialogue: 0,0:31:48.23,0:31:52.89,Default,,0000,0000,0000,,source so we encourage anyone to read\Nthrough it. No NDA is required, unlike most
Dialogue: 0,0:31:52.89,0:31:59.57,Default,,0000,0000,0000,,of the UEFI sources. So that's sort of the\Nstate of where things are - it's pretty
Dialogue: 0,0:31:59.57,0:32:04.68,Default,,0000,0000,0000,,much in very beta, but it is usable. But\Nthere are a lot of areas where we could
Dialogue: 0,0:32:04.68,0:32:08.68,Default,,0000,0000,0000,,continue to do research - things like the\Nembedded controllers on Chromebooks are
Dialogue: 0,0:32:08.68,0:32:14.36,Default,,0000,0000,0000,,open source. We can use those to help with\Nour root of trust as well. Porting
Dialogue: 0,0:32:14.36,0:32:17.07,Default,,0000,0000,0000,,coreboot to more modern platforms would\Nlet us take advantage of things like
Dialogue: 0,0:32:17.07,0:32:23.44,Default,,0000,0000,0000,,tamper switches and Intel Boot Guard. I'm\Nalso working on porting coreboot over to
Dialogue: 0,0:32:23.44,0:32:30.03,Default,,0000,0000,0000,,server platforms so that we can use it for\Nmore secure cloud hosting. Servers have a
Dialogue: 0,0:32:30.03,0:32:36.48,Default,,0000,0000,0000,,very different threat model from from\Nlaptops, and a lot of things have firmware
Dialogue: 0,0:32:36.48,0:32:41.09,Default,,0000,0000,0000,,that we have to be concerned about. One\Ncollaboration I'm looking at there is with
Dialogue: 0,0:32:41.09,0:32:45.99,Default,,0000,0000,0000,,the open BMC project to be able to take\Nadvantage of the open source in the
Dialogue: 0,0:32:45.99,0:32:54.16,Default,,0000,0000,0000,,management controller for the servers. And\NI'm also collaborating with the Mass Open
Dialogue: 0,0:32:54.16,0:33:01.13,Default,,0000,0000,0000,,Cloud project that's trying to build\Nsecure bare metal clouds. I'm cautiously
Dialogue: 0,0:33:01.13,0:33:06.59,Default,,0000,0000,0000,,optimistic about enclaves and how they\Nwill help us with the security, especially
Dialogue: 0,0:33:06.59,0:33:10.27,Default,,0000,0000,0000,,in a environment where we control the\Nfirmware and we can ensure that the
Dialogue: 0,0:33:10.27,0:33:17.27,Default,,0000,0000,0000,,enclaves are set up in a safe way. There\Nare a lot of issues on GitHub, again,
Dialogue: 0,0:33:17.27,0:33:25.15,Default,,0000,0000,0000,,please welcome contributions. I hope\Neveryone gets inspired to to work on the
Dialogue: 0,0:33:25.15,0:33:31.08,Default,,0000,0000,0000,,installing this on their laptop. And if if\Nyou are interested I'll be hanging out at
Dialogue: 0,0:33:31.08,0:33:38.22,Default,,0000,0000,0000,,the coreboot assembly later today and\Noccasionally this week. The coreboot team
Dialogue: 0,0:33:38.22,0:33:42.61,Default,,0000,0000,0000,,has a bunch of people here. They have\Nflash programmers and can help you install
Dialogue: 0,0:33:42.61,0:33:50.99,Default,,0000,0000,0000,,coreboot on your laptop. The source code\Nfor Heads is available on GitHub, and a
Dialogue: 0,0:33:50.99,0:33:56.42,Default,,0000,0000,0000,,annotated version of this talk is up on my\Nwebsite, and welcome comments and feedback
Dialogue: 0,0:33:56.42,0:34:02.34,Default,,0000,0000,0000,,on it. So thank you all for coming to hear\Nabout this project I hope that everyone is
Dialogue: 0,0:34:02.34,0:34:06.90,Default,,0000,0000,0000,,and you know as excited about open source\Nfirmware as I am and I'd love to take any
Dialogue: 0,0:34:06.90,0:34:09.92,Default,,0000,0000,0000,,questions that you all have.
Dialogue: 0,0:34:09.92,0:34:21.74,Default,,0000,0000,0000,,{\i1}Applause{\i0}
Dialogue: 0,0:34:28.55,0:34:31.73,Default,,0000,0000,0000,,Question: Thanks for your great talk -\Nthis is very interesting. Do you have any
Dialogue: 0,0:34:31.73,0:34:39.01,Default,,0000,0000,0000,,advice for the 95% of us who are stuck on\Nnon coreboot compatible laptops.
Dialogue: 0,0:34:39.01,0:34:42.89,Default,,0000,0000,0000,,Trammell: Buy a Chromebook?\N{\i1}Laughter{\i0}
Dialogue: 0,0:34:42.89,0:34:52.95,Default,,0000,0000,0000,,Trammell: It's hard to trust the closed-\Nsource firmware. It certainly; there are
Dialogue: 0,0:34:52.95,0:34:55.92,Default,,0000,0000,0000,,people we have to trust - there are\Ninstitutions we have to trust. We have to
Dialogue: 0,0:34:55.92,0:35:01.62,Default,,0000,0000,0000,,trust Intel to some extent, and Intel is\Nresponsible for, you know, both our CPUs
Dialogue: 0,0:35:01.62,0:35:09.37,Default,,0000,0000,0000,,and a lot of the firmware. Depending on\Nyour threat model, firmware attacks may
Dialogue: 0,0:35:09.37,0:35:15.28,Default,,0000,0000,0000,,not be a huge concern for your particular\Nmachine. Or they might be, you know, of
Dialogue: 0,0:35:15.28,0:35:20.47,Default,,0000,0000,0000,,grave concern, in which case even just\Ndoing some of the things that Peter Stuge
Dialogue: 0,0:35:20.47,0:35:30.02,Default,,0000,0000,0000,,suggested of clipping the write-protect\Npin on the on the chip, removing things
Dialogue: 0,0:35:30.02,0:35:35.20,Default,,0000,0000,0000,,that might be hostile and attacking your\Nsystem. His guides are really good one to
Dialogue: 0,0:35:35.20,0:35:43.10,Default,,0000,0000,0000,,follow for the hardware security.\NQuestion: I was wondering if you also
Dialogue: 0,0:35:43.10,0:35:49.61,Default,,0000,0000,0000,,support ARM - I just saw Intel laptops so\NI was just wondering.
Dialogue: 0,0:35:49.61,0:35:55.23,Default,,0000,0000,0000,,Trammell: So ARM it has a lot of\Nadvantages as a CPU. It only has 20 years
Dialogue: 0,0:35:55.23,0:36:00.75,Default,,0000,0000,0000,,of legacy baggage rather than 40. And the\Nboot process on it is much much simpler
Dialogue: 0,0:36:00.75,0:36:06.82,Default,,0000,0000,0000,,since it doesn't have to go through real\Nmode to long mode to paging and all the
Dialogue: 0,0:36:06.82,0:36:15.14,Default,,0000,0000,0000,,other steps. The downside to a lot of ARMs\Nis that they their boot code is a few is
Dialogue: 0,0:36:15.14,0:36:22.19,Default,,0000,0000,0000,,on die and outside of the control of the\Nuser. Luckily, most of that boot code is
Dialogue: 0,0:36:22.19,0:36:29.28,Default,,0000,0000,0000,,fairly simple, and can establish - and\Nsome of them will establish a hardware
Dialogue: 0,0:36:29.28,0:36:37.49,Default,,0000,0000,0000,,root of trust. But in general, yeah that\Nthe ARM to U-Boot to whatever seems to
Dialogue: 0,0:36:37.49,0:36:44.09,Default,,0000,0000,0000,,work out pretty well. I know there's been\Nsome interest in, "can U-Boot be replaced
Dialogue: 0,0:36:44.09,0:36:49.92,Default,,0000,0000,0000,,with a Linux BIOS or coreboot like thing",\Nand I suspect the folks at the booth would
Dialogue: 0,0:36:49.92,0:36:54.70,Default,,0000,0000,0000,,be able to talk more about that.\NQuestion: And then just a followup - so if
Dialogue: 0,0:36:54.70,0:37:00.51,Default,,0000,0000,0000,,coreboot or Libreboot supports the\Nplatform - Heads will work too right?
Dialogue: 0,0:37:00.51,0:37:05.59,Default,,0000,0000,0000,,Trammell: Essentially yes, yeah.\NHeads is a payload for coreboot.
Dialogue: 0,0:37:05.59,0:37:13.03,Default,,0000,0000,0000,,Question: OK.\NHerald: It's there on the left.
Dialogue: 0,0:37:13.03,0:37:17.96,Default,,0000,0000,0000,,Signal Angel: Thank you - there's a\Nquestion from the Internet about coreboot.
Dialogue: 0,0:37:17.96,0:37:23.43,Default,,0000,0000,0000,,Coreboot has blobs included and, for\Nexample, binary blobs from Intel with all
Dialogue: 0,0:37:23.43,0:37:28.75,Default,,0000,0000,0000,,the firmware support package and all that\Nstuff. How can we call coreboot secure,
Dialogue: 0,0:37:28.75,0:37:33.06,Default,,0000,0000,0000,,then, in the light of this - let alone\Nopen source?
Dialogue: 0,0:37:33.06,0:37:37.89,Default,,0000,0000,0000,,Trammell: So the intel FSP is a\Nsignificant concern. This is the firmware
Dialogue: 0,0:37:37.89,0:37:42.01,Default,,0000,0000,0000,,support package that is required to\Ninitialize the memory controllers on on
Dialogue: 0,0:37:42.01,0:37:52.20,Default,,0000,0000,0000,,modern Intel cpus. On older CPUs, such as\Nthe the Sandy Bridge and Ivy Bridge, the
Dialogue: 0,0:37:52.20,0:37:57.04,Default,,0000,0000,0000,,coreboot and Libreboot are able to\Ninitialize the memory natively without
Dialogue: 0,0:37:57.04,0:38:05.87,Default,,0000,0000,0000,,having to go into the FSB. However, if you\Nlook at what coreboot is doing in the MRC
Dialogue: 0,0:38:05.87,0:38:10.93,Default,,0000,0000,0000,,on those platforms, it tends to just be\Npoking a bunch of registers with values
Dialogue: 0,0:38:10.93,0:38:20.17,Default,,0000,0000,0000,,that seem to work. And it's modern memory\Ncontrollers are so complex that, and Intel
Dialogue: 0,0:38:20.17,0:38:26.70,Default,,0000,0000,0000,,is unwilling to document them, that\Nwithout extensive NDA's that it's very
Dialogue: 0,0:38:26.70,0:38:32.33,Default,,0000,0000,0000,,hard to build any sort of memory\Ninitialization. So what we can't say it's
Dialogue: 0,0:38:32.33,0:38:38.61,Default,,0000,0000,0000,,a hundred percent free software, we can at\Nleast we can ensure that the FSP is
Dialogue: 0,0:38:38.61,0:38:47.20,Default,,0000,0000,0000,,measured and it's unchanging. We can also\Nlook at the state of things that it sets
Dialogue: 0,0:38:47.20,0:38:52.21,Default,,0000,0000,0000,,up and include those in our measurements.\NSo even if it doesn't get us one hundred
Dialogue: 0,0:38:52.21,0:38:57.85,Default,,0000,0000,0000,,percent open source - and as far as I know\Nthe only system that does that right now
Dialogue: 0,0:38:57.85,0:39:05.28,Default,,0000,0000,0000,,is bunnies' Novena laptop. At least we can\Nmeasure it and we can know that it hasn't
Dialogue: 0,0:39:05.28,0:39:10.81,Default,,0000,0000,0000,,been tampered with from\Nwhat we initially installed.
Dialogue: 0,0:39:10.81,0:39:17.26,Default,,0000,0000,0000,,Question: And before so this is a great\Nproject and I'd like to ask why you did
Dialogue: 0,0:39:17.26,0:39:23.65,Default,,0000,0000,0000,,certain architectural decisions. The\Nspecific combination of Linux and shell.
Dialogue: 0,0:39:23.65,0:39:29.84,Default,,0000,0000,0000,,So why didn't you choose a BSD kernel which\Nare usually perceived to be more secure
Dialogue: 0,0:39:29.84,0:39:34.72,Default,,0000,0000,0000,,and of a higher quality, and why did you\Nchoose a shell over let's say, Python
Dialogue: 0,0:39:34.72,0:39:41.23,Default,,0000,0000,0000,,or Haskell, which are also often\Nperceived of higher quality?
Dialogue: 0,0:39:41.23,0:39:45.40,Default,,0000,0000,0000,,Trammell: There is a lot of desire to\Nsupport Python in Heads. The downside is
Dialogue: 0,0:39:45.40,0:39:51.91,Default,,0000,0000,0000,,that there's a very limited space: the\NX230 bootrom, for instance, has 4
Dialogue: 0,0:39:51.91,0:40:02.07,Default,,0000,0000,0000,,megabytes of available space. The Python\Ninterpreter is a couple megs already. In
Dialogue: 0,0:40:02.07,0:40:09.08,Default,,0000,0000,0000,,terms of why Linux over BSD - the kexec\Nsystem call is a core component of this:
Dialogue: 0,0:40:09.08,0:40:14.94,Default,,0000,0000,0000,,to be able to do a graceful shut down and\Ntransfer from the Linux kernel to another
Dialogue: 0,0:40:14.94,0:40:22.37,Default,,0000,0000,0000,,kernel or - to any multi-boot compliant\Nkernels, which includes BSD. It is a
Dialogue: 0,0:40:22.37,0:40:31.01,Default,,0000,0000,0000,,necessary feature if it, if BSD had such\Nfunctionality, that it would be a fine
Dialogue: 0,0:40:31.01,0:40:37.22,Default,,0000,0000,0000,,just a choice for the the internal boot\NROM/boot loader.
Dialogue: 0,0:40:45.70,0:40:53.60,Default,,0000,0000,0000,,Question: Thanks for great work. How to\Nperform updates of coreboot and its
Dialogue: 0,0:40:53.60,0:41:00.39,Default,,0000,0000,0000,,payload when it's binaries used in\Nmeasurement for releasing encryption key
Dialogue: 0,0:41:00.39,0:41:07.15,Default,,0000,0000,0000,,then when you update coreboot this\Nmeasurement will change and you will know
Dialogue: 0,0:41:07.15,0:41:12.25,Default,,0000,0000,0000,,no longer will be able to boot the system\N- how to solve that problem?
Dialogue: 0,0:41:12.25,0:41:19.18,Default,,0000,0000,0000,,Trammell: So migrating encryption keys\Nwith TPM requires a explicit step of
Dialogue: 0,0:41:19.18,0:41:24.06,Default,,0000,0000,0000,,retrieving the key from the TPM with the\Ncurrent configuration and then resealing
Dialogue: 0,0:41:24.06,0:41:30.21,Default,,0000,0000,0000,,it with the new configuration. One\Nadvantage of a reproducible build is the
Dialogue: 0,0:41:30.21,0:41:37.24,Default,,0000,0000,0000,,hashes of the of all the firmware stages\Ncan be published - it can be pre-computed,
Dialogue: 0,0:41:37.24,0:41:41.46,Default,,0000,0000,0000,,and then the PCR values can be pre-\Ncomputed so you can read you can seal the
Dialogue: 0,0:41:41.46,0:41:52.17,Default,,0000,0000,0000,,keys for the new values. In terms of the\Nupdate process for the Heads payload - one
Dialogue: 0,0:41:52.17,0:41:56.55,Default,,0000,0000,0000,,of the things that we're working on is\Nbeing able to have an even more minimal
Dialogue: 0,0:41:56.55,0:42:03.50,Default,,0000,0000,0000,,heads that has just a USB device driver\Nthat you can boot into, copy your new
Dialogue: 0,0:42:03.50,0:42:08.83,Default,,0000,0000,0000,,payload, and then install that elsewhere\Non the chip. And part of that process
Dialogue: 0,0:42:08.83,0:42:15.20,Default,,0000,0000,0000,,would involve resealing any of the keys\Nthat you need to transfer.
Dialogue: 0,0:42:15.20,0:42:17.27,Default,,0000,0000,0000,,Herald: Another question from the\NInternet.
Dialogue: 0,0:42:17.27,0:42:21.57,Default,,0000,0000,0000,,Signal Angel: Thank you. On your webpage\Nyou implemented Heads on ThinkPads only.
Dialogue: 0,0:42:21.57,0:42:28.25,Default,,0000,0000,0000,,How much work is still needed to translate\Nthis to, let's say, non-ThinkPads?
Dialogue: 0,0:42:28.25,0:42:32.89,Default,,0000,0000,0000,,Trammell: ThinkPads are really popular\Nwith the security community. It's quite
Dialogue: 0,0:42:32.89,0:42:36.28,Default,,0000,0000,0000,,interesting to look out at you know the\Nhall here and see how many ThinkPads there
Dialogue: 0,0:42:36.28,0:42:41.52,Default,,0000,0000,0000,,are. And as a result the coreboot\Ncommunity has been very supportive of
Dialogue: 0,0:42:41.52,0:42:48.82,Default,,0000,0000,0000,,ThinkPads. There's, other than the\NThinkPads and the Chromebooks, there
Dialogue: 0,0:42:48.82,0:42:53.27,Default,,0000,0000,0000,,aren't a lot of devices that support\Ncoreboot out of the box. And that's
Dialogue: 0,0:42:53.27,0:42:58.05,Default,,0000,0000,0000,,something that I hope would change - I\Nhope that some OEMs would realize there's
Dialogue: 0,0:42:58.05,0:43:04.56,Default,,0000,0000,0000,,value in provide an open source firmware\Nand move to move to using it. Both as a
Dialogue: 0,0:43:04.56,0:43:10.59,Default,,0000,0000,0000,,cost-saving measure as well as a freedom\Nmeasure. In terms of the difficulty
Dialogue: 0,0:43:10.59,0:43:15.78,Default,,0000,0000,0000,,important coreboot to a platform - I\Nhaven't successfully done that yet, but I
Dialogue: 0,0:43:15.78,0:43:23.35,Default,,0000,0000,0000,,suspect the people at the assembly would\Nbe happy to discuss that further.
Dialogue: 0,0:43:23.35,0:43:29.40,Default,,0000,0000,0000,,Question: Would you plan to rework\Nembedded controller firmware on ThinkPads
Dialogue: 0,0:43:29.40,0:43:38.42,Default,,0000,0000,0000,,because it's remain close at birth which\Nstill has an access to PC bus and probably
Dialogue: 0,0:43:38.42,0:43:43.44,Default,,0000,0000,0000,,couldn't be trusted.\NTrammell: So your question is how do we
Dialogue: 0,0:43:43.44,0:43:48.52,Default,,0000,0000,0000,,how do we replace the EC?\NQuestion: Yes do plan to replace EC with
Dialogue: 0,0:43:48.52,0:43:52.15,Default,,0000,0000,0000,,open source firmware as in the\NChromebooks?
Dialogue: 0,0:43:52.15,0:43:57.53,Default,,0000,0000,0000,,Trammell: So the Chromebook has open\Nsource EC. The part of building coreboot
Dialogue: 0,0:43:57.53,0:44:03.19,Default,,0000,0000,0000,,for Chromebook involves installing the ARM\Ncross compiler to build the EC firmware.
Dialogue: 0,0:44:03.19,0:44:08.79,Default,,0000,0000,0000,,And the Chromebooks actually have a really\Nelegant protocol for the EC to attest to
Dialogue: 0,0:44:08.79,0:44:14.43,Default,,0000,0000,0000,,the CPU that is running the firmware that\Nyou think it is running. On other
Dialogue: 0,0:44:14.43,0:44:23.70,Default,,0000,0000,0000,,platforms, this would require a lot more\Nresearch. The doc; many of the EC chipsets
Dialogue: 0,0:44:23.70,0:44:27.84,Default,,0000,0000,0000,,have data sheets available, so it's\Npossible to read through and see how they
Dialogue: 0,0:44:27.84,0:44:33.07,Default,,0000,0000,0000,,work. And most of them have updatable\Nfirmware. In case of the ThinkPads,
Dialogue: 0,0:44:33.07,0:44:37.41,Default,,0000,0000,0000,,there's a module in the ThinkPad BIOS that\Nwill do that update. There's, we would
Dialogue: 0,0:44:37.41,0:44:41.48,Default,,0000,0000,0000,,need to figure out what that protocol\Nlooks like.
Dialogue: 0,0:44:41.48,0:44:47.81,Default,,0000,0000,0000,,Question: Sorry yes I mean if you have\Nworking prototype on ThinkPads probably
Dialogue: 0,0:44:47.81,0:44:56.87,Default,,0000,0000,0000,,want to add remaining business open\Nsources EC on ThinkPads as well in the
Dialogue: 0,0:44:56.87,0:45:00.55,Default,,0000,0000,0000,,first place.\NTrammell: I'm sorry, I don't think I
Dialogue: 0,0:45:00.55,0:45:09.54,Default,,0000,0000,0000,,understood your follow-up.\NQuestion: Okay. So if you if you have a
Dialogue: 0,0:45:09.54,0:45:18.24,Default,,0000,0000,0000,,working prototype on ThinkPads and only on\NThinkPads, will you finish somewhat soon
Dialogue: 0,0:45:18.24,0:45:28.71,Default,,0000,0000,0000,,current existing prototype of open source\NEC exists in college shade by Lincoln's or
Dialogue: 0,0:45:28.71,0:45:36.83,Default,,0000,0000,0000,,you are playing to extend your work on\Nother platforms and finish this bits
Dialogue: 0,0:45:36.83,0:45:39.70,Default,,0000,0000,0000,,later.\NTrammell: Yeah right now I have not
Dialogue: 0,0:45:39.70,0:45:46.91,Default,,0000,0000,0000,,personally made any progress on the\NThinkPad EC. I was looking into it because
Dialogue: 0,0:45:46.91,0:45:51.70,Default,,0000,0000,0000,,I have a modified keyboard on my ThinkPad\Nthat that needs to updated EC firmware,
Dialogue: 0,0:45:51.70,0:46:00.74,Default,,0000,0000,0000,,but I haven't actually gotten into that.\NThis is a area of open research
Dialogue: 0,0:46:00.74,0:46:03.90,Default,,0000,0000,0000,,Signal Angel: Thank you, two quick\Nquestions from the IRC - are you planning
Dialogue: 0,0:46:03.90,0:46:07.69,Default,,0000,0000,0000,,to use systemd in the boot process\Nis the first one
Dialogue: 0,0:46:07.69,0:46:11.03,Default,,0000,0000,0000,,{\i1}Laughter{\i0}\NSignal Angel: And the second one let's say
Dialogue: 0,0:46:11.03,0:46:16.11,Default,,0000,0000,0000,,you flash your firmware at the Congress\Nright here with the help of a hardware
Dialogue: 0,0:46:16.11,0:46:22.90,Default,,0000,0000,0000,,programmer. Can you update when there's a\Nnew version or do you have to currently
Dialogue: 0,0:46:22.90,0:46:29.62,Default,,0000,0000,0000,,need the hardware access to update?\NTrammell: Right now you can update
Dialogue: 0,0:46:29.62,0:46:40.03,Default,,0000,0000,0000,,afterwards at great risk, because you can\Nleave the flash writeable, which would
Dialogue: 0,0:46:40.03,0:46:45.71,Default,,0000,0000,0000,,allow you to flash after the fact. We are\Nstill working on a good procedure for
Dialogue: 0,0:46:45.71,0:46:53.54,Default,,0000,0000,0000,,doing software-only firmware updates once\Nthe immutable boot block is installed. And
Dialogue: 0,0:46:53.54,0:46:58.95,Default,,0000,0000,0000,,to the other question - did I mention that\Nwe are really short on space and we don't
Dialogue: 0,0:46:58.95,0:47:07.71,Default,,0000,0000,0000,,want to put any large applications like\Nsystemd on there.
Dialogue: 0,0:47:07.71,0:47:11.29,Default,,0000,0000,0000,,Questioner: It was like good one, thanks.
Dialogue: 0,0:47:11.29,0:47:19.24,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:47:19.24,0:47:28.16,Default,,0000,0000,0000,,{\i1}postroll music{\i0}
Dialogue: 0,0:47:28.16,0:47:42.81,Default,,0000,0000,0000,,{\i1}subtitles created by c3subtitles.de\Nin the year 2018{\i0}