Micro-Renovator: Bringing Processor Firmware up to Code

Video thumbnail (Frame 0) Video thumbnail (Frame 452) Video thumbnail (Frame 1056) Video thumbnail (Frame 9882) Video thumbnail (Frame 10357) Video thumbnail (Frame 10744) Video thumbnail (Frame 17325) Video thumbnail (Frame 17792) Video thumbnail (Frame 18401) Video thumbnail (Frame 19080) Video thumbnail (Frame 23869)
Video in TIB AV-Portal: Micro-Renovator: Bringing Processor Firmware up to Code

Formal Metadata

Micro-Renovator: Bringing Processor Firmware up to Code
Title of Series
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Release Date

Content Metadata

Subject Area
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.
Befehlsprozessor Code Coprocessor Firmware
Demon Intel Code State of matter Multiplication sign Arm Software bug Magnetic stripe card Mechanism design Mathematics Insertion loss Different (Kate Ryan album) Befehlsprozessor Kernel (computing) Information security Physical system Point cloud Electric generator Intel Data storage device Sound effect Bit Flow separation Product (business) Type theory Befehlsprozessor Vector space Order (biology) System programming Website Normal (geometry) Right angle Quicksort Information security Bounded variation Physical system Firmware Laptop Surface Slide rule Link (knot theory) Patch (Unix) Real number Data storage device Web browser Coprocessor Product (business) Power (physics) Revision control Causality Operator (mathematics) Computer hardware Firmware Booting Window Operations research Standard deviation Validity (statistics) Patch (Unix) Surface Coprocessor Kernel (computing) Software Computer hardware Sheaf (mathematics) Computing platform Point cloud Window Operating system
Intel Patch (Unix) Befehlsprozessor System programming Physical system
Polar coordinate system Intel Building Structural load Code Multiplication sign 1 (number) Mereology Variable (mathematics) Non-volatile memory Sign (mathematics) Insertion loss Befehlsprozessor Kernel (computing) Core dump Physical system Graphics tablet Source code Electric generator Structural load Electronic signature Partition (number theory) Befehlsprozessor Computer configuration Order (biology) System programming Right angle Booting Point (geometry) Laptop Dataflow Booting Mobile app Existence Computer file Electronic data interchange Open source Patch (Unix) Device driver Spreadsheet Gastropod shell Utility software Booting Computing platform Polar coordinate system Patch (Unix) Code Line (geometry) Device driver Cartesian coordinate system Power (physics) Uniform resource locator Kernel (computing) Integrated development environment Personal digital assistant Mixed reality Utility software Gastropod shell Operating system Window Booting
Code Demo (music) Computer hardware Gastropod shell Drop (liquid) Line (geometry)
Thread (computing) Computer file Code Multiplication sign Sheaf (mathematics) Maxima and minima Bit Oval Computer hardware Booting Window Booting Physical system
Group action Scripting language Euclidean vector Code Software bug Medical imaging Mathematics Semiconductor memory Set (mathematics) Information security Partition (number theory) Physical system Scripting language Structural load Partition (number theory) Befehlsprozessor Computer configuration Software repository Chain System programming Normal (geometry) Information security Physical system Booting Firmware Point (geometry) Laptop Dataflow Booting Mobile app Server (computing) Patch (Unix) Connectivity (graph theory) Mobile Web Control flow Device driver Microcontroller Revision control Booting Installation art Default (computer science) Patch (Unix) Consistency Cartesian coordinate system Limit (category theory) Kernel (computing) Revision control Gastropod shell Window Booting
please join me in welcoming Matt King thank you so I'm here to talk today about a tool I wrote called micro venner micro renovator it's for patching CPU microcode and I really hope none of you have to use it so I'm at some quick
things about me that become relevant real quick here I used to actually work designing CPUs currently I work at a cloud doing hardware security things and in between I did product security validation for desktop CPUs for a very popular CPU vendor and about that sorry
I may may have missed something didn't see it coming so this was a really big deal the bugs were actually in the hardware real hard to fix but there were patches 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 a little bit of background right so everybody remembers meltdown that was fixed by patching the operating system kernels and that was all there was to it you go you patch your kernel it fixes the issue you're not vulnerable to the exploit anymore so kernel patching not fun but pretty straightforward Specter v1 required more patching because you had to go patch everything that had the new speculation gadgets in it so not just kernels browsers sandboxes Damons and anything that could potentially be used we just saw an X vector which was exploiting specter in a network connected daemon so lots of software to patch what's still just software still pretty straightforward we know how to patch software it's inconvenient but we can do it but some of the other variations too if you don't trust the ret Polina fix and for required micro code changes and this may 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 micro code but then you have to actually update the processor firmware so that the new capabilities are exposed to the operating system so it can use them to protect you from these bugs so what is micro code we have to patch it but not a lot of people really understand much about micro code or what it is for today we're just going to treat it like firmware right it's firmware that you load on to your processor I'm not going to go into a whole lot more depth about it that is a link on the slides you can click it it is very inaccurate it is not brief there's a lot there and it would waste my whole time slot to type go into it but like other kinds of firmware it can be patched 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 micro code patch so to load this to add new capabilities the big difference about micro code versus other types of firmware processors don't have persistent storage so when you load a micro code patch it only stays until the next time you reset the CPU or turn it off or reboot 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 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 this is generally then done by either your BIOS or your operating system 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 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 it will halt the system so because these patches are being reapplied by either bios to the OS that's generally where we get them from right when you when you need a new micro code 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 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 ok I see at least a couple Liars in the audience the common way is so I'm 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 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 this has been working pretty well on Linux but it's been going less well on Microsoft it took Microsoft about 2 months before they started redistributing the microcode updates and it was four or five months before they were doing it for 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 even though Intel has issued the patches Microsoft has patched their kernel you have no way to apply the microcode 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 even though all the patches I need exist and that is a little frustrating
so there and and I say many systems so I went digging there's not just these
system there's there's millions and really the only fix right go buy a new
if your vendors not doing 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 this is Windows PCs that were about three to nine years old anything older Intel has said they can't actually issue microcode pad so
they don't exist anything less than about three years old shipped with Windows 10 initially so it's not a problem there but BIOS updates are not coming quickly from a lot of these things so there are at least a couple third-party micro code update drivers that you can run in Windows but they don't actually work to patch spectre they will update your micro code but by the time they do so the Windows kernel has already started up tried to find the new capabilities failed to do so early in boot and decided they can't use them so it will run along and you'll have the new micro code but the kernel will not be making use of it at that point 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 core iSeries which are the ones giving patches and something like half a billion of them maybe can't actually update right now if anybody has better data I'm happy to update my spreadsheet that I used to generate this but if you look around and I did go look around most laptops in our sixth generation and beyond which is skylake are getting BIOS updates 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 have only seen BIOS updates for Xeon platform so no laptop or desktop systems are really getting updates there so this sucks right that's a lot of systems that can't patch in my case I only have one that I actually can't patch that I care about but that's still one too many so I started thinking when can these micro code updates be applied right BIOS can do it but I can't actually go modify my BIOS it's a sign package if I change micro code file in there it won't work it'll fail the signature check 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 so I went looking and unfortunately there was no efi utility in existence earlier this year that could actually do a micro code load from an EFI shell or Nafi environment the code to do it is already part of the open source UEFI codebase but it basically had hard pointed the data file to use to the you know known location that I couldn't modify but this is this is all open source code right and the codes there 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 I knew I knew what I was going into and I expected this was going to take me months of effort just to like get hello world to build but it didn't edie k2 has come a really long way I hadn't 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 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 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 BIOS you know has a UEFI now because this only works for you if I boot 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 we don't have to understand and then it goes and runs an EFI application right normally that ef5 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 boot loader after it finishes so let's try that so you can see this is the Windows
booted up you can see from the top line that's in red that the hardware support provided by the new micro code was not there that's what the top line and it just said the hardware support wasn't ready 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 micro code file that's the section in the middle it's telling you about it and in 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 boot loader again I added some breakpoints 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 so it does make boot a little bit longer but not substantially and now back in Windows hopefully this will get up soon and there we go and now you can see it's green the hardware supports they're detected the new micro code and we are [Applause]
so I wrote some scripts to install this automatically it goes and it modifies the EFI boot partition on a Windows system to load the microcode loader app it runs off a Linux live CD so you can just take like in a bun - or a fedora live CD image based off their website boot into it check out to get this repo from github and run the installer and it will go and it will detect your CPU version it will try and find updated micro code for it 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 will run before the windows bootloader on every startup there are some limitations so as I mentioned earlier this breaks sleep hibernation still works but because the you don't go through the normal boot flow on a wake from sleep this doesn't get run and the kernel panics and locks up real hard I don't currently support secure boot with this yet I just haven't gotten around to adding support for that it's I have seen some inconsistent behavior from Windows after booting sometimes I suspect I have left some things in memory that I shouldn't have in my application rebooting tends to fix that and I can't promise this will continue to work for very long Microsoft has already once started reverting the changes I've made to the boot partition about a month and a half ago a Windows Update started 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 to summarize right I get it firmware patching is real hard and I know Microsoft is is trying you if the change from BIOS to you if I should have made things better as with regards to patching and it really didn't but you know we're not we're not writing security patches for things 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 either not issuing patches or then making it even harder to apply updates when you're not supporting them it really seems not helpful and as an industry as a security industry industry if we're not like enabling users to make their systems more secure we're failing we're failing really bad and so as I said at the beginning I hope nobody has to use this because really what should happen is you know BIOS vendors OS vendors should be including these patches themselves and we shouldn't be going around hacking boot loaders just to patch our systems from security bugs
questions so yeah so the question is have I considered installing on the driver chain instead of is abou action so the problem is the Microsoft microcode driver is assigned package that includes both like the driver component and the microcode component oh the UEFI driver oh no I have not tried installing as you if I driver it might I will look into that so the question was our microcontroller is also affected by this so so this is or design for basically desktop laptop laptop server CPUs that have microcode patches that need to be applied so anything x86 that loads microcode this should work with although most microcontrollers we're not really impacted by spectre yeah any other questions okay thank you very much [Applause]