Intel Announces New Speculative Execution Side Channel Vulnerability

DooKey

[H]F Junkie
Joined
Apr 25, 2001
Messages
13,500
There's a new Core processor vulnerability that Intel has just announced and they consider this one to be of moderate severity. The Lazy FP state restore technique is the cause of this vulnerability and Intel is recommending that developers use the Eager FP state restore instead of Lazy FP state restore to work around this issue. Are these ever going to stop? This is not good for Intel and they need to get some new processors out on the market ASAP to put all of this to bed.

Intel would like to thank Julian Stecklina from Amazon Germany, Thomas Prescher from Cyberus Technology GmbH (https://www.cyberus-technology.de/), Zdenek Sojka from SYSGO AG (http://sysgo.com), and Colin Percival for reporting this issue and working with us on coordinated disclosure.
 
I honestly would have never thought the reason I am excited for the next Intel CPU won't be for performance but rather hard coded security fixes. If AMD would get a decent OC I would go with them.
 
I honestly would have never thought the reason I am excited for the next Intel CPU won't be for performance but rather hard coded security fixes. If AMD would get a decent OC I would go with them.
I don't understand this last part. AMD's chips are performing very well and they OC themselves now. The 2700+ review on this site says so, a manual OC is mostly unhelpful or unnecessary. The performance is on par with Intel on the majority of cases, and they trade blows on the rest. Some sort of dream target frequency really doesn't make sense if the performance is there. What am I missing?
 
Yes AMD is doing well but I won't ever buy AMD again after being burned once again by lack of support for the mobile Ryzen apus. And all these problem smell like ad campaign BS to get you you to buy a new computer.....
 
I don't understand this last part. AMD's chips are performing very well and they OC themselves now. The 2700+ review on this site says so, a manual OC is mostly unhelpful or unnecessary. The performance is on par with Intel on the majority of cases, and they trade blows on the rest. Some sort of dream target frequency really doesn't make sense if the performance is there. What am I missing?

You are missing the magical # which is the 5 Gigahurz that all the kids are after bruh. Don't you know that 6 FPS makes the world of a difference in Fortnite. :D
 
I don't understand this last part. AMD's chips are performing very well and they OC themselves now. The 2700+ review on this site says so, a manual OC is mostly unhelpful or unnecessary. The performance is on par with Intel on the majority of cases, and they trade blows on the rest. Some sort of dream target frequency really doesn't make sense if the performance is there. What am I missing?

This isn't entirely true. Precision Boost 2 doesn't clock quite as high as a manual overclock across all cores. Because you are limiting the overclock to what the weakest core can do, you may not be able to achieve as high a clock speed as you could on a single core. Thus, in some applications it hurts performance.
 
Next chip is due 2019 last I heard, thats a long time to wait to not purchased a pre-vulnerable piece of hardware.

Do we know if Ryzen 2 has any of these vulnerabilities?
 
Next chip is due 2019 last I heard, thats a long time to wait to not purchased a pre-vulnerable piece of hardware.

Do we know if Ryzen 2 has any of these vulnerabilities?

So far, not beyond any of the existing vulnerabilities Ryzen 1 has.
 
a manual OC is mostly unhelpful or unnecessary.


so the other day I put in place a manual OC on my threadripper 1900x and brought it up to base 4.2 with boosts to 4.62.. was great. then i start playing a game to see the difference.. nothing really. checked with TM and after a couple minutes the CPU had downclocked itself back to between 2.8 - 3.4 Ghz, since the game wasnt really demanding

that made me chuckle hard.

i have since removed the manual OC and just let the CPU control itself. the system is so damn fast anyways
 
This only affects intel again:)

AMD and ARM are not expected to be vuln. peoeple need to stop buying intel, their dominance has resulted in mediocrity that have manifested as security flaws ALL for higher prices
 
The problem is that fixes for this kind of crap may be upwards of 3.5 years away.
Exactly. But these companies were made aware of these vulnerabilities in advance of the press release to the public so they should have a jump start on some new architecture.
 
These side-channel vulnerabilities are overblown but could and should have been expected. Side-channel attacks leak random information, the attacker has to get lucky to get anything important and has to have a way of separating the important stuff from all the noise. That's why side-channel attacks on CPUs are overblown.

They could and should have been expected because eliminating side-channel vulnerabilities is a very difficult problem and imposes a cost in circuit complexity, power dissipation, performance and platform costs. For example, the current a CPU draws can create a side-channel vulnerability, as can stray EMI it radiates. The noise a keyboard makes creates a side-channel vulnerability, as does the noises your mouse makes (odds are which key/button has been pressed can be determined by the exact sound each makes). The noise a HDD makes as it operates does too. You're never going to be able to close them all off.

