Microcode for Spectre and Win 7:

Topic

New Reply

Hi Everyone-

This one has been nagging me for weeks, now. Microsoft is not supplying microcode for Win 7 Spectre vulnerability as part of their patches, and may or may not ever do so.  Now:

1) In the past. I remember them supplying microcode (or mitigation) for Meltdown/Total Meltdown as part of one patch or another during that frumus. Steve Gibson’s InSpectre version 8 says I’m protected, but at a performance loss, and no Spectre protection.

2) I’ve been agonizing about whether or not I should get the microcode download from Intel and install it.  My position up to this point is that I have not wanted to do this, as Spectre is very hard to implement. But with all these variants popping up again…aaargh.

3) I’m not even sure HOW to go about downloading the microcode from Intel and installing it…though they say my “Ivy Bridge” microcode fix for my processor in in the “production” stage.  Does that mean it’s for general use for the public, or just manufacturing environments?  https://newsroom.intel.com/wp-content/uploads/sites/11/2018/03/microcode-update-guidance.pdf

4) Dell lists my laptop as vulnerable “critical” and recommend I download and install their BIOS update. http://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driverId=TTD6M

I come from a time when flashing the BIOS was very dangerous and could brick your machine.  I have great deal of trepidation about that. So:

A) Do I sit still, and hope MSFT comes up with a microcode fix for Spectre inside a future patch?

B) Do I (somehow) download (where?) the microcode from Intel and apply it? (How?)

C) Do I download and flash the BIOS from Dell?

D) Should I just sit still and do nothing, since the whole Spectre thing is still in play, and new microcode and/or BIOS ALSO has a system performance hit? (Also, it’s still very hard to implement, but what about the new variants?)

…I’m very conflicted and confused.  I’ve built 2 PC’s and one PC super-workstation over the years (this is my first laptop), but I just bewildered.

PC stats below.

Win7 Pro SP1 64-bit, Dell Latitude E6330, Intel CORE i5 "Ivy Bridge", 12GB RAM, Group "0Patch", Multiple Air-Gapped backup drives in different locations. Linux Mint Greenhorn
--
"...all the people, all the time..."Peter Ustinov ad-lib in "Logan's Run"

Reply | Quote

Replies

NTDBD,

For what it’s worth I’ve upgraded the BIOS on  3 Dell machines (2 desktops & 1 Laptop) without major incident. There was a minor problem with the upgrade on my XPS 8920 where I’d get a message every time I booted and would have to click an OK button to continue but they fixed that in about a week with a new BIOS that fixed the problem.

My advice would be to load the latest BIOS (from the Dell Support Page) if it has been available for at least a month (time to find bugs like the one I mentioned above). That said, make sure your battery is fully charged ( in case of power fluctuations/outages) and that you are plugged in. Personally, I have all my computers on UPS systems as our power has a lot of minor fluctuations.

As always YMMV!

HTH 😎

May the Forces of good computing be with you!

RG

PowerShell & VBA Rule!
Computer Specs

4 users thanked author for this post.

Kirsty, Elly, Nibbled To Death By Ducks, Microfix

Reply | Quote

If it helps, here’s another small bit of experience…

Like RG above, I’ve recently updated the BIOS on my small Dell PowerEdge T20 system (Haswell Pentium G3220) running Win 7 x64 Ultimate.

I benchmarked it carefully both before and after the BIOS updates, and before and after the application of recent Windows Updates. I found performance wasn’t negatively affected by the BIOS update alone, and the machine has been perfectly stable afterward.

Notably applying the Windows Updates afterward reduced performance significantly until I disabled the Spectre/Meltdown mitigations.

-Noel

3 users thanked author for this post.

HiFlyer, jelson, Elly

Reply | Quote

It is a lot safer nowadays to flash a bios than it was when using floppy disks with no TSR’s and a flash utility.

I’d have to agree with RetiredGeeks advice.

Noel Carboni has recently updated his dell bios without a problem and published an article with a pre/ post benchmarks once patched up to date on W7.

Noel’s PerformanceTests

Keeping IT Lean, Clean and Mean!

2 users thanked author for this post.

Noel Carboni, Nibbled To Death By Ducks

Reply | Quote

I have not blown up a system with a bios patch.

Susan Bradley Patch Lady

2 users thanked author for this post.

Elly, Nibbled To Death By Ducks

Reply | Quote

I agree with all the comments prior to this time. Only thought I could restate a hierarchy of trust as to what entity knows the condition of the one machine most important to you. In my mind that familiarity and therefore order of trust, from most trusted to less trusted would be:

Dell
Intel
Microsoft

And I would seek solutions in that order. Stopping at the point that I was comfortable with the performance and protection provided, and not seek to make further changes.

4 users thanked author for this post.

HiFlyer, Elly, Noel Carboni, Nibbled To Death By Ducks

Reply | Quote

Forgot To Add:

This is my ONLY machine. Woody says, “If it ain’t broke don’t fix it”; maybe I should wait until it’s been confirmed there are attacks in the wild of Spectre; I mean, they have to have physical access to your machine, right?

Win7 Pro SP1 64-bit, Dell Latitude E6330, Intel CORE i5 "Ivy Bridge", 12GB RAM, Group "0Patch", Multiple Air-Gapped backup drives in different locations. Linux Mint Greenhorn
--
"...all the people, all the time..."Peter Ustinov ad-lib in "Logan's Run"

Reply | Quote

Nibbled To Death By Ducks wrote:

I mean, they have to have physical access to your machine, right?

Mostly yes, but there has been some talk that Spectre could be used against you through a “drive by” download of software (even Javascript) through your web browser.

Personally I don’t believe the threat of a “drive by” Spectre attack is greater than the threat of other attacks via things downloaded from your browser – meaning you should always be mindful of such things, and IMO take measures to limit what’s downloaded or run. While I recommend browsing with VERY few add-ons, there are a few good tools you can use that block things other than the content you want to see. One I use (in conjunction with other measures) is uBlock Origin, which can be configured not to allow contacts to literally hundreds of thousands of websites known to deliver bad things.

IMO we should not let an irrational fear of hypothetical Spectre or Meltdown drive us to do things that make our computing environments more difficult or less pleasurable to use. Remember, should there actually be Spectre attacks discovered in the wild, quite likely traditional anti-malware tools will quickly begin to detect and block them. They’re not magic.

-Noel

1 user thanked author for this post.

Nibbled To Death By Ducks

Reply | Quote

Possibly the only significant situation that the threat from a drive-by Spectre attack would be greater than the threat of other attacks would be if you are browsing in a virtual machine as Spectre has been demonstrated to break out of VMs and gain access to the host machine.

Reply | Quote

Nibbled To Death By Ducks wrote:

I’m not even sure HOW to go about downloading the microcode from Intel and installing it…though they say my “Ivy Bridge” microcode fix for my processor in in the “production” stage. Does that mean it’s for general use for the public, or just manufacturing environments? https://newsroom.intel.com/wp-content/uploads/sites/11/2018/03/microcode-update-guidance.pdf

The microcode as released by Intel is not really meant for direct use by end users.  They make a microcode update for Linux available to the public periodically, and even though it says it is for Linux, once it is built into a binary module, it’s no different than the microcode that would be in the firmware release from the PC or motherboard OEMs.  You can use the Linux microcode release to add the microcode to the BIOS/UEFI firmware package of your PC, but it’s not something that I would recommend for the typical PC user.  I write this as a basic reference, not as a how-to; this should only be attempted by advanced users.

First, the basics.  Microcode is stored in volatile memory on the CPU, so every time the CPU is powered on, the microcode that used to be in there before is gone, and it has to be loaded again.  When the PC is turned on, the BIOS/UEFI will load the microcode before booting the operating system.

During the boot process, control of the computer is passed from BIOS/UEFI to the OS, and if the OS has had a microcode update installed, the OS will check the version it has and compare it to what is currently loaded into the CPU (from the firmware).  If the OS version is newer, it will dump the microcode in the CPU and replace it with the newer version contained in the OS update, and the boot process will continue.  This happens nearly instantly; you won’t notice a delay.

