Personal computing discussed

Moderators: Flying Fox, morphine

 
cfOH
Gerbil In Training
Topic Author
Posts: 1
Joined: Thu Mar 13, 2014 10:22 am

How long a wait for Spectre/Meltdown-proof CPUs?

Sun Jan 14, 2018 11:16 pm

How long do we think consumers will need to wait before CPUs designed to avoid the Spectre and Meltdown bugs (i.e., are safe without after-the-fact patches) come to market? 12 months? 18? Longer?
 
The Egg
Gold subscriber
Minister of Gerbil Affairs
Posts: 2334
Joined: Sun Apr 06, 2008 4:46 pm

Re: How long a wait for Spectre/Meltdown-proof CPUs?

Sun Jan 14, 2018 11:31 pm

Just making an educated guess with no real info, I would say no earlier than Ice Lake, and that’s only if they got to work immediately back when the issue was discovered in mid-17. Ice Lake should be released late-2018 to early-2019........unless they DIDN’T get to work immediately, and the chip is delayed for that reason.

Whatever chip is released following Ice Lake will almost certainly include a fix. It’ll be interesting to see what happens with Cannon Lake, if it’s even released at all.
 
Ari Atari
Gold subscriber
Gerbil First Class
Posts: 141
Joined: Wed Jan 26, 2011 3:00 pm
Location: Earth

Re: How long a wait for Spectre/Meltdown-proof CPUs?

Sun Jan 14, 2018 11:41 pm

I get the feeling that it's the same for any computer part: wait until you need to buy it or like a month after it comes out. Whatever it is, there's not much you can really do about it anyway. It's not like you can change the silicon or engineer new things faster, so just install the patches when you get them (or IF, I guess).
 
just brew it!
Gold subscriber
Administrator
Posts: 51192
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: How long a wait for Spectre/Meltdown-proof CPUs?

Sun Jan 14, 2018 11:43 pm

The sorts of optimizations which led to these vulnerabilities are still useful to maximize performance; the key is to disable them in the specific situations where side channel information leakage can occur. I don't think we will see future CPUs going to designs which are inherently 100% impervious to these kinds of attacks.

What we will likely see are CPUs which provide additional features which allow OS and application software to block side channel attacks with minimal impact on performance. But it is still going to be a cooperative thing between the CPU and the software.

Disabling speculative execution across the board would result in a pretty big performance hit...
Nostalgia isn't what it used to be.
 
the
Gerbil Elite
Posts: 917
Joined: Tue Jun 29, 2010 2:26 am

Re: How long a wait for Spectre/Meltdown-proof CPUs?

Wed Jan 17, 2018 11:52 am

I strongly suspect that Intel will fix Meltdown for Cascade Lake due at the end of the year. The meltdown patches are handing AMD a golden opportunity in the server market as they close the performance gap in some scenarios where Intel was previously on top. Combined with lower pricing and higher memory support (at least without a high memory SKU), AMD is looking far more attractive at the moment. Getting a new Cascade Lake stepping primed should be Intel's priority in the server market right now while pushing for IT managers to wait on new purchase until a revised Cascade Lake is ready.

Ice Lake will almost certainly have the meltdown fix as that is currently eyeing a 2019 release date anyway.

The real question is when Spectre will be patched in hardware. Fixing this completely without impacting performance is going to be difficult.
Dual Opteron 6376, 96 GB DDR3, Asus KGPE-D16, GTX 970
Mac Pro Dual Xeon E5645, 48 GB DDR3, GTX 770
Core i7 3930K@4.2 Ghz, 32 GB DDR3, GA-X79-UP5-Wifi
Core i7 2600K@4.4 Ghz, 16 GB DDR3, GTX 970, GA-X68XP-UD4
 
DrDominodog51
Gerbil Elite
Posts: 694
Joined: Sat Jan 17, 2015 12:23 pm
Location: Silicon Valley

Re: How long a wait for Spectre/Meltdown-proof CPUs?

Wed Jan 17, 2018 1:01 pm

https://www.realworldtech.com/forum/?th ... tid=174129

tl:dr: Meltdown can likely be fixed in a new stepping, but Spectre will take longer to fix.
"Look real close cause strobe lights lie" -Anonymous
 
