Overclock.net banner

[Various] Spectre & Meltdown: Critical vulnerabilities in modern processors

152K views 2K replies 263 participants last post by  113802 
#1 ·
Quote:
Which systems are affected by Meltdown?
Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.

Which systems are affected by Spectre?
Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors.

What is the difference between Meltdown and Spectre?
Meltdown breaks the mechanism that keeps applications from accessing arbitrary system memory. Consequently, applications can access system memory. Spectre tricks other applications into accessing arbitrary locations in their memory. Both attacks use side channels to obtain the information from the accessed memory location.
https://meltdownattack.com/

Spectre: https://spectreattack.com/spectre.pdf
Meltdown: https://meltdownattack.com/meltdown.pdf

Google (Project Zero): Reading privileged memory with a side-channel
Today's CPU vulnerability: what you need to know
More details about mitigations for the CPU Speculative Execution issue

Microsoft: Windows Client Guidance for IT Pros to protect against speculative execution side-channel vulnerabilities

Intel: Intel Responds to Security Research Findings
Intel Issues Updates to Protect Systems from Security Exploits
Facts about The New Security Research Findings and Intel Products
Speculative Execution and Indirect Branch Prediction Side Channel Analysis Method
Intel Analysis of Speculative Execution Side Channels

AMD: Information Security is a Priority at AMD

ARM: Vulnerability of Speculative Processors to Cache Timing Side-Channel Mechanism

Apple: About speculative execution vulnerabilities in ARM-based and Intel CPUs

NVIDIA: Security Bulletin: NVIDIA GPU Display Driver Security Updates for Speculative Side Channels

tomshardware: Understanding The Meltdown And Spectre Exploits: Intel, AMD, ARM, And Nvidia
[H]ardOCP: Quick Facts about Meltdown and Spectre
Anandtech: Understanding Meltdown & Spectre: What To Know About New Exploits That Affect Virtually All CPUs
Cnet: How to protect yourself from Meltdown and Spectre CPU flaws
Wired: Meltdown and Spectre Fixes Arrive-But Don't Solve Everything
 
See less See more
#3 ·
We have known this for a while but it is still good to see that it is not being left alone as it is something Intel need to step up and resolve. Regarding there current platforms, yeah they are slave to OS developers patching the software side of things to try and help fix the mess. Good news for AMD to some degree however.
 
#5 ·
Quote:
Originally Posted by Avonosac View Post

Brilliant article, they include a tweet saying there is a 49% performance hit on AMD EPYC processors and immediately follow that up with the statement that says this switch is unnecessary on EPYC.

I can't facepalm hard enough.
They wouldn't need it anyway because a major selling point on Epyc is per-VM hardware memory encryption. I can steal a book from someone all I want, but if I can't read the language then it doesn't do me much good, does it?

Boy I bet that marketing line is being taken a lot more seriously now.
tongue.gif
 
#6 ·
Quote:
Originally Posted by Avonosac View Post

Brilliant article, they include a tweet saying there is a 49% performance hit on AMD EPYC processors and immediately follow that up with the statement that says this switch is unnecessary on EPYC.

I can't facepalm hard enough.
Yeah, they should have included results from an Intel CPU so we could see what the performance impact is. Bringing AMD into the discussion when it's not affected seems pointless to say the least.

Well, at least they went on to clarify and quote someone from AMD saying that it doesn't apply to AMD CPUs and I'm assuming that the patched OSes will automatically choose the best path for AMD CPUs, or in other words, apply this (or equivalent in Windows) automatically:
Quote:
Disable page table isolation by default on AMD processors by not setting
the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
is set.
https://lkml.org/lkml/2017/12/27/2