The point to all of this is that you don’t install the microcode into the CPU, per se, since it would just be lost the next time the PC is turned off.  You have to set it up so that one of the two methods here loads the microcode you want used during the startup or boot process.  That requires either a firmware update or an OS update.

If you were using Linux, you could use that file from Intel and set it to load it at boot time from then on (forming the OS update I mentioned), and that would be that.  Distros like Mint make it even easier; you simply need to click a radio button next to the “Intel Microcode Update” entry in the Driver Manager, and Mint will do it for you.  Unfortunately, I am not aware of any way to do this in Windows other than waiting for Microsoft to release an update for your version of Windows that contains the new microcode.

The other option is to use that release from Intel to build the binary module for your CPU, and to insert that manually into a firmware image that you will then flash to your PC.  This is an advanced technique and it should only be attempted by people who have some understanding about all of this stuff.  If your PC/motherboard maker has released an update that contains the new microcode, you do not need to do this; the work has already been done for you. 

The microcode updates from Intel come in the form of text-encoded binary blobs.  Linux will automatically build the binary blobs from the text, but to insert the module (the blob) into a firmware image, you’ll have to build it manually.

For this, I used a program called Microdecode.  It’s a simple Windows command-line utility that will read the text-encoded file and build all of the microcodes encoded within into the binary blobs we need.  It takes just a second to build them all, and after that, one needs only to go into the directory full of the new binary blobs and find the one whose filename matches the CPUID of the CPU you wish to update.  You can get this CPUID from a program like the appropriately-named CPUID.exe from CPUID.com, or you can look it up on a site like cpu-world.com.  Make sure the one you look up matches the CPU you’re using in every way; sometimes a subtle difference can mean a different CPU ID.

Once you have the microcode blob, you can then install it into the firmware image (the file that we would later flash to the firmware of the PC).  For this, I use a program called mmtool.exe, a program released by AMI for use with their own firmware images.  If your PC does not use AMI BIOS/UEFI, you will need a different program to do this.  All my PCs from my Core 2 Duo laptop forward (ASUS and Dell) have been AMI, so I have not needed to see what is available for other BIOS/UEFIs in some time.

Explaining how to use mmtool.exe is beyond the scope of this post, and there are sites that describe this in a good bit of detail if you search for them.  It’s fairly self-explanatory for a person who has a decent grasp on the basics of how BIOS and UEFI work (I’m having a hard time putting it into words!), but it is not for beginners.  It would be okay to download the tool and experiment with various firmware images to see how it works, but do NOT save the modified image and flash it to your PC if you do not know what you are doing.  Making a mistake doing this can very easily brick your PC, and I don’t mean the soft-bricking that can happen from, say, a failed Windows upgrade.  It is possible for you to render a PC or motherboard completely unusable in this way.  If you don’t have any idea how you would recover from that if it happened, this technique is not for you!

If you know what you’re doing, you can use mmtool.exe to replace the microcode exactly matching the CPUID of your CPU with the new blob we just built with Microdecode.  It goes without saying that you should be very, very certain that you are replacing the correct one here.

When that’s done, you can save the updated image and flash it to the BIOS/UEFI in the method of your choosing.

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon
XPG Xenia 15, i7-9750H/16GB & GTX1660ti, KDE Neon

7 users thanked author for this post.

kmbrite, RDRguy, Bill C., HiFlyer, jelson, Nibbled To Death By Ducks, Elly

Reply | Quote

@Ascaris …
There’s a windows driver developed by some VMware engineers called VMware CPU Microcode Update Driver (a VMware Fling) that will load the Intel released Linux microcode updates or AMD microcode updates during windows boot similar to what Linux does during boot.

It doesn’t replace the normal windows boot CPU microcode update sequence/functions which uses the “mcupdate_GenuineIntel.dll” and “mcupdate_AuthenticAMD.dll” files located in c:\windows\system32 folder but instead augments the boot sequence with a driver that checks against what CPU microcode has already been loaded by either the BIOS/UEFI and/or Windows and/or Linux.

If the VMware Fling driver detects that is has access to an updated microcode, it will update the CPU with its pre-stored updated microcode and will so report whether it did or not in the windows\system event log.

Problem is, the driver may or may not run in time and load it’s updated microcode prior to windows’ checking for Spectre mitigation.

If the driver runs in time, all good, if it doesn’t, windows won’t detect that CPU has latest mitigation microcode so windows won’t use any of the CPUs mitigation capability so even though the CPU will be eventually be loaded with the updated mitigation microcode when the driver eventually runs.

However, if you’re running a VM, the OS running in the VM will use the mitigated CPU functions as, when the VM boots, the updated mitigated CPU microcode will already be there, detected and used accordingly.

VWware Fling website hosting the VMware CPU Microcode Update Driver & Instructions …
https://labs.vmware.com/flings/vmware-cpu-microcode-update-driver#summary

Another minor issue is that this VMware Fling relies on Intel’s “microcode.dat” file format to read the Linux CPU microcode data. The Release Notes for Intel’s Linux CPU Microcode released 04/25/2018 state that they no longer support the “microcode.dat” file format.

However, a VMware website commenter asking for help, developed a simple windows program written in C# to convert the “intel-ucode” file format that Intel released to the previously supported “microcode.dat” format.

If you read the comments section, you’ll see that he posted download locations for both the executable & source.

Comment section showing “Intel Microcode.dat Converter” locations …
https://labs.vmware.com/flings/vmware-cpu-microcode-update-driver#comments

If you need it to run in XP (x64 or x86) you can find it here at bottom of page …
http://wp.xin.at/archives/tag/microdecode

Group B / Win 7 (Ultimate & Pro) [x64 & x86]
RDRguy

Reply | Quote

The Intel link that NTDBD mentioned is about 2 months old and Intel posted a newer microcode revision guide here (April 2018):
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/04/microcode-update-guidance.pdf

in THIS one, Intel has stopped production of some MCUs because of stability problems (those using Core 2 Duo, Core 2 Quads and some 1st generation core i7 CPUs AND older will not be getting any new MCUs).

also Dell has not yet offered any new BIOS/firmware updates for some older Dell machines using Intel Sandy Bridge processors as I checked the Dell support site myself; I use a Dell-based Sandy Bridge machine that is older than RetiredGeeks’, Noel’s and NTDBD’s computers – looks like I’ll have to wait longer for them to be released by Dell.

Reply | Quote

My desktop is a Sandy (i5-2500k) also… if you are running a Sandy Bridge on an Ubuntu-derived Linux as I am, you should have been offered the microcode update on or about March 14th.  No idea what MS is waiting for!

As for Asus, my motherboard maker… last firmware update was in late 2012.  Not holding my breath, but I’d rather do it the OS way anyway until I’m completely convinced it’s stable.

Given that the threats we’re patching against don’t even exist yet, I don’t see any problems for now.  But seriously, MS, get with the program.

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon
XPG Xenia 15, i7-9750H/16GB & GTX1660ti, KDE Neon

3 users thanked author for this post.

Bill C., HiFlyer, Nibbled To Death By Ducks

Reply | Quote

