Microsoft “helps” Intel by releasing KB 4090007, a Spectre 2 firmware update for Win10 1709, Skylake processors only

Topic

New Reply

I can’t recall ever seeing Microsoft issue a firmware update (other than a Surface firmware update) as a security patch. This one comes with its own K
[See the full post at: Microsoft “helps” Intel by releasing KB 4090007, a Spectre 2 firmware update for Win10 1709, Skylake processors only]

4 users thanked author for this post.

Elly, Fred, GoneToPlaid, MrBrian

Reply | Quote

Replies

If these work I have to commend Microsoft for taking this step. A lot of older systems will probably never get a firmware update from the PC maker. I know my Haswell HP is not on the list for one. Many of these systems still have some life left and its good to know they get some support yet. I was sort of upset that Dell issued my Kaby Lake bios update weeks after it was approved for release by Intel. Goes to show you how slow PC makers are for these updates. Sort of like driver updates have been for years.

Reply | Quote

The updated Kaby Lake microcode was released to Dell on February 20. Dell simply cannot have waited *weeks* to issue it to you.

Reply | Quote

The operative phrase, of course, is “If these work.”

I agree completely, if they work — with no significant side-effects, including slowdowns — they’re great.

Let’s see what happens….

2 users thanked author for this post.

Elly, WildBill

Reply | Quote

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

Known issues

Microsoft is not aware of any issues that affect this update currently.

Ha! Watch this space, I say!

3 users thanked author for this post.

Elly, WildBill, woody

Reply | Quote

This actually is a Windows update which updates Windows file mcupdate_GenuineIntel.dll.

1 user thanked author for this post.

woody

Reply | Quote

From Will Microsoft release CPU microcode updates via Windows Update as well?: “Windows, starting from Windows 7 at least, can and do microcode update itself. It has an embedded mechanism ready and used to do that – look for the mcupdate_GenuineIntel.dll file […]”

3 users thanked author for this post.

Elly, GoneToPlaid, woody

Reply | Quote

Microsoft has released Intel microcode updates via Windows Update before, but its been a while since I’ve seen one.  I speculated (pardon the pun) that Microsoft may take this step if they think hardware vendors are either dragging their feet or refusing to update older machines.

2 users thanked author for this post.

GoneToPlaid, woody

Reply | Quote

As already said, this is not the first time a microcode update got released via windows update (elsewhere, I mean it would be pretty mot of a mechanism, isn’t it?). KB2818604 comes to my mind.

If any, it’s a good news that microsoft seems to have fixed whatever was preventing spectre fixes to be “initialized” early enough (linux always had this support from day one, I mean). So kudos to them.

OTOH, can we talk about people *not* using an AV getting scr**ed? See latest P.B. article on ars.

1 user thanked author for this post.

woody

Reply | Quote

woody wrote:

I can’t recall ever seeing Microsoft issue a firmware update (other than a Surface firmware update)

That because it is not a Firmware update.  It’s a Microcode update. A Firmware update is motherboard specific and is done with a bios flash.

This Microcode update is being injected into Windows 10-1709 itself, possibly using VMwares Microcode Update Drivers or something roughly similar (and MS coded).  The nice thing about doing it this way is if you backup image the Windows install drive before applying the update you can completely reverse the install if things go bad by restoring the backup image no matter how MS installed / injected the new Microcode into itself.

Viper

3 users thanked author for this post.

Elly, Fred, woody

Reply | Quote

I’m learning a LOT today. Keep it comin’! And thanks, everybody…

2 users thanked author for this post.

Fred, Cascadian

Reply | Quote

This is NOT a firmware update, it is a microcode update (and technically a windows patch).

Microcode updates (which are digitally signed by Intel) are applied to a CPU by the OS when the OS boots. They don’t last after a power off and have to be reapplied by the OS. The CPU/motherboard are never permanently changed by them.

Firmware updates sometimes contain microcode updates which apply automatically during or before the POST process.

In summary:
Bad microcode update applied by the OS = hardware NOT bricked, if you can get the OS to stop applying it at boot you are back in business (remove the patch or system restore in PE mode)

