Massive security hole in CPU's incoming?Official Meltdown/Spectre Discussion Thread

[plopke]

I think that’s a little extreme.

For intel to get in trouble legally with coffee Lake someone must be harmed. There’s been no known exploit so no one harmed that way.

The home market probably won’t see more than a few percent performance difference once this is patched. So again no one harmed.

Remember they aren’t liable if your processor can’t reach the same Cinebench R15 score or FPS in LootBox II that AT got. They just have to sell you a chip that runs at the base frequency and single core turbo at TDP advertised. That’s why you have no recourse when your HP or Dell 8700k PC ends up 15% slower than your favorite review because you only have mediocre cooling, a power limited mobo and they’ve locked the turbo down to maintain TDP.

Where they could be in trouble is corporate purchases. If they sold chips that had to meet certain performance requirements and they knew or should have known the fix could preclude that then they are in trouble.

For the rest of us it probably won’t effect us much so not buying needed PCs or staying off the inter webs to protect ourselves from an exploit that hasn’t been seen in the wild doesn’t seem like the smartest thing.

Another saying we have in the human spaceflight biz is, if you want zero risk in your mission stay home.

Ow I agree , I was more thinking off do we actually know the patches will work? if I understand it correctly some of the spectre stuff are still being investigated if they can be patch properly , in that context is it ok to still sell/launch the product ? More like a moral question of it all.

 

[aigomorla]

Welp i guess i'll be waiting for my 1 dollar check in the mail from the class action lawsuit? *sarcasm*

No but seriously, without seeing how much "performance hit" we actually get from accurate testing, I honestly think people are jumping the gun.

Changing entire systems over to AMD and EYPC, sure, for the small guys with 1-2 systems thats not a problem, however for a data center which has 1000+ systems, saying changing them over to EYPC is not even funny.

And even then they still wont do it because EYPC does not have enough data on how reliable / Durable the system is under constant load and live operations.

When a system is validated at a data center, they dont just say, here lets dump a few systems and just go with it.
They run a few systems on a isolated node for months, and then take note of the failure rates.
If it lives up to validation, then they incorporate it in the next node upgrade which then goes live.

Unfortunately AMD is not quite there yet in validation, so if this bug is as big as the guys on mega phones + soap boxes are making it out to be, then we can see a much larger problem at hand.

One in which im pretty sure Intel will probably do massive amounts of product recalls on, and in worst case scenario, we all get new cpu's, or free upgrades.

 

[maddie]

Welp i guess i'll be waiting for my 1 dollar check in the mail from the class action lawsuit? *sarcasm*
......................................................................
One in which im pretty sure Intel will probably do massive amounts of product recalls on, and in worst case scenario, we all get new cpu's, or free upgrades.

Which new CPU and/or upgrade to what? Do you suggest them supplying Epyc to customers? A hardware solution to Meltdown is a low level redesign. Unless already started, years needed.

 

[IEC]

Which new CPU and/or upgrade to what? Do you suggest them supplying Epyc to customers? A hardware solution to Meltdown is a low level redesign. Unless already started, years needed.

Intel would literally have to replace every single CPU manufactured for over a decade to address Meltdown. Which is why a product recall is a preposterous scenario.

 

[aigomorla]

Why would they if the patch works?
Im not seeing what u guys are seeing...

If the patch works, and lets say the worst case scenario, its a 30% performance reduction, all intel needs to do is provide step ups, to clear that 30% performance reduction.

Why would they need to replace all the CPU's created?

The only time they would need to replace all the CPU's created would be if the patch proved uneffective and the exploit still existed.

And so far the reviews coming in doesn't show that big of a performance hit to the average user.

I honestly don't see why everyone is freaking out like the sky is falling, unless your the head IT or coordinator of a major company.

 

[Markfw]

Welp i guess i'll be waiting for my 1 dollar check in the mail from the class action lawsuit? *sarcasm*

No but seriously, without seeing how much "performance hit" we actually get from accurate testing, I honestly think people are jumping the gun.

Changing entire systems over to AMD and EYPC, sure, for the small guys with 1-2 systems thats not a problem, however for a data center which has 1000+ systems, saying changing them over to EYPC is not even funny.

And even then they still wont do it because EYPC does not have enough data on how reliable / Durable the system is under constant load and live operations.

When a system is validated at a data center, they dont just say, here lets dump a few systems and just go with it.
They run a few systems on a isolated node for months, and then take note of the failure rates.
If it lives up to validation, then they incorporate it in the next node upgrade which then goes live.