Being machine and software conservative, think I’ll just wait and see what develops “In The Wild” before I start jiggling UEFI/BIOS and microcodes. (I’m running BIOS now; the system came that way; the benefits and trials of switching to UEFI I’ve only partially explored, and are for another forum and topic.

Like I said, this is my only online machine. Built 2 PC’s, spec’d and had a commercial custom shop build my last XP-based Workstation to my specs (it’s not connected to the Net, and throwing away well into four figures of software is not in my budget)

Thanks, folks!

Reply | Quote

FYI, for those who don’t already know, Steve Gibson released Inspectre Release #8 on Apr 11, 2018.

Release #8 — Now shows whether an Intel microcode patch is (ever) available for Spectre.

Intel has finished designing microcode update patches for its processors. On April 2nd, 2018, they announced that processors that have not yet been patched will never be patched. Their full statement is available in this PDF document. In that document, Intel specifies which of their many processors do have patches and which of their more recent processors will never receive updated firmware. Now that the industry has this information, this 8th release of InSpectre incorporates that list of CPUIDs and displays whether microcode firmware updates exist for the system’s Intel CPU.

Well, I’ve run it and to my surprise this is what Release #8 indicates concerning my “i7-990x” system – CPUID 206C2.

Spectre & Meltdown Vulnerability Status
System is Meltdown protected: YES
System is Spectre protected: YES
Microcode Update Available: YES
Performance: SLOWER
CPUID: 206C2

Now, Intel’s Microcode Update Guidance dated April 2, 2018 has the Production Status listed as “Stopped” and a Pre-Mitigation Production MCU listed as “0x1E” for the Gulftown processors CPUID 206C2.

Intel’s Microcode Update Guidance dated April 2, 2018 also has the Production Status listed as “Production” and a New Production MCU listed as “0x1E” for the Westmere EP, WS which is also CPUID 206C2.

But, Intel has yet to release the new “0x1E” microcode update for the 206C2 to the public. I seriously doubt that Microsoft is in any hurry to release Win7 microcode updates for old legacy processors & I’m sure ASUS will never release anything for the i7-990x as Intel has officially “Stopped” it’s work on the Gulftown processors.

However, HP still supports their Z400/Z600/Z800 WorkStation Servers that use the Westmere EP XEONs for which Intel has released to HP the 206C2 “0x1E” microcode for their BIOS updates to mitigate Spectre Variant 2.

I know, I know, but what I’m about to do is something I know most of you on AskWoody frown upon HIGHLY. But, I still performed a somewhat precarious experiment on my ASUS P6T Deluxe V2 motherboard that incorporates an Intel i7-990x CPU.

1) I downloaded the latest HP Z400 BIOS 3.61 Rev A “sp84161” dated Mar 6, 2018 and used 7Zip to extract all files within it. The extracted BIOS Update folder contains the “DOS_Flash” folder which contains the “7G3_0361.bin” BIOS file.

https://support.hp.com/us-en/drivers/selfservice/hp-z400-workstation/3718668

2) I then used MCE Extractor (available at github) to extract all CPU microcodes contained in the “7G3_0361.bin” file including the new “0x1E” version for CPUID 206C2 … “cpu206C2_plat03_ver0000001E_2018-01-23_PRD_B8C45629”.

https://github.com/platomav/MCExtractor

3) I then used “MMtool.exe” version 3.26 to replace my 206C2 version “0x13” with the extracted “0x1E” in my P6T Deluxe V2 BIOS “P6T-ASUS-DELUXE-V2-1202.ROM” file.

4) Then with GREAT hesitation, anxiety, heart palpitations & 1 eye closed, I updated my ASUS P6T Deluxe V2 motherboard with the new BIOS containing the new “0x1E” CPU microcode.

To my pleasant surprise, no errors what-so-ever in extracting the new microcode, creating the new ASUS BIOS .rom file or successfully uploading it to the motherboard.

5) After setting the BIOS defaults, I booted into Windows 7 x64 and … wallah! … everything seems to be running normally that is if Win7 runs normally these days.

6) I verified the REG_BINARY values for Previous Update Signature & Update Signature and are both set to “00 00 00 00 1e 00 00 00” in key HKLM\HARDWARE\DESCRIPTION\System\Processor\0 … and they are.

7) I ran Intel Processor Identification Utility version 5.80 to verify all was well … all normal & indicating CPU revision “1E”.

8) I executed the Intel Processor Diagnostic Tool64bit version 4.1.0.24 … all tests PASSED.

9) I ran Intel Extreme Tuning Utility (XTU) version 6.4.1.19 … everything seemed normal but I did not perform any OC’ing.

10) I ran GRC’s Inspectre Release #8 … except for expected slower performance, all GOOD – results at the beginning of this post.

11) Finally, I performed disk benchmarks using ATTO’s Bench32 to test effect nf disk transfers to a Samsung 850 Pro 1TB SSD while enabling then disabling the Spectre mitigations using GRC’s Inspectre tool.

The average difference with all data transfer block sizes combined was approx 4.5% slower overall with Spectre mitigations enabled vs. disabled. But I did get up to 36% slower data transfers for small block sizes consisting of 0.5K then gradually decreasing to less than 10% slower at 4K or larger block sizes.

After all this, I believe I can deduce that I was able to acquire an updated 206C2 Microcode, extract it, replace the existing microcode with the new Spectre mitigated one in my X58 motherboard BIOS that incorporates an i7-990x with apparently no ill effects.

I believe I can also deduce that enabling Spectre mitigation vs. disabling it does seem to affect disk data transfer speeds therefore maybe indicating that the new Westmere EP “0x1E” microcode does have an effect and that maybe it’s performing as intended in the Gulftown processors as well as the Westmere EP processors.

Now, the real question I have is as follows:

Intel, in their Microcode Update Guidance of Apr 2, 2018, indicates that Spectre mitigation for the Gulftown processors is “Stopped”.

Therefore one has to assume that the “0x1E” update for the Westmere EP, WS processors when used with the Gulftown processors will not / may not mitigate Spectre as intended even though it appears to work.

Or does it really work but it hasn’t yet or never will be fully vetted by Intel in so much that it actually does perform as intended if used with Gulftown processors?

OK, I’m confused now so I’d like to pass this on to you AskWoody experts to see if you’re so inclined to ponder upon my experiment & thoughts and besides the anticipated “DON’T DO IT”, maybe offer some geekdomness wisdom.

With all the problems MS has with Windows Updates and Intel’s reluctance to, as of yet, release to the public any newly updated CPU microcodes for older CPU’s like mine, if / when the time comes that I either have to give up my i7-990x system to be protected from Spectre or, stay unprotected or, keep what I’ve done above or, I can upgrade to say a Westmere EP XEON x5690 (reports are that it works just fine in an ASUS P6T Deluxe V2 board), or I can just bite the bullet and then bite on an Apple (future modern technology of course).

Group B / Win7 SP1 [x64 & x86]
RDRguy

Win7 - PRO & Ultimate, x64 & x86
Win8.1 - PRO, x64 & x86
Groups A, B & ABS

8 users thanked author for this post.

kmbrite, Bill C., Microfix, Nibbled To Death By Ducks, RetiredGeek, Cascadian, Elly, columbia2011

Reply | Quote

No answers- just wanted to express my appreciation for your willingness to test this out…

Non-techy Win 10 Pro and Linux Mint experimenter

3 users thanked author for this post.

HiFlyer, RDRguy, Cascadian

Reply | Quote

Well, I’ve got this moderately old system that still performs GREAT and I really don’t want to put it out to pasture just yet. With the way things are going with Microsoft & Intel & ASUS & other OEMs support of their customers concerning legacy systems, it seems like with the help of AskWoody members, I’ll soon be (if not already) the main technical support provider for all of my systems.

As I find ways to do things that I would normally expect OEMs to do but they no longer do, I feel it’s my duty as a techie to pass onto others things I’ve learned so that they can also become somewhat more self-sufficient should the need arise.

Group B / Win7 SP1 (Ultimate & Pro) [x64 & x86]
RDRguy

Win7 - PRO & Ultimate, x64 & x86
Win8.1 - PRO, x64 & x86
Groups A, B & ABS

Reply | Quote

Very well executed. I applaud your dedication, and am a little jealous of the spare time you’ve given to pursue this.

I suppose the test condition would be to get one or more of the published malicious code, then allowing it to execute locally, isolated from the internet.

If you choose to continue in this way, I would enjoy reading more.

2 users thanked author for this post.

Microfix, RDRguy

Reply | Quote

Well, I’m retired so I’ve got nothing but time to research & work out Windows Update mess-ups 🙂

And I agree, the only real test to see if my method of protection against the currently disclosed Spectre vulnerabilities is to subject it to actual malicious Spectre code & see how my hacked patched system reacts.

Maybe in time, others can either confirm success or failure for this method of patching their no longer OEM supported legacy systems with Spectre mitigation.

Group B / Win7 SP1 (Ultimate & Pro) [x64 & x86]
RDRguy

Win7 - PRO & Ultimate, x64 & x86
Win8.1 - PRO, x64 & x86
Groups A, B & ABS

3 users thanked author for this post.

columbia2011, Microfix, Cascadian

