Windows Client Guidance against speculative execution vulnerabilities

Gordon7 said:

New update: KB4078130 (Important)

Update to Disable Mitigation against Spectre, Variant 2

Applies to: Windows 7 Service Pack 1Windows 8.1Windows 10 More

---

Summary

---

Intel has reported issues with recently released microcode meant to address Spectre variant 2 (CVE 2017-5715 Branch Target Injection) – specifically Intel noted that this microcode can cause “higher than expected reboots and other unpredictable system behavior” and then noted that situations like this may result in “data loss or corruption.” Our own experience is that system instability can in some circumstances cause data loss or corruption. On January 22^nd Intel recommended that customers stop deploying the current microcode version on impacted processors while they perform additional testing on the updated solution. We understand that Intel is continuing to investigate the potential impact of the current microcode version and encourage customers to review their guidance on an ongoing basis to inform their decisions.
While Intel tests, updates and deploys new microcode, we are making available an out of band update today, KB4078130, that specifically disables only the mitigation against CVE-2017-5715 – “Branch target injection vulnerability.” In our testing this update has been found to prevent the behavior described. For the full list of devices, see Intel’s microcode revision guidance. This update covers Windows 7 (SP1), Windows 8.1, and all versions of Windows 10, for client and server. If you are running an impacted device, this update can be applied by downloading it from the Microsoft Update Catalog website. Application of this payload specifically disables only the mitigation against CVE-2017-5715 – “Branch target injection vulnerability.”
We are also offering a new option – available for advanced users on impacted devices – to manually disable and enable the mitigation against Spectre Variant 2 (CVE 2017-5715) independently via registry setting changes. The instructions for the registry key settings can be found in the following two Knowledge Base articles:

• KB4073119: IT Pro Guidance
• KB4072698: Server Guidance

As of January 25, there are no known reports to indicate that this Spectre variant 2 (CVE 2017-5715 ) has been used to attack customers. We recommend Windows customers, when appropriate, reenable the mitigation against CVE-2017-5715 when Intel reports that this unpredictable system behavior has been resolved for your device.






How to get this update

---

Microsoft Update Catalog

	Title	Products	Classification	Last Updated	Version	Size
	Update for Windows (KB4078130)	Windows 10,Windows 10 LTSB,Windows 7,Windows 8.1,Windows Embedded Standard 7,Windows Server 2008,Windows Server 2008 R2,Windows Server 2012 R2,Windows Server 2016	Critical Updates	1/27/2018	n/a	24 KB

http://www.catalog.update.microsoft....q=%20KB4078130






More Information

---

Known issues in this update

---

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






Prerequisites

---

There are no prerequisites to apply this update.





Registry information

---

To apply this update, you don't have to make any changes to the registry.






Restart requirement

---

You will have to restart the computer after you apply this update.





Update replacement information

---

This update does not replace a previously released update.

---

Last Updated: Jan 27, 2018

I tried to install this twice and absolutely nothing happens.

Nevermind

Josey Wales said:

The Fault lies with Intel and Only Intel. That Company is responsible for the flawed CPU's that were being developed since the 90's not to mention the $24 Million that it''s Kind CEO made by selling his stock....

Completely bogus.

Spectre affects Intel, AMD, ARM v75+, even Apple's A-x CPUs.

Please do a little more reading and undeerstand what is going on here - Intel didn't know this was a possibility in the way that the CPUs were set up and the way that OSs and software made use of hte setup of the CPU Until June of 2017. The idea of this vulnerability dates back only to early 2016, when researchers at a security conference speculated on the existence of the vulnerabilities after the presentation of another vulnerability that was discovered in 2014.

This is not like with software, where some software depends upon a DLL that has been known to be exploited in the past, or anything remotely like it. That type of an opinion / attitude is pure FUD.

VBF said:

I agree with pretty much all of that but as I implied above, with most updates, you can back out fairly easily or recover in some other way. When it's the microcode that's being changed, "bricking" is a distinct possibility.
Also, many people buy (or are sold) computers the same way that they buy TVs DVD players, microwaves et al. Then they expect to just be able to use them with little or no effort.

As we know, that ain't the case!

When it is anything kernel related, bricking is a distinct possibility.

When it is anything OS related, bricking is a distinct possibility.

So, really, nothing really distinct about it.

The microcode that Intel has released (and periodically releases) is easily usable on *nix systems by placing it in a particular path so that the kernel loads it at boot time - something not working right, delete the file.

So, the bricking comes not from the hardware side of things, but the software side of things.

And thus, my point - it's Windows - bricking is not a distinct possibility in any update situation any more so than any other update situation -any update has the potential to brick your OS.

Now, if you're discussing probabilities, then you might be able to make a case - but I'd argue that driver updates, kernel updates an other backend updates are just as probable to lead to a brick situation as this microcode update is. In fact, I'd argue that kernel updates and driver updates both are more probable to lead to a bricking situation than the CPU microcode update will.

johngalt said:

Completely bogus.

Spectre affects Intel, AMD, ARM v75+, even Apple's A-x CPUs.

Please do a little more reading and undeerstand what is going on here - Intel didn't know this was a possibility in the way that the CPUs were set up and the way that OSs and software made use of hte setup of the CPU Until June of 2017. The idea of this vulnerability dates back only to early 2016, when researchers at a security conference speculated on the existence of the vulnerabilities after the presentation of another vulnerability that was discovered in 2014.

This is not like with software, where some software depends upon a DLL that has been known to be exploited in the past, or anything remotely like it. That type of an opinion / attitude is pure FUD.



When it is anything kernel related, bricking is a distinct possibility.

When it is anything OS related, bricking is a distinct possibility.

So, really, nothing really distinct about it.

The microcode that Intel has released (and periodically releases) is easily usable on *nix systems by placing it in a particular path so that the kernel loads it at boot time - something not working right, delete the file.

So, the bricking comes not from the hardware side of things, but the software side of things.

And thus, my point - it's Windows - bricking is not a distinct possibility in any update situation any more so than any other update situation -any update has the potential to brick your OS.

Now, if you're discussing probabilities, then you might be able to make a case - but I'd argue that driver updates, kernel updates an other backend updates are just as probable to lead to a brick situation as this microcode update is. In fact, I'd argue that kernel updates and driver updates both are more probable to lead to a bricking situation than the CPU microcode update will.

No John sorry I have to disagree.

You cannot really BRICK a system with the wrong OS, software, drivers etc. What you can do is make it unable to boot and then if you have an image you restore it, or rebuild the OS - as I keep saying!

Even a PC that won't boot like the AMDs were after that infamous CU...is NOT bricked. If it's possible to recover in any way, it's not bricked. BUT if the microcode and/or BIOS gets corrupted and it won't even get into the setup...THEN it's bricked. Hence my assertion that a microcode or BIOS update is infinitely more dangerous than a "regular" s/w update.

The microcode released to OSs is not going to brick your hardware - it is not a firmware type update.

The CPU microcode that is released periodically by Intel (see here for more details, including all of the previous ones they have released - Download Linux* Processor Microcode Data File ) is made to supersede what is loaded from the BIOS - nothing more.

it does not replace the BIOS microcode in the BIOS itself.

Detailed Description

Purpose

This microcode data file contains the latest microcode definitions for all Intel processors. Intel releases these updates periodically. These microcode data files correct processor behavior as documented in the respective processor specification guidelines.

While the regular approach to getting this microcode update is via a BIOS update, Intel realizes that this can be an administrative hassle. The Linux* operating system has a mechanism to update the microcode after booting. For example, this file will be used by the operating system mechanism if the file is placed in the /etc/firmware directory of the Linux system.

I hope that makes it a bit more clear.

johngalt said:

Completely bogus.

