Not sure what to make of this:
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
AMD Ryzen seems to be the winner if patches are selective and only affect Intel CPUs.
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.
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.
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.
Yeah, I heard that as well, and Microsoft would find it pretty hard to talk its way out of that when the world knows how aggressive it got when trying to push Win 10 on just about every Windows user who hadn't already upgraded.
Then there's Microsoft's non-support for older CPUs in Windows 10.... another way of forcing people to upgrade.
you are not done with this round of patching until you've got the microcode update via bios. (not yet released for most things)
there's a game company which blames meltdown/spectre for its problems. but they aren't home users like most of us.
https://www.epicgames.com/fortnite/forums/news/announcements/132642-epic-services-stability-update
fun thing.. the win patch borked some old amd machines
https://www.techrepublic.com/article/emergency-windows-meltdown-patch-locks-some-amd-pcs-into-endless-loop/
Next time use one of my special chips... My abacu-chip. Unhackable.
You can even play backgammon on it. Cool.
For those with AMD cpu's
http://www.firstpost.com/tech/news-analysis/microsoft-halts-security-updates-for-certain-amd-machines-after-meltdown-and-spectre-patches-cause-issues-4295321.html
And here
https://www.engadget.com/2018/01/09/microsoft-halts-meltdown-spectre-amd-patches/?sr_source=Twitter
And this for Anti virus https://doublepulsar.com/important-information-about-microsoft-meltdown-cpu-security-fixes-antivirus-vendors-and-you-a852ba0292ec
Thanks for the link Al. There's a handy little spreadsheet linked within there that summarizes antivirus status. It's about a third of the way down, a tiny link, and easy to miss so I'll link it here
https://docs.google.com/spreadsheets/d/184wcDt9I9TUNFFbsAVLpzAtckQxYiuirADzf3cL42FQ/htmlview?usp=sharing&sle=true
... until you visit a website which has been compromised.
Remember those adverts that had iffy content that were distributed via an agency to some fairly reputable websites:- https://forums.sinsofasolarempire.com/476193/page/1
Or download/install something that's been infected, eg https://forums.sinsofasolarempire.com/485055/page/1
Then, in theory, this could be exploited.
From what I've seen the circus has begun, people stating about a 1% hit to consumers oriented in gaming and a bigger hit to data centers, one of which was Fortnite blaming their weekend downtime on the bug.
Now if some of the knee jerk reactions are true, it's the x86 architecture that's at fault here and people are talking about moving more towards a variant of RISC/CISC or even pressuring Intel to drop x86 and open up the AMD64 instruction set on their processors to a form of open source flashing <this is both scary and awesome as hell at the same time>.
There are many great features available to you once you register, including:
Sign in or Create Account