Reply | Quote

Absolutely Fantastic! I had no idea it was possible to extract micro code from one file and paste it into another (except at the source code level) and then flash a BIOS with it. Well done and very informative!

May the Forces of good computing be with you!

RG

PowerShell & VBA Rule!
Computer Specs

1 user thanked author for this post.

RDRguy

Reply | Quote

@RG …
BIOS (Basic Input/Output System) can be thought of as simply a collection of file libraries consisting of modular hex data files representing either executable code and/or data that’s used to initialize (put to a known state) the hardware components of a PC or other hardware system upon power-up so that they can subsequently properly interpret software system calls (commands & responses) from a host operating system (i.e. Windows, Linux, DOS, Mac OS, etc.).

Modern EFI (Extensible Firmware Interface) & UEFI (Unified Extensible Firmware Interface) moves most of the normal BIOS functions from hardware based firmware BIOS to the hard disk which allows for increased BIOS like functionality, space & features. Wikipedia is a good primer for BIOS/EFI/UEFI.

Though some system OEMs develop their own BIOS and in-house BIOS Tools, several system OEMs use BIOS OEMs (AMI, Award, Insype, Phoenix to name a few) to develop their system BIOS and various corresponding BIOS maintenance tools. It should be noted that BIOS tools from one BIOS vendor usually doesn’t work with another vendor’s BIOS structure – BIOS structures are pretty fairly unique among BIOS vendors.

Various BIOS maintenance tools are used to upload, download, customize or otherwise maintain system BIOS with custom features like system OEM’s display LOGOs, maintain (add/remove/replace) system OEM approved devices (i.e. supported CPUs, memory & other components, etc.), provide capability for fixing BIOS bugs discovered post-development/release and provide capability for other updates/improvements to the BIOS file modules.

A prime example for BIOS modification tool use would be to add BIOS support for a newly developed CPU as long as the physical & electrical characteristics of a particular motherboard also permits support of that new CPU.

In essence, this is what I’ve done. I’ve simply replaced the specific hex data file module that contains the CPU Microcode (essentially a hex data file that’s loaded at system power-up into dedicated onboard ram within the design of the CPU which is used solely to determine/modify what function(s) a particular CPU instruction will or will not perform) using a tool that was most likely developed by the BIOS OEM vendor (AMI) of my ASUS motherboard – at least I hope so 🙂

There are a lot of BIOS/EFI/UEFI programmers, technicians and other crafty hackers out there that have an intimate knowledge of the interworking’s of the various flavors of BIOS (legacy BIOS & modern EFI/UEFI) that have either bought, borrowed, stolen or developed their own BIOS tools to view / add / remove / replace / extract / inject / modify the various bits / blocks / libraries contained within a typical BIOS file.

Though some of these files/tools can be found on-line for download for free, the key is to know (or determine) which files/tools are needed, how to use them and if they’re safe & can be trusted to do no more & no less than what’s expected.

A little bit of curiosity, basic technical know-how, self-discipline and risk acceptance goes a long way and is extremely valuable and helpful if you’re modifying BIOS yourself.

“DON’T DO IT IF YOU DON’T HAVE TO” is very sound advice if you’re modifying BIOS as you can easily brick a board making it irrecoverable especially if you’re cobbling together something for the first time that may or may not be compatible – kinda like what I did.

Some motherboards do have BIOS recovery features (primarily secondary BIOS storage) but most don’t & you shouldn’t routinely depend on this feature even if you’re an expert.

If you do, it’s like driving in 4 wheel drive in the mud until you get stuck – when you do get stuck, it’s too late (though most Mud-Boggers would tend to disagree but then again, I’m fairly sure they’re not here on AskWoody). I digressed – sorry.

I know what I’ve done appears to look good on the surface, but I can’t be really say for sure that I’ll be 100% protected against a real Spectre Variant 2 attack because Intel stated publicly that they’ve stopped mitigation work on my 1st Gen i7 CPU.

Maybe as far as the CPU / Windows interface & Windows interpretation of the CPU responses go, all appears good on the surface. But, besides Intel, who really knows what’s going on inside the i7 CPU itself when paired with this version of microcode.

Before I tried my experiment, I did a ton of research on the web concerning my system & Spectre Variant 2 and my conclusion was that there was a 0% chance that Intel, ASUS or MSFT would provide the necessary Spectre Variant 2 microcode fix for my specific 1st gen i7 system.

With my system hack fix, I feel I’ve increased my chances of being Spectre protected from 0% to maybe 50-50.

But, if I stay with my system hack & swap out the i7 with a Westmere XEON (more web research), I believe my chances of protection will increase to 99+% assuming that Intel’s fix is really the 100% fix for Spectre Variant 2.

Why 99+%, because nothing is ever 100% except death & taxes and who knows what the future holds (i.e. Spectre NG ?)

Except for a simple CPU swap, I’ve potentially saved my system from the wrath of the currently published/released Spectre Variant 2 vulnerability.

Though in no way do I want to inject BIOS hacking into this forum, for those who might be just a little bit more curious, a couple of interesting websites dealing with CPU Microcode BIOS modification & tools listed are below:

http://wp.xin.at/archives/tag/microdecode … AMI BIOS & CPU Microcode specific

https://www.win-raid.com … Home page – general BIOS/UEFI/Driver modification

https://www.win-raid.com/f47-HOT-CPU-Microcode-Optimization.html … CPU Microcode topics

As best as I can determine these sites are completely safe as I’ve been visiting them for several years now and I haven’t been hit yet (fingers crossed) by any malware, unexpected hidden/backdoor downloads or infections.

Best of all, no need to join, sign-up or submit email addresses to view articles or discussions. Pretty much like AskWoody but primarily focuses discussions on problems, potential solutions ideas and modifications that relate closer to the hardware level concerning BIOS, hardware drivers, custom modifications, etc.

While I’m no expert, I feel I know just enough to give it a try but I also hope I know enough to stay out of trouble …

Group B / Win7 (Ultimate & Pro) [x64 & x86]
RDRguy

Win7 - PRO & Ultimate, x64 & x86
Win8.1 - PRO, x64 & x86
Groups A, B & ABS

3 users thanked author for this post.

Elly, johnf, SueW

Reply | Quote

Edit – in my haste, I forgot to include step 12 above in #193032

12) Ran Microsoft’s Speculation Control Validation PowerShell Script to verify that MS’s tool detects & indicates expected Spectre mitigation within Gulftown processors when using the Westmere “0x1E” microcode update … except for “Windows OS support for PCID performance optimization is enabled: False” … all other indications: TRUE.

MS links pertaining to the PowerShell Script:

https://support.microsoft.com/en-us/help/4073119/protect-against-speculative-execution-side-channel-vulnerabilities-in

https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution

https://gallery.technet.microsoft.com/scriptcenter/Speculation-Control-e36f0050#content

The False PCID indication is as expected due to absence of “INVPCID” support in Gulftown or Westmere processors. I believe Windows currently doesn’t use “PCID” capability if either “PCID” or “INVPCID” is not supported. I believe Haswell processors were the first to implement both “PCID” & “INVPCID” and as such, they & their successors suffer less of a performance impact with Meltdown & Spectre mitigations implemented due to Windows use of both “PCID” & “INVPCID” instructions.

A good presentation primer for this can be found at:

https://arstechnica.com/gadgets/2018/01/heres-how-and-why-the-spectre-and-meltdown-patches-will-hurt-performance/

“Coreinfo” tool can be used to gain insight into a processors topology & included feature details:

https://docs.microsoft.com/en-us/sysinternals/downloads/coreinfo

Group B / Win7 SP1 (Ultimate & Pro) [x64 & x86]
RDRguy

Win7 - PRO & Ultimate, x64 & x86
Win8.1 - PRO, x64 & x86
Groups A, B & ABS

3 users thanked author for this post.

johnf, Microfix, Cascadian

Reply | Quote

Thanks to RDRguy for the incredible bravery and the equivalent of shoving the stick forward and gunning it.  Nice pullout and recovery! Gad, such brain surgery is beyond me, but I thank you!