Bad microcode update applied by new firmware = hardware (specifically the motherboard) bricked unless you can installed fixed firmware with good microcode (either old firmware if allowed or new firmware that fixes it — just hope the bad firmware/microcode doesn’t gitch when re-flashing)

6 users thanked author for this post.

woody, Elly, abbodi86, GoneToPlaid, MrBrian, Cascadian

Reply | Quote

Also, thinking of firmware updates…

These days it’s just crazy to have a motherboard design with no reasonable failsafe for a bad firmware flash. How hard is it to put a failsafe jumper that (boots from ROM and) puts you into a firmware recovery mode with support for basic video and USB (at least keyboard and flash drive)

Plug a properly formatted flash drive with a raw firmware image with a specific name into a specific USB port (do something else also) and wait for a confirmation-less progress bar-less emergency re-flash is not what I would call a “reasonable failsafe”.

1 user thanked author for this post.

Cascadian

Reply | Quote

So long as you are discussing a hardware feature that requires physical, real world manipulation of a literal jumper or switch, accessible under the first set of screws removed to open the case, I am in agreement. The problem is all current solutions are downloadable, because we can fix that with code.

My opinion is every code written can, and eventually will, be breached maliciously. This level of system change should require physical presence to initiate. I think you are saying the same, but do not want to assume.

Reply | Quote

Apart from the failsafe boot from ROM in case of a bad BIOS update, there is already technology for that, some eons ago (referring to the boot from a USB thumb drive with a file with a BIOS update having a specific filename). And I believe by that time there were already motherboards with 2 BIOS chips as a failsafe.

This old typewriter I’m using right now has that USB update system. It’s an Atom Acer Aspire One KAV10 from ~10 years ago.

It came with a bug that didn’t report the OS all the CPU speeds. The original owner, a friend who gave it to me 3 years ago, spent money on a 1.66GHz CPU when the BIOS was only reporting 1,33GHz to the OS. After years of the Ubuntu community screaming and ranting at Acer, they finally made the BIOS update. The good news it that now it works full speed (that’s a ~20% increase that promoted it from decorative slow door stopper to a very loved Mint Debian typewriter). The bad news is that suspension and hibernation are kinda broken on Linux. This has also happened with another Acer laptop 3 years ago when it was only 3 months old when Acer offered the upgrade from Windows 8 to 8.1 and recommended a BIOS update for better yadda yadda yadda with 8.1. After breaking hibernation, the old BIOS was not accepted back, couldn’t install it, so I had to keep the bug and Acer washed their hands off. (and it was a brand new laptop still under warranty and the new BIOS bugs were their responsibility!)

So, TLDR, this BIOS update technique exists for about 10 years; if you use Linux don’t upgrade the BIOS on an Acer laptop as they seem to brake power saving (ACPI?) unless you really need it; and if you can instead apply a microcode update, do it. IIIIIF (huge if) one is given.

Reply | Quote

Well, at least twice last month I wrote comments where SpectreV2 patches would only come from OEM badge or chipmaker. I have been proven wrong again. Surprised Microsoft is taking on this liability. Maybe I should not be.

Am interested to see going forward if they do complete the promise for other brands of silicon. Or whether this is another indication of unique relationship with one manufacturer.

Reply | Quote

FWIW, HP pushed out a Critical Alert mail today for a BIOS update for my Zbook 17, i7 Haswell plain Jane on Win7 Pro x64. Release notes say only security and stability, nothing about Spectre, etc. Two weeks ago they rolled out a microcode reversion which I applied. When I spoke to Business Support at the time, the tech said my latest installed wasn’t for Meltdown or Spectre anyway. HP had rolled one out, but not the SoftPaq I’d last installed. Maybe for only the latest chipsets?

Have to renew my Care Pack by March 8th and will be speaking to them about any impacts from today’s release and what specifically is mitigated but today’s is dated January 30th. No rush to install and not reversible…

Unrelated but patch-related question for Woody: Did a system restore last PM which failed. Earlier restore point also failed. Error was 0xc0000022. Googling said causes were endless and I couldn’t read the CBS.Log, not that I’d have a clue if I could… (Was able to undo that particular system restore successfully though. Go figure!)