Glorious
Gold subscriber
Grand Admiral Gerbil
Posts: 10900
Joined: Tue Aug 27, 2002 6:35 pm

Re: How long a wait for Spectre/Meltdown-proof CPUs?

Wed Jan 17, 2018 1:32 pm

DrDominodog51 wrote:
tl:dr: Meltdown can likely be fixed in a new stepping, but Spectre will take longer to fix.


Look, the next one (Ice lake?) is past the design phase at this point. We're definitely not going to be seeing this in any stepping for a current product, and we might not even be seeing it in the next one.

I'm not saying it's a massive change, but it's change in an area critical for performance. It's just the "put a gate here, bruv, and we're all good, I mean DURR so simples", no, these things are taped-out a -MINIMUM- of a YEAR before they're even sold. Intel isn't going to rush out a new stepping in the next 6-9 months that completely defies their current development & validation process, because if they screw it up, they have a bigger disaster on their hands. The current chips, while vulnerable, still work normally.

I mean, don't forget, Intel is putting out massive press releases about how they've already released updates that make their chips "immune":

https://newsroom.intel.com/news-release ... -exploits/

Intel wrote:
Intel has developed and is rapidly issuing updates for all types of Intel-based computer systems — including personal computers and servers — that render those systems immune from both exploits (referred to as “Spectre” and “Meltdown”) reported by Google Project Zero.


That kind of response shouldn't make you think that they are going to significantly disrupt their product pipeline.
 
K-L-Waster
Gerbil Team Leader
Posts: 258
Joined: Thu Feb 12, 2015 8:10 pm

Re: How long a wait for Spectre/Meltdown-proof CPUs?

Wed Jan 17, 2018 1:41 pm

Keep in mind this is effectively a new avenue of exploits. Even if chips are released that are immune to Meltdown and the known Spectre variants, you can bet there's going to be armies of hackers looking for more variants on these.

I wouldn't bet the farm on these vulnerabilities being the only one in the speculative execution arena. There are probably others that haven't been identified yet.
Main System: i7-8700K, ASUS ROG STRIX Z370-E, 16 GB DDR4 3200 RAM, MSI GTX 1080 TI, 1 TB CRUCIAL MX500, Corsair 550D

HTPC: I5-4460, ASUS H97M-E, 8 GB RAM, GTX 970, CRUCIAL 256GB MX100, SILVERSTONE GD09B
 
Glorious
Gold subscriber
Grand Admiral Gerbil
Posts: 10900
Joined: Tue Aug 27, 2002 6:35 pm

Re: How long a wait for Spectre/Meltdown-proof CPUs?

Wed Jan 17, 2018 2:27 pm

Having quickly skimmed the post, eh, like, I'm not exactly sure this guy really knows what he talking about:

https://www.moesif.com/blog/technical/c ... -Meltdown/

article wrote:
Let’s say there is an instruction that enable loads to hit and consumed even in presence of faults, or I am wrong on the above catch, why is it happening now rather than discovered decades ago.

1. Today’s CPUs have much deeper pipelines cough Prescott cough which provides a wider window between the speculative memory access and the actual nuke/squash of those faulting accesses. Faulting instructions are not handled until the instruction is up for retirement/committal to processor architectural state. Only at retirement is the pipeline nuked. Long pipelines allow for a large window between the execution of the faulting instruction and the retirement of it allowing other speculative instructions to race ahead.


Um.

Prescott was designed 15 years ago, sooo, uhhhh....

article wrote:
2. Larger cache hierarchy and slower memory fabric speed relative to fast CPU only ops such as cache hit/integer ops which provides a much larger time difference in cycles between a cache hit and a cache miss/memory to enable more robust cache timing attacks. Today’s large multi-core server CPUs with elaborate mesh fabrics to connect tens or hundreds of cores exaggerates this.


Uhhhh... the whitepaper (which this guys claims to have read) demonstrated this on two-core celerons. The most cores they listed in any demonstrated machine numbered but 12, and those were the cloud-provided ones: even the cheapest tier of a VPS I've had for like three (maybe four?) years is still a 6 core Ivy EP. Like, they weren't even looking for a bunch of cores, that's just what their likely newer-deployed instance (haswell/broadwell) had underneath it.

So what does this "tens to hundreds" of cores have to do with this? I mean, what?

