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

Page 2 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Toggle sidebar Toggle sidebar
Status
Not open for further replies.


Granting that you are not involved in this process and don't have any actual knowledge of what it might take to physically implement this on the actual process (Or maybe you do, I don't know that. I suspect you might, but don't know that either), on a rather educated guess, what would YOU say the timeframe involved with implementing those changes into a process would be?

Do you think that's something that can be done through microcode changes or does this need to happen at the hardware level?

Is this theoretically something that could be implemented into existing or in-progress designs, or does this require a complete redesign from the ground up?

Realistically, would making THOSE changes also have a hit on branch prediction and performance, or would it largely not affect the overall cycle?
 


So you figure succeptible versions of branch prediction have been implemented in consumer processors for "many decades"? LOL.

These vulnerabilities only affect CPUs that have been around for about 10 years, maybe slightly more, definitely not "decades". Honestly, I don't think you have too much awareness of where the sun even rises from on this subject. Maybe you do, I don't know, but it doesn't show through your comments.
 

This issue can potentially affect Intel CPUs all the way back to 1995, 23 years ago. So "decades" may very well be accurate.
http://www.tomshardware.com/news/intel-meltdown-spectre-cpu-patches,36225.html
 

The changes I thought about (assuming CPUs don't already have the necessary facilities) can't do anything about missing KPTI checks in speculative execution instruction flow, they can only deal with timing-related side-channel issues. If there was a possible microcode fix for KPTI and similar checks, Intel would have done it before OS vendors had to push out patches.

On the side-channel side of things, trying to design an architecture that is intrinsically side-channel-safe will almost certainly come with considerable performance compromises. If people freak out enough over this, we'll probably end up with CPUs having some slow security-hardened cores for handling sensitive data and high-performance cores for everything else.
 


Maybe, but I haven't seen that stated anywhere except the Tom's article. I may have simply overlooked it, but most the reference material I've read so far hasn't firmly stated that CPUs that old are among the indicated models. Have you seen a firm declaration in any of the actual testing saying it HAS been verified on those older architectures? Most that old stuff doesn't even support the majority of instructions used now.
 


I think they're saying that everything since the original Pentium is affected by Spectre because the original Pentium was the last Intel chip to not include branch prediction. Now I'm pretty sure nobody has broken out their vintage hardware from the mid to late 1990s to test this, so there probably is a more recent cut off point, but nobody knows for sure so they seem to just assume any CPU with branch prediction is affected.
 
IMO

Based on wut i just read on other popular tech sites, Intel and its whole shareholders are in very deep serious shit with this issue and since they just released a lot of their new gen procs. that startigically competes with latest Amd offerings if they dont manage to mitigate or fix this vulnerability a lot of their profits, budget allocation for RnD and marketing and credits from their business partners will go down the drain bigtime including their trading stocks.

Linus Torvalds also expresses disappointments on how Intel is currently addressing the issue as of the moment and a lot of Intel PR guys are spreading "false words of comfort" about the issue and also on other popular tech sites same thing happens which also are expressing disappointments on Intel's PR which based on the interpretation that Intel has no plans of fixing the vulnerability including the level 2 and 3 and it doesn't affects much of their latest procs. and including older 1st generation i3, i5 and i7 models knowing that 90 percent of all their procs. are vulnerable including old dual core ones.

I hope Tom's Hardware could make an article on how to properly bechmark Intel procs. specifically to see if an Intel proc. owner (in their server, gaming rig or laptop) is already affected by the issue since Tom's have lots of intel data benchies to compare their procs. to.
 

Maybe, maybe not. Most of these exploits require local access for exploitation and it isn't Intel's job to secure local access, that's the OS, services and applications' job to keep foreign code out of the system. The CPU is nothing more than the last line of defense after multiple other protection layers have already failed.

If the unexpected success of timing-based attacks is anything to go by, no system using multi-core CPUs to run multiple concurrent tasks can be trusted any more than its least trustworthy process.
 

Intel's Prescott (last generation on Netburst architecture which miserably under-delivered on performance gains while consuming significantly more power) might beg to differ. AMD doesn't have a monopoly on poor design choices, but it does deserve the shame of roughly duplicating Intel's failure.

Pursuing deeper pipelines primarily for the sake of achieving higher clock frequencies failed both companies spectacularly.
 


Did you read the article? You need physical access to the motherboard to exploit it.
 


I see your point but I would not pay money for something that is flawed, when I know it.
 

If you are going to consider side-channel exploits that require access to the machine to exploit as fundamentally flawed, then I have bad news for you: side-channel exploits will in all likelihood remain possible on all CPUs that haven't been specifically designed to be hardened against side-channel attacks. Hardening CPUs against side-channel attacks comes with severe performance compromises to make the execution rate and power usage as uniform as possible so data cannot be inferred from side-channel measurements, which is why the most secure elements in modern platforms are delegated to purpose-built micro-controllers and hard-wired logic.
 
I am not willing to sacrifice the kind of performance noted for my Windows 7 laptop running a Sandy Bridge i7 CPU. That is stupid, especially given that there really is NO threat. Now that so many systems are going to be updated, there is little reason for any scumbags to try to exploit these vulnerabilities, IMO. From my perspective, the cure is far worse than the disease, especially on older hardware / OS combinations. It just is not worth it. So, I believe Microsoft should make a way to have these patches be OPTIONAL and AVOIDABLE and UNINSTALLABLE. This is crap!
 


If you're running Windows 7 you can just choose to not install the security update and don't bother updating your BIOS, assuming your laptop manufacturer even bothers updating such an old product. Windows 10 is the OS that has issues with mandatory updates and you have to do more legwork to disable them if you choose to do so.
 
Well, since the Windows patch has very little affect on performance, even IN the workloads most affected, seems like if you simply avoid updating the firmware beyond any versions that were available prior to Nov 1, 2018, you can avoid 95% or more of the performance hit. No patch + firmware equals very little difference if any on the majority of systems. I think that's what I'm going to do since the consensus is that unless you allow exploitable malware to reside on your system there is zero risk of a side channel attack, and I have no plans to allow that, it makes little sense to intentionally cripple my system by installing the firmware at all.

I'd avoid the Windows 10 patch as well if I could, but obviously there is no way to avoid installing that AND continue to be able to install other updates. It's all or none in that regard, so I'll allow the update but avoid the firmware. Pretty doubtful at this point there will be any meaningful bios updates for my Z170 system that are unrelated to this patch anyhow, and any future ones will incorporate it, so for all intents and purposes this system is done getting firmware upgrades for the remainder of its lifetime.
 
Status
Not open for further replies.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom