Micro-Renovator: Bringing Processor Firmware up to Code
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| 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 | 10.5446/39715 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
DEF CON 26262 / 322
18
27
28
40
130
134
164
173
177
178
184
190
192
202
203
218
219
224
231
233
234
235
237
249
252
255
268
274
287
289
290
295
297
298
299
302
306
309
312
315
316
00:00
BefehlsprozessorCodeCoprozessorFirmware
00:18
HardwareValiditätProdukt <Mathematik>BefehlsprozessorComputersicherheitPunktwolkeHardwareValiditätProdukt <Mathematik>IntelExogene VariableComputersicherheitSampler <Musikinstrument>FirmwarePunktwolkeSystemplattform
00:42
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>
06:35
NeuroinformatikBildschirmfensterBefehlsprozessorIntelPhysikalisches SystemEingebettetes SystemPatch <Software>Computeranimation
06:54
BildschirmfensterPolarkoordinatenNetzbetriebssystemBildschirmfensterBefehlsprozessorIntelPhysikalisches SystemPolarkoordinatenEingebettetes SystemPatch <Software>Computeranimation
07:10
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
11:33
HardwareGeradeNabel <Mathematik>Demo <Programm>Computeranimation
11:52
BildschirmfensterGarbentheoriePhysikalisches SystemThreadElektronische PublikationMultiplikationsoperatorOvalIntelligentes NetzComputeranimation
12:16
HardwareBitSkriptspracheBootenComputeranimation
12:43
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
15:55
MikrocontrollerBefehlsprozessorKette <Mathematik>LastTreiber <Programm>ServerZusammenhängender GraphNotebook-ComputerPatch <Software>Computeranimation
Transkript: Englisch(automatisch erzeugt)
00:00
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
00:24
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
00:42
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
01:02
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
01:22
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
01:45
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
02:06
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
02:21
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
02:41
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
03:02
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
03:25
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
03:44
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
04:03
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
04:26
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
04:40
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
05:01
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,
05:24
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
05:42
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
06:03
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
06:23
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,
06:47
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
07:01
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
07:24
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
07:45
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
08:06
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,
08:23
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
08:46
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,
09:03
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
09:25
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
09:44
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
10:02
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
10:26
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
10:43
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
11:06
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
11:21
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
11:43
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.
12:00
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
12:26
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
12:51
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
13:01
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
13:22
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
13:41
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
14:01
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
14:22
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
14:44
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
15:05
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
15:26
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
15:43
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.
16:01
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.
16:40
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
17:03
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
17:23
very much.