Windows: How to get latest CPU microcode without modding the BIOS

Is there an easy way to tell what model CPU are supported/updated, since Intel said 5 yrs only, so I am guessing my 3750k is not getting updates.
Not that I am really worried most all software is getting patched now.

 

Just install this VMware driver with this newest microcode.dat and see what driver will say about microcode update.

Btw, PowerShell command output has changed with this updated microcode:

Spoiler

PS> Get-SpeculationControlSettings
Speculation control settings for CVE-2017-5715 [branch target injection]
Hardware support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: False
Windows OS support for branch target injection mitigation is disabled by system policy: False
Windows OS support for branch target injection mitigation is disabled by absence of hardware support: False
Speculation control settings for CVE-2017-5754 [rogue data cache load]
Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID optimization is enabled: False
Suggested actions
* Follow the guidance for enabling Windows support for speculation control mitigations are described in https://support.microsoft.com/help/4072698
BTIHardwarePresent : True
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : False
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : False
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled : False

But still "Windows OS support for branch target injection mitigation is enabled: False". I should dig whether to enable it and how.
https://support.microsoft.com/en-us...ive-execution-side-channel-vulnerabilities-in
Did the registry trick and now to reboot... Brb.

 

well thats promising, at least if ivy gets the patch, then people have the option to dropin a newer cpu on old 6 series boards.

 

But there is trouble with VMware driver method - I guess since it is loaded after the kernel is initialized kernel sees no HW support for BTI and doesn`t enable mitigation. I will try to play with the order of this driver loading but I prepare myself for the worst case- modding the BIOS file and flashing with USB flashback.

Update: And no luck. So looks like VMware driver method of CPU microcode update is not suited for security mitigations in case of CPUs without HW support for BTI (because kernel doesn`t turn mitigation on).

 

Loading microcode by software at boot should take practically, and almost literally, no time. It's vastly preferable to the considerable risk of bricking your motherboard or worse, which comes with BIOS modding. There's a reason that's warranty voiding behaviour, and just because warranty has expired doesn't make it less of a bad idea. If you personally are comfortable with BIOS modding, have at it you beast, but it is NOT something which should be recommended to the masses, when there is an alternative like this VMWare tool.

Microcode is stored in nonvolatile memory and must be loaded at every boot anyway. And I can assure you that linux boots significantly faster than windows already, while loading CPU microcode via a software mechanism. Writing a few KB to CPU doesn't take long.

As per my previous link, take a look at
HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0
If 'Previous update revision' and 'Update revision' are different, you already load new microcode at boot, via software. For example, my 5820K reads 2d and 3e respectively. Oh and it boots windows faster than it POSTs...

Which leads us back to the important question here: Why is this microcode update not being delivered via a Windows Update, as has been done in the past?

Edit: going by the above post, perhaps it is because microsoft couldn't figure out a way to make the kernel load the new microcode in the proper order. Works on linux. Seems to me they need to work on this some more.

 

Besides the jibberish of windows vs linux, which has no bearing to the discussion I might add, Windows does load newer microcode too at boot if it detects database is newer than bios. Problem is it's not been updated since 2015. It will surely be updated at some point soon.