Unfortunately AMD is not quite there yet in validation, so if this bug is as big as the guys on mega phones + soap boxes are making it out to be, then we can see a much larger problem at hand.

One in which im pretty sure Intel will probably do massive amounts of product recalls on, and in worst case scenario, we all get new cpu's, or free upgrades.

I am sure I am not the only one that has run threadripper for MONTHS@100% load 24/7/365 since it came out, and thats without ECC, and at a higher speed. Its the exact chip as EPYC, but at a higher speed, so I am sure the testing is farther along than you may think. This is unlike previous Intel Xeons that are way different than their retail counterparts. The EPYC is simply the same amount of ccx's or MORE on the same platform (tr4/sp3 are really the same) with the same pin count. I am even running almost twice the ram speed that EPYC runs

 

[maddie]

Intel would literally have to replace every single CPU manufactured for over a decade to address Meltdown. Which is why a product recall is a preposterous scenario.

Agreed.

A very precarious situation for Intel. All the elements of a perfect storm in regards their stock price. A resurgent AMD was bad enough, but this loss of performance and lawsuits will have big effect on the stock. People might now even question their other ventures away from mainstream CPUs.

 

[Markfw]

Why would they if the patch works?
Im not seeing what u guys are seeing...

If the patch works, and lets say the worst case scenario, its a 30% performance reduction, all intel needs to do is provide step ups, to clear that 30% performance reduction.

Why would they need to replace all the CPU's created?

The only time they would need to replace all the CPU's created would be if the patch proved uneffective and the exploit still existed.

And so far the reviews coming in doesn't show that big of a performance hit to the average user.

I honestly don't see why everyone is freaking out like the sky is falling, unless your the head IT or coordinator of a major company.

I am not sure, but based on all I see the hit is serious for data center servers. If the data center is budgeted within 10% of its maximum, then they would need more servers to make up the difference, and overnight. The next few weeks will tell, so I won't be a doomsayer until it happens, but I am saying its seriously possible based on the data so far.

Oh, and by the way, I retired from a large company that had data centers with floor space literally measured in square miles, and we were at 90% a lot of the time, so I know of what I speak, and they were ALL Intel processors, except the few IBM P7,P8 and P9's. I guess there were a few mainframes in there too.

 

[goldstone77]

https://lists.opensuse.org/opensuse-security-announce/2018-01/msg00002.html

An update that fixes one vulnerability is now available.

Description:

This update for ucode-intel fixes the following issues:


The CPU microcode for Haswell-X, Skylake-X and Broadwell-X chipsets was
updated to report both branch prediction control via CPUID flag and
ability to control branch prediction via an MSR register.