Ran sfc /scannow and got “found corrupt files but unable to fix some of them”. Ran in Safe Mode and got the same result. More Googling. Found your old article about kb2952664 and kb3022345 which can break sfc and give false positives. Fingers crossed, that’s all I’ve got!

So, big question, both of those telemetry updates were installed in early 2015 before I ceased trusting Windows Update or found your articles. Am I safe to uninstall both of these updates without risk to life and limb and workstation???

Thanks!

Reply | Quote

anonymous wrote:

So, big question, both of those telemetry updates were installed in early 2015 before I ceased trusting Windows Update or found your articles. Am I safe to uninstall both of these updates without risk to life and limb and workstation???

You can uninstall them safely.  You will probably find multiple copies of at least KB2952664 –  you will uninstall and it will seem to reinstall, but what is happening is an earlier viersion is becoming visible. So you have to uninstall ALL of them.

There are several topics on that on the site. Search for “remove KB2952664”

Reply | Quote

Thanks! Found the post but the DISM commands didn’t work for me and/or this machine. Maybe we’re both retarded. Was able to remove both updates from Programs & Features and neither appear to have reinstalled after a cold boot. Will hide them in Windows Update when they reappear after Defcon 3+.

Reply | Quote

Now I’m even more confused.  If your motherboard manufacturer releases a firmware update that addresses the same vulnerability and presumably includes the new microcode, which should you install?  How do you know if the microcode in that FW update is the same as that in the Microsoft update?  If they’re not and you install both, I assume the kernel stomps on the BIOS microcode upon boot.  Wouldn’t that be an issue?

 

Reply | Quote

From Intel’s latest set of Spectre microcode fixes is coming to a Windows update: “Microcode updates have two main distribution channels.”

2 users thanked author for this post.

Fred, woody

Reply | Quote

anonymous wrote:

Microsoft has released Intel microcode updates via Windows Update before, but its been a while since I’ve seen one. I speculated (pardon the pun) that Microsoft may take this step if they think hardware vendors are either dragging their feet or refusing to update older machines.

True, and at the time it was for the ME engine vulnerabilities, and there were issues. The issues were whether or not it should be Microsoft or the motherboard OEMs who should be fixing the ME engine vulnerabilities, and that Microsoft kind of botched it in terms of properly detecting specific CPU models and flavors.

Reply | Quote

Cascadian wrote:

Well, at least twice last month I wrote comments where SpectreV2 patches would only come from OEM badge or chipmaker. I have been proven wrong again. Surprised Microsoft is taking on this liability. Maybe I should not be. Am interested to see going forward if they do complete the promise for other brands of silicon. Or whether this is another indication of unique relationship with one manufacturer.

I would say that this is the end of the relationship between Microsoft and Intel. As you said, you are surprised that Microsoft is taking on this liability. I am not, since at the end of the day it is in Microsoft’s best interests do actually do something about it since Microsoft now realizes that the OEM motherboards manufacturers have no interest in releasing BIOS updates with new microcode to address Spectre 2 for out of warranty motherboards. I have checked the web sites for all of the major OEM motherboard manufacturers. They all seem to be following the same strategy — only offer BIOS updates for motherboard models which are still in warranty or perhaps not too long out of warranty.

1 user thanked author for this post.

Cascadian

Reply | Quote

PKCano wrote:

anonymous wrote:

So, big question, both of those telemetry updates were installed in early 2015 before I ceased trusting Windows Update or found your articles. Am I safe to uninstall both of these updates without risk to life and limb and workstation???

You can uninstall them safely. You will probably find multiple copies of at least KB2952664 – you will uninstall and it will seem to reinstall, but what is happening is an earlier viersion is becoming visible. So you have to uninstall ALL of them. There are several topics on that on the site. Search for “remove KB2952664”

I have written a new batch file (CMD file) which will automatically detect and optionally remove all installed instances of KB2952664. It won’t do so if it first detects that there may be issues with the user’s hard drive which would need to be addressed first. The test is simple. Check whether or not the OS hard drive partition’s dirty bit has been set. If it has been set, then my batch file exits immediately and without doing anything — other than to display a warning message that the user’s hard drive may be failing or has other issues which need to be addressed first. Anyway, either tonight or tomorrow night I will create a topic about it, so that it can be reviewed by all of the experts here.