As for your risk factor, there is hardly any.
There are tools that can automatically do things like updating microcode in a bios(masses don't need to do it by hand)
If you aren't sure of doing it yourself, there are plenty of threads that do bios requests so that's also an option.

Secondly, there is no voided warranty from this.
It's not easily detectable, certainly way above the RMA department's ability anyways.

Plus, most boards have bios flashback or a secondary bios so these risks are very low with that being said.

VMware tool is more work.

Time to update bios with latest microcode with UBU tool? 2 mins.
Then all one has to do is flash the updated bios.

 

And I am back with new shiny HW support for BTI mitigation and enabled mitigation. Looks like I was right - kernel is loaded before most of drivers/services. I was forced to use USB flashback method.

Big problem with UBU of the latest version (v1.69.6) is - it processes CPU microcodes for 2011 platform CPUs differently comparing to others. So I made a serious work to insert microcode to BIOS file:
- found how to extract CPU microcodes from container "microcode.dat" in the form of bin-files;
- found how UBU works with bin-files;
- corrected the part of bat-file for 2011 patform CPUs;
- ran UBU and modified the original BIOS file;
- checked CPU patches in BIOS file just in case;
- found BIOS manual to refresh the USB flashback process in my memory;
- created two USB flash drives with modified and with original BIOSes;
- started USB flashback and prayed.

 

either i not reading at right or i find the instruction confusing.

Aida64 says i have 74h which sure is old cause there have been atlest 3 bios update since my 3.20 from asrock z170 extreme 4 that had microcode updates, I really hope that MS just pushes the microcode updates needed to people other wise majority of people will never get those updates

 

Let me be clear here. I'm not interested in a circular argument with a hurt dude on the internet who gave out bad advice and wants to rage at me for saying so.

 

Hurt? What are you talking about.

You were ranting about windows vs linux in a negative tonality which added nothing to the discussion.
If this is your attempt at trolling it's a poor attempt; if not, you have very poor forum etiquette and lack the ability to have a proper discussion

I haven't tried the latest but I have updated 2011 systems before with it, no different than mainstream platforms.

 

Me too, but since then it was changed to work with bin-files extracted from "microcode.dat" container - except for 2011 platform. These bin-files are converted into ffs-files (on the fly) before patching the BIOS file. And 2011 platform stayed with several old ffs-files.

 

It is possible to chainload windows after running a microcode update via biosbits bootloader,
but thats pretty complicated to setup, only recommend if you don't have bios recovery options, and can't afford long term downtime

https://github.com/biosbits/bits

 

So this is not a real microcode update process, just some Windows driver?

 

It is real microcode update made by driver on every boot of Windows.

 

There's more to this than BIOS recovery options. Incorrectly modifying your BIOS can permanently damage your hardware. To make a simple example, what do you think happens if you overwrite bits which control voltages to your CPU, RAM, or PCI slots? Things get fried. As I've said before, there are reasons why modded BIOSes break warranties. If it's unavoidable, and/or you can afford to replace all your gear, then it's a viable last ditch. But it should be considered exactly that.

It is 'real'. This is the way Windows and Linux and various other OSs do it. Microcode updates are not a one-time thing, it has to be done every time you boot. It's just a matter of writing some data to the CPU, but that data is stored in non-volatile memory, meaning, when you power off/reboot, it is gone. Using the OS kernel is a good way to do that, and kernel-level drivers are a good way to implement such a feature. The tool in this thread is just a driver not made by microsoft, but by VMWare. There's also the one which is part of windows (which sadly does not yet implement this new microcode), and of course, the BIOS can do it.

Guys, again I should remind you that we are mere hours past the official earliest release date for updates. Patience is in order here.
By all means, if, in the following weeks or months (yes, you should expect it to take that long), you learn through a reliable source (read: the vendor) that your vendor definitely will not be providing an update, ever, and no software solution presents itself (obviously, people are working on it!), and you are technically adept, and financially free to risk frying your gear, it's maybe time to mod the BIOS. Until then just chilllllllll

I feel you, guys, I do. I'm sitting here refreshing my vendors' BIOS update pages about every nanosecond or so. We all want the full fix and we all want it yesterday. But don't allow your sense of urgency to damage your calm. There's a massive amount of misinformation and hysteria surrounding this issue, and with good reason. It's a really, really big deal. But we are little fish in a real big pond. End-users at home are last on a long list of people waiting for fixes. It might take a while.

 

No, I was pointing out that it is possible for the OS to perform the task we require, using linux as an example. There was negativity because it is not a positive thing that Windows has failed to do this. Windows users should be asking for a better implementation from Microsoft. It adds to the discussion because it informs users that it is possible for their operating system to do the job and gets them asking why it is not doing so. This creates a positive movement toward a solution from our vendor.

it's not that I lack the ability to have a proper discussion, it's just that you're wrong, got hurt about my saying so, started throwing around words like "jibberish" in your first reply, demonstrating your own poor etiquette, and accordingly, I lack not the ability but the desire to have any discussion with you. That is why I have added you to my ignore list. Good bye.

 

I don't know what Microsoft's thinking is. Making microcode updates easy shouldn't be that hard. I'd like to be able to do it the same way as on Linux, where I can put the microcode files in a special directory, and the kernel automatically loads them from there at boot.

Download the files, put them in the /lib/firmware/intel-ucode directory, done. The kernel automatically looks there for microcode files, picks up the file that matches the system's CPU and applies the microcode. Why can't MS do the same?

 

Well said. But I did the modding not out of hysteria but out of interest. On the way I learned one new tool (MCExtractor), modified one familiar tool (newest UBU bat file), and managed to not brick my rig. Satisfaction was big.

Microsoft is known to be slow and secretive (hiding many features and tools).

PS Also I turned PowerShell script for checking the status of mitigations to .Net application
https://forums.guru3d.com/threads/u...7-5715-and-cve-2017-5754-status-check.418918/

 

Besides the fact that I was ignored, to correct this guys own misinformation.

Nope, modifying a bios does not damage hardware.

The chance that 'bits' are overwritten incorrectly will turn into a no post situation.
Sorry but changing a few bits is not going to cause physical damage period.

Changing a few bits is not going to make your RAM or PCI slots implode.
As for your CPU voltage, that's not going to happen as many bits have to be flagged to be changed from auto voltage.

Yeah you could change default manual voltage but it won't do any good because manual voltage must be enabled in the first place.
Considered as a list ditch?

Risks are very small with today's user friendly tools available for such modifications.
This is just a rant of someone who has zero experience of anything BIOS related.

As for any small chance that does arise, many boards have removable BIOS chips(Which are cheap to replace) along with dual bios and USB flashback support.

Windows can and does, the problem is the microcode library has not been updated in a while.

 

I did the same I was a hardware dev back in the 90s so this was right up my alley. I guess we have a strange idea of fun hahaha Nerds gon' Nerd! XD

Sorry if you felt I was pointing that 'hysteria' tag at you, I wasn't. When I wrote that I was thinking about a bunch of news sites I've read over the past few days. I can see your method, you tried the update via the vmware driver and everything was flagged like it should work but didn't, realised it's about the order of execution, and wanted to try things in a different order. In doing so, you've not only fixed your own PC, but given us a very strong hint as to why Microsoft aren't using their tools to update the microcode. GG, WP.

I don't know if you guys realise this, but search engines return this thread pretty high up the list, when you go looking for info about the microcode. My concern is not about nerds like us, it is, as I've said earlier, about average joe reading this thread and trying bios mods because they read it on the internet it must be a good idea.... I'd like a dollar for every post on some forum somewhere telling people to do something they really ought not do