1 00:00:14,987 --> 00:00:19,620 Herald Angel: So, most of the cloud services rely on closed source proprietary 2 00:00:19,620 --> 00:00:23,760 server firmware; header[?] firmware; with known security implications to[?] tenants. 3 00:00:23,760 --> 00:00:30,140 Imagine... So that's where LinuxBoot comes to the rescue because it wants to replace 4 00:00:30,140 --> 00:00:36,199 this closed source firmware with an open Linux boot version and our next speaker 5 00:00:36,199 --> 00:00:41,030 Trammell Hudson he's an integral part of that project and he's here to provide you 6 00:00:41,030 --> 00:00:45,819 an overview of this Linux boot project. Thank you very much and please give a warm 7 00:00:45,819 --> 00:00:48,448 round round of applause to Trammell Hudson, please! 8 00:00:48,448 --> 00:00:56,249 *applause* Trammell: Thank you! 9 00:00:56,249 --> 00:01:01,639 Securing the boot process is really fundamental to having secure systems 10 00:01:01,639 --> 00:01:09,890 because of the vulnerabilities in firmware can affect any security that the operating 11 00:01:09,890 --> 00:01:15,250 system tries to provide. And for that reason I think it's really important that 12 00:01:15,250 --> 00:01:21,299 we replace the proprietary vendor firmwares with open source, like Linux. 13 00:01:21,299 --> 00:01:26,259 And this is not a new idea. My collaborator Ron Minich started a project 14 00:01:26,259 --> 00:01:31,840 called LinuxBIOS back in the 90s when he was at Los Alamos National Labs. They 15 00:01:31,840 --> 00:01:36,230 built the world's third fastest supercomputer out of a Linux cluster that 16 00:01:36,230 --> 00:01:44,810 used BIOS in the ROM to make it more reliable. LinuxBIOS turned into coreboot 17 00:01:44,810 --> 00:01:52,610 in 2005 and the Linux part was removed and became a generic bootloader, and it now 18 00:01:52,610 --> 00:01:59,140 powers the Chromebooks as well as projects like the Heads slightly more secure laptop 19 00:01:59,140 --> 00:02:04,829 firmware that I presented last year at CCC. Unfortunately it doesn't support any 20 00:02:04,829 --> 00:02:12,710 server main boards anymore. Most servers are running a variant of Intel's UEFI 21 00:02:12,710 --> 00:02:19,220 firmware, which is a project that Intel started to replace the somewhat aging 22 00:02:19,220 --> 00:02:24,861 16-bit real mode BIOS of the 80s and 90s. And, like a lot of second systems, it's 23 00:02:24,861 --> 00:02:30,000 pretty complicated. If you've been to any talks on firmware security you've probably 24 00:02:30,000 --> 00:02:37,070 seen this slide before. It goes through multiple phases as the system boots, the 25 00:02:37,070 --> 00:02:44,970 first phase does a cryptographic verification of the pre-EFI phase this the 26 00:02:44,970 --> 00:02:49,950 PEI phase is responsible for bringing up the memory controller the CPU interconnect 27 00:02:49,950 --> 00:02:55,150 and a few other critical devices. It also enables paging and long mode and then 28 00:02:55,150 --> 00:03:03,060 jumps into the device execution environment or DXE phase. This is where 29 00:03:03,060 --> 00:03:07,620 UEFI option ROMs are executed as well, as well as all of the remaining devices are 30 00:03:07,620 --> 00:03:14,590 initialized. Once the PCI bus and USB buses have been walked and enumerated, it 31 00:03:14,590 --> 00:03:20,350 transfers to the boot device selection phase, which figures out which disk or USB 32 00:03:20,350 --> 00:03:26,670 stick or network to boot from. That loads a boot loader from that device which 33 00:03:26,670 --> 00:03:32,230 eventually loads a real operating system, which then is the operating system that's 34 00:03:32,230 --> 00:03:37,560 running on the machine. What we're proposing is that we replace all of this 35 00:03:37,560 --> 00:03:45,680 with the Linux boot kernel and runtime. We can do all of the device enumeration in 36 00:03:45,680 --> 00:03:50,200 Linux, it already has support for doing this, and then we can use more 37 00:03:50,200 --> 00:03:54,840 sophisticated protocols and tools to locate the real kernel that we want to 38 00:03:54,840 --> 00:04:03,820 run, and use the kexec system call to be able to start that new kernel. And the 39 00:04:03,820 --> 00:04:09,040 reason we want to use Linux here is because it gives us the ability to have a 40 00:04:09,040 --> 00:04:13,540 more secure system. It gives us a lot more flexibility and hopefully it lets us 41 00:04:13,540 --> 00:04:20,760 create a more resilient system out of it. On the security front one of the big areas 42 00:04:20,760 --> 00:04:28,070 that we get some benefit is we reduced the attack surface that in the DXE phase these 43 00:04:28,070 --> 00:04:35,480 drivers are an enormous amount of code on the Intel S2600 there are over 400 modules 44 00:04:35,480 --> 00:04:41,100 that get loaded. They do things like the option roms that I mentioned, and if you 45 00:04:41,100 --> 00:04:44,440 want an example of how dangerous option roms can be, you can look at my 46 00:04:44,440 --> 00:04:50,680 Thunderstrike talks from a few years ago. They also do things like display the boot 47 00:04:50,680 --> 00:04:55,410 splash, the vendor logo, and this has been a place where quite a few buffer overflows 48 00:04:55,410 --> 00:05:00,210 have been found in vendor firmwares in the past. They have a complete network stack 49 00:05:00,210 --> 00:05:09,770 IPv4 and v6 as well as HTTP and HTTPS. They have legacy device drivers for things 50 00:05:09,770 --> 00:05:14,490 like floppy drives, and again, these sort of dusty corners are where vulnerabilities 51 00:05:14,490 --> 00:05:20,540 in Xen have been found that allowed a hypervisor break. There are also modules 52 00:05:20,540 --> 00:05:25,880 like the Microsoft OEM activation that we just don't know what they do, or things 53 00:05:25,880 --> 00:05:35,780 like a y2k rollover module that probably hasn't been tested in two decades. So the 54 00:05:35,780 --> 00:05:41,060 final OS bootloader phase is actually not part of UEFI, but it's typically in, the 55 00:05:41,060 --> 00:05:46,430 Linux system, its GRUB, the grand unified bootloader. And y'all -- many of you are 56 00:05:46,430 --> 00:05:51,160 probably familiar with its interface, but did you know that it has its own file 57 00:05:51,160 --> 00:05:58,900 system, video, and network drivers. About almost 250 thousand lines of code make up 58 00:05:58,900 --> 00:06:04,440 GRUB. I don't bring up the size of this to complain about the space it takes, but 59 00:06:04,440 --> 00:06:09,540 because of how much it increases our attack surface. You might think that 60 00:06:09,540 --> 00:06:13,770 having three different operating systems involved in this boot process gives us a 61 00:06:13,770 --> 00:06:19,270 defense in depth, but I would argue that we are subject to the weakest link in this 62 00:06:19,270 --> 00:06:23,710 chain because if you can compromise UEFI, you can compromise grub, and if you can 63 00:06:23,710 --> 00:06:27,520 compromise grub you can compromise the Linux kernel that you want to run on the 64 00:06:27,520 --> 00:06:35,420 machine. So there are lots of ways these attacks could be launched. As I mentioned 65 00:06:35,420 --> 00:06:39,780 UEFI has a network device driver, grub has a network device driver, and of course 66 00:06:39,780 --> 00:06:43,620 Linux has a network device driver. This means that a remote attacker could 67 00:06:43,620 --> 00:06:48,300 potentially get code execution during the boot process. 68 00:06:48,300 --> 00:06:56,430 UEFI has a USB driver, grub has a USB driver, and of course Linux has a USB 69 00:06:56,430 --> 00:07:02,520 driver. There have been bugs found in USB stacks -- which unfortunately are very 70 00:07:02,520 --> 00:07:08,060 complex -- and a buffer overflow in a USB descriptor handler could allow a local 71 00:07:08,060 --> 00:07:12,870 attacker to plug in a rogue device and take control of the firmware during the 72 00:07:12,870 --> 00:07:19,370 boot. Of course UEFI has a FAT driver, GRUB has a FAT driver, Linux has a FAT 73 00:07:19,370 --> 00:07:26,139 driver. This gives an attacker a place to gain persistence and perhaps leverage code 74 00:07:26,139 --> 00:07:35,190 execution during the initial file system or partition walk. So what we argue is 75 00:07:35,190 --> 00:07:39,650 that we should have the operating system that has the most contributors, and the 76 00:07:39,650 --> 00:07:47,070 most code review, and the most frequent update schedule, for these roles. Linux 77 00:07:47,070 --> 00:07:52,790 has a lot more eyes on it, it undergoes a much more rapid update schedule than 78 00:07:52,790 --> 00:08:01,180 pretty much any vendor firmware. You might ask, why do we keep the PEI and the SEC 79 00:08:01,180 --> 00:08:08,270 phase from the UEFI firmware? Couldn't we use coreboot in this place, and the 80 00:08:08,270 --> 00:08:12,630 problem is that vendors are not documenting the memory controller or the 81 00:08:12,630 --> 00:08:18,080 CPU interconnect. Instead they're providing a opaque binary blob called the 82 00:08:18,080 --> 00:08:25,450 firmware support package, or FSP, that does the memory controller and the CPU 83 00:08:25,450 --> 00:08:32,879 initialization. On most coreboot systems -- on most modern coreboot systems -- 84 00:08:32,879 --> 00:08:38,139 coreboot actually calls into the FSP to do this initialization. And on a lot of the 85 00:08:38,139 --> 00:08:43,479 devices the FSB has grown in scope so it now includes video device drivers and 86 00:08:43,479 --> 00:08:49,160 power management, and it's actually larger than the PEI phase on some of the servers 87 00:08:49,160 --> 00:08:57,680 that we're dealing with. The other wrinkle is that most modern CPUs don't come out of 88 00:08:57,680 --> 00:09:02,059 reset into the legacy reset vector anymore. Instead, they execute an 89 00:09:02,059 --> 00:09:07,329 authenticated code module, called boot guard, that's signed by Intel, and the CPU 90 00:09:07,329 --> 00:09:15,129 will not start up if that's not present. The good news is that this boot guard ACM 91 00:09:15,129 --> 00:09:22,600 measures the PEI phase into the TPM, which allows us to detect attempts to modify it 92 00:09:22,600 --> 00:09:28,459 from malicious attacks. The bad news is that we are not able to change it on many 93 00:09:28,459 --> 00:09:33,800 of these systems. But even with that in place, we still have a much, much more 94 00:09:33,800 --> 00:09:39,730 flexible system. If you've ever worked with the UEFI shell or with GRUBs menu 95 00:09:39,730 --> 00:09:46,619 config, it's really not as flexible, and the tooling is not anywhere near as 96 00:09:46,619 --> 00:09:51,490 mature, as being able to write things with shell scripts, or with go, or with real 97 00:09:51,490 --> 00:09:57,520 languages. Additionally we can configure at the Linux boot kernel with standard 98 00:09:57,520 --> 00:10:04,420 Linux config tools. UEFI supports booting from FAT file systems, but with LinuxBoot 99 00:10:04,420 --> 00:10:09,380 we can boot from any of the hundreds of file systems that Linux supports. We can 100 00:10:09,380 --> 00:10:15,709 boot from encrypted filesystems, since we have LUKS and cryptsetup. Most UEFI 101 00:10:15,709 --> 00:10:19,790 firmwares can only boot from the network device that is installed on the server 102 00:10:19,790 --> 00:10:25,029 motherboard. We can boot from any network device that Linux supports, and we can use 103 00:10:25,029 --> 00:10:30,899 proper protocols; we're not limited to PXE and TFTP. We can use SSL, we can do 104 00:10:30,899 --> 00:10:37,500 cryptographic measurements of the kernels that we receive. And the runtime that 105 00:10:37,500 --> 00:10:42,920 makes up Linux boot is also very flexible. Last year I presented the Heads runtime 106 00:10:42,920 --> 00:10:50,110 for laptops. This is a very security focused initial ram disk that attempts to 107 00:10:50,110 --> 00:10:55,170 provide a slightly more secure, measured, and attested firmware, and this works 108 00:10:55,170 --> 00:11:00,689 really well with Linux boot. My collaborator Ron Minnich is working on a 109 00:11:00,689 --> 00:11:06,220 go based firmware, called NERF, and this is written entirely in just-in-time 110 00:11:06,220 --> 00:11:10,699 compiled Go, which is really nice because it gives you memory safety, and is very 111 00:11:10,699 --> 00:11:16,160 popular inside of Google. Being able to tailor the device drivers that are 112 00:11:16,160 --> 00:11:21,999 included also allows the system to boot much faster. UEFI on the Open Compute 113 00:11:21,999 --> 00:11:27,630 Winterfell takes about eight minutes to startup. With NERF, excuse me -- with 114 00:11:27,630 --> 00:11:32,869 with Linux boot and NERF it starts up in about 20 seconds. I found similar results 115 00:11:32,869 --> 00:11:38,509 on the Intel mainboard that I'm working on and hopefully we will get a video there's 116 00:11:38,509 --> 00:11:45,350 an action this is from power-on to executes the PEI phase out of the 117 00:11:45,350 --> 00:11:52,209 ROM and then jumps into a small wrapper around the Linux kernel which then prints 118 00:11:52,209 --> 00:11:59,239 to the serial port and we now have the Linux print case and we have an 119 00:11:59,239 --> 00:12:03,170 interactive shell in about 20 seconds which is quite a bit better than the four 120 00:12:03,170 --> 00:12:11,189 minutes that the system used to take it scrolled by pretty fast but you might have 121 00:12:11,189 --> 00:12:15,540 noticed that the print case has ... - that the Linux kernel thinks it's running under 122 00:12:15,540 --> 00:12:20,089 EFI this because we have a small wrapper around the kernel but for the most part 123 00:12:20,089 --> 00:12:26,279 the kernel is able to do all of the PCI and device enumeration that it needs to do 124 00:12:26,279 --> 00:12:29,779 because it already does it since it doesn't trust the vendor BIOSes in a lot 125 00:12:29,779 --> 00:12:38,569 of cases so I'm really glad that the Congress has added a track on technical 126 00:12:38,569 --> 00:12:45,420 resiliency and I would encourage Congress to also add a track on resiliency of our 127 00:12:45,420 --> 00:12:50,639 social systems because it's really vital that we deal with both online and offline 128 00:12:50,639 --> 00:12:55,529 harassment and I think that that will help us make a safer and more secure Congress 129 00:12:55,529 --> 00:13:05,607 as well. *applause* 130 00:13:05,607 --> 00:13:12,029 So last year when I presented at Heads I proposed three criteria for a 131 00:13:12,029 --> 00:13:16,339 resilient technical system: that they need to be built with open-source software, 132 00:13:16,339 --> 00:13:20,330 they need to be reproducibly built, and they need to be measured into some sort of 133 00:13:20,330 --> 00:13:26,749 cryptographic hardware. The open is, you know, I think, in this crowd, is not 134 00:13:26,749 --> 00:13:33,600 controversial. But the reason that we need it is because a lot of the server vendors 135 00:13:33,600 --> 00:13:37,810 don't actually control their own firmware; they license it from independent BIOS 136 00:13:37,810 --> 00:13:45,230 vendors who then tailor it for whatever current model of machine the 137 00:13:45,230 --> 00:13:51,089 manufacturer is making. This means that they typically don't support older 138 00:13:51,089 --> 00:13:55,559 hardware and, if there are vulnerabilities, it's necessary that we be 139 00:13:55,559 --> 00:14:00,660 able to make these patches on our own schedule and we need to be able to self- 140 00:14:00,660 --> 00:14:07,319 help when it comes to our own security. The other problem is that closed source 141 00:14:07,319 --> 00:14:13,209 systems can hide vulnerabilities for decades — this is especially true for very 142 00:14:13,209 --> 00:14:17,070 privileged devices like the management engine. There's been several talks here at 143 00:14:17,070 --> 00:14:23,790 Congress about the concerns that we have with the management engine. Some vendors 144 00:14:23,790 --> 00:14:29,929 are even violating our trust entirely and using their place in the firmware 145 00:14:29,929 --> 00:14:38,470 to install malware or adware onto the systems. So for this reason we really need 146 00:14:38,470 --> 00:14:47,290 our own control over this firmware. Reproducibility is becoming much more of 147 00:14:47,290 --> 00:14:53,589 an issue, and the goal here is to be able to ensure that everyone who builds the 148 00:14:53,589 --> 00:14:59,159 Linux boot firmware gets exactly the same result that everyone else does. This is a 149 00:14:59,159 --> 00:15:03,759 requirement to be able to ensure that we're not introducing accidental 150 00:15:03,759 --> 00:15:08,649 vulnerabilities through picking up the wrong library, or intentional ones through 151 00:15:08,649 --> 00:15:16,079 compiler supply chain attacks, such as Ken Thompson's Trusting Trust article. With 152 00:15:16,079 --> 00:15:21,569 the Linux boot firmware, our Kernel and Initial Ramdisk are reproducibly built, so 153 00:15:21,569 --> 00:15:27,819 we get exactly the same hashes on the firmware. Unfortunately we don't control 154 00:15:27,819 --> 00:15:33,560 the UEFI portions that we're using — the PEI and the SEC phase — so those aren't 155 00:15:33,560 --> 00:15:41,920 included in our reproducibility right now. "Measured" is a another place 156 00:15:41,920 --> 00:15:48,059 where we need to take into account the runtime security of the system. So 157 00:15:48,059 --> 00:15:52,509 reproducible builds handle the compile time, but measuring what's running into 158 00:15:52,509 --> 00:15:58,589 cryptographic coprocessors — like the TPM — gives us the ability to make 159 00:15:58,589 --> 00:16:02,939 attestations as to what is actually running on the system. On the Heads 160 00:16:02,939 --> 00:16:09,499 firmware we do this to the user that the firmware can produce a one-time secret 161 00:16:09,499 --> 00:16:14,319 that you can compare against your phone to know that it has not been tampered with. 162 00:16:14,319 --> 00:16:18,309 In the server case it uses remote attestation to be able to prove to the 163 00:16:18,309 --> 00:16:25,299 user that the code that is running is what they expect. This is a collaboration with 164 00:16:25,299 --> 00:16:30,759 the Mass Open Cloud Project, out of Boston University and MIT, that is attempting to 165 00:16:30,759 --> 00:16:37,660 provide a hardware root of trust for the servers, so that you can know that a cloud 166 00:16:37,660 --> 00:16:45,529 provider has not tampered with your system. The TPM is not invulnerable, as 167 00:16:45,529 --> 00:16:49,889 Christopher Tarnovsky showed at DEFCON, but the level of effort that it takes to 168 00:16:49,889 --> 00:16:55,269 break into a TPM, to decap it, and to read out the bits with a microscope raises the 169 00:16:55,269 --> 00:17:02,290 bar really significantly. And part of resiliency is making honest trade-offs 170 00:17:02,290 --> 00:17:09,369 about security threats versus the difficulty in launching the attacks, and 171 00:17:09,369 --> 00:17:14,888 if the TPM prevents remote attacks or prevents software-only attacks, that is a 172 00:17:14,888 --> 00:17:22,709 sufficiently high bar for a lot of these applications. We have quite a bit of 173 00:17:22,709 --> 00:17:28,549 ongoing research with this. As I mentioned the management engine is an area of great 174 00:17:28,549 --> 00:17:35,330 concern and we are working on figuring out how to remove most of its capabilities, so 175 00:17:35,330 --> 00:17:41,389 that it's not able to interfere with the running system. There's another device in 176 00:17:41,389 --> 00:17:45,780 most server motherboards called the board management controller, or the BMC, that 177 00:17:45,780 --> 00:17:52,799 has a similar level of access to memory and devices. So we're concerned about 178 00:17:52,799 --> 00:17:57,889 what's running on there, and there's a project out of Facebook called OpenBMC 179 00:17:57,889 --> 00:18:05,210 that is an open source Linux distribution to run on that coprocessor, and what 180 00:18:05,210 --> 00:18:10,981 Facebook has done through the Open Compute Initiative is, they have their OEMs pre- 181 00:18:10,981 --> 00:18:19,690 installing that on the new open compute nodes, switches, and storage systems. And 182 00:18:19,690 --> 00:18:26,549 this is really where we need to get with Linux boot as well. Right now it requires 183 00:18:26,549 --> 00:18:31,250 physical access to the SPI Flash and a hardware programmer to be able to install. 184 00:18:31,250 --> 00:18:37,060 That's not a hurdle for everyone, but this is not something that we want people to be 185 00:18:37,060 --> 00:18:43,559 doing in their server rooms. We want OEMs to be providing these systems that are 186 00:18:43,559 --> 00:18:49,320 secure by default so that it's not necessary to break out your chip clip to 187 00:18:49,320 --> 00:18:55,260 make this happen. But if you do want to contribute, right now we support three 188 00:18:55,260 --> 00:19:02,789 different main boards: The Intel S2600, which is a modern Wolf Pass CPU, the Mass 189 00:19:02,789 --> 00:19:09,159 Open Cloud is working with the Dell R630, which is a Haswell, I believe, and then 190 00:19:09,159 --> 00:19:14,799 Ron Minnich and John Murrie are working on the Open Compute Hardware, and this is 191 00:19:14,799 --> 00:19:21,990 again a — in conjunction with OpenBMC — a real potential for having free software in 192 00:19:21,990 --> 00:19:28,260 our firmware again. So, if you'd like more info, we have a website. There's some 193 00:19:28,260 --> 00:19:35,700 install instructions and we'd love to help you build more secure, more flexible, and 194 00:19:35,700 --> 00:19:39,620 more resilient systems. And I really want to thank everyone for coming here today, 195 00:19:39,620 --> 00:19:42,409 and I'd love to answer any questions that you might have! 196 00:19:42,409 --> 00:19:51,234 *applause* 197 00:19:51,234 --> 00:19:53,240 Herald: Thank you very much Trammel Hudson 198 00:19:53,240 --> 00:19:58,700 for this talk. We have 10 minutes for Q&A, so please line up at the microphones if 199 00:19:58,700 --> 00:20:02,880 you have any questions but there are no questions from the signal angel and the 200 00:20:02,880 --> 00:20:05,310 internet, so please, microphone number one. 201 00:20:05,310 --> 00:20:11,759 Q: One quick question. Is Two Sigma using this for any of their internal systems, 202 00:20:11,759 --> 00:20:15,990 and B, and how much vendor outreach is in there to try and make this beyond just the 203 00:20:15,990 --> 00:20:21,020 Open Compute but also a lot of the vendors that were on your slides to adopt this. 204 00:20:21,020 --> 00:20:28,700 A: So currently, we don't have any deployed systems taking advantage of it. It's still 205 00:20:28,700 --> 00:20:33,509 very much at the research stage. I've been spending quite a bit of time visiting 206 00:20:33,509 --> 00:20:40,650 OEMs, and one of my goals for 2018 is to have a mainstream OEM shipping it. The 207 00:20:40,650 --> 00:20:47,480 Heads project is shipping firmware on some laptops from Librem, and I'm hoping we can 208 00:20:47,480 --> 00:20:53,631 get Linux boot on servers as well. Herald: Microphone number 2, please. 209 00:20:53,631 --> 00:21:00,880 Q: The question I have is about the size of Linux. So you mention that there is 210 00:21:00,880 --> 00:21:08,120 problems with UEFI, and it's not open source, and stuff like that. But the issue 211 00:21:08,120 --> 00:21:16,120 you mention is that the main part of Evo UEFI is EDK, which is open source and 212 00:21:16,120 --> 00:21:21,050 then, I mean, I just have to guess that the HTTP client and stuff that they have 213 00:21:21,050 --> 00:21:28,169 in the Apple boot, I assume it was, is for downloading their firmware, but how is 214 00:21:28,169 --> 00:21:33,240 replacing something that's huge with something that's even bigger going to make 215 00:21:33,240 --> 00:21:37,440 the thing more secure? Because I think the the whole point of having a security 216 00:21:37,440 --> 00:21:42,720 kernel is to have it really small to be verifiable and I don't see that happening 217 00:21:42,720 --> 00:21:49,140 with Linux, because at the same time people are coming up with other things. I 218 00:21:49,140 --> 00:21:54,370 don't remember the the other hypervisor, which is supposed to be better than KVM, 219 00:21:54,370 --> 00:22:01,089 because KVM is not really verifiable. A: So that that's a great question. The 220 00:22:01,089 --> 00:22:06,960 concern is that Linux is a huge TCB — a Trusted Computing Base — and that that is 221 00:22:06,960 --> 00:22:13,029 a big concern. Since we're already running linux on the server, it essentially is 222 00:22:13,029 --> 00:22:21,830 inside our TCB already, so it is large, it is difficult to verify. However the 223 00:22:21,830 --> 00:22:26,250 lessons that we've learned in porting Linux to run in this environment make it 224 00:22:26,250 --> 00:22:31,470 also very conceivable that we could build other systems. If you want to use a 225 00:22:31,470 --> 00:22:37,290 certified — excuse me, a verified microkernel, that would be a great place 226 00:22:37,290 --> 00:22:46,500 to bring into the firmware and I'd love to figure out some way to make that 227 00:22:46,500 --> 00:22:55,340 happen. The second question, just to point out, that even though EDK 2 — which is the 228 00:22:55,340 --> 00:23:02,000 open source components of UEFI are open source — there's a huge amount of closed 229 00:23:02,000 --> 00:23:08,280 source that goes into building a UEFI firmware, and we can't verify the closed 230 00:23:08,280 --> 00:23:14,490 source part, and even the open source parts don't have the level of inspection 231 00:23:14,490 --> 00:23:21,870 and correctness that the Linux kernel has gone through, and Linux systems that are 232 00:23:21,870 --> 00:23:31,370 exposed on the internet. Most of the UEFI development is not focused on that level 233 00:23:31,370 --> 00:23:35,070 of defense that Linux has to deal with everyday. 234 00:23:35,070 --> 00:23:40,850 H: Microphone number 2, please. Q: Thank you for your talk. Would it be 235 00:23:40,850 --> 00:23:49,130 possible also to support, apart from servers, to support laptops? Especially 236 00:23:49,130 --> 00:23:54,870 the one locked down by Boot Guard? A: So the issue with Boot Guard on laptops 237 00:23:54,870 --> 00:24:01,779 is that the CPU fuses are typically set in what's called a Verified Boot Mode, and 238 00:24:01,779 --> 00:24:07,789 that will not exit the boot guard ACM if the firmware does not match the 239 00:24:07,789 --> 00:24:12,679 manufacturer's hash. So this doesn't give us any way to take advantage– to 240 00:24:12,679 --> 00:24:18,519 circumvent that. Most server chipsets are set in what's called Measured Boot Mode. 241 00:24:18,519 --> 00:24:24,679 So the Boot Guard ACM just measures the next stage into the TPM, and then jumps 242 00:24:24,679 --> 00:24:30,680 into it. So if an attacker has modified the firmware you will be able to detect it 243 00:24:30,680 --> 00:24:36,900 during the attestation phase. H: Microphone number one, please — just 244 00:24:36,900 --> 00:24:45,710 one question. Q: Thank you. On ARM it's much faster to 245 00:24:45,710 --> 00:24:51,510 boot something. It's also much simpler: You have an address, you load the bin 246 00:24:51,510 --> 00:24:58,509 file, and it boots. On x86 is much more complex, and the amount of codes you saw 247 00:24:58,509 --> 00:25:06,029 was for GRUB relates to that. So my question: I've seen Allwinner boards, 248 00:25:06,029 --> 00:25:16,720 Cortex A8, booting in four seconds just to get a shell, and six seconds to get a QT, 249 00:25:16,720 --> 00:25:21,990 so the Linux kernel pretty QT app, to do a dashboard for a car — so five to 250 00:25:21,990 --> 00:25:29,509 six seconds. So I'm wondering why is there such a big difference for a server to take 251 00:25:29,509 --> 00:25:37,500 20 or 22 seconds? Is it the peripherals that needs to be initialized or what's the 252 00:25:37,500 --> 00:25:40,980 reason for it? A: So there are several things that 253 00:25:40,980 --> 00:25:45,090 contribute to the 20 seconds, and one of the things that we're looking into is 254 00:25:45,090 --> 00:25:50,649 trying to profile that. We're able to swap out the PEI core and turn on a lot of 255 00:25:50,649 --> 00:25:56,480 debugging. And what I've seen on the Dell system, a lot of that time is spent 256 00:25:56,480 --> 00:26:01,700 waiting for the Management Engine to come online, and then there's also— it appears 257 00:26:01,700 --> 00:26:09,769 to be a one second timeout for every CPU in the system, that they bring the CPUs on 258 00:26:09,769 --> 00:26:16,360 one at a time, and it takes almost precisely 1 million microseconds for each 259 00:26:16,360 --> 00:26:21,509 one. So there are things in the vendor firmware that we currently don't have the 260 00:26:21,509 --> 00:26:27,220 ability to change — that appear to be the long tent, excuse me, long poll in the 261 00:26:27,220 --> 00:26:33,320 tent on the boot process. H: Microphone 3 in the back, please. 262 00:26:33,320 --> 00:26:40,580 Q: You addressed a lot about security, but my question is rather, there's a lot of 263 00:26:40,580 --> 00:26:47,600 settings — for example BIOS, there's UEFI settings, and there's stuff like remote 264 00:26:47,600 --> 00:26:55,360 booting — which is a whole bunch of weird protocols, proprietary stuff, and stuff 265 00:26:55,360 --> 00:27:01,740 that's really hard to handle. If you have a large installation, for example, you 266 00:27:01,740 --> 00:27:09,649 can't just say: Okay deploy all my boot orders for the BIOS settings. Are you 267 00:27:09,649 --> 00:27:14,279 going to address that in some unified, nice way, where I can say, okay I have 268 00:27:14,279 --> 00:27:22,050 this one protocol that runs on my Linux firmware that does that nicely. 269 00:27:22,050 --> 00:27:28,549 A: That's exactly how most sites will deploy it. That they will write their own 270 00:27:28,549 --> 00:27:34,570 boot scripts that use traditional — excuse me — that use normal protocols. So in the 271 00:27:34,570 --> 00:27:42,380 Mass Open Cloud they are doing a wget over SSL that can then measure the received 272 00:27:42,380 --> 00:27:51,990 kernel into the TPM and then kexec it. And that's done without requiring changes to 273 00:27:51,990 --> 00:27:56,850 in-VRAM-variables, or all the sort of setup that you have to put into to 274 00:27:56,850 --> 00:28:02,470 configuring a UEFI system. That can be replaced with a very small shell script. 275 00:28:02,470 --> 00:28:08,799 H: We have time for one last question — and this is from the Signal Angel, because 276 00:28:08,799 --> 00:28:13,669 the internet has a question. Q: Yes, the internet has two very simple 277 00:28:13,669 --> 00:28:17,950 technical questions: Do you know if there's any progress, or do you know if 278 00:28:17,950 --> 00:28:24,440 any ATAs on the Talus 2 project. And are there any size concerns when writing 279 00:28:24,440 --> 00:28:27,186 firmware in Go? 280 00:28:27,186 --> 00:28:32,690 A: So the Talus 2 project is a Power based system, and right now we're 281 00:28:32,690 --> 00:28:38,580 mostly focused on the x86 servers, since that's the very mainstream available sorts 282 00:28:38,580 --> 00:28:45,220 of boards, and the Go firmware is actually quite small. I've mostly been working on 283 00:28:45,220 --> 00:28:50,690 the Heads side, which is based on shell scripts. My understanding is that the 284 00:28:50,690 --> 00:28:55,940 just-in-time compiled Go does not add more than a few hundred kilobytes to the ROM 285 00:28:55,940 --> 00:29:03,190 image and only a few 100 milliseconds to to the boot time. The advantage of Go is 286 00:29:03,190 --> 00:29:11,210 that it is memory safe, and it's an actual programming language, so it allows the 287 00:29:11,210 --> 00:29:14,720 initialization scripts to be verified in a way that shell scripts can be very 288 00:29:14,720 --> 00:29:18,840 difficult to do. H: So thank you very much for answering 289 00:29:18,840 --> 00:29:22,080 all these questions. Please give a warm round of applause to 290 00:29:22,080 --> 00:29:30,319 Trammel Hudson. Thank you very much! *applause* 291 00:29:30,319 --> 00:29:33,539 *postroll music* 292 00:29:33,539 --> 00:29:52,000 subtitles created by c3subtitles.de in the year 2020. Join, and help us!