There are two other old Windows 7 telemetry updates which also may have multiple instances installed. After performing a lot of experimental testing, I determined that it is better to take down all instances of the “big three” telemetry updates, which installed multiple versions, separately and individually. Microsoft has made this a riot of fun since this is exactly what Microsoft does not want users to be able to easily do.

Reply | Quote

davefox wrote:

Now I’m even more confused. If your motherboard manufacturer releases a firmware update that addresses the same vulnerability and presumably includes the new microcode, which should you install? How do you know if the microcode in that FW update is the same as that in the Microsoft update? If they’re not and you install both, I assume the kernel stomps on the BIOS microcode upon boot. Wouldn’t that be an issue?

If you install a BIOS update which is provided by your PC manufacturer or OEM motherboard manufacturer, then I am sure that Microsoft will detect that your CPU is already running the new Intel microcode which fixes the Spectre 2 vulnerability. This is easy for Microsoft to detect since all CPU microcode has a version number.

If you install a BIOS update which is provided by your PC manufacturer or OEM motherboard manufacturer, then you might find that it is impossible to revert to an earlier microcode which does not have the Spectre 2 fix, and as a result, your CPU will forever operate considerably more slowly — on that motherboard. And if the new microcode in the BIOS update is flawed, then you will find yourself in a rather bad situation.

If you install Microsoft’s update, then at least you can recover if the new CPU microcode which is included in Microsoft’s update is once again flawed. Recovering could be a pain in the butt, since you would have to boot to a Command Prompt and then type in commands to remove the bad Microsoft update, but at least this could be done.

The upshot is that the safest option, at least for the time being, is to go with the Microsoft solution instead of a potentially irreversible OEM solution.

2 users thanked author for this post.

Elly, Noel Carboni

Reply | Quote

I too must commend Microsoft for taking this step, and I can understand why they have decided to do so. Microsoft obviously understands that both computer manufacturers and in particular OEM motherboard manufacturers probably will not bother to create new BIOS updates which include Intel’s latest firmware which addresses the Spectre 2 vulnerability since these products are out of warranty. Microsoft seems to be stepping up to the plate in order to protect computers which are used in the corporate world, and at the same time this generates a side affect of also protecting consumers using home computers. At the end of the day, Intel is going to owe Microsoft big time if Microsoft pulls this off.

Intel just released microcode updates to OEMs for many Haswell and Broadwell CPUs. Yet whether or not your motherboard manufacturer will make them available is, well, are resounding “probably not” for older motherboards. Why? Because it would hurt sales for their current products which they are obligated to support, versus older product which they are no longer required to support. It is what it is. I am sure that the bean counters in their legal departments have already running the numbers.

For OEM motherboard manufacturers, simply think about it. They do not manufacture the CPUs which get installed into their products. Thus they have little reason to bother with supporting motherboards which are out of warranty since they would rather sell new motherboards. I said “little reason” for a reason. At the same time, OEM motherboard manufacturers could incur backlash and brand avoidance by not publishing BIOS updates which include Intel’s latest microcode for out-of-warranty motherboards. I think that we will fairly rapidly see which OEM motherboard manufacturers percolate to the top in terms of brand loyalty, depending on whether or not they decide to implement BIOS updates which protect against Spectre for their customers whose motherboards are out of warranty.

It is going to get interesting, since recently it appears that the first few Spectre exploits are actually out there in the wild.

Reply | Quote

I’m still amazed that in discussions people now speak of Haswell as “old hardware”. It was new tech what, 3, 4 years ago?

As an engineer I certainly understand the rate at which technology moves. I understand that there have been a number of new Intel CPU architectures since then. But there’s something fundamental at play here…

Perhaps a computer isn’t something that should be thought of as “throwaway tech”… The implications of we all being groomed to think of hardware being “old” in a few scant years and software being replaced in months are substantially not good.

It’s hard to put what I’m thinking into words (maybe I’m just tired this evening) but when everything changes in months – not years – and companies don’t support things for years, no big, important problems can get solved. Complex computer programs that actually advance the world’s state of the art don’t get written in months.

