News Intel's Downfall Mitigations Drop Performance Up to 39%, Tests Show

[Admin]

Linux publication Phoronix evaluates the performance impact of Downfall mitigations on different Intel processors.

Intel's Downfall Mitigations Drop Performance Up to 39%, Tests Show : Read more

 

[ikjadoon]

Linux publication Phoronix evaluates the performance impact of Downfall mitigations on different Intel processors.

Intel's Downfall Mitigations Drop Performance Up to 39%, Tests Show : Read more

Damn. So why did Intel need a year for these mitigations?

Luckily, we can send Intel more money with updated CPUs that don’t need these mitigations (but maybe we’ll get other mitigations next year at this pace).

Good that Intel finally shipped Sapphire Rapids. Had this embargo expired last year, it’d mean Intel had nothing to sell.

Will be curious to see consumer workloads that might use GATHER.

 

[rluker5]

Damn. So why did Intel need a year for these mitigations?

Luckily, we can send Intel more money with updated CPUs that don’t need these mitigations (but maybe we’ll get other mitigations next year at this pace).

Good that Intel finally shipped Sapphire Rapids. Had this embargo expired last year, it’d mean Intel had nothing to sell.

Will be curious to see consumer workloads that might use GATHER.

Intel had the fix available at the time the vulnerability was published.

Perhaps you should ask AMD why it has been a year and they haven't come up with a mitigation for SQUIP. Which affects all Zen (at least through Zen 3, but I haven't heard that the root cause, the scheduler design, has been changed with Zen 4), is very similar to Downfall in that you need to have the attack occur on the same core as the victim and that it can bypass conventional security.

Where it is different is that basically all programs make use of what is vulnerable in SQUIP's case: the CPU scheduler.

Actually there are mitigations for SQUIP: turn off SMT, keep other programs from sharing a core that is running a secure operation, and don't do operations that need to be secure. Just not some microcode update like Intel has provided. With SQUIP you have to trust that the system administrators of affected hardware are fixing the security hole themselves. What is the performance penalty? That depends on the fix implemented and is hard to test. If my relatively ignorant butt were to fix it I would just shut down SMT which could have a performance penalty of up to 50% depending on the workload. But some system administrators (or their bosses) aren't much better.

Both Downfall and SQUIP are side channel attacks that aren't much of a threat for the typical home user. More of a threat for businesses or gov agencies that work on shared servers.

All chips have some security flaws. It would be nice if AMD were as quick to patch them as Intel is.

And it does suck that mitigations generally come with performance penalties.

 

[bit_user]

As I said in the comments of the last article about Downfall, those benchmarks (which I linked at the time) don't cover CPUs without AVX-512. So, we don't know what's the impact on just AVX2.

 

[vehekos]

I wonder what is the accumulated effect of all "mitigation" patches that cover for security flaws.

There should be a map somewhere.

 

[bit_user]

I wonder what is the accumulated effect of all "mitigation" patches that cover for security flaws.

Funny enough, current CPU models actually perform a little better with most of the mitigations that existed at the time they were released. There are some theories about why this is.

There should be a map somewhere.

You can find benchmark articles which test this proposition, here and there.

 

[ikjadoon]

Intel had the fix available at the time the vulnerability was published.

When was the fix released, though? The vuln was reported to Intel ~11 months ago.

[Q] How long was this vulberability under embargo?

[A] Almost one year. I reported this vulnerability to Intel August 24, 2022.

 

[rluker5]

When was the fix released, though? The vuln was reported to Intel ~11 months ago.

And how long has the patch been out?
They don't report a vulnerability as soon as it has been discovered unless it is being exploited. They give the affected companies some time to mitigate it.
Apparently they were waiting for the BlackHat USA conference on August 9 and USENIX Security Symposium on August 11 to announce it after giving Intel some time to patch it. With SQUIP, AMD was notified in late 2021 and it was published 8/9/22 during the time Black Hat USA 2022 was going on.

 

[NinoPino]

Intel had the fix available at the time the vulnerability was published.