Now I really want to see what the performance impact on Intel CPUs is going to be. From 5% to 49% is a big gap and we need to know the usage scenarios to see if this is a big issue or not. If a 49% impact is only on exotic workloads, Intel will get away with it, but a more general scenario could (I never thought I'd say this) actually break them. Even if 5% performance impact is what will happen in most cases, that means that the IPC advantage Intel has over AMD right now is going to be mostly wiped out.
 
#7 ·
Quote:
Originally Posted by tpi2007 View Post

I'm assuming that the patched OSes will automatically choose the best path for AMD CPUs, or in other words, apply this (or equivalent in Windows) automatically:
Unless Intel decides to grease some palms to ensure the AMD CPUs are also flagged for the instruction so that they also get hit with the performance decrease.
 
#8 ·
I remember reading about using ASLR disabled when the Ryzen segfaulting occurred to minimize the segfaults.

It remains to been seen how it affects Intel CPUs.
 
#9 ·
A lot of info here

http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table

https://news.ycombinator.com/item?id=16046636 -> Good discussion here...

Windows have been working on some fixes too
https://twitter.com/aionescu/status/930412525111296000

This is the resume of the patch status
https://lwn.net/SubscriberLink/741878/eb6c9d3913d7cb2b/

And a page on wikipedia was created on dec 29
https://en.wikipedia.org/wiki/Kernel_page-table_isolation

AWS instances apparently are going to be rebooted on jan 4... Azure instances on jan 10... (some people are commenting about emails received previously)

Edit: and the Intel CEO sold a lot of shares on dec 19... https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx
 
#10 ·
Quote:
Originally Posted by figuretti View Post

Edit: and the Intel CEO sold a lot of shares on dec 19... https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx
thats a sign of one of three possibilities.

1) Intel's CEO is planning to leave
2) Intel's CEO is expecting some awful news to affect intel's stock in a bad bad way. (remember Equifax? their whole board of directors withheld the news about the hack so they could divest themselves from the company, once they were divested they released the news about the hack). I would expect company affecting bad news to result in most of the directors divesting, not just the CEO; so unless the rest of intel's directors also recently sold off shares, then this probably isn't why he's selling.
3) Intel's CEO wants to invest in something else, or needs a lot of liquid assets for some reason (this is unlikely unless he plans to buy or massively invest in a company; or he's going to be sat on the board of another company and that company has share requirements to be seated... this is more common then you'd expect)
 
#11 ·
Quote:
Originally Posted by PiOfPie View Post

Quote:
Originally Posted by tpi2007 View Post

I'm assuming that the patched OSes will automatically choose the best path for AMD CPUs, or in other words, apply this (or equivalent in Windows) automatically:
Unless Intel decides to grease some palms to ensure the AMD CPUs are also flagged for the instruction so that they also get hit with the performance decrease.
That would last for about half a day, at best. The complaints would be so numerous and so loud that Intel would stop before it began.
 
#12 ·
Quote:
Originally Posted by azanimefan View Post

thats a sign of one of three possibilities.

1) Intel's CEO is planning to leave
2) Intel's CEO is expecting some awful news to affect intel's stock in a bad bad way. (remember Equifax? their whole board of directors withheld the news about the hack so they could divest themselves from the company, once they were divested they released the news about the hack). I would expect company affecting bad news to result in most of the directors divesting, not just the CEO; so unless the rest of intel's directors also recently sold off shares, then this probably isn't why he's selling.
3) Intel's CEO wants to invest in something else, or needs a lot of liquid assets for some reason (this is unlikely unless he plans to buy or massively invest in a company; or he's going to be sat on the board of another company and that company has share requirements to be seated... this is more common then you'd expect)
I don't like your hypothesis.
1) he's leaving - does he really needs to sell share / keep the bare minimum for that?
2) and 3) pretty much the same - bad stock performance.

I've heard the rise of silicon pricing, not sure how this is affecting Intel considering that they probably make their own ingot. I like to think tech stock will perform poorly due to rising production and R&D cost.
 
#13 ·
2 and 3 aren't the same thing at all

Lots of corporate officers hold seats on multiple companies. It's really inbred that way. I would not be surprised at all if he was being added to the board of another company; one which requires a min percentage of ownership. Look it up, I wouldn't be surprised to learn he's already on several corporate boards already.
 
#14 ·
biggrin.gif
 