article wrote:
Addition of performance enhancing features for fine granularity cache control such as the x86 CLFLUSH and PREFETx give more control for cache timing attacks.


CLFLUSH is Williamette. Which was designed two decades ago.

PREFETx goes back to the Pentium 3 and earlier, so you're talking 2 Decades PLUS.

article wrote:
Wider issue processors that enable parallel integer, floating, and memory ops simultaneously. One could place long floating point operations such as divide or sqrt right before the faulting instruction to keep the core busy, but still keeping the integer and memory pipelines free for the attack. Since the faulting instruction will not nuke the pipeline until retirement, it has to wait until any earlier instructions in the instruction sequence to be committed including long running floating point ops.


I don't think there has been a serious improvement in multi-issue since the core 2.

article wrote:
Virtualization and PaaS. Many web scale companies are now running workloads cloud providers like AWS and Azure. Before cloud, Fortune 500 companies would run their own trusted applications on their own hardware. Thus, applications from different companies were physically separated, unlike today. While it is unknown if Meltdown can allow a guest OS to break into the hypervisor or host OS, what is known is that many virtualization techniques are more lightweight than full blown VT-x. For example, multiple apps in Heroku, AWS Beanstalk, or Azure Web apps along with Docker containers are running within the same VM. Companies no longer spin up a separate VM for each application. This could allow a rogue application to read kernel memory of the specific VM. Shares resources were not a thing in the 90’s when OoO execution became mainstream with the Pentium Pro/Pentium III.


Uh, no one says that meltdown allows someone to break into the hyperviser/host. It's read-only. That might indirectly lead you into information you could use to do things, but uhh...

I mean, this guy claims to have read the paper, and he's just ...wrong before we get back to how they have way more "lab" demonstrators than "cloud"... :roll:

article wrote:
The use of the Global and User/Supervisor bits in x86 paging entries which enables the kernel memory space to be mapped into every user process (but protected from Ring3 code execution) to reduce pressure on TLBs and slow context switching to a separate kernel process. This performance optimization has been done since the 1990’s.


In other words, since we've, you know, HAD protected virtual memory and so forth. :o


----

I mean, the whole piece is rife with self-contradiction and misrepresentation....
 
just brew it!
Gold subscriber
Administrator
Posts: 51192
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: How long a wait for Spectre/Meltdown-proof CPUs?

Wed Jan 17, 2018 11:08 pm

@Glorious - I think you're being a little harsh there. You're interpreting things in the worst possible way.

If I may play devil's advocate here:

Glorious wrote:
article wrote:
Let’s say there is an instruction that enable loads to hit and consumed even in presence of faults, or I am wrong on the above catch, why is it happening now rather than discovered decades ago.

1. Today’s CPUs have much deeper pipelines cough Prescott cough which provides a wider window between the speculative memory access and the actual nuke/squash of those faulting accesses. Faulting instructions are not handled until the instruction is up for retirement/committal to processor architectural state. Only at retirement is the pipeline nuked. Long pipelines allow for a large window between the execution of the faulting instruction and the retirement of it allowing other speculative instructions to race ahead.

Um.

Prescott was designed 15 years ago, sooo, uhhhh....

So? He's just citing the most egregious example of long pipelines, at 31 stages. More recent Intel designs are in the 14-20 range. AMD's Bulldozer was 20, Ryzen is 19. Still plenty long. His point is that all high performance CPU designs over the past couple of decades have had deep pipelines.

Glorious wrote:
article wrote:
2. Larger cache hierarchy and slower memory fabric speed relative to fast CPU only ops such as cache hit/integer ops which provides a much larger time difference in cycles between a cache hit and a cache miss/memory to enable more robust cache timing attacks. Today’s large multi-core server CPUs with elaborate mesh fabrics to connect tens or hundreds of cores exaggerates this.

Uhhhh... the whitepaper (which this guys claims to have read) demonstrated this on two-core celerons. The most cores they listed in any demonstrated machine numbered but 12, and those were the cloud-provided ones: even the cheapest tier of a VPS I've had for like three (maybe four?) years is still a 6 core Ivy EP. Like, they weren't even looking for a bunch of cores, that's just what their likely newer-deployed instance (haswell/broadwell) had underneath it.

Again, so? The point is that cache hit vs. miss results in a measurable difference in execution time which can result in side channel information leakage. Yes, large multi-socket systems will exaggerate this, and that's what he's trying to point out; nowhere does he say that it isn't an issue on single-socket systems.

Glorious wrote:
So what does this "tens to hundreds" of cores have to do with this? I mean, what?

The problem will be even worse on many-cores systems, because the timing differences will be even more obvious and easier to exploit.

Glorious wrote:
article wrote:
Addition of performance enhancing features for fine granularity cache control such as the x86 CLFLUSH and PREFETx give more control for cache timing attacks.


CLFLUSH is Williamette. Which was designed two decades ago.

PREFETx goes back to the Pentium 3 and earlier, so you're talking 2 Decades PLUS.

...and side channel leakage attacks have probably been theoretically possible for about that long too. It's just that nobody has demonstrated a working prototype until now.

Glorious wrote:
article wrote:
Wider issue processors that enable parallel integer, floating, and memory ops simultaneously. One could place long floating point operations such as divide or sqrt right before the faulting instruction to keep the core busy, but still keeping the integer and memory pipelines free for the attack. Since the faulting instruction will not nuke the pipeline until retirement, it has to wait until any earlier instructions in the instruction sequence to be committed including long running floating point ops.


I don't think there has been a serious improvement in multi-issue since the core 2.

Again, this is broadly consistent with the timeframe in which these types of timing attacks are now believed (in hindsight) to have been possible.

Glorious wrote:
article wrote:
Virtualization and PaaS. Many web scale companies are now running workloads cloud providers like AWS and Azure. Before cloud, Fortune 500 companies would run their own trusted applications on their own hardware. Thus, applications from different companies were physically separated, unlike today. While it is unknown if Meltdown can allow a guest OS to break into the hypervisor or host OS, what is known is that many virtualization techniques are more lightweight than full blown VT-x. For example, multiple apps in Heroku, AWS Beanstalk, or Azure Web apps along with Docker containers are running within the same VM. Companies no longer spin up a separate VM for each application. This could allow a rogue application to read kernel memory of the specific VM. Shares resources were not a thing in the 90’s when OoO execution became mainstream with the Pentium Pro/Pentium III.

Uh, no one says that meltdown allows someone to break into the hyperviser/host. It's read-only. That might indirectly lead you into information you could use to do things, but uhh...

He didn't say it does. He said it is unknown if it can. Which is a true statement. Factor in the possibility that it could be used in combination with some other vulnerability (Rowhammer, perhaps?), and I'd say that statement is a pretty good hedge.

Glorious wrote:
I mean, this guy claims to have read the paper, and he's just ...wrong before we get back to how they have way more "lab" demonstrators than "cloud"... :roll:

I think mostly he's just using a different definition of "today's CPUs" than you are. He defines "today's CPUs" as anything with a deep-ish pipeline, speculative execution, multiple privilege levels, and a cache. Which does indeed encompass pretty much any high performance CPU made in the past 2 decades.

Glorious wrote:
article wrote:
The use of the Global and User/Supervisor bits in x86 paging entries which enables the kernel memory space to be mapped into every user process (but protected from Ring3 code execution) to reduce pressure on TLBs and slow context switching to a separate kernel process. This performance optimization has been done since the 1990’s.


In other words, since we've, you know, HAD protected virtual memory and so forth. :o

See above.

Glorious wrote:
I mean, the whole piece is rife with self-contradiction and misrepresentation....

I guess I'm just not seeing that.

He's using a broader definition of what qualifies as a "modern" CPU (and one that is more consistent with how long these types of attacks have been theoretically exploitable, in hindsight). He's also pointing out some worst-case scenarios, as opposed to what would be considered the most common/likely scenarios. I don't see that as self-contradictory. At worst, it's perhaps a tad alarmist.

But if someone had told me a couple of years ago that measuring the timing of register loads from memory, to deduce what happened in code that was speculatively executed (with all directly visible results thrown away), and use this info to leak encryption keys and other sensitive data, I would've considered them to be alarmist, if not outright loony. And look where we are today.

***

I'll grant you that the author's writing style may not be the best. This is not too unusual for engineers. I don't think his intent was to mislead, or to misrepresent anything; and the info presented is essentially correct.
Nostalgia isn't what it used to be.
 
