• Guest, The rules for the P & N subforum have been updated to prohibit "ad hominem" or personal attacks against other posters. See the full details in the post "Politics and News Rules & Guidelines."

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

Page 14 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

beginner99

Diamond Member
Jun 2, 2009
4,856
1,251
136
. Sounds like a lot of ARM chips also are affected. My phone may be affected.... AMD makes ARM chips too as well as a lot of other companies.
Google said they already patched android and in fact my android phone got a small update about 2 weeks ago. Since OSX supposedly was patched in December I assume iOS got patches as well already?

One thing to keep in mind, Meltdown and Spectre aren't bugs. They are attacks that exploit features of modern CPUs.
The Intel social media PR team hard at work. Hint: You aren't doing any better than the ridiculous official Intel PR statement. Tell your bosses to stop making their company look like fools.

I really don't think something is a bug if it's working as designed. A bug to me is an unintended flaw that affects performance, not a security "hole" that can be exploited in a product that works as designed.

The way I look at it is this: Bug = design was fine, execution had issues. In this case; execution was fine, design was 'flawed'.
Allowing reading cache/memory current process does not have the privilege to do so is a bug.

Since this specific part of the CPU was designed in early 2000s or even the 90ties it's fair enough to say that back then security wasn't such a huge concern and even if Intel knew of the flaw, no big deal they still did it. However it's not uncommon such internal knowledge getting lost over time. So it's possible Intel actually did not know this until recently or they simply forgot that knowledge. I can't believe they knew it and did not fix it in hardware because of the consequences this would have.
 

bryanW1995

Lifer
May 22, 2007
11,143
32
91
These are implementations of side-channel attacks. They expose flaws in processor designs, they are not bugs in themselves. Even Android on ARM is getting patched to get the Kernel address space out of user space.

Side channel attacks are nothing new, just see the references in the Meltdown paper. First you need to understand what the issue is. AMD is also affected by Specter, and the authors say AMD may be affected by Meltdown - they don't know.
You seem awfully defensive about all of this, and you're reading "near-zero" as "may be affected"...interesting.
 

coercitiv

Diamond Member
Jan 24, 2014
4,546
6,258
136
I agree with Phyanz. It is not a "bug" in the traditional sense of an incorrect output of data. It is a design "choice" or "flaw" if you wish that allows an exploit. By the definition of "bug" that a lot of posters are using, every security hole that has to be, or has been, patched in hardware or an OS is a "bug". That said, to the end user, it doesnt really matter. It has to be patched in either case, and the ultimate performance loss is the same.
"bug" , "flaw" or "choice" or whatever, what I'd like to know is why Intel scrambled to sell Coffee Lake after they found out about the flaw. If it turns out CFL is affected it doesn't matter what we call it anymore.

Judging by the way Intel PR handled the issue I'd day the design decision is present in every modern Intel CPU. So it's not a bug, it's systematic failure.
 

bryanW1995

Lifer
May 22, 2007
11,143
32
91
I'm going to put my tin foil hat on, intel is too big a company with too competent engineers to let something like this slip for all this time.
It's almost like it is a purposely designed "feature" or intended circumstance.
Why? Well, performance enhancement? The decision to allow/enable this hole/feature could have come way back when AMD was extremely competitive..circa 2002-2005...once added, it's too tempting just leave it there, especially when intel processor improvements have been miniscule from iteration to iteration since sandy bridge.

More crazy explanation...CIA forced exploit? :/
I wouldn't be shocked to learn that the US govt was involved in this, though I think the preponderance of the evidence suggests that intel made a bad decision a long time ago and is now going to have to pay for it. Knowing how corporations work, they're probably pretty happy with their success over the past decade+ and will be able to deal with the fallout just fine. Hopefully they'll be more careful about these things in the future at least.
 
  • Like
Reactions: french toast

french toast

Senior member
Feb 22, 2017
988
824
136
I wouldn't be shocked to learn that the US govt was involved in this, though I think the preponderance of the evidence suggests that intel made a bad decision a long time ago and is now going to have to pay for it. Knowing how corporations work, they're probably pretty happy with their success over the past decade+ and will be able to deal with the fallout just fine. Hopefully they'll be more careful about these things in the future at least.
I'm convinced certain people/engineers at least knew about it...how could they not?
Most likely reason is that back in the day it offered some kind of performance enhancement? Or incurred a performance hit if fixed...perhaps they just left it there and forgot about it.

