Understanding The Meltdown And Spectre Exploits: Intel, AMD, ARM, And Nvidia

  • Thread starter Thread starter Guest
  • Start date Start date
Toggle sidebar Toggle sidebar
Status
Not open for further replies.
Wow that hard earn money we spent on intel cpus will come at a bigger cost now. I am sure they have know this issues for well over 20 years but Greed is the ROOT of aLL EVIL.
 
A lot of people are claiming that gaming won't be affected, but that confuses me. You're making a lot calls from user space to the drivers, which should be in kernel space. We're not accessing the GPU from user mode directly, are we? Isn't this going through drivers and / or the HAL?
 


The problem lies (becomes exploitable) when you move in and out of memory spaces. So, if you don't have a malware running already and you are gaming, if the/a malware tries to access something without you making it run or force a switch of programs, nothing will happen since no memory will be moving (no randomized movement of memory addresses happen). So, the stuff put in the user memory address space will remain there without actually calling anything "new" to be put there from the kernel space (drivers should really be loaded at the start and not during gameplay). Now, for Streaming though. You are forcing several context switches there, so it will be interesting to see if it happens. The DX driver needs to send the data to another program residing in a different user space, so that implies moving memory.

That is how I understand this problem, so feel free to correct me.

Cheers!
 
Is there any indication that the Microsoft patch doesn't inflict an unneeded slowdown on AMD hardware? I know that Linus stopped that on the Linux side, but who's to say that Microsoft didn't just apply the fix to all architectures?



Yes we are. That's what Microsoft changed in the driver model between XP and Vista. There is still a kernel component to the drivers, but much of the work is done in user mode, which both adds to OS stability (early NVIDIA Vista drivers notwithstanding) and benefits performance.
 

Most of the DirectX and other APIs' runtime is user-space and that's what typical software interacts with the most. Not every DirectX call results in a trip through a system call.

In the case of server-style workloads that frequently involve the file system, IO and inter-process synchronization though, most of those have a very thin APIs that do little more than populate structures and do basic sanity checks before doing system calls.
 
I do not want to play the "devil's advocate" but, if he knew about the fault since last June he wouldn't sell on purpose for the case he would be accused for "abandoning ship" before it sinks. After all he is CEO from since May 2013. The flaws are rumored to be on most intel's chips many years before.
 
Intel's statement on the matter specifically says that the exploits are not caused by a "bug" or a "flaw" that is unique to Intel products. Intel also noted that the exploits can "gather sensitive data from computing devices that are operating as designed."
Click to expand...
Exactly, it's not a bug. The backdoor has been functioning perfectly for decades. : 3
 


Intel knew about this issue but got confirmation that external resources were looking in the matter. If the CEO of Intel sold his shares due to this story, it means it has the potential to have a huge impact for Intel as a company.



Nonetheless, this uncertainty means nothing good for the investors. I would not buy Intel stock right now, it might not be a dip at all, it could be a fall. Investing in AMD, as of today, make way more sense since they are almost not affected by this. If you look at the road map to, AMD will be on 7nm next year.

 

Agreed. There was so much bad info out there, but you cut through the mess and laid out the facts in a concise article. Thanks!
 
I'm surprised nobody has commented on this:

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).
Click to expand...

Is there some reason we don't believe that disabling branch prediction is going to plant a tremendous foot on the back of performance? I mean, the whole POINT of branch prediction IS increased performance, right? I think there are probably a LOT of little tidbits like this that are likely important, but are not getting the kind of publicity that some of these other stunts and statements are getting due to simply being overlooked.

I mean, great, you removed the problem. Maybe. But you completely removed branch prediction from ALL ZEN processors, so how's that not going to seriously affect performance? Or am I reading this wrong?
 

Since branch prediction is required to boost performance in loops, chained list, parsing, manipulating tree structures and countless everyday algorithms, I'd expect outright disabling branch prediction to have a severe impact on performance if it does exactly what it sounds like it does.

Without branch prediction, those 96+ slots in the reorder queue aren't going to see much use and could be cut down to 32 or so or the thread count per core increased to four to help fill it.

I'll add this to my bucket of reasons not to upgrade my PC this year.
 
Yeah, this is getting worse and worse all the time, and all people are really HEARING is the damage control schpeel coming out in in full force while they quietly slip the reality right past everybody. Later they can say, no we said that but you weren't paying attention. Almost makes it worth just dealing with having the vulnerability and forget about patching anything. Keep sensitive data on unconnected devices or something.
 

m

Well, the OS patch at least disable the communication to the vulnerability part with the cost of performance. My PC cost $2k, and I ain't upgrading my whole dam processor and motherboard until Intel compensate it.

The OS patch only solve 50% - 70% of this vulnerability issue, and the other is in the architecture itself which require to upgrade it.
 
Upgrade it to what? There's nothing you can upgrade it TO that doesn't have the same exact problem. If they have to start from scratch to totally redesign these architectures, we're probably looking at another 1-2 years before anybody has a suitable release that resolves the vulnerability. And if they can't figure out some way to still use branch prediction without there being other exploits, new CPUs might be at Ivy bridge performance levels again.
 


This is architecture flaws, so software update only the good solution to fix it with a cost of performance sacrifice; however, if you want to completely solve this vulnerability, than an upgrade to the newer CPU that doesn't affect by these two vulnerability is the only option that some cyber security experts recommended. The software patch probably will disable the communication to the vulnerability part, but we still live with this vulnerability exist on our past and presence processors.

" Some experts say that to completely get rid of the risks created by the flaws, the affected processors need to be replaced entirely. But that's not realistically going to happen anytime soon.

There aren't any processors available at the moment that can replace the vulnerable ones and still provide the same kind of functionality.

Experts say that it will take years to bring to market new chips that can perform the same tasks both safely and effectively. " http://money.cnn.com/2018/01/04/technology/business/apple-macs-ios-spectre-meltdown/index.html

I also believe some antivirus can detect this type of malicious attack and activity as well.
 

Since Spectre is fundamentally a timing exploit, attempting to prevent it at the hardware level means having to find a way to prevent processes running on the same CPU from snooping task-dependent performance variations.

A possibly simple and effective fix for timing exploits might be to configure a cache line eviction threshold to preempt threads triggering anomalously frequent evictions. Can't do timing analysis if you get preempted faster than you can thrash the caches to monitor their performance. Another candidate might be to set a threshold on how often a process can read the high performance timers - can't do an effective timing attack if you don't have a reference for how much time has gone by, when you got preempted and when your process resumed.
 


Nvidia doesn't only make GPUs, they do make some mobile CPUs based on the ARM architecture, those are what are affected by the vulnerability. These CPUs go into tablets, Nvidia devices like the Shield, Shield K1 Tablet and Shield TV, and also the Nintendo Switch.
 

And Tesla Model-S/X cars until Tesla decided to switch to Intel in late 2017.
 
Dont have a cow people. You have been living with this sh*t for many decades and if you were secretly hacked, are you in jail right now for the crap you have on your computer? The world is not coming to an end. So chill... What needed to happen has happened; And that said, the future is bright and sun will shine again!
 
Status
Not open for further replies.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom