We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Micro-Renovator: Bringing Processor Firmware up to Code

00:00

Formale Metadaten

Titel
Micro-Renovator: Bringing Processor Firmware up to Code
Serientitel
Anzahl der Teile
322
Autor
Lizenz
CC-Namensnennung 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
The mitigations for Spectre highlighted a weak link in the patching process for many users: firmware (un)availability. While updated microcode was made publicly available for many processors, end-users are unable to directly consume it. Instead, platform and operating system vendors need to distribute firmware and kernel patches which include the new microcode. Inconsistent support from those vendors has left millions of users without a way to consume these critical security updates, until now. Micro-Renovator provides the ability to apply microcode updates without modifying either platform firmware or the operating system, through simple (and reversible) modifications to the EFI boot partition.
BefehlsprozessorCodeCoprozessorFirmware
HardwareValiditätProdukt <Mathematik>BefehlsprozessorComputersicherheitPunktwolkeHardwareValiditätProdukt <Mathematik>IntelExogene VariableComputersicherheitSampler <Musikinstrument>FirmwarePunktwolkeSystemplattform
BetriebssystemMathematikOrdnung <Mathematik>SoftwareTypentheorieBildschirmfensterGenerator <Informatik>GrenzschichtablösungPhysikalischer EffektAggregatzustandBefehlsprozessorBitPhysikalisches SystemVerschlingungQuick-SortVersionsverwaltungNichtlinearer OperatorCoprozessorProgrammfehlerFirmwareNotebook-ComputerDämon <Informatik>InformationsspeicherungKernel <Informatik>FlächentheorieSoundverarbeitungWeb SiteDifferentePatch <Software>MultiplikationsoperatorStandardabweichungMechanismus-Design-TheorieGeometrische FrustrationBildschirmfensterBefehlsprozessorGarbentheorieIntelPhysikalisches SystemNichtlinearer OperatorCoprozessorProgrammfehlerMagnetkarteComputersicherheitFirmwareInformationsspeicherungKernel <Informatik>Kartesische KoordinatenEinfügungsdämpfungFlächentheoriePatch <Software>ARM <Computerarchitektur>
NeuroinformatikBildschirmfensterBefehlsprozessorIntelPhysikalisches SystemEingebettetes SystemPatch <Software>Computeranimation
BildschirmfensterPolarkoordinatenNetzbetriebssystemBildschirmfensterBefehlsprozessorIntelPhysikalisches SystemPolarkoordinatenEingebettetes SystemPatch <Software>Computeranimation
CodeMathematikOrdnung <Mathematik>CodierungTabellenkalkulationGebäude <Mathematik>BildschirmfensterGenerator <Informatik>ProgrammierumgebungBefehlsprozessorFunktionalGeradeLastMereologiePhysikalisches SystemProjektive EbeneSpeicherabzugTreiber <Programm>SystemprogrammElektronische UnterschriftNabel <Mathematik>Notebook-ComputerExistenzsatzPunktKernel <Informatik>Kartesische KoordinatenElektronische PublikationBootenOpen SourcePatch <Software>SystemplattformMultiplikationsoperatorURLEinsCodeBildschirmfensterVariableKonfiguration <Informatik>BefehlsprozessorIntelLastLeistung <Physik>Physikalisches SystemTreiber <Programm>SystemprogrammNabel <Mathematik>PartitionsfunktionKernel <Informatik>Kartesische KoordinatenEingebettetes SystemEinfügungsdämpfungQuellcodeBootenPatch <Software>Nichtflüchtiger Speicher
HardwareGeradeNabel <Mathematik>Demo <Programm>Computeranimation
BildschirmfensterGarbentheoriePhysikalisches SystemThreadElektronische PublikationMultiplikationsoperatorOvalIntelligentes NetzComputeranimation
HardwareBitSkriptspracheBootenComputeranimation
Bildgebendes VerfahrenMathematikHalbleiterspeicherBildschirmfensterBefehlsprozessorPhysikalisches SystemDatenflussVersionsverwaltungNormalvektorComputersicherheitPunktRepository <Informatik>PartitionsfunktionKontrollstrukturKernel <Informatik>Kartesische KoordinatenInstallation <Informatik>BootenNP-hartes ProblemPatch <Software>DefaultApp <Programm>MathematikHackerBildschirmfensterKonfiguration <Informatik>Inverser LimesPhysikalisches SystemVersionsverwaltungZusammenhängender GraphComputersicherheitFirmwareNabel <Mathematik>Dämon <Informatik>PartitionsfunktionKontrollstrukturSchnittmengeSkriptspracheBootenPatch <Software>HoaxMinkowski-MetrikMobiles Internet
MikrocontrollerBefehlsprozessorKette <Mathematik>LastTreiber <Programm>ServerZusammenhängender GraphNotebook-ComputerPatch <Software>Computeranimation
Transkript: Englisch(automatisch erzeugt)
Please join me in welcoming Matt King. Uh, thank you. So, I'm here to talk today about a tool I wrote called micro-renovator. 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 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. Uh, uh, uh, uh, uh, uh, uh, 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 net specter, which was exploiting specter in, 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
repoline 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 gonna treat it like firmware, right? It's firmware that you load onto your processor, uh, I'm not gonna 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 errata, 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, 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 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 vendor's website, you know, weekly, checks for BIOS updates and then downloads them? Okay, I see at least a couple of 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 2 months before they started redistributing the microcode updates, uh, and it was 4 or 5 months before they were doing it for, uh, most of the Intel CPUs. They sort of rolled them out slowly for 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 now is to 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 3 to 9 years old. Um, anything older, Intel has said they can't actually issue microcode patches, so they don't exist. Uh, anything less than about 3 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 can find, there's somewhere on the order of 2 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 used 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 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 that 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 the 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, EDK2 has come a really long
way. Uh, I had a functioning build environment in less than half an hour, and that was mostly because I screwed up installing a couple of dependencies on the first try. Um, so I started cutting and pasting code from the existing update routine into a
project 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. Ok, 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
UEFI 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 going to reboot and we're going to 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 that section at the bottom, there's four threads in the system. It loaded the microcode to all four threads. And then we start running the Windows bootloader again. Um, I added some breakpoints in there so you could see it because, uh, 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 a Fedora
live CD image based off their website, uh, boot into it, check out the Git, 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. Um, 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 weeks. So, uh, to summarize, right, I, I get it. Firmware patching is real
hard and I know Microsoft is, is trying. Um, UEFI, the change from BIOS to UEFI should have made things better as, 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, you know, either not issuing patches or then making it even harder to apply updates when you're not supporting them 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 boot loaders 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 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, design for basically desktop, laptop, laptop
server CPU's 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? Alright, thank you
very much.