More interesting to me is coffeelake..is it affected? If so they have some explaining to do.
2018 is going to be very interesting indeed. :)
 
  • Like
Reactions: bryanW1995

goldstone77

Senior member
Dec 12, 2017
217
93
61
Meltdown” and “Spectre”: Every modern processor has unfixable security flaws
Immediate concern is for Intel chips, but everyone is at risk.
PETER BRIGHT - 1/3/2018, 7:30 PM

Spectre
Owners of AMD and ARM systems shouldn't rest easy, though, and that's thanks to Spectre. Spectre is a more general attack, based on a wider range of speculative execution features. The paper describes using speculation around, for example, array bounds checks and branches instructions to leak information, with proof-of-concept attacks being successful on AMD, ARM, and Intel systems. Spectre attacks can be used both to leak information from the kernel to user programs, but also from virtualization hypervisors to guest systems.

Moreover, Spectre doesn't offer any straightforward solution. Speculation is essential to high performance processors, and while there may be limited ways to block certain certain kinds of speculative execution, general techniques that will defend against any information leakage due to speculative execution aren't known.

Sensitive pieces of code could be amended to include "serializing instructions"—instructions that force the processor to wait for all outstanding memory reads and writes to finish (and hence prevent any speculation based on those reads and writes)—that prevent most kinds of speculation from occurring. ARM has introduced just such an instruction in response to Spectre, and x86 processors from Intel and AMD already have several. But these instructions would have to be very carefully placed, with no easy way of identifying the correct placement.

In the immediate term, it looks like most systems will shortly have patches for Meltdown. At least for Linux and Windows, these patches allow end-users to opt out if they would prefer. The most vulnerable users are probably cloud service providers; Meltdown and Spectre can both in principle be used to further attacks against hypervisors, making it easier for malicious user to break out of their virtual machines.

For typical desktop users, the risk is arguably less significant. While both Meltdown and Spectre can have value in expanding the scope of an existing flaw, neither one is sufficient on its own to, for example, break out of a Web browser.

Longer term, we'd expect a future Intel architecture to offer some kind of a fix, either by avoiding speculation around this kind of problematic memory access, or making the memory access permission checks faster so that this time interval between reading kernel memory, and checking that the process has permission to read kernel memory, is eliminated.
https://xem.github.io/minix86/manual/intel-x86-and-64-manual-vol3/o_fe12b1e2a880e0ce-273.html
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.
The instructions implementing parallel instruction execution go back to Pentium processors.
 
Last edited:

OrangeKhrush

Senior member
Feb 11, 2017
220
343
96
https://www.amd.com/en/corporate/speculative-execution


Looks like AMD feels everything is good on their end! Don't forget to update your OS!
From all the AMD representatives the statements are very coherent, transparent and confident, compared to the intel diversion attempt it seems like this is a case of Intel out on their own with this, sure AMD may have its type 1 intrusions but those are the commonly updated ones, moving along and waiting for the big tamale.
 
  • Like
Reactions: lightmanek

pandemonium

Golden Member
Mar 17, 2011
1,777
76
91
It only affected NVME with high I/O.
Now I am curious how much this could actually affect a consumer machine. I suppose I could run some crystaldisk tests before/after patch to see the I/O differences. I don't have a lot of benchmarks to utilize, but if anyone wants to recommend some to run with an NVME drive, I'll gladly do my best to accommodate! (My primary drive is an Intel 750 400GB connected via hyperkit on ASUS X99.)
 

jpiniero

Lifer
Oct 1, 2010
10,079
2,338
136
Benchmarking The Intel CPU Bug Fix, What Can Desktop Users Expect?
Hardware Unboxed
Published on Jan 4, 2018


The benchmarks for the 8700K show that desktop users will not be affected by the recent windows patch. It only affected NVME with high I/O. This makes me wonder about streaming capabilities?
There is a hit although it's only 1-2% in the games they tested. ComputerBase tested a 7700K and AssCreed was 3% slower.

It's more of a problem for servers where the hit is more severe.
 

coercitiv

Diamond Member
Jan 24, 2014
4,546
6,258
136
We'll have to wait for the whole story to unfold, but so far it looks to me like Intel is making a mess, and it's not the flaw itself that's the problem, it's how they respond to it. It's almost as if their entire strategy is based on pointing at ARM and AMD and saying "they done bad too".

