someone did speculate since some drm/anti cheat have a lot to do with virtual machines and what not, they (and thus the games with them) get bogged down... who knows.

In this case, Intel itself [not AMD] released the news that its processors up to 10 years old had security flaws, and that it would release patches that may impact on performance by up to 50%.  Microsoft also released patches to fix the issue from an OS point of view.  However, AMD is not responsible for breaking the news.  Apparently, it was a couple of engineers at Google, who first informed Intel and Microsoft of the issue.

I know that if I were an Intel CPU owner from within that time frame, [which I am] I'd be mightily pissed at the huge performance hit, but I'd also be suspicious.... very suspicious.  I mean, why has this only come out now... a 10 year old flaw?  And why is it necessary for these CPUs to take a such a big performance hit when patched?  Does anybody else smell fish?

On another note, I'm so glad I went with an AMD Ryzen for my new build.  I had considered an Intel based rebuild, but as luck would have it, I decided against it due to cost considerations.... and my Ryzen 1700 does overclock very well, so performance won't be an issue. 

As for what I'm going to do about my i7 4970K, well I suppose it'll be a bit of wait and see.  Just because the patch has been issued, doesn't mean I have to apply it, and if I'm somehow forced to, well I'll check my options then.

To be really accurate, this is not Intel's fault so much as it is a very specific set of specialized verification folks at Intel.    I would be very surprised if they got fired, either, because the skill is so specialized.   You can't just replace them.  Their annual performance reviews might not turn out so good, though. 

It's like a 1% hit, people.  Check the people actually doing real benchmarks.

Frankly, I don't know what to believe anymore.  It just seems that too many people have differing opinions about what's what.  A 1% hit is well below what most are saying, so I'm just going to wait until the situation is better clarified for the average/general user.

If speculative execution only sped up CPU's by 1%, Intel wouldn't have been doing it the last 25 years.  And that's what the software workaround for Meltdown is:  squash speculative execution, so that it doesn't expose kernel memory in the invalidated cache line.   

1% my foot.

Yep, either way nothing is going into the trash here.  All I can do at this point is see how it washes out and live with it, so that's what I'll do.  I'm betting it's not going to be a big deal.

I'm reminded of a New Egg processor review I saw once.  A guy had bought a say 2.8ghz processor and then about 6 months later replaced it with a say 3.0ghz processor of the same line, then realized/moaned that he really wasn't really seeing any difference.  Sometimes experience costs a little.  

Ok, there appears to be some misunderstanding in what is going on, and I'm actually going to take Intel's defense on this one:

First, the vulnerability is indeed related to speculative execution, but that's NOT what is being turned off in the patches (thank God, or we would be back into the stone age lol!).

Second - and this is where I can see Intel's side - this vulnerability ONLY happens because of PERFORMANCE optimizations made by *OS vendors*.

Let me see if I can explain this in a simple way: Intel provides 'rings' of security, and external rings cannot access code running in internal rings. So, the Kernel would be running in ring 0, and user code in ring 3. This is great, works as intended and, so far, has no known vulnerabilities.

So what happened? Switching from one ring to another takes some time, from a CPU's perspective. To optimize performance by preventing these costly switch operations, OS vendors 'hide' Kernel code in the same ring as user code, i.e.; each process has its own hidden copy of the Kernel. The Kernel code is still protected by process isolation if user code tries to access this Kernel section (the CPU will throw an exception), but the level of protection is not the same.

Because of this, the speculative execution part of the CPU is still able to access this Kernel area even when currently running user code. It is only when an instruction in user land actually *tries* to access this forbidden part of memory that the operation fails. However, part of this Kernel code might already be in the speculative *cache*.

Using some complicated methods which I don't fully understand and are related to instructions already in the speculative cache being executed MUCH faster than if they weren't, it's possible to, in time, make a map of the contents of the Kernel. This is a really convoluted process, guys!

However, this is only possible because of the performance optimization OS vendors *chose* to implement in their OSs. Intel's fault here is allowing the speculative cache,  when running user code, to access memory that would throw an exception otherwise.

Intel provided the mechanism for this not to happen, but OS vendors chose not to use it for performance reasons. In the end something nobody had foreseen - until Google engineers found it last year - came to bit them both in the proverbial bottom.

Some allege that Intel already knew this could happen when they implemented the system, but chose to allow the speculative cache to access forbidden regions of memory for performance reasons anyway. Wether this is true or not I do not know.

The x% performance decrease happens because most of the Kernel code is no longer being mapped into user space after the fix, thus forcing the CPU to switch rings (slower) whenever it needs to access Kernel code. Since the Kernel deals with performing all file IO operations, that is where you will normally see the biggest performance decreases.

Switching the CPU to hypervisor mode is not necessarily slower.   AMD maintains separate copies of the register file, so they can switch back-and-forth between user and hypervisor instructions all day and not even care.    If the privileged-mode switch was all it was, then yeah--no big deal.   1% performance hit it is.   Except...

