Part numbers of CPU's without the meltdown and spectre bugs?

[jpiniero]

OOC, will the Meltdown OS patches slow down all chips or just Intel chips? Sucks for those on a non-affected platform but are dragged down anyways.

In terms of x86, Meltdown hurts Intel only. Some ARM cores are hurt by it too.

Spectre #2 hurts both AMD and Intel but it's only a minor hit except for Skylake+.

 

[Topweasel]

Both of you are being repetitive down to the saying the same exact thing a day later.

So I will repeat hopefully in a simpler and easier to register way. LTC I know why you are saying not a bug. But it only applies to Spectre.

In regards to Meltdown. It would not exist if Intel CPU's unlike did what it was supposed to when verifying memory access permissions after the code has been processed. It should do a check notice the discrepancy and chuck it. That is what the check is for. That is what all other CPU's do. Whether it was an intentional choice by an engineer when realizing it was doing what it was supposed to do, a design decision by Intel to ignore the security check for performance, or it was just an oversight because when this was originally done, there wasn't really an attack vector that could utilize it anyways, there is a design feature included in the CPU that doesn't handle it's job correctly. That is a bug and not a CPU doing what it is supposed but a new exploit takes advantage of that.

Again Meltdown can't exist if there wasn't a bug in the CPU. Susceptible to Meltdown means the CPU has a bug in it.

 

[zinfamous]

I/O supposedly takes a big hit. So something like 4K editiing would also take a hit.

This. OP should only be thinking about Ryzen or TR at this point, and will be fine going forward with this specific vulnerability, because the "performance-based bug" (meltdown) doesn't exist in Zen-based AMD chips. Spectre effects everything, but doesn't appear to lead to a measurable performance hit for anything.

 

[Topweasel]

In terms of x86, Meltdown hurts Intel only. Some ARM cores are hurt by it too.

Spectre #2 hurts both AMD and Intel but it's only a minor hit except for Skylake+.

Better way of putting it.

Spectre #1 affects all CPU's with OoO execution. But nothing at this time can really be used to take advantage of it.

Spectre #2 Can affect all CPU's with OoO. How AMD's system works makes it extremely difficult and for a lot of CPU's each use case for this exploit requires the virus to be coded specifically for the CPU. The exploit as used against Intel CPU's seems to be much more universal for Intel. But even then the data that can be retrieved is limited. So neither Spectre is a good attack vector now, that and the difficulty of using it on an AMD CPU makes it a "near Zero risk". This makes Spectre more of learning tool, that there are security risks when dealing with speculative computing. Something for AMD, Intel, ARM and even IBM to take into consideration as their architectures develop.

Meltdown #3 Is an immediate security risk to people whom security is a really important part of their product choices. This is mainly an Intel thing because it requires the ignoring of security functions that you have in place specifically for these types of issues. There are few ARM implementations that are also susceptible to this.

 

[DaveSimmons]

Furmark is another example of revealing a case of either a "bug," "design flaw," or "working as intended but open to exploit" depending on how you view the world.

It puts an unexpected and unrealistic load on the GPU that is technically correct (the best kind of correct) but was not accounted for in existing GPU designs. GPUs overheated and in some cases could be damaged. No existing game would trigger this behavior, but this new exploit demonstrated the need to update designs to block this edge case from triggering misbehavior.

Was every existing GPU "defective"? Not in my view, but you're free to disagree.

 

[BrandonT]

If I/O is mostly impacted, has anyone tested with Intel chips with Handbrake? I'd bu curious if I'm affected.

 

[Topweasel]

Furmark is another example of revealing a case of either a "bug," "design flaw," or "working as intended but open to exploit" depending on how you view the world.

It puts an unexpected and unrealistic load on the GPU that is technically correct (the best kind of correct) but was not accounted for in existing GPU designs. GPUs overheated and in some cases could be damaged. No existing game would trigger this behavior, but this new exploit demonstrated the need to update designs to block this edge case from triggering misbehavior.

Was every existing GPU "defective"? Not in my view, but you're free to disagree.

That would be a design flaw like Nvidia's solder in the mid 2000's, the chinese caps on motherboards, or the Red Ring of death. The GPU's didn't have a thermal limit set correctly to prevent an application to over exert the video card and cause it to be damaged. If it did have those thermal protections but they weren't working correctly it would be a bug. If someone found a hack that cause the GPU driver to ignore those thermal limitations and kill the card then it would be working as intended but open to be exploited.