Pointing fingers is not what I expected from the No.1 CPU maker in the world. After they made technological leadership the selling point of their products, coming around to hide behind the little guys when shit hits the fan is pathetic to say the least. It turns out the giant Intel is just a spoiled brat in need of some harsh lessons to get back on track.
 

TheGiant

Senior member
Jun 12, 2017
748
353
106
We'll have to wait for the whole story to unfold, but so far it looks to me like Intel is making a mess, and it's not the flaw itself that's the problem, it's how they respond to it. It's almost as if their entire strategy is based on pointing at ARM and AMD and saying "they done bad too".

Pointing fingers is not what I expected from the No.1 CPU maker in the world. After they made technological leadership the selling point of their products, coming around to hide behind the little guys when shit hits the fan is pathetic to say the least. It turns out the giant Intel is just a spoiled brat in need of some harsh lessons to get back on track.
Well,
that is standard modern people and especially corporate behavior. The mass stupidity crowns it all. When we are f...d we need to point at other they are too. Strategy "if I look bad other must too".
The average JoePushTehButton will never look at the root cause nor will ever understand it. The same reason while current polititians win.....

The world is rules by how things look like not how they really are....sad but true.

However, I think positively and my guess Intel will find a way how not to lose perf while mitigating the problem. If they must, they will do it! :)
 

Atari2600

Golden Member
Nov 22, 2016
1,239
1,407
136
As far as I can tell an actual bug means a system outputs an undesired result because of an error. it just so happens this doesn't appear to be one.

Or as Phynaz wrote: "Technically, designs have flaws, implementations have bugs."
Who cares?

Flawed design or bugged design. End result is the same - an insecure system.


A flawed design would reflect worse for Intel. It'd mean simultaneous and connected failures in (i) design requirements, (ii) the checking loop for design requirements, (iii) design verification, (iv) the checking loop for design verification, (v) hardware verification test requirements and (vi) checking loop of hardware verification test requirements.

That is a pretty long connected string of process failures.
 

Eddward

Member
Apr 10, 2012
56
19
81
There is a hit although it's only 1-2% in the games they tested. ComputerBase tested a 7700K and AssCreed was 3% slower.

It's more of a problem for servers where the hit is more severe.
What hit in the games ?
AFAICS:
Ashes of the Singularity - positive impact
AC: Origins - positive impact
Battlefield 1 - positive impact
but still within margin of error
 

moinmoin

Platinum Member
Jun 1, 2017
2,750
3,619
136
Tell me what design decision/intent Intel failed to properly implement.
The lack of privilege separation that should be there but isn't on Intel chips. Even the paper starts out describing how it's supposed to work, then goes on as if it actually doesn't matter at all. Considering Intel did add additional features (like PCID) over time that coincidentally make it easier to implement privilege separation band-aid later (and that's what the KAISER research leading to the discovery of the Meltdown and Spectre attacks is all about) Intel likely was fully aware of their own implementation shortcomings there. It works on AMD chips in a way anybody sane would expect.
 
May 11, 2008
18,309
831
126
Well, its the case, but not where the case was made that Intel made a choice, a bad choice to specifically allow it to happen when it should not happen, to speed up execution, THATS the post I really want to quote.
Well, sorry. I have not encoutered that for as far as i can remember. I cannot provide a link.
Maybe somebody else already did or when it is true, i am sure it will become a huge news item on the media.
 

Paratus

Lifer
Jun 4, 2004
14,992
8,722
146
Who cares?

Flawed design or bugged design. End result is the same - an insecure system.


A flawed design would reflect worse for Intel. It'd mean simultaneous and connected failures in (i) design requirements, (ii) the checking loop for design requirements, (iii) design verification, (iv) the checking loop for design verification, (v) hardware verification test requirements and (vi) checking loop of hardware verification test requirements.

That is a pretty long connected string of process failures.
In the human spaceflight business we would call that “links in the error chain”. Many links can end up being attributed to budget and schedule pressure.

People also tend to stop questioning design and process risks if it appears to have worked out in the past.

I don’t see why the chip business isn’t susceptible to the same problems.
 
  • Like
Reactions: ZGR

kyubi

Senior member
Feb 11, 2008
544
33
91
Confirmed all generation s are vulnerable? This slow down fix will push my migration to ryzen alot sooner
 

ASK THE COMMUNITY