Massive security hole in CPU's incoming?Official Meltdown/Spectre Discussion Thread

Page 84 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

naukkis

Senior member
Jun 5, 2002
782
637
136
Intel and AMD are looking to increase performance by looking at everything there is to improve upon in their architectures. How does non-standard use of a prefix on an operation that has been enhanced to give better performance with short strings equate to sloppy ISA extension?
Well-defined ISA doesn't allow non-standard use of prefixes. It's plain stupidity to chase performance by compromising ISA.
 

tamz_msc

Diamond Member
Jan 5, 2017
3,865
3,729
136
Well-defined ISA doesn't allow non-standard use of prefixes. It's plain stupidity to chase performance by compromising ISA.
Well unlike RISC-V, x86 ISA didn't evolve to its current state through an independent body overseeing the implementation and extension of the ISA.
 

naukkis

Senior member
Jun 5, 2002
782
637
136
Well unlike RISC-V, x86 ISA didn't evolve to its current state through an independent body overseeing the implementation and extension of the ISA.

It's not a valid point. They can have legacy support but still define new extensions to have unambiguous coding. Bugs like that are avoidable - Intel just did a lousy job. And when there is one such a bug there sure is plenty more coming.
 

moinmoin

Diamond Member
Jun 1, 2017
4,996
7,776
136
How does non-standard use of a prefix on an operation that has been enhanced to give better performance with short strings equate to sloppy ISA extension?
Is that even a question? This bug causes the CPU to go into an impossible state that shouldn't ever exist! So at some point somewhere the whole design broke apart and didn't behave as designed, because some part wasn't covered. And if that's not sloppy to you, please tell me what you consider sloppy.
 

tamz_msc

Diamond Member
Jan 5, 2017
3,865
3,729
136
It's not a valid point. They can have legacy support but still define new extensions to have unambiguous coding. Bugs like that are avoidable - Intel just did a lousy job. And when there is one such a bug there sure is plenty more coming.
Where does "legacy support" figure here? The bug is due to an unexpected behaviour with FSRM at the micro-op level. To trigger it in a way that could pose a security risk, you'll need to have access to an insider at Intel with knowledge of how the micro-ops work.
 

tamz_msc

Diamond Member
Jan 5, 2017
3,865
3,729
136
Is that even a question? This bug causes the CPU to go into an impossible state that shouldn't ever exist! So at some point somewhere the whole design broke apart and didn't behave as designed, because some part wasn't covered. And if that's not sloppy to you, please tell me what you consider sloppy.
Read the blog post again - the CPU can recover from such states on its own.

You want sloppy? How about this? It took Intel to find out that one of AMD's fixes for Spectre didn't actually work for four years.
 

moinmoin

Diamond Member
Jun 1, 2017
4,996
7,776
136
the CPU can recover from such states on its own.
That's great, and what does it do as long it didn't recover yet? And what about the DoSing possible by putting multiple cores/SMT threads into that state and causing machine check exceptions?
 
  • Like
Reactions: Markfw
Jul 27, 2020
18,231
11,949
116
You want sloppy? How about this? It took Intel to find out that one of AMD's fixes for Spectre didn't actually work for four years.
AMD can be excused coz they were busy kicking Intel's butt during those four years. Thanks Intel, for doing AMD's job FOR them. Time and money well spent, for a change! Now back to making chips, Intel! You owe an 8-core Gracemont i3-N305 to every Skylake and later CPU owner to make up for the sloppy Swiss Cheese CPU design that got slower and slower over the years due to the mitigation patches.
 
  • Like
Reactions: Markfw

tamz_msc

Diamond Member
Jan 5, 2017
3,865
3,729
136
AMD can be excused coz they were busy kicking Intel's butt during those four years. Thanks Intel, for doing AMD's job FOR them. Time and money well spent, for a change! Now back to making chips, Intel! You owe an 8-core Gracemont i3-N305 to every Skylake and later CPU owner to make up for the sloppy Swiss Cheese CPU design that got slower and slower over the years due to the mitigation patches.
Skylake isn't affected by the way with Reptar.
 

tamz_msc

Diamond Member
Jan 5, 2017
3,865
3,729
136
That's great, and what does it do as long it didn't recover yet? And what about the DoSing possible by putting multiple cores/SMT threads into that state and causing machine check exceptions?
To do that you'll need inside knowledge of how the Intel micro-ops are decoded. Unless you kidnap an Intel engineer with knowledge of such things and tell him at gunpoint to spill the beans, nothing is going to happen.
 

naukkis

Senior member
Jun 5, 2002
782
637
136
To do that you'll need inside knowledge of how the Intel micro-ops are decoded. Unless you kidnap an Intel engineer with knowledge of such things and tell him at gunpoint to spill the beans, nothing is going to happen.

Are you kidding? CPU goes to unstable state - corrupting data unknown ways. Using that corruption state to actually steal privileged data is the hard part but for data integrity going into non-working state is much bigger problem.
 

tamz_msc

Diamond Member
Jan 5, 2017
3,865
3,729
136
Are you kidding? CPU goes to unstable state - corrupting data unknown ways. Using that corruption state to actually steal privileged data is the hard part but for data integrity going into non-working state is much bigger problem.
So do MCEs never occur in VMs in the cloud? Don't all cloud providers have redundancy built-in? Doesn't there exist something called Live Migration?
 

naukkis

Senior member
Jun 5, 2002
782
637
136
So do MCEs never occur in VMs in the cloud? Don't all cloud providers have redundancy built-in? Doesn't there exist something called Live Migration?

Yes, that what ISA should do - give MCE when error occurs. That's not the case with that bug - cpu continues execution without notification leading possible undetected data corruption. That's the worst kind of cpu malfunctioning - actually we don't know yet if that bug can be used to modify other privileges data too. That's possible case with such kind of unexpected cpu behaviour.
 
Jul 27, 2020
18,231
11,949
116
CPUID Family_Model​
Stepping​
Code Name(s) / Microarchitecture(s)​
CPUID​
Post-barrier Return Stack Buffer Predictions - CVE-2022-26373 - INTEL-SA-00706​
Stale Data Read from Legacy xAPIC - CVE-2022-21233 CVE-2022-38090 - INTEL-SA-00657 -Intel-SA-00767​
06_AAH​
1​
Meteor Lake (Redwood - Cresmont)​
A06A4​
Not affected
Not affected
06_CFH​
2​
Emerald Rapids​
B06E0​
Software​
Hardware+Software​

They fixed at least two vulnerabilities in Redwood Cove.

Nine more to go. Maybe by 2030? :D
 

Nothingness

Platinum Member
Jul 3, 2013
2,810
1,501
136
Is there any site that tracks the performance impact of these microcode updates? I know Phoronix does from time to time, but it's not systematic.

I can understand review sites do their job as fast as possible on CPU release, but the thing is that what was true at some point in time isn't relevant anymore because of bug and security issues fixes. It looks like we only get reviews when the impact is severe enough to be noticed by everyone (e.g., the Bulldozer TLB bug). But the small slowdowns accumulate and after one or two years, this might change ranking on some apps.
 
Jul 27, 2020
18,231
11,949
116
Is there any site that tracks the performance impact of these microcode updates? I know Phoronix does from time to time, but it's not systematic.
One way would be to check, for example, 7950X scores at launch (from AT review) and the ones we will see in their hopefully upcoming 9950X review. There might not be many benchmarks to compare though coz I noticed that they don't keep their benchmark suite consistent between reviews (removing some tests and adding new ones).
 
  • Like
Reactions: Nothingness