This update is part of a mitigation for a branch predictor based
information disclosure attack, and needs additional code in the Linux
Kernel to be active (bsc#1068032 CVE-2017-5715)

https://www.suse.com/security/cve/CVE-2017-5715/
Note from the SUSE Security Team
SUSE is aware of the Spectre Attack named side channel attack and will be publishing updates.

Intel has a fix for Spectre

 

[amd6502]

I hazard a wild guess that Atom is wholly unaffected on Meltdown.

I don't see Spectre as a concern.

 

[wahdangun]

Why would they if the patch works?
Im not seeing what u guys are seeing...

If the patch works, and lets say the worst case scenario, its a 30% performance reduction, all intel needs to do is provide step ups, to clear that 30% performance reduction.

Why would they need to replace all the CPU's created?

The only time they would need to replace all the CPU's created would be if the patch proved uneffective and the exploit still existed.

And so far the reviews coming in doesn't show that big of a performance hit to the average user.

I honestly don't see why everyone is freaking out like the sky is falling, unless your the head IT or coordinator of a major company.

do you mean intel will provide firmware that automatically overclock ? to offset the loss ?? that was crazy and if the power budget exceeded then the electricity cost will jump considerably

 

[goldstone77]

Why would they if the patch works?
Im not seeing what u guys are seeing...

If the patch works, and lets say the worst case scenario, its a 30% performance reduction, all intel needs to do is provide step ups, to clear that 30% performance reduction.

Why would they need to replace all the CPU's created?

The only time they would need to replace all the CPU's created would be if the patch proved uneffective and the exploit still existed.

And so far the reviews coming in doesn't show that big of a performance hit to the average user.

I honestly don't see why everyone is freaking out like the sky is falling, unless your the head IT or coordinator of a major company.

They also have a patch for Spectre that affect branch chain speculation. AMD has a patch that reads that it is disabling branch chain prediction. We don't know how much that will affect performance on top of the patch Intel had to implement for Meltdown. This could potentially be serious, since this was something implemented right after the 486 processors to improve speed!
https://xem.github.io/minix86/manual/intel-x86-and-64-manual-vol3/o_fe12b1e2a880e0ce-273.html
8.3 SERIALIZING INSTRUCTIONS

The Intel 64 and IA-32 architectures define several serializing instructions. These instructions force the
processor to complete all modifications to flags, registers, and memory by previous instructions and to drain all
buffered writes to memory before the next instruction is fetched and executed. For example, when a MOV to
control register instruction is used to load a new value into control register CR0 to enable protected mode, the
processor must perform a serializing operation before it enters protected mode. This serializing operation ensures
that all operations that were started while the processor was in real-address mode are completed before the switch
to protected mode is made.
The concept of serializing instructions was introduced into the IA-32 architecture with the Pentium processor to
support parallel instruction execution. Serializing instructions have no meaning for the Intel486 and earlier proces-
sors that do not implement parallel instruction execution.
It is important to note that executing of serializing instructions on P6 and more recent processor families constrain
speculative execution because the results of speculatively executed instructions are discarded. The following
instructions are serializing instructions:
•Privileged serializing instructions — INVD, INVEPT, INVLPG, INVVPID, LGDT, LIDT, LLDT, LTR, MOV (to
control register, with the exception of MOV CR83), MOV (to debug register), WBINVD, and WRMSR4.
•Non-privileged serializing instructions — CPUID, IRET, and RSM.

 

[bononos]

So now Intel says Spectre (variant 1+2) is fixable after Google and CERT said it was not.
Hopefully there will be a follow up on this.

 

[goldstone77]

I hazard a wild guess that Atom is wholly unaffected on Meltdown.

I don't see Spectre as a concern.

Atom is on the list

• Intel® Core™ i3 processor (45nm and 32nm)
• Intel® Core™ i5 processor (45nm and 32nm)
• Intel® Core™ i7 processor (45nm and 32nm)
• Intel® Core™ M processor family (45nm and 32nm)
• 2nd generation Intel® Core™ processors
• 3rd generation Intel® Core™ processors
• 4th generation Intel® Core™ processors
• 5th generation Intel® Core™ processors
• 6th generation Intel® Core™ processors
• 7th generation Intel® Core™ processors
• 8th generation Intel® Core™ processors
• Intel® Core™ X-series Processor Family for Intel® X99 platforms
• Intel® Core™ X-series Processor Family for Intel® X299 platforms
• Intel® Xeon® processor 3400 series
• Intel® Xeon® processor 3600 series
• Intel® Xeon® processor 5500 series
• Intel® Xeon® processor 5600 series
• Intel® Xeon® processor 6500 series
• Intel® Xeon® processor 7500 series
• Intel® Xeon® Processor E3 Family
• Intel® Xeon® Processor E3 v2 Family
• Intel® Xeon® Processor E3 v3 Family
• Intel® Xeon® Processor E3 v4 Family
• Intel® Xeon® Processor E3 v5 Family
• Intel® Xeon® Processor E3 v6 Family
• Intel® Xeon® Processor E5 Family
• Intel® Xeon® Processor E5 v2 Family
• Intel® Xeon® Processor E5 v3 Family
• Intel® Xeon® Processor E5 v4 Family
• Intel® Xeon® Processor E7 Family
• Intel® Xeon® Processor E7 v2 Family
• Intel® Xeon® Processor E7 v3 Family
• Intel® Xeon® Processor E7 v4 Family
• Intel® Xeon® Processor Scalable Family
• Intel® Xeon Phi™ Processor 3200, 5200, 7200 Series
• Intel® Atom™ Processor C Series
• Intel® Atom™ Processor E Series
• Intel® Atom™ Processor A Series
• Intel® Atom™ Processor x3 Series
• Intel® Atom™ Processor Z Series
• Intel® Celeron® Processor J Series
• Intel® Celeron® Processor N Series
• Intel® Pentium® Processor J Series
• Intel® Pentium® Processor N Series

 

[wahdangun]

Atom is on the list

if the atom was in-order then it will not affected

 

[amd6502]

Atom is on the list

Is the list for Meltdown exclusively (not Meltdown or Spectre)?

Edit: according to wiki anything with speculative execution (even in-order atom does speculative execution) _might_ be vulnerable to Meltdown.

https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)