Redocbew
Gold subscriber
Gerbil Jedi
Posts: 1599
Joined: Sat Mar 15, 2014 11:44 am

Re: How long a wait for Spectre/Meltdown-proof CPUs?

Wed Jan 17, 2018 11:48 pm

I'm still a bit surprised that such a complicated timing attack is possible within an interpreted language like javascript. I would have thought that was the domain of low level C code, or something similar, and that trying to write the same thing in a higher level language would be infeasible because of all the extra stuff inbetween the code its self and the hardware, but apparently that's not the case.
Do not meddle in the affairs of archers, for they are subtle and you won't hear them coming.
 
just brew it!
Gold subscriber
Administrator
Posts: 51192
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: How long a wait for Spectre/Meltdown-proof CPUs?

Wed Jan 17, 2018 11:58 pm

Redocbew wrote:
I'm still a bit surprised that such a complicated timing attack is possible within an interpreted language like javascript. I would have thought that was the domain of low level C code, or something similar, and that trying to write the same thing in a higher level language would be infeasible because of all the extra stuff inbetween the code its self and the hardware, but apparently that's not the case.

Based on what I've read, the JavaScript version of the Spectre attack exploits the newer JIT JavaScript engines used in recent browsers. The JavaScript gets compiled to machine code on the fly, inside the browser. That's the bad news.

The good news is that this particular attack vector can be mitigated by improving the JavaScript JIT compilers to spot the types of code sequences that trigger the side channel leakage, and emit alternative code that isn't vulnerable. The alternative code will be slightly less optimal from a performance standpoint, but if this is done intelligently (i.e. only when needed), the penalty shouldn't be too bad.

The upcoming Chrome version 64 is supposed to include this, from what I understand.
Nostalgia isn't what it used to be.
 
Glorious
Gold subscriber
Grand Admiral Gerbil
Posts: 10900
Joined: Tue Aug 27, 2002 6:35 pm

Re: How long a wait for Spectre/Meltdown-proof CPUs?

Thu Jan 18, 2018 8:11 am

JBI wrote:
I think you're being a little harsh there. You're interpreting things in the worst possible way.


What? Me, harsh? Liable to fly off the handle at the slightest (perceived) provocation?

Noooo, that's so uncharacteristic of me. :lol:

---

I mean, you are totally right and I accept the criticism 100%: I am responding to what is a matter of tone, presentation and composition, not the thrust of the tl;dr: version of his argument.

In fact, I never disputed that, in the previous post I conceded the basic point but was arguing it was reductionist in terms of the overall effort it takes to produce a CPU after the design-phase. But that wasn't even what got me to throw my hands up.

That was when he said "Let’s say there is an instruction that enable loads to hit and consumed even in presence of faults, or I am wrong on the above catch, why is it happening now rather than discovered decades ago." and then preceded to bullet-point a bunch of things that were decades old.

Heck, before that I was already primed to start sharpening the knives:

article wrote:
Is the attack believable?


At best that's impolitely inept. Yes, in a more charitable light it's a rhetorical device tending towards explanation, but come on, someone needs to talk to that guy. Having someone, however loosely, associated with Intel appear to call the legitimacy of all this into question is very not good.

And there are other things where he is very imprecise where precision matters, saying architectural when in context he's wrong unless he actually meant micro-architectural. I mean, I think that's what he meant, sure, but since so much of this hinges on the distinction between the two it is hard to excuse.

And this bit really didn't help:

article wrote:
One thing is for certain, caching and speculation are not going away anytime soon. If it is a logic bug, it may be a simple fix for future Intel CPUs.


article wrote:
This isn’t an Intel specific problem or a x86 problem but rather a fundamental problem in general CPU architecture


That's uhh... OK?

I mean, "Intel Bug" and "fundamental and universal" are incongruent, to say the least.

---

So, in summary, yes I'm being harsh. I don't disagree with the simplified assertion, and I don't actually think he's deliberately trying to be deceitful or anything close to it. He just, uh, needs to work with someone about how to structure his thoughts, or something.

And, in my defense, I've been reading so much cryptocurrency stuff where the inconsistency & ambiguity *IS* intentional that I was unfortunately pre-disposed to think the worst of someone who is only really guilty of having a very poorly structured train of thought.

Who is online

Users browsing this forum: No registered users and 2 guests