-Noel

5 users thanked author for this post.

LH, Cascadian, MrBrian, Elly, David F

Reply | Quote

Noel Carboni wrote:

I’m still amazed that in discussions people now speak of Haswell as “old hardware”. It was new tech what, 3, 4 years ago? As an engineer I certainly understand the rate at which technology moves. I understand that there have been a number of new Intel CPU architectures since then.

Honestly, those architectures are not at all groundbreaking. I had a (severely overclocked, I admit) Core 2 Quad Q9650 (CPU from Q3 2008) until last year or so and changed it for an i5-6402P Skylake and it is marginally faster (Q4 2015 – over SEVEN years later). I deliberately chose not to get Kaby Lake i5-7400 (Q1 2017) back then, because it was just a fraction faster and not to be supported by Windows 8.1. So basically we’re talking 8 and a half years without any significant improvements. Intel’s monopoly didn’t force them to do anything spectacular. Now, when AMD is at least partly back to the game, maybe they’ll do a bit more.

Fractal Design Pop Air * Thermaltake Toughpower GF3 750W * ASUS TUF GAMING B560M-PLUS * Intel Core i9-11900K * 4 x 8 GB G.Skill Aegis DDR4 3600 MHz CL16 * ASRock RX 6800 XT Phantom Gaming 16GB OC * XPG GAMMIX S70 BLADE 1TB * SanDisk Ultra 3D 1TB * Samsung EVO 840 250GB * DVD RW Lite-ON iHAS 124 * Windows 10 Pro 22H2 64-bit Insider * Windows 11 Pro Beta Insider

1 user thanked author for this post.

Noel Carboni

Reply | Quote

I’ll have to disagree with you that architectures haven’t been advancing much.

Yes, individual core speed has been rising only modestly, but compute throughput has been increasing overall radically through advancements in multithreading (i.e., more and more cores working on things simultaneously) coupled with RAM and I/O speed advancements.

The compute throughput of a high-end Haswell design e.g., 4 core i7-4940 @ 3.10 GHz vs., say, a SkyLake e.g., 18 core i9-7980 @2.6 GHz really works out to be pretty different…

That being said, many (most?) modern software cannot take advantage of extreme multi-threading, so users may not see a 2 to 1 or 3 to 1 improvement in their overall computing experiences between a Haswell-based system and a Skylake-based system.

I’m all for advancement of tech into faster and faster speeds, but making people think their Haswell-based systems (or God forbid, even older systems) are simply too old to matter (and be supported) borders on being a too-obvious ruse to get everyone to spend more money.

-Noel

2 users thanked author for this post.

MrBrian, Elly

Reply | Quote

Noel Carboni wrote:

I’ll have to disagree with you that architectures haven’t been advancing much. Yes, individual core speed has been rising only modestly, but compute throughput has been increasing overall radically through advancements in multithreading (i.e., more and more cores working on things simultaneously) coupled with RAM and I/O speed advancements. The compute throughput of a high-end Haswell design e.g., 4 core i7-4940 @ 3.10 GHz vs., say, a SkyLake e.g., 18 core i9-7980 @2.6 GHz really works out to be pretty different…

That’s comparing 4 cores to 18 cores… Not too fair. And these are synthetic benchmarks.

I cannot find info on prices at launch, but I suppose there will be a significant gap there as well.

Both are far from being mainstream CPUs. And I guess that’s where we should look. It’s like 2017 Ferrari may be significantly faster than a 2007 Ferrari (I don’t really care), but a 2017 Chevy won’t be much quicker than a 2007 Chevy.

Here you can find a comparison of top desktop 4-core CPUs (4790K vs. 6700K) and it doesn’t look too impressive (it’s in Polish, but you can translate or just look at the pics):

http://www.benchmark.pl/aktualnosci/intel-core-i7-6700k-skylake-4790k-haswell-porownanie-wydajnosci.html