There is no perfect security, and all security has a cost. Proper security system design scales the cost according to the value and lifespan of the asset being protected: you don't put vault doors on piggy-banks. Most (99.99+%) CPUs don't do anything critical enough to require the investment and cost/power/performance trade-offs necessary to close off side-channel vulnerabilities like the one disclosed here.

If you are doing something that does justify those trade-offs, like generating root keys for PKI, then you build access-controlled servers in Faraday cages with motor-generator sets or other forms of isolated power supply, use at least one of the multi-serverkey generation protocols, always require at least two authorized people be present when any access (electronic or physical) is made to a server, have the list of allowed pairs of be random, changing, and published each day, and so on. Vault doors and armed guards may be appropriate; full CCTV surveillance and detailed access logging certainly.

But that's not what we're talking about here, where talking about people worried that maybe their Steam password will leak or something.
How much would you pay to reduce the odds of that happening via a side-channel leak? Not much, I bet, and you'd be wise to not, since a side-channel leak is by far not the most likely way that will happen.

So these side-channel vulnerabilities are just a PR problem, that's the real reason they are being addressed at all.

Disclaimer: I worked in Intel's Platform Security Group nee' Data Protection Operation for a few years (no, we didn't work on the CPUs) that's where I learned about cryptographic security systems, but it's been over a decade since I left Intel.
 
The problem is that fixes for this kind of crap may be upwards of 3.5 years away.
And if they rush though changes to the architecture, they risk creating even bigger problems. Most people don't realize how complex modern CPUs are. Frankly I'm amazed they work at all.
 
Yes AMD is doing well but I won't ever buy AMD again after being burned once again by lack of support for the mobile Ryzen apus. And all these problem smell like ad campaign BS to get you you to buy a new computer.....
well my Volvo S80 blew a tire @ 110km/h and I didn't even get a new tire.....fuck Volvo never buying another ever again. Oh, and once I bought coffee that tasted like a donkeys ballsweat and I totally stopped drinking coffee.
 
Last edited:
These side-channel vulnerabilities are overblown but could and should have been expected. Side-channel attacks leak random information, the attacker has to get lucky to get anything important and has to have a way of separating the important stuff from all the noise. That's why side-channel attacks on CPUs are overblown.

They could and should have been expected because eliminating side-channel vulnerabilities is a very difficult problem and imposes a cost in circuit complexity, power dissipation, performance and platform costs. For example, the current a CPU draws can create a side-channel vulnerability, as can stray EMI it radiates. The noise a keyboard makes creates a side-channel vulnerability, as does the noises your mouse makes (odds are which key/button has been pressed can be determined by the exact sound each makes). The noise a HDD makes as it operates does too. You're never going to be able to close them all off.

There is no perfect security, and all security has a cost. Proper security system design scales the cost according to the value and lifespan of the asset being protected: you don't put vault doors on piggy-banks. Most (99.99+%) CPUs don't do anything critical enough to require the investment and cost/power/performance trade-offs necessary to close off side-channel vulnerabilities like the one disclosed here.

If you are doing something that does justify those trade-offs, like generating root keys for PKI, then you build access-controlled servers in Faraday cages with motor-generator sets or other forms of isolated power supply, use at least one of the multi-serverkey generation protocols, always require at least two authorized people be present when any access (electronic or physical) is made to a server, have the list of allowed pairs of be random, changing, and published each day, and so on. Vault doors and armed guards may be appropriate; full CCTV surveillance and detailed access logging certainly.

But that's not what we're talking about here, where talking about people worried that maybe their Steam password will leak or something.
How much would you pay to reduce the odds of that happening via a side-channel leak? Not much, I bet, and you'd be wise to not, since a side-channel leak is by far not the most likely way that will happen.

So these side-channel vulnerabilities are just a PR problem, that's the real reason they are being addressed at all.

Disclaimer: I worked in Intel's Platform Security Group nee' Data Protection Operation for a few years (no, we didn't work on the CPUs) that's where I learned about cryptographic security systems, but it's been over a decade since I left Intel.
The real danger for the average user is in cloud computing environments. These types of side-channel attacks can leak data from one virtual machine to another, making it possible for someone to run an otherwise innocuous looking service that is really stealing customer data from the other virtual machines on that CPU. So your credit card info, or whatever, could be compromised even if you use legitimate, well run services/web-sites. So it's a little bigger problem than you implied.
 
Yes AMD is doing well but I won't ever buy AMD again after being burned once again by lack of support for the mobile Ryzen apus. And all these problem smell like ad campaign BS to get you you to buy a new computer.....
The vulnerabilities exist. They aren't marketing bs.

In 20+ years in this hobby I've been burned by almost all major companies at one time or another.

I no longer use that as a metric for buying.
 
Last edited:
Exactly. But these companies were made aware of these vulnerabilities in advance of the press release to the public so they should have a jump start on some new architecture.

We could very well see a newer architecture from Intel is less than 3-5 years. As you said, these issues are not new to Intel. We are only now just hearing about them. We don't really know, although given that it does take 3 years or more, we probably won't see fixes to this or a new architecture for at least another 1-2 years.
 
The real danger for the average user is in cloud computing environments. These types of side-channel attacks can leak data from one virtual machine to another, making it possible for someone to run an otherwise innocuous looking service that is really stealing customer data from the other virtual machines on that CPU. So your credit card info, or whatever, could be compromised even if you use legitimate, well run services/web-sites. So it's a little bigger problem than you implied.

The odds that this vulnerability will leak anything useful from one VM to another, and that the attacker will recognize it as something useful, are minuscule.
Imagine all the things the attacker has to know about the leaky VM: what OS and apps it is running, for just a start.

Your credit card info is far more likely to be compromised by a human being (waiter, cashier, server admin) than by a side-channel vulnerability.
And I don't care, because if it is compromised, my card issuer eats any losses that occur.
 
Yes AMD is doing well but I won't ever buy AMD again after being burned once again by lack of support for the mobile Ryzen apus. And all these problem smell like ad campaign BS to get you you to buy a new computer.....
isn't more like lack of support from whatever vendor your laptop is?
 
These side-channel vulnerabilities are overblown but could and should have been expected. Side-channel attacks leak random information, the attacker has to get lucky to get anything important and has to have a way of separating the important stuff from all the noise. That's why side-channel attacks on CPUs are overblown.

They could and should have been expected because eliminating side-channel vulnerabilities is a very difficult problem and imposes a cost in circuit complexity, power dissipation, performance and platform costs. For example, the current a CPU draws can create a side-channel vulnerability, as can stray EMI it radiates. The noise a keyboard makes creates a side-channel vulnerability, as does the noises your mouse makes (odds are which key/button has been pressed can be determined by the exact sound each makes). The noise a HDD makes as it operates does too. You're never going to be able to close them all off.

There is no perfect security, and all security has a cost. Proper security system design scales the cost according to the value and lifespan of the asset being protected: you don't put vault doors on piggy-banks. Most (99.99+%) CPUs don't do anything critical enough to require the investment and cost/power/performance trade-offs necessary to close off side-channel vulnerabilities like the one disclosed here.

If you are doing something that does justify those trade-offs, like generating root keys for PKI, then you build access-controlled servers in Faraday cages with motor-generator sets or other forms of isolated power supply, use at least one of the multi-serverkey generation protocols, always require at least two authorized people be present when any access (electronic or physical) is made to a server, have the list of allowed pairs of be random, changing, and published each day, and so on. Vault doors and armed guards may be appropriate; full CCTV surveillance and detailed access logging certainly.

But that's not what we're talking about here, where talking about people worried that maybe their Steam password will leak or something.
How much would you pay to reduce the odds of that happening via a side-channel leak? Not much, I bet, and you'd be wise to not, since a side-channel leak is by far not the most likely way that will happen.

So these side-channel vulnerabilities are just a PR problem, that's the real reason they are being addressed at all.

Disclaimer: I worked in Intel's Platform Security Group nee' Data Protection Operation for a few years (no, we didn't work on the CPUs) that's where I learned about cryptographic security systems, but it's been over a decade since I left Intel.

I don't get why more people haven't used critical thinking to understand the issue and break it down like you have. Unforunately, when you're on the top an everyone's gunning for you they'll go after whatever they can. I think the worst part are these AMD fanboys just pouring gasoline on the fire thinking this is something bigger than it actually is. I love the comparison to other side channel attacks and how nothing can completely be mitigated unless crazy measures are taken to ensure security. They don't complain about that because they don't understand the actual problem, the history of it and why they're not at risk. But oh, it only affects Intel? Better make it a bigger deal than it is so I can get more people in my party!
 
I don't get why more people haven't used critical thinking to understand the issue and break it down like you have. Unforunately, when you're on the top an everyone's gunning for you they'll go after whatever they can. I think the worst part are these AMD fanboys just pouring gasoline on the fire thinking this is something bigger than it actually is. I love the comparison to other side channel attacks and how nothing can completely be mitigated unless crazy measures are taken to ensure security. They don't complain about that because they don't understand the actual problem, the history of it and why they're not at risk. But oh, it only affects Intel? Better make it a bigger deal than it is so I can get more people in my party!

I'm pretty sure some of these vulnerabilities have been announced to also effect or could effect AMD processors as well.

The difference seems to be Intel's current software end fixes reducing the performance of their CPU's far more significantly then it effects AMD as of now at least.

All the negative talk about Intel is not just coming from "AMD fanboys", but from actual Intel consumers and its understandable as to why. If I owned a Ferrari and tomorrow Ferrari approaches and tells me that they made mistakes in the process of designing my cars engine that could result in catastrophic consequences and the only way to resolve it was to put a Fiat 500 engine in my car. Oh hell yea I'd be boiling over the top with anger.

Now my analogy blows it a good bit out of proportion since the performance hits aren't anywhere near that level, but it still doesn't stop people who spent good hard earned money on some of Intel's best processors on the market to see their performance dip closer to the competitions product in any way. Specially when the competitions product as of right now does not have the same premium cost of entry for its highest range parts.

I don't get the fanboy analogy though, I've owned everything from a Pentium, Pentium 3, Pentium 4, AMD FX-53, Core 2 Quad Q6600 (if memory serves me rihht), and two Core i7's lastly this 3820. Tomorrow I'm picking up the parts from Microcenter for an AMD Ryzen 2700X build.

I've owned far more Intel parts then AMD, but I always try to buy the best product within my current price range at the time. These vulnerability exploits have not factored into my decision, what made my decision was seeing the nice improvements that Zen+ brought tilt the Ryzen architecture and my goal is to upgrade this system I'm building to Zen 2 next year. I'm placing my bets on Zen 2 offering far more advancements then the refresh that Zen+, but even if in wrong and it only is about the same type of improvement I'll still be really happy none the less.

I think we can honestly say that Intel's R&D coffers are over flowing at the brim compared to AMD's and for some Intel consumers this situation brings them frustration even more knowing that.
 
If I owned a Ferrari and tomorrow Ferrari approaches and tells me that they made mistakes in the process of designing my cars engine that could result in catastrophic consequences and the only way to resolve it was to put a Fiat 500 engine in my car. Oh hell yea I'd be boiling over the top with anger.

Now my analogy blows it a good bit out of proportion ...

Yes, it does. You weren't buying a secure cryptoprocessor designed and marketed as a highly-secure place to keep and use your secrets. It wasn't advertised as meeting any relevant crypto-security standards. So, big shock: you didn't wind up with a secure processor. It leaks information. All general-purpose x86 and ARM processors do, and probably always will.

The proper analogy is finding out that your Ferrari isn't bulletproof.
Well, duh: you didn't pay for bulletproofing, and you probably didn't want the decrease in performance that all that bulletproofing would cause, so even though that lack of bulletproofing might possibly get you killed, you have no reason to be upset.
 
The odds that this vulnerability will leak anything useful from one VM to another, and that the attacker will recognize it as something useful, are minuscule.
Imagine all the things the attacker has to know about the leaky VM: what OS and apps it is running, for just a start.

Your credit card info is far more likely to be compromised by a human being (waiter, cashier, server admin) than by a side-channel vulnerability.
And I don't care, because if it is compromised, my card issuer eats any losses that occur.
I agree that side-channel attacks require the hacker to know exactly what they are looking for and that this is beyond the scope of most hackers. However, there exists today teams of state sponsored hackers (China, DPRK, etc.) that have the resources to utilize these types of attacks. And before someone says, "They aren't interested in your credit card, they are looking for corporate and government secrets", I'd like to point out that countries like North Korea, which are cash starved, DO use teams of hackers to steal bitcoin, credit card info, or anything else they can easily turn into cash. So, the threat is real, if limited. Trying to argue otherwise is just as annoying as hyping it up.
 
Mitigation

RHEL-7 will automatically default to (safe) “eager” floating point register restore on Sandy Bridge and newer Intel processors. AMD processors are not affected. You can mitigate this issue on older processors by booting the kernel with the 'eagerfpu=on' parameter to enable eager FPU restore mode. In this mode FPU state is saved and restored for every task/context switch regardless of whether the current process invokes FPU instructions or not. The parameter does not affect performance negatively, and can be applied with no adverse effects to processors that are not affected.

https://access.redhat.com/security/cve/cve-2018-3665
 
Back
Top