I’m going to live with the Meltdown “Mitigation” (don’t you love that euphemism?) MSFT pushed out earlier, until Spectre breaks out.  The Meltdown “Mitigation” slowed me down enough as it is.  This, just for mere “I”, as noodling around in code guts is a bit beyond the pale for me. Perhaps in another lifetime! 🙂

In any case, well done! Salud!

Win7 Pro SP1 64-bit, Dell Latitude E6330, Intel CORE i5 "Ivy Bridge", 12GB RAM, Group "0Patch", Multiple Air-Gapped backup drives in different locations. Linux Mint Greenhorn
--
"...all the people, all the time..."Peter Ustinov ad-lib in "Logan's Run"

1 user thanked author for this post.

RDRguy

Reply | Quote

@Nibbled …
Thank you for your kind words sir, but you forgot to add “all the while starring at the brick wall ahead” 🙂

Group B / Win7 (Ultimate & Pro) [x64 & x86]
RDRguy

Win7 - PRO & Ultimate, x64 & x86
Win8.1 - PRO, x64 & x86
Groups A, B & ABS

Reply | Quote

Oops, almost forgot;

Question: Is the latest Dell BIOS for my system (https://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=P1P6W) likely to already contain the Spectre microcode fix a/o April 3rd?  I see no mentions of Spectre microcode in the description of improvements and fixes.

I may be mixing up Oranges and Elephants here.

Thanks in advance!

Win7 Pro SP1 64-bit, Dell Latitude E6330, Intel CORE i5 "Ivy Bridge", 12GB RAM, Group "0Patch", Multiple Air-Gapped backup drives in different locations. Linux Mint Greenhorn
--
"...all the people, all the time..."Peter Ustinov ad-lib in "Logan's Run"

Reply | Quote

Nibbled to Death by Ducks – the link in the above post is to a Bios version A09 from the year 2013!!! Scroll down the page to “Other Versions” and you’ll see the latest Bios version as A20 from April 26 of 2018. I think A20 is the one you want, assuming you want to update the Bios.

Click on “A20” and you’ll see the “Fixes”. You should verify this but it looks like there is some firmware code/microcode for the Intel Management Engine and also for Spectre/Meltdown.

1 user thanked author for this post.

Nibbled To Death By Ducks

Reply | Quote

OW! Thanks….it’s been a long week and Gramps is tired.

Question: How well will this BIOS update work with the already-installed MSFT Meltdown mitigation contained in a previous patch? Any info on conflicts?

Win7 Pro SP1 64-bit, Dell Latitude E6330, Intel CORE i5 "Ivy Bridge", 12GB RAM, Group "0Patch", Multiple Air-Gapped backup drives in different locations. Linux Mint Greenhorn
--
"...all the people, all the time..."Peter Ustinov ad-lib in "Logan's Run"

Reply | Quote

Nibbled – Not quite sure what you’re asking but you will need a firmware or microcode update to be protected from the so-called 2nd variant of Spectre. It looks like the A20 Bios update will provide this protection for you. If you’re up to date (through April) with Microsoft patches, then you should be protected from Variant 1 of Spectre and also Meltdown and Total Meltdown.

If you’re asking whether there are any issues with the Bios update itself, that I don’t know. I haven’t heard anything to that effect, but Bios updates were sort of dicey, at least in the past. On the other hand, more recently Bios updates have been more issue free. My personal opinion is that Dell is a fairly good company and probably did a fair amount of testing before releasing the A20 update. Since it was released on April 26, Dell is probably pretty confident A20 will work with Microsoft patches through April. As far as working with May Microsoft patches, well, who knows? Perhaps other more knowledgeable folks here can provide more insight into the potential issues involved.

Reply | Quote

Thanks, DrBonzo *,

Downloaded it and am going to “keep it in my pocket” until the scourge breaks out in the wild.  Already have enough slowdown from the MSFT Meltdown/Total Meltdown patch, and this is my only PC at the moment-I’m playing it rather conservative.

Still waiting for MSFT to “complete the investigation” on KB 4103718 and fix THAT.

Aaaargh.

*(Dog Doo-Dah Band? Just Curious 🙂

Win7 Pro SP1 64-bit, Dell Latitude E6330, Intel CORE i5 "Ivy Bridge", 12GB RAM, Group "0Patch", Multiple Air-Gapped backup drives in different locations. Linux Mint Greenhorn
--
"...all the people, all the time..."Peter Ustinov ad-lib in "Logan's Run"

Reply | Quote

Nibbled – I’ve got 2 Dells running Win 7 SP1 x64. One is an Ivy Bridge the other a Broadwell. I’m trying to keep both safe and running until end of support in Jan 2020. If Spectre shows up in the wild I’ll probably try to update the Bios. Otherwise I’m not planning to update it.

In the meantime, I’ve been fortunate enough to get an iMAC (used by my wife) and am saving my pennies to get another MAC of some type. I also have Ubuntu 16.04 LTS set up on an old laptop. It serves well as an emergency computer, but for me, at least, I find it fairly difficult to go beyond what I would call a simple standard installation. The lingo seems totally different from either Windows or MacOS and it was a real chore to get Midi files to play and I’ve had just about zero luck/success getting any peripherals to work. I might try Mint Cinnamon at some point since according to others here it seems more user friendly. I have to admit that I am swayed by the free price of Ubuntu and Mint, especially compared to a MAC.

1 user thanked author for this post.

columbia2011

Reply | Quote

If you are a music composer, Ubuntu Studio may be a better choice. Here’s a couple of links that might help for MIDI:

Ted’s Linux Midi Guide

USB MIDI controllers  & making music with Ubuntu

You can work with MIDI in Mint, but you’ll have to get a low latency kernel, according to what I’ve seen (see the Ted link). The support forums for Mint and Ubuntu are very good, you will likely get an answer if you post there.

It is a bit of work (though not as weird as learning where things are in Win10), and the lingo is different, but you pick things up fast when you are using it every day. And it is nice just to go to Software Manager (or Updates), and just download new microcode when offered…or roll it back if you don’t want it.

 

1 user thanked author for this post.

DrBonzo

Reply | Quote

@johnf – Thanks for the Midi links. Fortunately I don’t have to compose, just listen. There was some arcane setting I needed to choose, after which 3 or 4 programs suddenly started playing the files.

I spend so much of my computer time dealing with MS patches/updates that I haven’t had much time for learning other systems.

I have marveled, though, at how smoothly updates go with both MacOS and Ubuntu. They just work! No white knuckles, heart arrhythmias, emergency room visits, etc.

Reply | Quote

@nibbled …
I agree with DrBonzo, the current Dell A20 BIOS update for you system contains the Spectre Variant 2 CPU microcode fix.

Also as stated by others, I believe there’s minimal risk these days if you follow your system manufacturer’s BIOS/UEFI update instructions to the letter and use the update files/tools obtained directly from your system manufacturer.

But, things can still happen during the update process that can cause the update to fail possibly rendering your system inoperable or result in other undesirable effects like system feature deletions, additions, modifications, etc.

So unless there’s some undesirable existing condition that an updated BIOS/UEFI resolves, you probably shouldn’t update unless you’re willing to except some risk.

Most importantly, NEVER interrupt the update process once started. If updating a laptop, make sure the battery has sufficient charge in case you lose power during the update process. I recommend plugging the laptop in and not performing the update if the laptop is just running on battery power.

For a desktop, it would be beneficial to run with a battery backup as risk increases if you’re in a power-loss prone situation like a major weather storm brewing, tornado, forgot to pay the electric bill 🙂 , etc.

As such, I believe the A20 BIOS/UEFI update that includes the CPU Microcode that incorporates the Spectre Variant 2 fix is warranted and worth the minimal risk. But it’s really up to you to choose when to install it.

Personally, with the recently reported discovery of 8 new variants of Spectre vulnerabilities (Spectre NG) concerning Intel (& possibly AMD) and that they (?) are working on a fix for the new vulnerabilities, I’d probably hold off updating until either there are reports of existing Spectre Variant 2 attacks detected or until Intel/AMD release a new round of CPU Microcode updates to OEMs like Dell and they intern release updates to their recently updated BIOS/UEFI files.

Or, you can use this technically desired A20 BIOS update as a practice update in preparation for the next update should that turn out to be the case. Your choice really.

Seems like Intel has taken a page out of the current MSFT playbook – update the update which updates the update to the update 🙂

Group B / Win7 (Ultimate & Pro) [x64 & x86]
RDRguy

Win7 - PRO & Ultimate, x64 & x86
Win8.1 - PRO, x64 & x86
Groups A, B & ABS

1 user thanked author for this post.

johnf

Reply | Quote

Many thanks to Ascaris and RDRguy for their insights and potential solutions. I am running an old i7-960 (Bloomfield) on an Intel DX58SO2 motherboard. From this, there ‘may’ be an ‘unofficial’ solution possible, but I KNOW, that it is far outside my comfort and knowledge zone to try such experimentation.

I do know that when I was searching the Intel sight, I did read that the reason some of these microcode updates now shown as “stopped”, was explained as being due to a lack of documentation for the legacy equipment/BIOS/firmware. Maybe I am naive, but I truely doubt that is true, as I find it hard to believe a corporation would have lost all of its product info. I also saw a later explanation on the support forums that it was due to the assessment that these older machines, being used mostly in ‘internal’ situations, were not a priority. This I partially believe is more accurate, but it distills down to ‘not many still running’ as front line systems to be worth the effort.

I did download an update that was said to include my CPU, but when I opened the files and looked at the text, the firmware date for the CPUID for my CPU had a 2012 date, confirming it was not included in the bundled update.

In retrospect, that machine is old. My Lenovo laptop was updated via a new UEFI and firmware and is safe according to Steve Gibson’s Inspectre utility, but took a performance hit that is most evident when doing WU searches and patching. Meanwhile the Linux machines have all had the kernal and firmware updates offered by the distros, and the one that actually had a new UEFI/BIOS and firmware available was flashed manually. I did not ‘feel’ any performance degradation.

Thanks to all for their contributions to this thread.

2 users thanked author for this post.

RDRguy, johnf

Reply | Quote

@Bill_C:

“…I truly doubt that is true, as I find it hard to believe a corporation would have lost all of its product info.”

(Large sigh) Sit down, my son.

My wife has been a IT Technical Writer, perm and contract, govt. & civil, for, well, shall we say a couple of decades, and the documentation stories she could write a book about would stun an ox.

Documentation is always the stepchild of any commercial outfit in IT. It’s really amazing. “Get it to the trade show, shoot the engineers who say it’s not ready, and, uh, the docs? What docs? We don’t need no stinkin’ docs!”

…and if there ARE older docs of a older model, oh, my… “The horror…The horror…”  They may consist of scribbled notes on the back of lunch bags, and maybe a napkin or two if you’re really lucky. They may or may not exist in English. (Good thing she understands several languages.)

Honor Bright. 

Win7 Pro SP1 64-bit, Dell Latitude E6330, Intel CORE i5 "Ivy Bridge", 12GB RAM, Group "0Patch", Multiple Air-Gapped backup drives in different locations. Linux Mint Greenhorn
--
"...all the people, all the time..."Peter Ustinov ad-lib in "Logan's Run"

1 user thanked author for this post.

Kirsty

Reply | Quote

@Bill C.
I did a bit of poking around and this is what I’ve found – some potentially good news, some bad, and some hope. Feel free to repeat my path via enclosed links if you like.

Intel’s Microcode Revision Guidance dated March 6 2018 lists the Bloomfield i7-960 Production Status “Pre-Beta” & Pre-Mitigation Production MCU is “0x1B” as seen here:
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/03/microcode-update-guidance.pdf

Intel’s Microcode Revision Guidance dated April 2 2018, states that Production Status for Bloomfield is “Stopped” & again Pre-Mitigation Production MCU is “0x1B” as seen here:
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/04/microcode-update-guidance.pdf

CPUID 106A5 is the CPUID for some i7 Bloomfield (920, 930, 950, 960, 975) & Xeon Bloomfield thereby they use the same CPU microcode. Some early versions of i7 Bloomfield (920, 940, 965) are CPUID 106A4 while CPUID 206C2 are the Gulftown CPUs (970, 980, 980x, 990x).

It should be noted that, CPUs i7-920, 930, 950, 960 & 975 are listed as CPUID 106A5 in the Mar 6 Intel Microcode Revision Guidance but they are listed as 106A4 in the Apr 2 revision.

I believe this is an error in the Apr 2 guidance as various other CPU websites list these as CPUID 106A5. I suspect the CPUIDs in the 2 adjacent Bloomfield rows were accidentally swapped probably because there are 2 versions of the i7-920.

Good 3rd party website for AMD & Intel CPU stats: (once there, search for i7-960)
http://www.cpu-world.com/index.html

This can also be confirmed on your system using GRC’s Revision #8 “Inspectre” tool or several other CPUID identification utilities like HWiNFO, CPUID, CPU-Z, etc. all available on-line for free download.

In any event, though not publicly released, Intel has indeed updated the CPUID 106A5 microcode to version “0x1C” with a date of 2018-01-24, (your i7-960 is CPUID 106A5) and “officially” released it to some OEMs like HP & Dell which they in turn released updated BIOS to their customers available for download from their websites.

The BIOS version 3.61A dated Mar 6, 2018 update file sp84161.exe that I’ve downloaded from HP for the Z400 system contains the 106A5 updated “0x1C” version.
https://support.hp.com/us-en/drivers/selfservice/swdetails/hp-z400-workstation/3718668/swItemId/wk-207274-1

The Dell PowerEdge 610’s (likely others) BIOS version 6.5.0 dated Mar 20, 2018 update file “R610_BIOS_60HK9_WN64_6.5.0.EXE” also contains the updated CPU microcodes for CPUIDs 106A5 & 206C2.
http://www.dell.com/support/home/us/en/04/drivers/driversdetails?driverId=60HK9

If you’re curious, you can download the HP and/or Dell BIOS update files, 7-Zip to extract the HP or Dell BIOS update files & the MC Microcode Extractor tool to extract the updated Intel CPU microcodes from the extracted OEM BIOS files and follow my previous post for steps I used and you can extract them for verification.

7-Zip v18.05 … a very good Zipping / Un-Zipping tool (does install in Windows)
https://www.7-zip.org/

MC Extractor v1.16.3 r66 … compiled & ready to run in Windows (it does not install)
https://github.com/platomav/MCExtractor/releases

I believe this means that, unlike shown in Intel’s last Microcode Revision Guidance of Apr 2nd, Intel has mitigated & released (at least to some OEM system vendors) updated microcodes for some i7 Bloomfield, Xeon Bloomfield, Gulftown, and Westmere-EP & WS processors.

Unfortunately, unless Intel also releases these 106A5 & 206C2 updates to MSFT and they in turn release them as a Windows update to the Intel Microcode update file “mcupdate_GenuineIntel.dll” located in the c:\Windows\System32 directory which is run at Windows boot, and the sparse not-so-easy-to-use tools to hack the DX58SO2’s Phoenix BIOS like I hacked mine, it would seem to be a bit difficult to proceed further at this time.

So, here are your options as I see them today:

Wait for Intel and/or MSFT to provide an official update for your i7-960/motherboard … may or may not ever happen, let’s hope it does 🙂

Attempt the CPU microcode replacement hack … your DX58SO2 board’s BIOS is based on Phoenix BIOS – few BIOS tools available & those found are hard to use and may not work as expected (in some cases). See links below:

BIOS ID / BIOS Developer identification website: (scroll down and look for BIOS SOX5820J-86A or BOARD DX58SO2 – your board is near bottom of page)
https://www.wimsbios.com/intelphoenixbiosids.jsp

Some Phoenix BIOS CPU microcode hacking directions & tools:
https://www.win-raid.com/t2811f47-Guide-How-to-update-CPU-microcodes-NCPUCODE-BIN-CPUCODE-BIN-on-a-non-UEFI-Award-Phoenix-BIOS.html

This may help some but its set up for LGA 771 & 775 not your LGA 1366 board though tools & steps should be the same:
https://www.delidded.com/how-to-update-cpu-microcode-in-award-or-phoenix-bios/

However, there’s another potentially good option to consider:

Upgrade your i7 Bloomfield to a Westmere-EP Xeon. I know this sounds like a stretch but if you follow the breadcrumbs below you’ll see that you might end up with some additional advantages.

First run Intel® Desktop Compatibility Tool links listed here:
http://processormatch.intel.com/
http://processormatch.intel.com/MotherBoards/Index/
http://processormatch.intel.com/MotherBoards/ByChipSetName?chipSetName=X58
http://processormatch.intel.com/Processors/CompatibleProcessors?componentName=DX58SO2

You’ll notice that, per Intel’s Desktop Compatibility Tool (last link above), the DX58SO2 supports the i7-990x which is a “Gulftown” CPU … CPUID 206C2. I’ll explain below why this is important later below.

Next, let’s look at when the i7-990x was first supported. Click on the i7-990x CPU selection. You’ll notice that the i7-990x CPU has been supported since BIOS version 603. Clicking on the 603 BIOS version this takes you to Intel’s website here:
https://downloadcenter.intel.com/product/50242

Now double clicking on “BIOS Update [SOX5820J.86A] takes you here:
https://downloadcenter.intel.com/download/23054/BIOS-Update-SOX5820J-86A-?product=50242

Then clicking on Release Notes (pdf) opens up this PDF file:
https://downloadmirror.intel.com/23054/eng/SO2_0920_ReleaseNotes.pdf

You’ll notice that BIOS version 603 is the initial release BIOS for the DX58SO2 board meaning that the i7-990x has always been supported. You’ll also see that this latest BIOS version 920 added capability for “New Processor Support”.

If all the supported processors listed in the Intel Desktop Compatibility Tool have been compatible since BIOS 603, what new processors are being supported? I suspect it’s the Westmere-EP & WS Xeons as there aren’t any other 1366 processors that weren’t already supported in previous BIOS versions.

Noting your board currently supports the i7-990x is important because CPUID 206C2 is the same CPUID for both the “Gulftown” i7s and the “Westmere-EP” Xeons (i.e. 56xx series) which means your DX58SO2 board most likely also supports Westmere-EP processors which … Intel has officially finished mitigating Spectre Variant 2 microcode & officially released it (at least to some OEMs).

I’m currently planning on replacing my i7-990x with x5690 Xeon in my X58 system as many websites have confirmed this works.

If it’s publicly disclosed that it’s mitigated & released then maybe someday MSFT may be more inclined to include it, the 206C2 update, in their next Intel microcode update file “mcupdate_GenuineIntel.dll”. But then again, if they do that, they may also include the 106A5 Bloomfield as we now know that they too have been mitigated and released at least to Dell & HP. Who knows, it might happen 🙂

Though the top of the line X56xx 6-core Xeons sold new for $1600+, they’ve been discontinued and you’d be hard pressed to find any new one’s for sale now. Besides, who would spend $1600 for old tech that may not get the Spectre fix?

But, you’ll find them on Amazon for under $200 used (i.e. system pulls) and lesser 4-core versions for much less. Some sellers on Amazon list them as new but believe me they’re used. Look at seller reviews and return policies. eBay has several for a little less but I would avoid ones sold as new coming from China.

The main reason I believe Westmere-EPs are not officially listed as compatible with your X58 board is because they have additional features, mainly 2 QPI bus structures to accommodate Dual Processor capability that the X58 chipset on your DX58SO2 doesn’t support. But, these Xeons work just fine as a single processor in the dual processor 5000 series chipset boards as well as in the single processor boards using the X58 chipset.

Other FYI stuff that might be of interest …

Other additional Xeon features include: ECC memory (DX58SO2 is ECC capable) and deeper memory addressing … 288GB vs. 24GB for i7.

But unofficially, your 1st gen i7 actually supports up to 48GB if using 6 x 8GB memory. Memory specs for your board indicates that it does support 8GB memory sticks so you can upgrade to 48GB if you choose to do so. See here:
https://www.intel.com/content/www/us/en/support/articles/000006914/boards-and-kits/desktop-boards.html

I personally know 1st gen i7’s support 48GB because they incorporate a 36 Bit memory address bus = 2^36 = 64GB. But with only 3 memory channels on your/my board, we MAX out at 48GB. I’m using 48GB in my ASUS P6T Deluxe V2 setup and there are also reports on various websites that confirm this. Here’s one:
http://wp.xin.at/archives/880

I suspect when X58 chipset first came out, 8GB DDR3 memory wasn’t fully developed & readily available so it wasn’t in put the X58 board specs and we already know all about engineers revisiting “old documentation” from @Nibbles 🙂

Good primer for Westmere-EP here:
https://en.wikipedia.org/wiki/Westmere_(microarchitecture)

Not-so-good (sparse info) primer for Gulftown here:
https://en.wikipedia.org/wiki/Gulftown

Good primer for Bloomfield here:
https://en.wikipedia.org/wiki/Bloomfield_(microprocessor)

Good primer for Intel i7 Processors here:
https://en.wikipedia.org/wiki/List_of_Intel_Core_i7_microprocessors

So it appears that all may not lost for the future of your Bloomfield i7-960 system post Spectre. If you really want to keep it going, you have some potentially viable options here to consider.

Group B / Win7 (Ultimate & Pro) [x64 & x86]
RDRguy

Win7 - PRO & Ultimate, x64 & x86
Win8.1 - PRO, x64 & x86
Groups A, B & ABS

4 users thanked author for this post.

Bill C., kmbrite, Elly, columbia2011

Reply | Quote

WOW!!! Thanks for the dissertation. I am serious about that compliment. I am already on BIOS 920. All my tools for CPU identification show 106A5 including the Intel Processor ID Utility.

I just finished doing a cut and paste of your post in MSWord (preserving links) for further exploration and future reference. Some of the documents I am familiar with, but others are very interesting. When the new Linux Kaby Lake build is complete, and this Win7Pro-64 PC is no longer front line and critical, this looks like an interesting project – if my research and study leads me to believe it is something I can actually pull off.

I have come across the 48GB spec in the past and I know I have it archived. The Intel documentation states 24, but I think it may have said 48 on the original motherboard box. This has been a nice, durable and reliable board, but from experience it is memory picky. My initial build of 6-2GB sticks was not able to OC the memory or hold the XMP-1600 setting, even though they were specifically listed as tested and compatible. Exchanging to 3-4GB sticks did allow the memory to be OCed. I no longer run any OC settings, as in real world use I found OCing the graphics card was more noticable in a game and was controlable with software.

Thanks again.

Reply | Quote

@kmbrite
That’s great news, I’m glad to hear you had success updating your CPU microcode and Inspectre confirmation doesn’t hurt.

But I would encourage you to also run the Microsoft PowerShell script to help ensure that you’re really protected.

https://gallery.technet.microsoft.com/scriptcenter/Speculation-Control-e36f0050#content

According to VMware, even though the VMware CPU Microcode Update Driver will upload the newer microcode version during boot, Windows’ Spectre mitigation check routine may run prior to the VMware driver executing it’s microcode upload payload. If this happens, I believe that you may get a false positive to Spectre mitigation being active within windows.

In other words, the CPU will have the mitigated microcode update, but windows will already be setup in such a way that it won’t use the the corresponding mitigating system calls to make use of the CPU mitigating functions.

I’m not sure exactly how Steve Gibson coded up his Inspectre tool, does he interact with the CPU microcode directly to detect Spectre mitigation functionality or does he interact with Windows to determine whether Windows is set up to use it. He might get it from Windows the same way that the PowerShell script does but I just don’t know and I have no way of asking him.

But, I do expect the PowerShell script to simply report whether or not windows is set up to use it. Then again I may be wrong there too.

If you go the the VMware CPU Microcode Update Driver website comments section and scroll down to the “Nico Weytens” posting (posted about 1 month ago), you’ll see that the VMware driver updated his CPU microcode but the PowerShell script indicated that his windows was not set up to use it. Further down responses state that in his system, the VMware engineers believe that the driver apparently ran to late in the boot sequence for windows to detect that the CPU was mitigated which it eventually was.

https://labs.vmware.com/flings/vmware-cpu-microcode-update-driver?ClickID=cxk7eiw7vksskvqs44nxlafzqswiq7lwlnea#comments

Because his example showed that the PowerShell script indicated that his system was not Spectre protected even though the driver indicated that the CPU microcode was updated, at this time I would tend to trust the PowerShell script result just a wee bit more than Inspectre but only because I don’t know exactly how Inspectre determines the Spectre mitigation state of the system.

In any event, you’ve come up with an alternative but similar method to Spectre Variant 2 protect “Gulftown” and that deserves a whole hardy WELL-DONE.

Thank you for sharing (and please don’t mention the trust thing to Steve).

Group B / Win 7 (Ultimate & Pro) [x64 & x86]
RDRguy

Win7 - PRO & Ultimate, x64 & x86
Win8.1 - PRO, x64 & x86
Groups A, B & ABS

1 user thanked author for this post.

kmbrite

Reply | Quote

Hi all,

The VMware fling method is one method which I am working on in order to provide a viable solution for all Win7 and Win8x users (and equivalent 2008 and 2012 servers) who wish to do one of two things:

1. Use the latest Intel Meltdown and Spectre microcode, or

2. Use the latest Intel microcode which was released just prior to when Intel started releasing their Meltdown and Spectre microcode.

I haven’t tested the VMware fling in WinXP, yet I think that it may work for XP as well. Wouldn’t that be dandy!

The other method is using the UEFI BIOS Updater tool to allow users to patch downloaded BIOS flash files with the latest Intel microcode, as in #1 or #2, above. Note that this utility only works with AMI Aptio4 and Aptio5 BIOSes. Also note that this utility is only for desktop motherboards. UEFI BIOS Updater version 1.70 is out of beta and is in further pre-release testing. Please don’t flash any modified BIOS file which you create with this utility unless you absolutely know what you are doing — as in you are a really, really, REALLY experienced computer user, and as in you really, really, REALLY understand BIOS files, and that you also really, really, REALLY understand the following notes:

— Some motherboard BIOSes have a setting which will allow you to boot, using a BIOS file which resides on a USB flash drive. Don’t boot further than to a command prompt, as system instability can occur if you boot further into Windows or Linux. The point of this USB boot feature is to simply test if the BIOS file on the USB drive actually works, before you commit to actually flashing your motherboard BIOS.

— Generally, one should first reset the present BIOS to its default settings before flashing the BIOS.

— Some things must be disabled in BIOS prior to flashing. An example is Fast Boot. If you don’t know what you must disable in BIOS prior to flashing, then NEVER flash your computer’s BIOS!

— Some motherboards feature a second “recovery” BIOS chip. It is used in case you somehow royally mess up when flashing the main BIOS.

— Some motherboard OEMs will not, under normal circumstances, allow you to flash an older BIOS version. Yet some OEMs do have “special ways” to allow you to flash an older BIOS file. ASUS is an example. I am not allowed to publicly disclose how to do this, yet it is very simple to do, given the caveats which I mentioned, above.

The UEFI BIOS Updater tool requires AMI’s MMTool. This is a proprietary AMI utility which is needed by UEFI BIOS Updater. AMI no longer allows this tool to be publicly available, or to be incorporated within UEFI BIOS Updater. There either are infected versions of AMI’s MMTool out there, or true versions which are hosted on malicious web sites. Do yourself a favor and don’t go a hunting online for MMTool. I have the non-hacked versions which have been verified by both MD5 and CRC. Yeah, MD5 is depreciated as a stand-alone file verification method since it is possible to somewhat alter a file yet produce the same MD5 signature. Yet it is impossible to do the same and also produce the same CRC signature. In other words, passing both MD5 and CRC is as good as it gets. Yet the security world would prefer just one method instead of this simple combination of two methods. That is an entirely separate topic.

Presently I prefer the VMware fling method since there is no way that you can possible mess up your computer’s BIOS, and since if somehow your Windows computer won’t boot, all you have to do is to delete the microcode.dat file which the VMware method placed in your Windows\System32 folder. After doing so and successfully booting up, you can then either uninstall the VMware fling utility, or put a new microcode.dat file into the Windows\System32 folder.

Recently there was a pull request for the VMware fling. The fling itself wasn’t responsible. Instead the issue appears to be that some users had CPUs which, via the fling, loaded Intel’s Meltdown Spectre microcode which had caveats for using said microcode. Oh, of course the users were running Windows 10.

That’s all for now.

Best regards,

–GTP

1 user thanked author for this post.

AlexEiffel

Reply | Quote

Hi everyone,

The VMware Fling’s original settings are to load as StartType=0x2 ; SERVICE_AUTO_START 0x00000002 (the Fling’s original value). While the Fling will update your CPU’s microcode to use Intel’s latest microcode, unfortunately this occurs way too late during the OS boot process for Windows to “see” it and to implement the additional software based protections which have been delivered to all Windows systems via security updates.

It is unclear as to whether or not Microsoft, on OS boot-up, is examining what microcode is actually running in your computer’s CPU cores, or whether Microsoft is only examining what microcode is in the computer’s BIOS. The ideal goal is for nobody to have to flash their older computer’s BIOS in order to implement Intel’s latest (August) CPU microcode for Meltdown and Spectre, and for Windows to “see” that your CPU is running Intel’s latest microcode for Meltdown and Spectre virtually at the instant when the Windows kernel loads.

Not only is flashing your computer’s BIOS potentially risky if you are not absolutely sure about what you are doing, but also it may be extremely difficult (and perhaps impossible with some motherboard manufacturers) to flash back to an earlier BIOS version.

The upshot is that I have been pursuing alternative methods to flashing your computer’s BIOS, and for users who have older hardware for which the motherboard manufacturer is not providing BIOS updates for Meltdown and Spectre.

I have been hacking and testing the VMware Microcode Update Driver. The cool thing is that after hacking, I can get the driver itself to load as StartType=0x0 ; SERVICE_BOOT_START 0x00000000. I can get the driver to load instantly when the kernel itself is loaded. This is the desired goal, yet VMware has some work to do in order to make it fully work.

The problem is that only a very rudimentary 8.3 file system driver is available during the SERVICE_BOOT_START stage of OS boot-up. In other words, no long file names as only 8.3 file names are supported at this zero level boot stage.

Thus, once the VMware driver loads under SERVICE_BOOT_START and virtually at the moment that the OS kernel itself loads, the driver then tries to load microcode files which have file names which do not have 8.3 compliant file names. This where the VMware driver fails when setting SERVICE_BOOT_START, instead of the VMware Fling’s original value of SERVICE_AUTO_START. The SERVICE_AUTO_START stage of the OS boot process does support long file names, yet as mentioned, the SERVICE_BOOT_START stage of the OS boot process does not.

I will contact the Fling’s developers to modify the Fling to use 8.3 file names. Hopefully they will send me a revised Fling which I can test.

Note that the Fling’s cpumcupdate32.sys and cpumcupdate64.sys files are digitally signed. Please dot NOT attempt to remove the signatures from these Fling files to subsequently edit them in terms of their internally called file names, and then to put your OS into TEST MODE in which you have disabled driver verification of the signing for all drivers. Why? Because both Microsoft and most AV manufacturers now prevent OS driver TEST MODE, and because the end result after reboot most likely will be that your computer’s BIOS will PREVENT you from loading your OS, if your OS boots via UEFI! Why? Because the bootcfg.efi will become no longer valid, and System Repair will not fix this issue. I encountered this issue, yet fortunately I booted from my Macrium Reflect USB thumb drive and had Macrium repair the UEFI boot issue.

I specifically mention the above paragraph in order to prevent everyone from trying to put their OS into TEST MODE in order to test your own hacked VMware Fling. Just so do not try to go there, whether with the VMware Fling or any other program which you might try to hack. The upshot is that putting your OS into TEST MODE for unsigned drivers is a really, really BAD IDEA with potentially bad consequences. Do NOT attempt this, regardless of whatever you see online about how to do it, since most of these online articles are seriously outdated in terms of potential consequences.

1 user thanked author for this post.

Elly

Reply | Quote