Fractal Design Pop Air * Thermaltake Toughpower GF3 750W * ASUS TUF GAMING B560M-PLUS * Intel Core i9-11900K * 4 x 8 GB G.Skill Aegis DDR4 3600 MHz CL16 * ASRock RX 6800 XT Phantom Gaming 16GB OC * XPG GAMMIX S70 BLADE 1TB * SanDisk Ultra 3D 1TB * Samsung EVO 840 250GB * DVD RW Lite-ON iHAS 124 * Windows 10 Pro 22H2 64-bit Insider * Windows 11 Pro Beta Insider

1 user thanked author for this post.

Noel Carboni

Reply | Quote

It might seem an unfair comparison except that the prices of mutli-core CPUs keep coming down. Using more cores is definitely where we are headed, since clock/switching speeds are necessarily limited by physics.

Hey, I avoided comparing Xeons. I actually use Xeons in my systems (2 each). This shows a progression of overall CPU throughput for five different actual dual Xeon-based workstations in the past 13 years…

I actually owned/own the first four and I can tell you that for some of the work I do the amount of work I’ve been able to push through these systems virtually doubled with each new model. Benchmarks are not completely useless.

-Noel

1 user thanked author for this post.

Elly

Reply | Quote

Noel Carboni wrote:

I’m still amazed that in discussions people now speak of Haswell as “old hardware”. It was new tech what, 3, 4 years ago?

I don’t consider Haswell to be “old hardware”. It was the newest hardware I could get that met my requirements when I bought a new computer a couple of years ago — I wanted a computer that would have no problem running Windows 7, including being able to update it with no issues. Haswell was (and still is) the latest technology that met my needs. (Broadwell would have, but Broadwell simply wasn’t available.)

Group "L" (Linux Mint)
with Windows 10 running in a remote session on my file server

2 users thanked author for this post.

GoneToPlaid, Elly

Reply | Quote

MrJimPhelps wrote:

I don’t consider Haswell to be “old hardware”. It was the newest hardware I could get that met my requirements when I bought a new computer a couple of years ago — I wanted a computer that would have no problem running Windows 7, including being able to update it with no issues. Haswell was (and still is) the latest technology that met my needs. (Broadwell would have, but Broadwell simply wasn’t available.)

When I was considering upgrading my Sandy Bridge machine in the beginning of 2016, I was also planning to get a new system that would allow me to continue to run Windows 7 and 8.1 with official support, like you. I originally planned to upgrade to Skylake, but when I heard in January 2016 that Microsoft wanted to restrict the support of Windows 7 and 8.1 on Skylake to July 2017 (a decision that has since been reversed by Microsoft), I immediately put my plans on hold.

Later I decided it is best for me to upgrade to the X99 platform (Haswell-E / Broadwell-E) with six core CPUs instead since it still is officially supported under Windows 7 and 8.1. I have since made a substantial hardware investment into the platform, and I intend to use my X99 systems for a long time with Windows 7 and 8.1.

Hope for the best. Prepare for the worst.

1 user thanked author for this post.

Elly

Reply | Quote

For inspiration or language to help get your idea out, you could turn to Douglas Adams’s Hitchhiker “trilogy”. Both Deep Thought and Earth mark 1 required a long duration run. Forty-two may not be the answer you need though.

Reply | Quote

Noel, we agree with you. Your feeling of 3 to 4 years is now “old” is correct.  This is not the way it should be.

We are being “groomed” to think, if your device is just a year or two old, it is time to start looking. Why? Because it makes sales.

Canadian Tech was commenting on hard drives. We occasionally hear people say how much they love SSDs and if spinning a hard drive is over a year old you may as well have it replaced.

Not true. SSDs can fail too, with much less warning. If people are replacing devices every year or two, they must be dropping them or getting them wet or somehow abusing them.

Noel you are right.

I have seen people with computers that were decades old (decades) and they still do the job that person or company needs. Don’t believe me? Look at Point of Sale POS machines still running “paid supported” Windows XP.

 

1 user thanked author for this post.

Elly

Reply | Quote

There’s nothing remarkable about the microcode update coming through the OS.  Intel releases the updates to the public so they can be used, and they’re specifically labeled as being for Linux (an OS)– they’re not going to be angry at MS or anyone else for doing the same.   I’d be more surprised if Microsoft didn’t release them as Windows updates.

There’s nothing wrong with installing both the firmware-based microcode update and the OS microcode update (as opposed to only doing one or the other).   They won’t conflict.