Suppose the attacker is in control of an unprivileged user-space process, which is normally prevented from reading the value at a protected memory address Ap by the CPU's memory protection mechanism. To circumvent such memory protection and read bit 0 at Ap, the attacker executes the following sequence of instructions:

1. Clears the cache at two unprotected (i.e., normally readable by the attacker) addresses A0u and A1u;
2. Reads the value at protected address Ap to a register R;
3. Computes an address Axu that is equal to either A0u or A1u depending on whether bit 0 of register R is 0 or 1 (this should be done with arithmetic instructions rather than branches to avoid the branch predictor complicating matters);
4. Reads the memory at address Axu.

The CPU's memory protection mechanism will raise a memory protection fault when attempting to read from the protected address Ap at step 2. However, since waiting for the memory protection hardware to finish its checks can cause significant slowdowns, affected CPUs will actually perform the read at step 2 and continue with steps 3 and 4 speculatively, and only annul their effects when the memory protection fault gets detected some clock cycles later.

Wiki currently states that pre-2013 Atom should be OK.

 

[AdamK47]

Part of me wishes Google never attempted performing this exploit. Fixes of some kind have to be performed once any exploit is disclosed. This kind of fix I could have done without.

 

[goldstone77]

Personally, I'd rather have a secure system. If the flaw is significant to cause harm to the consumer than they should be compensated. I'll take a new free secure CPU please. Thank you.

 

[sandorski]

This last year has been one of the most drama filled ever. A dark cloud looms over Intel until they can engineer a CPU that doesn't contain this flaw. Until then brute force will be needed to regain lost performance, but that's easier said than done.

 

[SpaceBeer]

https://lists.opensuse.org/opensuse-security-announce/2018-01/msg00004.html
An update that fixes one vulnerability is now available.

Description:

This update for kernel-firmware fixes the following issues:

- Add microcode_amd_fam17h.bin (bsc#1068032 CVE-2017-5715)

This new firmware disables branch prediction on AMD family 17h processor
to mitigate a attack on the branch predictor that could lead to
information disclosure from e.g. kernel memory (bsc#1068032 CVE-2017-5715).

https://www.suse.com/security/cve/CVE-2017-5715/
Note from the SUSE Security Team
SUSE is aware of the Spectre Attack named side channel attack and will be publishing updates.

This is a Fix for AMD for Spectre.

Wait! Have they completely disabled branch prediction? How this works?

 

[goldstone77]

Wait! Have they completely disabled branch prediction? How this works?

That's what it says. Intel has also done something with branch prediction as well. We don't know what kind of performance implication this will have, but theoretically it could be substantial since this was originally implemented to increase performance right after the 486 processor.

 

[wahdangun]

That's what it says. Intel has also done something with branch prediction as well. We don't know what kind of performance implication this will have, but theoretically it could be substantial since this was originally implemented to increase performance right after the 486 processor.

not disabling all branch prediction, just specific that can lead to vulnerability.

that's why amd said the performance lost is negligible

 

[DigDog]

i'm gonna side with cpu manufacturers saying "it works as intended".

in other news, Lamborghini willingly released their latest car knowing full well at launch that the tires it comes equipped with are subject to a defect where if an attacker lays spikes in front of the oncoming vehicle, the tires can be punctured.
Also locks that can be opened, the chassis is susceptible to fires when covered in gasoline, and the windshield will shatter if simply struck with an 8-pound hammer.

a vulnerability is not a defect. the FDIV floating point bug was a defect. in common market products, you might have a slim chance if it was proven that a manufacturing company skipped common tests for common vulnerability, such as a company that produces roof tiles and does not test them for rain.

when it comes down to research-based technology, you just don't have a chance. unless you prove that they *knew* the vulnerability existed and went into production anyway ...

 

[coercitiv]

i'm gonna side with cpu manufacturers saying "it works as intended".

Which CPU manufacturers other than Intel are claiming it works as intended?

in other news, Lamborghini willingly released their latest car knowing full well at launch that the tires it comes equipped with are subject to a defect where if an attacker lays spikes in front of the oncoming vehicle, the tires can be punctured.
Also locks that can be opened, the chassis is susceptible to fires when covered in gasoline, and the windscreen will shatter if simply struck with an 8-pound hammer.

Car analogies, always the best way to misrepresent what is happening in the IT industry.

 

[DigDog]

a vulnerability is not a defect.

Welcome to AnandTech Forums, where you need to type in single sentences to avoid confusing people.