File I/O operations are very expensive, but so are cache misses.   That's why you speculatively execute instruction streams ahead of time:  to fetch the cache while other pipelines go on about their business.   Part of the means for fetching the kernel memory (that convoluted process you mentioned) is making the code speculatively execute instructions accessing the kernel memory, and just let it trap when it finally figures out it is accessing a forbidden space.   Okay, no big deal--simply code the interrupt handler to save off the invalidated cache line.   If the hardware does not prevent you from doing that, then the software has to--either by not speculatively executing that, or flushing the cache line itself.   I'm sorry, but that's not a 1% performance hit.

The one part where I would come in Intel's defense is:   yes, it IS in the design.   All the verification folks do is verify that the actual hardware behaves according to spec, as defined by the CPU architects.  The security folks are busy verifying the crypto unit--not the MMU or the TLB.    That didn't cross anybody's mind.   Simple human mistake.

As always this have gotten out of proportion. -Instant Panic every time.           

-It will all be good, don't worry about it.       

neone6

reply 30

As always this have gotten out of proportion. -Instant Panic every time.           

-It will all be good, don't worry about it.       

Tell that to the guys who own servers in data centers: some of those things execute millions of file I/Os per second or more. To them, the 30% decrease in performance and 30% increase in CPU load is very much real.

Some data centers, such as Amazon, charge you for CPU usage/hour on their VMs - well, what you were usually paying for that just went up by 30% overnight. Permanently. Other servers were already operating near maximum capacity - this sudden 30% increase in CPU usage will push them over the edge, requiring new servers/etc...

For the casual user it isn't THAT bad... for others, it can be pretty close to a catastrophe.

Well I ,<was> going to build a new computer next month with an 8700K but....????

As much as we all try to explain it, and I don't know we can, I think the proof in the pudding has yet to be revealed.  In other words, let's wait until the Intel and Microsoft patches have been applied and then see what a performance hit there is.  My Intel machine is in pieces at the moment, and due to life's various distractions I don't know when I'll get to reassemble it, so I won't know what the impact for me is until I get around to rebuilding it.

Thing is, I still can't help being suspicious.  Various reports suggest that Intel knew of this flaw some years ago, yet it has only become important enough to fix now.  Then there's Microsoft's push to get everybody on Windows 10 and not supporting older processors, etc. 

Okay, maybe there is a genuine flaw, but are Intel and Microsoft being totally honest about it with users?  Like why didn't it come out years ago?  Did Intel remain silent deliberately so its sales didn't dip as people crossed over to AMD?   Like why now?  I mean, surely it would benefit both Intel and Microsoft if a serious performance hit drove many users to upgrade to the latest edition processors.

Like I said, I can't help but be suspicious.  Yes, maybe I do have trust issues, but the tech industry is fickle and honesty is not always its best policy.  Like the case with Apple slowing down older iPhones, to so-say prolong the life of the device.  From what I've been reading, hardly anyone believes it, that it's a drive to push older phone users to upgrade; hence the class actions against Apple mounting all over the world.  

Hmm, maybe I'm not the only one with trust issues.  

why didn't it come out years ago... because the researchers only found the hole last year. where did you read intel knowing about this for years? people are only talking about its ceo potentially getting done for insider trading for selling stocks last year and not the other years so far.

why did everyone keep silent? because you don't really talk about holes you can't fix unless you want attacks out there months before you've got your fixes out. seriously, it's not like linux has its patches out months ago detailing everything about the flaw.

--

still have to wait for bios update too... (for the microcode)... supposedly that'll cause slow down too.

---

nvidia drivers are now out.

We have some hard facts about patches and performance hits. It looks like there will be little impact on gaming performance. However writes to SSD's can take a huge hit....

https://www.techspot.com/article/1556-meltdown-and-spectre-cpu-performance-windows/page4.html

Question about the 'Security Flaws' found in Intel Chips. 

So if I am behind a firewall and a router and use a VPN and its on a 'home computer' and I pretty much only do gaming on it. How can I get hacked? I understand that I 'can' be hacked but dont' I first have to be 'found'? If use zero patches (we dont need any stinking patches).. won't it be 'life as usual?  

I ask this as I was finally going to get an I8700K next month and build a new computer. My current gaming one is an I5 3570K which is 4 cores, 4 threads. It works however I am looking at migrating up to a larger monitor with 1440p. 

To recap>>> How likely is it to get 'hacked' for a regular home user and what would YOU assuming Jaffo was going to hack someone, need to go out and find and hack said random person?

The initial number released by people in the tech industry was exaggerated from everything I've seen. Of course this makes better articles and generally gets more clicks. The world we live in...

I'm partial to AMD myself, but even with that I won't sing doom and gloom for Intel. Exploits are part of the advanced tech we use every day. The important part is how companies handle these exploits and how quickly they are corrected with minimal impact.