'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign

OK, so W10 only. Manual downloads for those in the know.

 

How does this work?

Is it loaded at (every) boot, like Linux does?

 

Yes. From what I have read it is a microcode update.

Processor microcode is akin to processor firmware. The kernel is able to update the processor's firmware without the need to update it via a BIOS update. A microcode update is kept in volatile memory, thus the BIOS/UEFI or kernel updates the microcode during every boot.

 

Oh boy... performance degradation for the masses!

 

Appears to me, MS must be using a driver similar to VMware CPU Microcode Update Driver: http://forum.notebookreview.com/threads/how-to-update-microcode-from-windows.787152/

 

Updated Microcode Revision Guidance for March 1, 2018.
Link: ht-tps://newsroom.intel.com/wp-content/uploads/sites/11/2018/03/microcode-update-guidance.pdf

 

Arrgh. And if it arrives via WU, how to prevent it ... one can't.

Hopefully the registry tweaks will undo the 'damage'.

 

Code:

Skylake    Intel Core i5-6400T CPU @ 2.20GHz

It didn't arrive here. Maybe because HP had already provided the / an update?

 

It's a manual update from what I've read.

If it's not made available for W7, there's another reason to shift to Linux as the host OS for a VM setup.

 

Yes. As far as KB4090007 goes, it has to be downloaded manually from the Win Update Catalog site as noted below. Also it's still unclear if this is just a .bin file that is used for manually flashing your BIOS or not. My understanding is Microsoft is just providing this to assist users whose motherboard manufacture is no longer supporting BIOS updates for the board.

https://support.microsoft.com/en-us/help/4090007/intel-microcode-updates

 

I can't say for certain because the microcode contained within that package is encrypted and I can't get at it to inspect or isolate it. However, there had been some talk that Microsoft applies these type of microcode updates via:

Code:

C:\Windows\System32\mcupdate_GenuineIntel.dll
C:\Windows\System32\mcupdate_AuthenticAMD.dll

How they are applied is beyond me.

 

This isn't a bios update.

Microsoft will put a copy of the microcode for supported intel processors in C:\Windows\System32\mcupdate_GenuineIntel.dll. This is how it has worked before (e.g. on my old/defunct Vista laptop).

At boot up the appropriate microcode data is copied to the CPU at boot time, but only if the revision stored in this file is later than the revision that was copied to the CPU by the bios prior to boot. So anyone who gets a bios update with the new microcode from their OEM/supplier, won't see any affect of this update.

It looks like only Skylake microcode has been provided for now. I would assume microcode for other CPUs will follow at some point (including for AMD CPUs). At some point I would expect to see this offered through Windows Update rather than as a specific download.

 

I am curious to test the new RESTRICT_INDIRECT_BRANCH_PREDICTION_ALWAYS_ON process mitigation.

Does anyone know of a portable tool (local executable binary) which would attempt to trigger this indirect branch predication CPU issue and therefore hopefully trip this process mitigation in the process?

Process Hacker does not yet have support for this process mitigation and therefore I don't have any other way that I know of to test this mitigation at the moment. I am trying to figure out the ProcessMitigations bit for the two-element array on my RS3 mitigations spreadsheet.

 

If anyone is wondering, I have just applied KB4090007 to one of our laptops containing a Skylake-H processor (not my main laptop, and after taking an image of the system drive using Macrium Reflect).

The update was painless and only took 5 mins including a restart.

Before the update HWiNFO64 showed the microcode was version BA, after the update it was C2.

Before the update InSpectre.exe showed the system was vulnerable to Spectre, after the update it was not vulnerable to Spectre (It was already patched against Meltdown).

So that machine appears to be all patched now.

 

Very interesting discussion on hacker news.
https://news.ycombinator.com/item?id=16107578

 

Any discernible performance impacts @pling_man?

 

No. I do some numerical programming work which is floating point heavy and I can’t see any measurable difference. If any one is worried about performance they can always uninstall the update.

Performance may be more of an issue for my Haswell laptop when there is a microcode update for that. I did experiment with the pulled Linux microcode file and the VMware driver and there was a few percent slow down on my Haswell.

 

Yeah I have Haswell on this system. Will just have to stay vigilant, this thread has been very useful.

 

I checked & my laptop haswell processor has both pcid & invpcid flags suggesting performance impact of spectre patches should be minimal whenever they are made available.However reading some posts here gives the impression that anything 4th gen & older is susceptible to significant performance loss because of spectre patches,am I missing something here.

 

Updated March 6, 2018.

 

With my 4th generation i7 Ultrabook, I ran my system with that latest BIOS/microcode update for approx. 5-7 days and attempted to get accustomed to the loss of performance to the best of my abilities. I suppose I did get used to the perf loss to a certain extent and forgot about it.

However, today, I was playing around with the InSpectre tool (from GRC) and got the idea to try disabling just the Spectre mitigation only as some of us had discussed here previously. InSpectre (when elevated) is essentially a GUI that allows modifying those same registry keys which is nice.

Oh my... the system booted significantly faster. I should also note that this i7 Ultrabook has a fast SSD. There was a huge difference there to boot time. I would have to get some tools to gauge this time difference, but for now I don't plan to go back to a slowed down system. Another area of slowdown in particular were UAC popups. Any programs which I used elevated had a particularly longer startup time in comparison to non-elevated apps. Apps with a large amount of input/output also seemed to suffer more from the performance hit.

I haven't seen any official performance comparisons from Intel or Microsoft that were specific to those 4th generation or older CPU's. They seemed to always avoid (likely on purpose) showing results for those CPUs.

No more Spectre mitigation for me. No, thank you. I've got the system back that I paid good money for.

EDIT: Actually, I will take this one step further after having more time to play around. Without the Spectre mitigation, rendering of web pages (at least in Chromium) is much, much faster. So this Spectre mitigation affects more than just system boot time and application launch times. It affects legitimate, daily web browsing. I am not a big fan of Intel right now.

 

The microcode update in regards to Intel processors for all practical purposes was to remove the "speculation" from branch prediction processing. It was this factor that lead to greater cached memory throughput and increased speed performance in Intel processors. AMD until Ryzen V5 never did speculative branch prediction hence the no loss of performance hit.

As far as removing the Intel microcode mitigation pertaining to security, it all depends if this vulnerability will ever be exploited. It appears anything cloud based is the hardware most likely to be exploited. Translation - data center servers and related hardware. At this point, it is doubtful we will ever see desktops being exploited.

 

Holy guacamole! The microcode for my Sandy Bridge Core i7 processor (circa 2011) has reached Production status. Now, the question is how can I get my hands on it. Knowing ASUS, I suspect I will have to get is from Microsoft.

 

Thank you for these details. To be quite honest, I did not understand the underlying hardware perspective here. So I appreciate the insight.