It's not a hard concept. Intel doesn't have any security checks for cache data read tasks. Design flaw. Intel has security checks in place but the CPU ignores those checks for whatever reason. Bug. Intel has the security checks in place, but under certain circumstances someone can exploit part of the pipeline to circumvent those security measures. Open to exploitation.

Meltdown takes advantage of Option 2. Intel having the security process in place but it doesn't do what it is supposed to do when there is a discrepancy. So Bug.

I don't know why people are getting worked up with it being called a Bug. A Bug means no malice or intent. It's really gentle and playing with kid gloves to call this a Bug. Because a bug implies that they didn't realize that it was not working like intended until it was brought to their attention. But who knows when Intel actually realized this and whether it was an intentional or not.

 

[LTC8K6]

Yeah. No. The CPUs are not working as intended. The CPUs are intended to prevent code accessing privileged data.

I just gave you an example of how stupid it is to claim a buggy system is working as intended. That is it's stupid to claim a system is working as intended just because it functions to some extent.

But the intel CPUs are not working as designed. Because they were designed to prevent code accessing privileged data. Intel spent a lot of time and money and silicone to prevent code accessing privileged data. But they failed because they missed something.

So the intel CPUs have a bug. We can play word games all day. Of course bugs can be exploited. Of course bugs may fall outside the normal workload. Of course bugs may not be discovered yet. But they are still bugs and they are still a huge security concern and you are still wrong to claim intel CPUs work as intended.

Again: intel CPUs were intended to prevent code accessing privileged data. They have a bug so they don't do this. So they don't work as intended. AKA they are buggy.

Sure, okay...

That would be a design flaw like Nvidia's solder in the mid 2000's, the chinese caps on motherboards, or the Red Ring of death. The GPU's didn't have a thermal limit set correctly to prevent an application to over exert the video card and cause it to be damaged. If it did have those thermal protections but they weren't working correctly it would be a bug. If someone found a hack that cause the GPU driver to ignore those thermal limitations and kill the card then it would be working as intended but open to be exploited.

It's not a hard concept. Intel doesn't have any security checks for cache data read tasks. Design flaw. Intel has security checks in place but the CPU ignores those checks for whatever reason. Bug. Intel has the security checks in place, but under certain circumstances someone can exploit part of the pipeline to circumvent those security measures. Open to exploitation.

Meltdown takes advantage of Option 2. Intel having the security process in place but it doesn't do what it is supposed to do when there is a discrepancy. So Bug.

I don't know why people are getting worked up with it being called a Bug. A Bug means no malice or intent. It's really gentle and playing with kid gloves to call this a Bug. Because a bug implies that they didn't realize that it was not working like intended until it was brought to their attention. But who knows when Intel actually realized this and whether it was an intentional or not.

If Intel releases chips "later this year" that are not vulnerable, then we will have an idea that they knew before Google told them.

 

[Topweasel]

Sure, okay...

If Intel releases chips "later this year" that are not vulnerable, then we will have an idea that they knew before Google told them.

I don't know Intel is a company that can literally throw money at a problem, we have also heard about Intel pushing validation to basically take shortcuts. In the end whether this was intentional or Intel realized this years ago, I doubt they or many other companies would volunteer this up. So likely if they knew they sat on it till someone brought it to their attention. Whether they knew about it before Google I doubt they would do anything till Google talked to them. So any timeline for a solution that came after the announcement wouldn't mean much to me. Now if Skylake-X or Coffee Lake weren't vulnerable to Meltdown, that would be another story altogether.

 

[scannall]

I don't know why people are getting worked up with it being called a Bug. A Bug means no malice or intent. It's really gentle and playing with kid gloves to call this a Bug. Because a bug implies that they didn't realize that it was not working like intended until it was brought to their attention. But who knows when Intel actually realized this and whether it was an intentional or not.

I'm not sure why people are getting worked up over a word. Since it doesn't matter one way or the other. It's still the same sized problem, regardless of the cause.

 

[rbk123]

In terms of x86, Meltdown hurts Intel only. Some ARM cores are hurt by it too.

Spectre #2 hurts both AMD and Intel but it's only a minor hit except for Skylake+.

I more was referring to the patch - since it is at the OS level. i.e. will only Intel machines run slower? Or will AMD systems also run slower? I'd think since it's at the OS level both platforms are going to run slower after the patch is applied.

 

[Topweasel]

I'm not sure why people are getting worked up over a word. Since it doesn't matter one way or the other. It's still the same sized problem, regardless of the cause.