When you first turn on the PC, it will load the appropriate microcode into the CPU before it boots the OS.  Once control is passed to the OS during the boot process, the OS will check the microcode loaded into the CPU against that in the OS update.  If the microcode in the OS update is newer, the OS will unload the firmware-based microcode from the CPU and replace it with what is in the update.

If you have a significantly old motherboard or PC (meaning that the OEM has stopped releasing new firmware updates), it’s probably already doing this. I’ve seen several CPU microcode updates in my own update history in Windows (this was years ago, when I was still running Windows 7).

Flashing firmware always presents some level of risk, though usually it is quite minor, and the problematic microcodes we’ve seen until now only make that worse.  It would be wise to hold off on the flashing for the time being and let the update be delivered via the OS– at least until enough time has elapsed to be sure that the microcode is working well and not causing any issues.

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

4 users thanked author for this post.

Cascadian, MrBrian, Elly, woody

Reply | Quote

I hope Windows 8.1 don’t get it

1 user thanked author for this post.

radosuaf

Reply | Quote

If it’s not pushed into cumulative update, you can just skip it. It’s 8.1, not 10 :).

Fractal Design Pop Air * Thermaltake Toughpower GF3 750W * ASUS TUF GAMING B560M-PLUS * Intel Core i9-11900K * 4 x 8 GB G.Skill Aegis DDR4 3600 MHz CL16 * ASRock RX 6800 XT Phantom Gaming 16GB OC * XPG GAMMIX S70 BLADE 1TB * SanDisk Ultra 3D 1TB * Samsung EVO 840 250GB * DVD RW Lite-ON iHAS 124 * Windows 10 Pro 22H2 64-bit Insider * Windows 11 Pro Beta Insider

Reply | Quote

woody wrote:

I’m learning a LOT today. Keep it comin’! And thanks, everybody…

“just feeling like a guinea pig again, and again …….  ‘-S   “

* _ ... _ *

Reply | Quote

Lost any faith in MS, sticking with Group W, there are no exploits in the wild

Reply | Quote

From Windows Client Guidance for IT Pros to protect against speculative execution side-channel vulnerabilities: “Microsoft will make available Intel microcode updates for devices running Windows 10 version 1709 and Windows Server 2016 version 1709, through the Microsoft Update Catalog.”

Reply | Quote

A consumer with the entry level or slightly higher requisites for Windows 10 is now in an interesting position. And so too is Microsoft. These consumers are more than likely on older hardware, possibly 32 bit architecture and a minimum of 2GB RAM. The meltdown and spectre vulnerability patches and updates have a high probability of imposing a 30% or more performance hit on these systems, if installed.

There are millions of consumers with these specs and many have limited computing knowledge and/or do do not follow current tech news and/or leave all the decision making to Microsoft. As this particular microcode update will not be sent via windows update and the OEMs are unlikely to deliver chipzilla’s BIOS updates to most of these systems, they will remain perpetually insecure.

W10 is a fully supported OS. Microsoft having millions of potentially insecure W10 systems is not where they want to be. I think the Cabal will probably reconvene before year end and decide it is better (for them) to have poor performing systems than insecure ones. It is highly likely that Microsoft will silently install the microcode update via BITS to every W10 user.

Business wise, W10 has to remain the most secure OS ever. The vendors will see new product sales.

Reply | Quote

I downloaded and installed this patch over Win 10 Pro 1709, 64-bit, with a Skylake i5-6500.

No slowdown or other issues so far. If that changes, I’ll post back.

I like the idea that it’s a “microcode” rather than a BIOS update (which would have a higher degree of bricking potential), because in theory at least, the microcode update can be uninstalled or overwritten via backed-up image restore if need be.

Once installed successfully, it does show up in the Win 10 update history screen.

2 users thanked author for this post.

rc primak, Cascadian

Reply | Quote

I’m still on 1703, so this will have to wait for Woody’s green light (or amber) on the FCU.

-- rc primak

Reply | Quote

There was this in 2011:

https://support.microsoft.com/en-us/help/2493989/microcode-update-for-intel-processors-in-windows-7-or-in-windows-serve

Reply | Quote