Windows Client Guidance against speculative execution vulnerabilities

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.

Apple makes their own chips.

Qualcomm makes their own chips.

Other manufacturers also manufacture chips to the ARM v75 standards.

So, again, it is not just Intel, and it is not just Intel and AMD.

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:)

Microcode is in the BIOS / UEFI, which is the first place it is encountered.

Linux has hte ability to supersede that with updated microcode, which is loaded by the kernel at boot from that folder.

As far as I know, Window sdoes not have the ability to load microcode after the fact, superseding what is in the BIOS (but I may be wrong on this if Microsoft is, in fact, offering update(s) via WU that are microcode-specific, as we seem to be seeing here recently). And if it does, then they have been doing this all along without many of us knowing about it.

But when the OS makes use of newer microcode, it does not overwrite the BIOS / UEFI.

So, no, an OS loading microcode is not going to brick the machine any more than a bad driver load.

However, yes, a bad driver load, can, in fact, brick a machine - if the driver causes a hardware fault that is not resolved, it can very well fry the hardware - which is the type of bricking VBF was referring to - and which can easily happen with bad drivers, and has happened in the past.

Ok John I think I found the answer to my question:

In recent years, there is an increasing attention to the UEFI BIOS security. As a result, there are more advanced technologies created to protect UEFI BIOS from illegal modifications. One of such technologies is Intel Boot Guard (BG) – a hardware-assisted BIOS integrity verification mechanism available since Haswell microarchitecture (2013). So-called «UEFI rootkits killer» this technology is designed to create a trusted boot chain (where a current boot component cryptographically measures/verifies the integrity of the next one) with Root-of-Trust locked into hardware.


The first boot component (the Root of Trust) in this chain is Intel CPU with the microcode (located inside the CPU boot ROM). It loads into the protected internal CPU memory called Authenticated Code RAM (ACRAM), verifies and executes an Intel-signed BG startup Authenticated Code Module (ACM). The hash of the RSA public key (which is used to verify the signature of the ACM) is hard-coded inside the CPU. This is an Intel-developed part of the technology implementation. Intel BG ACM acts before the execution of BIOS and is responsible for verifying its initial part called the Initial Boot Block (IBB). Usually, the IBB represents the contents of SEC/PEI volumes of UEFI BIOS.

Bypassing Intel Boot Guard Embedi

johngalt said:

Apple makes their own chips.

Qualcomm makes their own chips.

Other manufacturers also manufacture chips to the ARM v75 standards.

So, again, it is not just Intel, and it is not just Intel and AMD.



Microcode is in the BIOS / UEFI, which is the first place it is encountered.

Linux has hte ability to supersede that with updated microcode, which is loaded by the kernel at boot from that folder.

As far as I know, Window sdoes not have the ability to load microcode after the fact, superseding what is in the BIOS (but I may be wrong on this if Microsoft is, in fact, offering update(s) via WU that are microcode-specific, as we seem to be seeing here recently). And if it does, then they have been doing this all along without many of us knowing about it.

But when the OS makes use of newer microcode, it does not overwrite the BIOS / UEFI.

So, no, an OS loading microcode is not going to brick the machine any more than a bad driver load.

However, yes, a bad driver load, can, in fact, brick a machine - if the driver causes a hardware fault that is not resolved, it can very well fry the hardware - which is the type of bricking VBF was referring to - and which can easily happen with bad drivers, and has happened in the past.

Listen, The fault is with the Chip, no matter who made it. It is not a Windows issue , but granted they may have made it worse. All the fixes out there will not help Why is Intel and AMD and maybe Apple re Engineering their Chips?
You can have a different opinion , but I believe that when Intel took responsibility the Chip were at fault.

johngalt said:

However, yes, a bad driver load, can, in fact, brick a machine - if the driver causes a hardware fault that is not resolved, it can very well fry the hardware - which is the type of bricking VBF was referring to - and which can easily happen with bad drivers, and has happened in the past.

I honestly find that difficult to believe John, that a driver can permanently damage hardware!

Josey Wales said:

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

Wrong. It is not faulty. And that is the FUD you have to stop believing in. This is a very novel approach to trying to break something that should not be breakable in the first place - because this so-called faulty CPU you keep harping on is what makes things work so much faster.

I've repeatedly posted links, but you're not taking the time to read them and understand them, and I have better things to o today than to continue to argue with you. Suffice it to say, you're opinions are off base because it sounds like you're following the media too much and the actual researchers too little.

I'm sorry if I am coming across as rude, but I refuse to entertain any more arguments from you on this matter. The information is out there and easily accessible, if you would just do so.

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!

I was similarly blown away when I found out about this whole process myself.

But the microcode is only half the problem - remember, it is not just the CPUs, but how their capabilities are actually used by OSs, that grants the full spectrum of the vulnerabilities.

The Ars Technica article I posted a little bit ago, from 11 Jan, explains it very clearly but with a lot of detail (without all of the technical overhead that I found in the actual research papers that I read and posted here earlier) on how the technology of the CPUs works, and why they were made that way, and also, if patched, how much of a performance loss you'll expect under various scenarios.

That's why when the article first broke, one of the first things mentioned was that the Linux kernel had already been patched earlier for the fix. And that's why there is almost 0 panic in the Linux community. It's not about the microcode, because if it was only that all they would have said is "Download the microcode and place it in /etc/firmware and you'll be fine."

In fact, here is a complete breakdown on how the process works in *nix with firmware: Kernel/Firmware - Ubuntu Wiki

But the article(s) from when the vulnerability was first reported to the public specifically stated that the Linux kernel had been patched. And that Microsoft, Apple, and other OS developers were working on their own patches.

My reasoning then (and it stands now) was that this was not a hardware only problem - and that is what got me digging deeper into the vulnerabilities, to the point where I actually read the research papers themselves that were published on both vulnerabilities. I even summed them up here earlier - and interpreted a lot of the introductions of both papers here as well. And this reasoning is why I've also been replying to Josey's posts about it being Intel or Intel and AMDs fault.

Josey Wales said:

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

Lol - if you can show me where Windows has loaded the fixed microcode for your CPU and show me that the OS (kernel) has also been fully patched for the vulnerabilities, then yes I can see why you'd think something is wrong....

CountMike said:

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.

No- it was not tested for this sort of a security risk because no one knew this sort of a risk existed in the first place.

Again, let me reiterate: These vulnerabilities were just a gleam in the eyes of the researchers who found them in early 2016. And the speculation began that they might exist after attending a security conference that had a presentation on another vulnerability, one that was found in 2014. All of this is directly from the researcher's paper on the vulnerability, i quoted it earlier and pointed it out very determinedly.

It's kinda pointless for you to say that that the capabilities of the CPUs, which go back well over 10 years, could have been tested for a security vulnerability whose concept that didn't even exist 2 years ago.

I used the analogy of the automobile as a prime example - you can't hold the developers of the original internal combustion engine at fault for smog and carcinogens being emitted from ICEs because back then they didn't know that smog could be caused from ICEs, and that said combustion was releasing carcinogens into the air for people to breathe.

but, by trying to blame Intel and AMD (and every other CPU maker) for this vulnerability is 100% equivalent to doing the above.

johngalt said:

Wrong. It is not faulty. And that is the FUD you have to stop believing in. This is a very novel approach to trying to break something that should not be breakable in the first place - because this so-called faulty CPU you keep harping on is what makes things work so much faster.

I've repeatedly posted links, but you're not taking the time to read them and understand them, and I have better things to o today than to continue to argue with you. Suffice it to say, you're opinions are off base because it sounds like you're following the media too much and the actual researchers too little.

I'm sorry if I am coming across as rude, but I refuse to entertain any more arguments from you on this matter. The information is out there and easily accessible, if you would just do so.



I was similarly blown away when I found out about this whole process myself.

But the microcode is only half the problem - remember, it is not just the CPUs, but how their capabilities are actually used by OSs, that grants the full spectrum of the vulnerabilities.

The Ars Technica article I posted a little bit ago, from 11 Jan, explains it very clearly but with a lot of detail (without all of the technical overhead that I found in the actual research papers that I read and posted here earlier) on how the technology of the CPUs works, and why they were made that way, and also, if patched, how much of a performance loss you'll expect under various scenarios.

That's why when the article first broke, one of the first things mentioned was that the Linux kernel had already been patched earlier for the fix. And that's why there is almost 0 panic in the Linux community. It's not about the microcode, because if it was only that all they would have said is "Download the microcode and place it in /etc/firmware and you'll be fine."

In fact, here is a complete breakdown on how the process works in *nix with firmware: Kernel/Firmware - Ubuntu Wiki

But the article(s) from when the vulnerability was first reported to the public specifically stated that the Linux kernel had been patched. And that Microsoft, Apple, and other OS developers were working on their own patches.

My reasoning then (and it stands now) was that this was not a hardware only problem - and that is what got me digging deeper into the vulnerabilities, to the point where I actually read the research papers themselves that were published on both vulnerabilities. I even summed them up here earlier - and interpreted a lot of the introductions of both papers here as well. And this reasoning is why I've also been replying to Josey's posts about it being Intel or Intel and AMDs fault.



Lol - if you can show me where Windows has loaded the fixed microcode for your CPU and show me that the OS (kernel) has also been fully patched for the vulnerabilities, then yes I can see why you'd think something is wrong....



No- it was not tested for this sort of a security risk because no one knew this sort of a risk existed in the first place.

Again, let me reiterate: These vulnerabilities were just a gleam in the eyes of the researchers who found them in early 2016. And the speculation began that they might exist after attending a security conference that had a presentation on another vulnerability, one that was found in 2014. All of this is directly from the researcher's paper on the vulnerability, i quoted it earlier and pointed it out very determinedly.

It's kinda pointless for you to say that that the capabilities of the CPUs, which go back well over 10 years, could have been tested for a security vulnerability whose concept that didn't even exist 2 years ago.

I used the analogy of the automobile as a prime example - you can't hold the developers of the original internal combustion engine at fault for smog and carcinogens being emitted from ICEs because back then they didn't know that smog could be caused from ICEs, and that said combustion was releasing carcinogens into the air for people to breathe.

but, by trying to blame Intel and AMD (and every other CPU maker) for this vulnerability is 100% equivalent to doing the above.

FUD, Maybe you ought to tell Intel that. Well since I do not know everything involved on this Planet, I will listen to the head of Intel --You can listen to whoever you please.:)

In a statement, ARM Holdings said the flaw is not an architectural one and that the side-channel exploit “only works if a certain type of malicious code is already running on a device and could at worst result in small pieces of data being accessed from privileged memory.” ARM said that a majority of its processors were not affected and provided a list of those that were.
The big question is how much Intel is going to be liable for the security flaw, according to Bernstein analyst Stacy Rasgon in a note, calling to mind a $475 million hit Intel took in 1994 to address a bug in its Pentium processors, and the $700 million impact in 2011 to address the Cougar Point chipset issue.
“The current problem feels much bigger ($475M would have replaced perhaps 5-10M processors back in 1994, and the Cougar Point issue affected ~8M units, while the affected PC installed base today is in the hundreds of millions of units); potential liability remains the biggest open-ended question we have at the moment,” Rasgon said.
Intel said on its conference call that it did not expect to face a financial impact from the vulnerability.

Intel admits vulnerability, but plays down effects; stock slides, AMD gains - MarketWatch

Tony K said:

SFAIK, the only 4 components on a MoBo that have embedded code are the BIOS chip, CPU, the Northbridge, and the Southbridge. Anything that has embedded microcode can be rendered useless or "bricked" if not coded correctly. That is difficult for me to comprehend, for if it can be coded once, then why can't it be coded again even after being coded wrongly?

Sire - on a motherboard directly. But, technically, the CPU isn't a part of the motherboard, it is a separate component added to a motherboard. Just like HDs, optical drives, GPUs, etc.

And your graphics cards have their own BIOS and firmware.

So do your HDs and any optical drives you have installed.

As for coding, if you code it incorrectly, you could damage it when trying to use it. The fastest (although not really best, but give me time) analogy I can come up with is this:

Try using a 120V appliance on a 240V line. You've just used that appliance in a way that will (probably) kill it. And rather permanently.

If the coding is wrong, and it, say, draws the wrong amount of power (because all these silicon parts need electricity to do their silicon parts things that they do) - poof! fried. And once fried, you cannot recode (for lack of a better word - reload the appropriate firmware that it needed to make it accessible to be able to reload the ROM) them for anything - they are damaged goods.

That why, in the Android phone world, I was known for attempting (more than once!) to brick one particular phone that I had, he Motorola DROID BIONIC - to prove a point. There is what we started calling a soft brick, which is the scenario that you're referring to - the coding got it all wrong, and nothing worked - and Motorola said "Oops, sorry, send it to us and we'll fix it for you" to which I said "Pooof - watch this - and 'recoded' it to make ti work again (again, more than once!), and then there is hard brick - where you cannot even access the device to try to recode it because it is damaged goods - which is what I described above.

So, sometimes you can - if it just broke the booting process. But sometimes , you can't - because it broke something in the component itself.