I think it comes down to culpability. A bug or Design flaw makes Intel culpable for the security hole. I mean not that it matters it's not like we as fanboys can put Intel on trial for this. But mentally I think people take issue with the idea that their chosen CPU supplier may or may not be at fault.

 

[Topweasel]

I more was referring to the patch - since it is at the OS level, will only Intel machines run slower? Or will AMD systems also run slower? I'd think since it's at the OS level both platforms are going to run slower after the patch is applied.

The problem is as it is right now a properly patched machine for Meltdown should only slow down Intel systems. I do fear that depending on the how the security risks of Spectre developes that OS companies will attempt to bubble wrap kernel level cache by making all CPU's go through the extra work Intel CPU's have to now.

 

[rbk123]

I do fear that depending on the how the security risks of Spectre developes that OS companies will attempt to bubble wrap kernel level cache by making all CPU's go through the extra work Intel CPU's have to now.

Right - my fear also. My other fear is Microsoft's developer's are inept and so will code a patch that impacts both since it's easier for them. Linux I would expect them to code it be processor specific IF that is possible.

 

[teejee]

Right - my fear also. My other fear is Microsoft's developer's are inept and so will code a patch that impacts both since it's easier for them. Linux I would expect them to code it be processor specific IF that is possible.

MS has just bought a lot of EPYC servers for their data centers. So we can be pretty sure they do proper optimisation for the ZEN core.

 

[rbk123]

MS has just bought a lot of EPYC servers for their data centers. So we can be pretty sure they do proper optimisation for the ZEN core.

Microsoft and proper coding are 2 things that have never been mentioned in the same sentence together.

 

[Smoblikat]

Microsoft and proper coding are 2 things that have never been mentioned in the same sentence together.

I personally know people who had direct acces to source code for windows, a direct quote is "Its a complete ****ing mess"

 

[DaveSimmons]

I personally know people who had direct acces to source code for windows, a direct quote is "Its a complete ****ing mess"

In fairness, that's partly because it needs to include miles of duct tape and baling wire in order to keep legacy API calls and expected behavior from 25+ years ago working. I've read scores or possibly even hundreds of API pages on MSDN where it mentions that "this misleading name or weird behavior or so-called pointer that is really a handle is that way for compatibility with (old version of Windows or old API)"

 

[Snowleopard3000]

Looks like Core 2 Duo, and thus my trusty Q6600's, aren't affected.

OOC, will the Meltdown OS patches slow down all chips or just Intel chips? Sucks for those on a non-affected platform but are dragged down anyways.

I still have the tower I built in 2006 with the Q6600 and the Asus Striker Extreme motherboard..... It runs Windows Serv er 2008 R 2 now..... it was a fast system.... in 2006

 

[dualsmp]

From what I have read every Intel CPU from Pentium Pro forward is affected except for Itanium and early Atoms. Intel listed only 45nm--> forward as affected by Meltdown and Spectre probably because Intel isn't going to bother updating microcode for processors before 2008.

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr

As far as real world support I seriously doubt many motherboard manufacturers will provide BIOS updates earlier than Skylake for consumers. Server products will probably get updates older than Skylake, but even then it depends.

That being said a Raspberry Pi 3 is completely immune to Meltdown and Spectre and will be faster than any chip from the mid 1990's.

 

[SPBHM]

Windows 10 can load the updated microcodes if MS wants, I just wonder if Intel is going to bother with stuff like C2D, I think they should, Pentium 4 and lower I think it's OK not to.

 

[rbk123]

If C2D is impacted and they don't list it, I would imagine they are exposing themselves to liability risk, so I'm guessing it really isn't impacted. More likely, imo, that some of the post C2D performance gains are from the prefetch stuff that is the source of this problem for them.

 

[jpiniero]

If C2D is impacted and they don't list it, I would imagine they are exposing themselves to liability risk, so I'm guessing it really isn't impacted.

All of C2D/C2Q is considered End of Interactive Support, so I imagine they didn't test it.

 

[DaveSimmons]

Update from ArsTechnica on the performance impacts of S&M : https://arstechnica.com/gadgets/201...e-and-meltdown-patches-will-hurt-performance/

Still under 10% for gaming and compute tasks like video encoding, but up to 30-40% for synthetic benchmarks that spend 100% of their time making kernel calls (aka Furmark for S&M)

 

[jkauff]

No one is being forced to apply patches. If you have a video editing workstation, for example, that can't afford a performance hit of any kind, disconnect it from the internet and it won't be vulnerable to any exploits. Use a less critical machine to access the internet.