#15 ·
Do I sense a wave of incoming cheap Xeons for hobbyists?
wheee.gif
Sorry...
 
#17 ·
Quote:
Originally Posted by KyadCK View Post

They wouldn't need it anyway because a major selling point on Epyc is per-VM hardware memory encryption. I can steal a book from someone all I want, but if I can't read the language then it doesn't do me much good, does it?

Boy I bet that marketing line is being taken a lot more seriously now.
tongue.gif
I know, but my point is that *THEY* also knew it, and yet included something so completely stupid in the article. This is so inflammatory it's at honest-to-god shill level. Intel didn't even need to PAY for this kind of negative association.

Quote:
Originally Posted by tpi2007 View Post

Yeah, they should have included results from an Intel CPU so we could see what the performance impact is. Bringing AMD into the discussion when it's not affected seems pointless to say the least.

Well, at least they went on to clarify and quote someone from AMD saying that it doesn't apply to AMD CPUs and I'm assuming that the patched OSes will automatically choose the best path for AMD CPUs, or in other words, apply this (or equivalent in Windows) automatically:
https://lkml.org/lkml/2017/12/27/2

Now I really want to see what the performance impact on Intel CPUs is going to be. From 5% to 49% is a big gap and we need to know the usage scenarios to see if this is a big issue or not. If a 49% impact is only on exotic workloads, Intel will get away with it, but a more general scenario could (I never thought I'd say this) actually break them. Even if 5% performance impact is what will happen in most cases, that means that the IPC advantage Intel has over AMD right now is going to be mostly wiped out.
Pointless, ha. This might be a somewhat rare exception to Hanlon's razor. They should immediately remove the tweet and any reference to the 49% number as the *HARDWARE* already provides this security. Any retraction of the AMD numbers should be replaced by the worst case scenario of Intel's numbers.
 
#19 ·
Quote:
Originally Posted by Avonosac View Post

Quote:
Originally Posted by tpi2007 View Post

Yeah, they should have included results from an Intel CPU so we could see what the performance impact is. Bringing AMD into the discussion when it's not affected seems pointless to say the least.

Well, at least they went on to clarify and quote someone from AMD saying that it doesn't apply to AMD CPUs and I'm assuming that the patched OSes will automatically choose the best path for AMD CPUs, or in other words, apply this (or equivalent in Windows) automatically:
https://lkml.org/lkml/2017/12/27/2

Now I really want to see what the performance impact on Intel CPUs is going to be. From 5% to 49% is a big gap and we need to know the usage scenarios to see if this is a big issue or not. If a 49% impact is only on exotic workloads, Intel will get away with it, but a more general scenario could (I never thought I'd say this) actually break them. Even if 5% performance impact is what will happen in most cases, that means that the IPC advantage Intel has over AMD right now is going to be mostly wiped out.
Pointless, ha. This might be a somewhat rare exception to Hanlon's razor. They should immediately remove the tweet and any reference to the 49% number as the *HARDWARE* already provides this security. Any retraction of the AMD numbers should be replaced by the worst case scenario of Intel's numbers.
I agree with them posting Intel numbers.

When it comes to AMD, that part has perhaps the unintended consequence that people will know that something happened behind the scenes if AMD CPUs also degrade in performance when they shouldn't.

The correct way to post that story would be:

1. Here are the Intel numbers;
2. Here are the AMD numbers if something behind the scenes happens.
 
#20 ·
Quote:
Originally Posted by tpi2007 View Post

I agree with them posting Intel numbers.

When it comes to AMD, that part has perhaps the unintended consequence that people will know that something happened behind the scenes if AMD CPUs also degrade in performance when they shouldn't.

The correct way to post that story would be:

1. Here are the Intel numbers;
2. Here are the AMD numbers if something behind the scenes happens.
I disagree completely with any association with AMD. This is disclosed and referenced as a solely *INTEL* bug. If at any point in the future something in this affects AMD directly somehow, then and *ONLY* then do they even get mentioned. The only exception being the statement AMD is unaffected by this bug and has no performance impact.

This legitimately may make EPYC superior in performance to intel, not just better PPD. The new normal is to compare AMD throughput on all tasks to Intel's new throughput when the fixes are released to all kernels.
 
#21 ·
Quote:
Originally Posted by Avonosac View Post

Quote:
Originally Posted by tpi2007 View Post

I agree with them posting Intel numbers.

When it comes to AMD, that part has perhaps the unintended consequence that people will know that something happened behind the scenes if AMD CPUs also degrade in performance when they shouldn't.

The correct way to post that story would be:

1. Here are the Intel numbers;
2. Here are the AMD numbers if something behind the scenes happens.
I disagree completely with any association with AMD. This is disclosed and referenced as a solely *INTEL* bug. If at any point in the future something in this affects AMD directly somehow, then and *ONLY* then do they even get mentioned. The only exception being the statement AMD is unaffected by this bug and has no performance impact.

This legitimately may make EPYC superior in performance to intel, not just better PPD. The new normal is to compare AMD throughput on all tasks to Intel's new throughput when the fixes are released to all kernels.
I was referring to AMD's reply to someone's opinion that:
Quote:
/* Assume for now that ALL x86 CPUs are insecure */
- setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
+ if (c->x86_vendor != X86_VENDOR_AMD)
+ setup_force_cpu_bug(X86_BUG_CPU_INSECURE);

fpu__init_system(c);
https://lkml.org/lkml/2017/12/27/2

Edit: Just to be clear, I agree that without trying to source Intel numbers for the article, they do seem incompetent. It's hard to say that it's outright bad faith because you'd somehow have to selectively not read parts of the article both before and after that part with the AMD numbers tweet to not understand that AMD CPUs are not affected.
 
#23 ·
rich000@reddit breaks it down (matches up with explanations on ycombinator as well):
Quote:
It sounds like this is tied to speculative execution. If you're speculatively executing an instruction then it is possible you'll just end up throwing away the result anyway, so you want to do it as cheaply as possible. Maybe Intel figured out that they can skip the priv checks while speculatively executing, and then perform them before actually implementing the results if it turns out the instruction was needed. However, maybe it turns out that the speculative execution opens up some back-door way of getting at the data, such as via the cache/timing/etc, which wouldn't be exposed if an exception was raised sooner.
Sucks. Intel's 30% performance lead is rearing it's ugly head, and the debt is due.
 
#24 ·
Quote:
Originally Posted by Ghoxt View Post

So correct me if I'm wrong...Did Intel lose control of one of the vulnerabilities they designed on purpose for 3 letter "Agencies", /tinfoil
rolleyes.gif
redface.gif
You're probably wrong because those are usually software bugs where plausible deniability means that you'll never know if it was incompetence or on purpose, and the fix does not entail significant performance loss, not on a hardware problem that, if confirmed, will mean that their CPUs will lose a not insignificant amount of performance when the OSes are patched for security. That's many millions, potentially billions of dollars worth of a mistake, so the simplest explanation is that this was a mistake, an oversight in the design.

Quote:
Originally Posted by mouacyk View Post

rich000@reddit breaks it down (matches up with explanations on ycombinator as well):
Quote:
It sounds like this is tied to speculative execution. If you're speculatively executing an instruction then it is possible you'll just end up throwing away the result anyway, so you want to do it as cheaply as possible. Maybe Intel figured out that they can skip the priv checks while speculatively executing, and then perform them before actually implementing the results if it turns out the instruction was needed. However, maybe it turns out that the speculative execution opens up some back-door way of getting at the data, such as via the cache/timing/etc, which wouldn't be exposed if an exception was raised sooner.
Sucks. Intel's 30% performance lead is rearing it's ugly head, and the debt is due.
It's kind of ironically fitting that in a world that is speeding up with cheap speculations of all sorts that this would happen. Let's hope that those AIs that make their own code don't choose to speculate cheaply too much.
redface.gif
 
#25 ·
  • Rep+
Reactions: sumitlian
#26 ·
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top