Perhaps you should ask AMD why it has been a year and they haven't come up with a mitigation for SQUIP. Which affects all Zen (at least through Zen 3, but I haven't heard that the root cause, the scheduler design, has been changed with Zen 4), is very similar to Downfall in that you need to have the attack occur on the same core as the victim and that it can bypass conventional security.

Where it is different is that basically all programs make use of what is vulnerable in SQUIP's case: the CPU scheduler.

Actually there are mitigations for SQUIP: turn off SMT, keep other programs from sharing a core that is running a secure operation, and don't do operations that need to be secure. Just not some microcode update like Intel has provided. With SQUIP you have to trust that the system administrators of affected hardware are fixing the security hole themselves. What is the performance penalty? That depends on the fix implemented and is hard to test. If my relatively ignorant butt were to fix it I would just shut down SMT which could have a performance penalty of up to 50% depending on the workload. But some system administrators (or their bosses) aren't much better.

Both Downfall and SQUIP are side channel attacks that aren't much of a threat for the typical home user. More of a threat for businesses or gov agencies that work on shared servers.

All chips have some security flaws. It would be nice if AMD were as quick to patch them as Intel is.

And it does suck that mitigations generally come with performance penalties.

Not all comments that critics Intel are pro AMD, your reply instead...

 

[NinoPino]

As I said in the comments of the last article about Downfall, those benchmarks (which I linked at the time) don't cover CPUs without AVX-512. So, we don't know what's the impact on just AVX2.

It is a preliminary round of tests. I bet Michael will do very soon the usual comprehensive series of tests.
I'm also curious for dbms, compilation, rendering and so on.

 

[bit_user]

It is a preliminary round of tests. I bet Michael will do very soon the usual comprehensive series of tests.
I'm also curious for dbms, compilation, rendering and so on.

Rendering is already pretty well-covered: Embree, OSPRay, and OpenVKL. I don't know if Blender uses much AVX-512 for CPU rendering, but my guess is probably not, given that he didn't include it. Even if it does, it shouldn't be worse affected than the others.

The other classes of programs you mentioned should be largely unaffected. I mean, given that simdjson wasn't even measurably affected should tell you something - specifically, that even heavy users of AVX-512 aren't hampered if they don't use gather instructions.

 

[ikjadoon]

And how long has the patch been out?
They don't report a vulnerability as soon as it has been discovered unless it is being exploited. They give the affected companies some time to mitigate it.
Apparently they were waiting for the BlackHat USA conference on August 9 and USENIX Security Symposium on August 11 to announce it after giving Intel some time to patch it. With SQUIP, AMD was notified in late 2021 and it was published 8/9/22 during the time Black Hat USA 2022 was going on.

So now it's "some time to mitigate it". I agree: the only question, and a legitimate one, is why the patch took one year. We don't know. Intel can answer that, not us.

It was reported in August 2022. Intel's patches are just rolling out in August 2023. It took a year.

Mitigation timelines aren't related to conferences or symposiums: Intel actually, genuinely, seriously took one year from the report to roll out the patch. It is more likely Intel has had a long communique with the security researcher (Intel is not Apple) and they long ago confirmed the end of the embargo date.

When the embargo date was privately confirmed to the researcher, they likely decided, "OK, I can present my findings."

Your first reply here was nonsense.

//

Agreed with what as @NinoPino noted: simply stating a concern about Intel doesn't mean AMD somehow has the right answer. This isn't a zero-sum game. Many times, both Intel and AMD are play corporate games: they aren't interested in the end-user, but the shareholder. But, we digress.

 

[TJ Hooker]

shut down SMT which could have a performance penalty of up to 50%

That would mean SMT was increasing performance by 100%, and I have never seen anything to suggest that level of performance benefit. I thought it was more like 30%?

 

[Amdlova]

At this rate we will be forced to use an abacus.
Need get rid of the smt and put more E cores...

E cores wars...

 

[AgentBirdnest]

At this rate we will be forced to use an abacus.

Not so fast - someone could have loaded those abacus beads full of explosive powder.

 

[rluker5]

That would mean SMT was increasing performance by 100%, and I have never seen anything to suggest that level of performance benefit. I thought it was more like 30%?