Spectre affects Intel, AMD, ARM v75+, even Apple's A-x CPUs.

Please do a little more reading and undeerstand what is going on here - Intel didn't know this was a possibility in the way that the CPUs were set up and the way that OSs and software made use of hte setup of the CPU Until June of 2017. The idea of this vulnerability dates back only to early 2016, when researchers at a security conference speculated on the existence of the vulnerabilities after the presentation of another vulnerability that was discovered in 2014.

This is not like with software, where some software depends upon a DLL that has been known to be exploited in the past, or anything remotely like it. That type of an opinion / attitude is pure FUD.



When it is anything kernel related, bricking is a distinct possibility.

When it is anything OS related, bricking is a distinct possibility.

So, really, nothing really distinct about it.



The microcode that Intel has released (and periodically releases) is easily usable on *nix systems by placing it in a particular path so that the kernel loads it at boot time - something not working right, delete the file.

So, the bricking comes not from the hardware side of things, but the software side of things.

And thus, my point - it's Windows - bricking is not a distinct possibility in any update situation any more so than any other update situation -any update has the potential to brick your OS.

Now, if you're discussing probabilities, then you might be able to make a case - but I'd argue that driver updates, kernel updates an other backend updates are just as probable to lead to a brick situation as this microcode update is. In fact, I'd argue that kernel updates and driver updates both are more probable to lead to a bricking situation than the CPU microcode update will.

Who produced The Faulty Chips? Intel and AMD. Why did Intel take Full Responsibility? The Original issue ls with Intel and AMD.

johngalt said:

The microcode released to OSs is not going to brick your hardware - it is not a firmware type update.

The CPU microcode that is released periodically by Intel (see here for more details, including all of the previous ones they have released - Download Linux* Processor Microcode Data File ) is made to supersede what is loaded from the BIOS - nothing more.

it does not replace the BIOS microcode in the BIOS itself.



I hope that makes it a bit more clear.

So is it microcode applied after BIOS(hardware check), during the CMOS phase(applying hardware settings), or during the OS load phase?
I like learning new things:)

Cliff S said:

So is it microcode applied after BIOS(hardware check), during the CMOS phase(applying hardware settings), or during the OS load phase?
I like learning new things:)

Bottom line is without the faulty chips all the other problems would not exist.:)

johngalt said:

The microcode released to OSs is not going to brick your hardware - it is not a firmware type update.

The CPU microcode that is released periodically by Intel (see here for more details, including all of the previous ones they have released - Download Linux* Processor Microcode Data File ) is made to supersede what is loaded from the BIOS - nothing more.

it does not replace the BIOS microcode in the BIOS itself.



I hope that makes it a bit more clear.

If you're 100% sure about that well yes it alters my thinking.
So, to be clear, are you saying that after power-on and POST, the OS loads and then the microcode data file is called to overwrite existing microcode?
In which case the "fix" is actually part of the OS albeit at kernel level?

If so, then I agree that if it went horribly wrong, a re-image or rebuild WOULD sort it out.
But, that isn't how I thought it worked at all!

VBF said:

If you're 100% sure about that well yes it alters my thinking.
So, to be clear, are you saying that after power-on and POST, the OS loads and then the microcode data file is called to overwrite existing microcode?
In which case the "fix" is actually part of the OS albeit at kernel level?

If so, then I agree that if it went horribly wrong, a re-image or rebuild WOULD sort it out.
But, that isn't how I thought it worked at all!

If that was the case my PC would not be vulnerable but it is?

Josey Wales said:

Who produced The Faulty Chips? Intel and AMD. Why did Intel take Full Responsibility? The Original issue ls with Intel and AMD.

Meltdown problem came from a performance enhancing feature that was not properly tested for security risks. Who knows how many new holes will be discovered in the future as this one Could have been even worse existed for years. CPUs became enormously complicated. For once, somebody discovered it before hackers did, could have been even worse mess.