 please join me in welcoming Matt King. Thank you. So I'm here to talk today about a tool I wrote called Microvenor, Microrenovator. It's for patching CPU microcode and I really hope none of you have to use it. Um, so I'm Matt. Uh, some quick things about me that become relevant real quick here. I used to actually work designing CPUs. Uh, currently I work at a cloud doing hardware security things. And in between, uh, I did product security validation for desktop CPUs for a very popular CPU vendor. And, uh, about that, um, sorry, uh, I may, I may have missed something. Uh, didn't see it coming. So, uh, this was a really big deal. Uh, the bugs were actually in the hardware, uh, real hard to fix, but there were patches. Uh, and there were several different kinds of patches for the different kinds of bugs. And so that's really what we're talking here today is about some of those patches. Um, a little bit of background, right? So everybody remembers Meltdown. Uh, that was fixed by patching the operating system kernels. Uh, and that was all there was to it. You go, you patch your kernel. Uh, it fixes the issue. You're not vulnerable to the exploit anymore. So, kernel patching, not fun, but pretty straightforward. Uh, Spectre V1 required more patching. Um, because you had to go patch everything that had the new speculation gadgets in it. So, not just kernels, browsers, sandboxes, uh, daemons, and anything that could potentially be used. Uh, we just saw NetSpectre, which was exploiting Spectre in a network connected daemon. So, lots of software to patch, but still just software. Uh, still pretty straightforward. We know how to patch software. It's inconvenient, but we can do it. Uh, but some of the other variations, um, two, if you, uh, don't trust the REC Peline fix, and four, uh, required microcode changes. And, um, this means you have to actually go patch the CPU firmware in order for the software fixes to take effect. So you have to do two things, which is you have to get the kernel patches to use the new microcode, but then you have to actually update the processor firmware so that the, uh, the new capabilities are exposed to the operating system so it can use them to protect you from these bugs. So, what is microcode? We have to patch it, but not a lot of people really understand much about microcode or what it is. Uh, for today, we're just going to treat it like firmware, right? It's firmware that you load onto your processor. Uh, I'm not going to go into a whole lot more depth about it. Um, that is a link on the slides. You can click it. It is very inaccurate. It is not brief. Um, there's a lot there, and it would waste my whole time slot to go into it. Um, but like other kinds of firmware, it can be patched. Uh, and it happens semi-regularly to fix bugs and other orata. And this was not really any different. Spectre wasn't using any new capability in the CPU that didn't exist before. It was just using the standard microcode patch to load this, uh, to add the new capabilities. The big difference about microcode versus other types of firmware, um, processors don't have persistent storage. So when you load a microcode patch, uh, it only stays until the next time you reset the CPU or turn it off or reboot. Um, even going to sleep causes the microcode patch to get lost because it's just stored non-persistently. So anytime the CPU loses power, it goes away and you have to reload it when the system comes back up. Um, that means that some bit of software has to store this patch file and reload it very early on when you turn the system back on. Uh, this is generally then done by either your BIOS or your operating system. Um, and it happens every time you boot, right? Either BIOS does it or the operating system does it on every boot, every reset, every wake from sleep. Um, anything that really changes the state of the processor and causes that to go away. So they have to be aware of the patch. They have to know it's there and they have to remember to reload it because if the system is depending on that patch and you go through a sleep wake cycle and you lose it and it's not there when you come back and something is expecting it, uh, it will halt the system. So because these patches are being reapplied by, uh, either BIOS or the OS, that's generally where we get them from, right? When you, when you need new microcode, uh, you can go to Intel's website and download it, but that doesn't do a lot because you still have to get some of your software to load it. And so, uh, BIOS updates are the most reliable way of doing it, but like quick show of hands, who goes to their laptop vendors website, you know, weekly checks for BIOS updates and then downloads them. Okay, I see at least a couple liars in the audience. Um, the common way is, so really unless you're running like a MacBook or a Surface where your OS updates are also your firmware updates, it tends to not happen reliably. Um, the other common method is your operating system will distribute the updates. They'll get them from Microsoft, they'll drop them in a package and they'll redistribute them through the normal OS update mechanism. Uh, this has been working pretty well on Linux, but it's been going less well on Microsoft. Uh, it took Microsoft about two months before they started redistributing the microcode updates. Uh, and it was four or five months before they were doing it for, uh, most of the Intel CPUs, they sort of rolled them out slowly for older and older generations of CPUs and they're still only doing this in Windows 10. So if you have an older version of Windows on your laptop, you can't actually get fully patched for Spectre. Uh, even though Intel has issued the patches, Microsoft has patched their kernel, you have no way to apply the microcode. Um, I have a system at home that is in this state that I can't actually patch for Spectre using any officially supported tool right now. Uh, even though all the patches I need exist. And that is a little frustrating. So, um, there are, and, and I say many systems, uh, so I, I went digging, um, there's not just a system, there's, there's millions. Um, and really the only fixed right is go buy a new computer if your vendor's not issuing a BIOS update or go buy a new operating system if you're still, if you're new enough to be supported by Windows 10. Um, this is Windows PCs that were about three to nine years old. Um, anything older Intel has said they can't actually issue microcode patch so they don't exist. Uh, anything less than about three years old shipped with Windows 10 initially. So it's not a problem there. Um, but BIOS updates are not coming quickly from a lot of these things. Uh, so there are at least a couple third party microcode update drivers that you can run in Windows, but they don't actually work to patch Spectre. They will update your microcode, but by the time they do so, uh, the Windows kernel has already started up, tried to find the new capabilities failed to do so, uh, early in boot and decided they can't use them. So it will run along and you'll have the new microcode but the kernel will not be making use of it at that point. Um, based on the publicly available data I could find, there's somewhere on the order of two and a half billion Intel CPUs that shipped, uh, core i-series, which are the ones getting patches, and something like half a billion of them maybe can't actually update right now. Uh, if anybody has better data, I'm happy to update my spreadsheet that I use to generate this. Um, but if you look around, uh, and I did go look around, most laptop, most systems less than, uh, or sixth generation and beyond, which is Skylake, are getting BIOS updates. Um, fourth and fifth generation, it's kind of spotty, it's a mix. Some vendors have done it, some haven't. And anything third generation or older, I've only seen BIOS updates for Xeon platform. So no laptop or desktop systems are really getting updates there. Uh, so this sucks, right? That's a lot of systems that can't patch. Uh, in my case, I only have one that I actually can't patch that I care about, but that's still one too many. Um, so I started thinking, when can these microcode updates be applied? Right? Um, BIOS can do it, but I can't actually go modify my BIOS. Uh, it's a signed package. If I change the microcode file in there, it won't work, it'll fail the signature check. Uh, the same thing with the OS, the built-in files are all signed drivers by Microsoft, I can't change them or they'll stop working. So where else can I do this? Maybe in the bootloader. Um, so I went looking. And unfortunately there was no EFI utility in existence earlier this year that could actually do a microcode load from an EFI shell or an EFI environment. Um, the code to do it is already part of the open source UEFI code base, but uh, it basically had hard pointed the data file to use, uh, to the, you know, known location that I couldn't modify. Um, but this is, this is all open source code, right? And the code's there, uh, how hard could it be to turn it into something I could run myself? And I see people in the front snickering because the first time I tried to actually build something in EFI, it took the better part of a day to get a working build environment. So when I asked myself how hard could this be, uh, I knew, I knew what I was going into and I expected this was going to take me, uh, months of effort just to like get Hello World to build. Um, but it didn't. Uh, EDK 2 has come a really long way. Uh, I hadn't functioning build environment in less than half an hour and that was mostly because I screwed up installing a couple dependencies on the first try. Um, so I started cutting pasting code from the existing update routine into a standalone app that I could run myself and it worked. That was, I expected this to be a more interesting part of the talk but it really wasn't because it's a few hundred lines of code that I copied. Okay, so now I've got this, I need to run it. Uh, BIOS, you know, has a, or UEFI now because this only works for UFI boot. Um, but it's a, it's a pretty simple flow. It does a whole bunch of stuff we don't actually care about right now. Uh, we don't have to understand. Um, and then it goes and runs an EFI application. Right? Normally that EFI application is your Windows bootloader, but it doesn't have to be. You can change that and we can run our application first and then run the Windows bootloader after it finishes. So, let's try that. Uh, so you can see this is the, the Windows booted up. You can see from the top line that's in red that the hardware support provided by the new microcode was not there. Uh, that's what the top line meant. It just said the hardware support wasn't ready. Um, so we're gonna reboot and we're gonna drop into an EFI shell. There it is. And you're going to see it parses the microcode file. That's the section in the middle. It's telling you about it. And then that section at the bottom, there's four threads in this system. It loaded the microcode to all four threads. And then we start running the Windows bootloader again. Um, I added some break points in there so you could see it because without them it only takes like maybe a second and you wouldn't have had time to see it. Um, so it does make boot a little bit longer but not substantially. Uh, and now back in Windows, hopefully this will get up soon. There we go. And now you can see, uh, it's green. The hardware support's there. It detected the new microcode. And we are patched. So, I wrote some scripts to install this automatically. Uh, it goes and it modifies the EFI boot partition on a Windows system to load the microcode loader app. Uh, it runs off a Linux live CD so you can just take like an Ubuntu or Fedora live CD image based off their website. Uh, boot into it. Check out the get this repo from GitHub. Um, and run the installer. And it will go and it will detect your CPU version. It will try and find updated microcode for it. Uh, and then it will copy that and all the EFI apps it needs onto the boot partition and set them as the default boot target so that it will run before the Windows boot loader on every startup. Uh, there are some limitations. So, as I mentioned earlier, uh, this breaks sleep. Um, hibernation still works but because the, you don't go through the normal boot flow on a wake from sleep, uh, this doesn't get run and the kernel panics and locks up real hard. Um, I don't currently support secure boot with this yet. Uh, I just haven't gotten around to adding support for that. Um, it's, I've seen some, uh, inconsistent behavior from Windows after booting. Sometimes I suspect I have left some things in memory that I shouldn't have in my application. Um, rebooting tends to fix that. Uh, and I can't promise this will continue to work for very long. Uh, Microsoft has already once started reverting the changes I've made to the boot partition. Uh, about a month and a half ago a Windows update started, um, rolling back my changes on every Windows boot. So I had to make some modifications and it works now but I also haven't run Windows update in a couple of weeks. So, uh, to summarize, right, I, I get it, firmware patching is real hard and I know Microsoft is, is trying. Um, UEFA, the change from BIOS to UEFI should have made things better with regards to patching and it really didn't. Um, but, you know, we're not, we're not writing security patches for things, uh, just to put out a press release saying we wrote a security patch, that's not the point, right? The point is to make end users more secure and going around and, you know, say, uh, either not issuing patches or then making it even harder to apply updates when you're not supporting them, it really seems, uh, not helpful. And as an industry, as a security industry, if we're not like enabling users to make their systems more secure, we're failing. Uh, we're failing really bad. And so, uh, as I said at the beginning, I hope nobody has to use this because really what should happen is, uh, you know, BIOS vendors, OS vendors should be including these patches themselves and we shouldn't be, uh, going around hacking bootloaders just to patch our systems from security books. Questions? So, uh, yeah, so the question is, have I considered installing on the driver chain instead of as a boot action? So the problem is, uh, the Microsoft, uh, microcode driver is a signed package that includes both like the driver component and the microcode component. Oh, the UEFI driver. Oh, so, no, I have not tried installing it as a UEFI driver. It might, I will look into that. Uh, so the question was, are microcontrollers also affected by this? So, so this is for, uh, designed for basically desktop, laptop, laptop, server, CPUs that have microcode patches that need to be applied. So anything, uh, x86 that loads microcode, this should work with although, uh, most microcontrollers were not really impacted by Spectre. Yeah. Uh, any other questions? All right. Thank you very much.