You conveniently left out my "depending on the workload" from your quote. Just like Intel doesn't have a 39% penalty in all workloads AMD doesn't for this. The average for both is clearly less, I just copied the language used in this article for framing the problem.

 

[mac_angel]

I hope they make this patch optional. I really doubt these 'bugs' affect most people, especially those that don't want to give up that kind of performance.

 

[rluker5]

So now it's "some time to mitigate it". I agree: the only question, and a legitimate one, is why the patch took one year. We don't know. Intel can answer that, not us.

It was reported in August 2022. Intel's patches are just rolling out in August 2023. It took a year.

Mitigation timelines aren't related to conferences or symposiums: Intel actually, genuinely, seriously took one year from the report to roll out the patch. It is more likely Intel has had a long communique with the security researcher (Intel is not Apple) and they long ago confirmed the end of the embargo date.

When the embargo date was privately confirmed to the researcher, they likely decided, "OK, I can present my findings."

Your first reply here was nonsense.

//

Agreed with what as @NinoPino noted: simply stating a concern about Intel doesn't mean AMD somehow has the right answer. This isn't a zero-sum game. Many times, both Intel and AMD are play corporate games: they aren't interested in the end-user, but the shareholder. But, we digress.

So did anyone else outside the researchers and Intel know of this specialized lab exploit before it was mitigated? Yes they should have fixed it faster, or even right away. Better yet Intel should have been perfect and had no exploits to begin with.
But I also care about the security of servers I don't own, but that may have my sensitive data on as well. Many of these are likely using zen based CPUs.
The difference between having a secret exploit that gets revealed at the same time as a fix, and having a secret exploit revealed and then not bothering to fix it is huge.
The latter bothers me much more from a data security standpoint.

 

[TJ Hooker]

You conveniently left out my "depending on the workload" from your quote. Just like Intel doesn't have a 39% penalty in all workloads AMD doesn't for this. The average for both is clearly less, I just copied the language used in this article for framing the problem.

I wasn't talking about averages either, I meant that there is no workload that would suffer a 50% performance drop from disabling SMT.

Edit: Anandtech found a best case difference of +78% performance for one of their benchmarks with Zen 3, which is a lot higher than I was expecting to be honest (although naturally the average is much lower). So in that case, disabling SMT would be a 44% performance reduction, which is admittedly getting pretty close to 50%.

Investigating Performance of Multi-Threading on Zen 3 and AMD Ryzen 5000

www.anandtech.com

 

[Matt_ogu812]

Downfall affects Intel mainstream and server processors, spanning from the Skylake to the Rocket Lake microarchitecture. Therefore, you're likely affected unless you own one of Intel's more recent processors, such as Alder Lake, Raptor Lake, or Sapphire Rapids. Intel has put up an extensive list of all the affected chips.

This is a great way to improve revenue is it not?
Upgrade less you risk a 'Downfall' of your system.
M$ did the same with exploits vurnability if you didn't upgrade your OS to the latest and greatest.

 

[bit_user]

This is a great way to improve revenue is it not?
Upgrade less you risk a 'Downfall' of your system.

Yeah, it's long been said about mitigations that they make new products look better, simply by making old ones perform worse. Greatest innovation in the "upgrade treadmill", ever!
: D

That's different than saying any of these vulnerabilities was intentional, but they do carry a certain degree of positive benefit, if they're only found in obsolete products.

 

[rluker5]

I wasn't talking about averages either, I meant that there is no workload that would suffer a 50% performance drop from disabling SMT.

Edit: Anandtech found a best case difference of +78% performance for one of their benchmarks with Zen 3, which is a lot higher than I was expecting to be honest (although naturally the average is much lower). So in that case, disabling SMT would be a 44% performance reduction, which is admittedly getting pretty close to 50%.

Investigating Performance of Multi-Threading on Zen 3 and AMD Ryzen 5000

www.anandtech.com

Ok you got me. I was wrong in my off the cuff estimation on the effectiveness of SMT. Wrong.

 

[Matt_ogu812]

Ok you got me. I was wrong in my off the cuff estimation on the effectiveness of SMT. Wrong.

Not to worry you still have R.H.I.P. (Rank Has Its Privileges) among your admirers here.