Thursday, August 30th 2018

Intel Explains Key Difference Between "Coffee Lake" and "Whiskey Lake"

Intel "Whiskey Lake" CPU microarchitecture recently made its debut with "Whiskey Lake-U," an SoC designed for Ultrabooks and 2-in-1 laptops. Since it's the 4th refinement of Intel's 2015 "Skylake" architecture, we wondered what set a "Whiskey Lake" core apart from "Coffee Lake." Silicon fabrication node seemed like the first place to start, with rumors of a "14 nm+++" node for this architecture, which should help it feed up to 8 cores better in a compact LGA115x MSDT environment. Turns out, the process hasn't changed, and that "Whiskey Lake" is being built on the same 14 nm++ node as "Coffee Lake."

In a statement to AnandTech, Intel explained that the key difference between "Whiskey Lake" and "Coffee Lake" is silicon-level hardening against "Meltdown" variants 3 and 5. This isn't just a software-level mitigation part of the microcode, but a hardware fix that reduces the performance impact of the mitigation, compared to a software fix implemented via patched microcode. "Cascade Lake" will pack the most important hardware-level fixes, including "Spectre" variant 2 (aka branch target injection). Software-level fixes reduce performance by 3-10 percent, but a hardware-level fix is expected to impact performance "a lot less."
Source: AnandTech
Add your own comment

32 Comments on Intel Explains Key Difference Between "Coffee Lake" and "Whiskey Lake"

#1
Smartcom5
Am I the only one having a hard time believing that those changes which allegedly were made are ones on the very silicon-level instead of just ordinary updates on µCode-level? I mean, I'm fine with fixes on Meltdown anyway though it seems highly unlikely that they already fixed even L1TF aka Foreshadow this fast, given the little time and all the time-consuming processes which are involved.

In addition, it's rather unlikely that they would risk to postpone something (which they actually risk to do in such a case) by fabbing a completely new mask (which always includes the risk that something goes wrong), given the competitive market-situation at the moment. So a completely or at least comprehensive re-design of the very core? In that time-frame?! Something seems fishy here.

If they actually managed to make a stunt like that (Foreshadow was revealed just in January '18!), they should've must been also able to mitigate (via µCode) or eliminate Meltdown completely and address some parts Spectre by January already in hardware. They didn't neither of both. So either they're lying this time or were lying (and were incredibly lazy) back in January (and half the year before) …
Posted on Reply
#2
dalekdukesboy
Simply put, Coffee lake gives you a caffeine buzz, Whiskey lake makes you puke and pass out.
Posted on Reply
#3
deu
Smartcom5 said:
Am I the only one having a hard time believing that those changes which allegedly were made are ones on the very silicon-level instead of just ordinary updates on µCode-level? I mean, I'm fine with fixes on Meltdown anyway though it seems highly unlikely that they already fixed even L1TF aka Foreshadow this fast, given the little time and all the time-consuming processes which are involved.

In addition, it's rather unlikely that they would risk to postpone something (which they actually risk to do in such a case) by fabbing a completely new mask (which always includes the risk that something goes wrong), given the competitive market-situation at the moment. So a completely or at least comprehensive re-design of the very core? In that time-frame?! Something seems fishy here.

If they actually managed to make a stunt like that (Foreshadow was revealed just in January '18!), they should've must been also able to mitigate (via µCode) or eliminate Meltdown completely and address some parts Spectre by January already in hardware. They didn't neither of both. So either they're lying this time or were lying (and were incredibly lazy) back in January (and half the year before) …
Remember: They knew about these exploits before you did! :0 They might very well have been planing fixes on hardwarelevel way before we knew of the actual breach. Again im guessing, but Intel had every interest in it not getting out to the public before they had a fix (Again only intel knows! :D)
Posted on Reply
#4
R0H1T
Smartcom5 said:
Am I the only one having a hard time believing that those changes which allegedly were made are ones on the very silicon-level instead of just ordinary updates on µCode-level? I mean, I'm fine with fixes on Meltdown anyway though it seems highly unlikely that they already fixed even L1TF aka Foreshadow this fast, given the little time and all the time-consuming processes which are involved.

In addition, it's rather unlikely that they would risk to postpone something (which they actually risk to do in such a case) by fabbing a completely new mask (which always includes the risk that something goes wrong), given the competitive market-situation at the moment. So a completely or at least comprehensive re-design of the very core? In that time-frame?! Something seems fishy here.

If they actually managed to make a stunt like that (Foreshadow was revealed just in January '18!), they should've must been also able to mitigate (via µCode) or eliminate Meltdown completely and address some parts Spectre by January already in hardware. They didn't neither of both. So either they're lying this time or were lying (and were incredibly lazy) back in January (and half the year before) …
My initial assessment of smeltdown wrt Intel is that they know they skimped on security & probably did have a very good idea about these exploits, even if we discount the NSA baked deliberate holes theory. Now the fact that they've fixed holes as recent as L1TF in hardware, seems to support the theory. Which probably means that they skimped on some of the major (security) aspects of their hardware design by choice, perhaps in a race to beat AMD. I mean look at the recent results FFS, it's a slaughterhouse!
https://www.phoronix.com/scan.php?page=article&item=linux-419-mitigations
Posted on Reply
#5
bonehead123
Simply put, they (intel) know that we now know that they knew that we didnt know about this until we knew....

And now that they know that we did in fact know about what they thought we didn't know, they have to come up with some lame explanation to try to explain why, and how they are gonna fix it, and try to make themselves look good in the process....

Bottom line: C.Y.A. all the time, every time, or die tryin :D
Posted on Reply
#6
jaggerwild
How Very boring, seeing AMD people posting in an Intel Thread.
Posted on Reply
#7
First Strike
Smartcom5 said:
Am I the only one having a hard time believing that those changes which allegedly were made are ones on the very silicon-level instead of just ordinary updates on µCode-level? I mean, I'm fine with fixes on Meltdown anyway though it seems highly unlikely that they already fixed even L1TF aka Foreshadow this fast, given the little time and all the time-consuming processes which are involved.

In addition, it's rather unlikely that they would risk to postpone something (which they actually risk to do in such a case) by fabbing a completely new mask (which always includes the risk that something goes wrong), given the competitive market-situation at the moment. So a completely or at least comprehensive re-design of the very core? In that time-frame?! Something seems fishy here.

If they actually managed to make a stunt like that (Foreshadow was revealed just in January '18!), they should've must been also able to mitigate (via µCode) or eliminate Meltdown completely and address some parts Spectre by January already in hardware. They didn't neither of both. So either they're lying this time or were lying (and were incredibly lazy) back in January (and half the year before) …
My guess is that it is related to performance. They can't find a hardware solution that is satisfyingly fast enough (not messing up that much). Baking a slow hardware solution into silicon could permanently make them crippled at single-threaded performance. So they prefer to wait, meanwhile people can choose to (or unawaredly) enjoy "blazingly fast" experience with security holes wide open.
And for vulnerabilities with minor performance impact, they can fix them quite fast.
Posted on Reply
#8
OSdevr
In other words Intel is selling a new stepping as a new microarchitecture.
Posted on Reply
#9
mcraygsx
I suppose we should not expect the usual 1 to 5 % IPC gain this time around.

"When fixed in software, Intel expects a 3-10% drop in performance depending on the workload – when fixed in hardware, Intel says that performance drop is a lot less, but expects new platforms (like Cascade Lake) to offer better overall performance anyway.":eek:
Posted on Reply
#10
hat
Enthusiast
That means it's still vulnerable to some Meltdown variants, and of course Spectre. Even the Cascade Lake will still be vulnerable to Spectre (only protects against variant 2).

Wake me in 10 years when it's over... :shadedshu:
Posted on Reply
#11
First Strike
hat said:
That means it's still vulnerable to some Meltdown variants, and of course Spectre. Even the Cascade Lake will still be vulnerable to Spectre (only protects against variant 2).

Wake me in 10 years when it's over... :shadedshu:
A firmware patch is a patch, as a basic fact.
Posted on Reply
#12
hat
Enthusiast
First Strike said:
A firmware patch is a patch, as a basic fact.
The OP says silicon level hardening.
Posted on Reply
#13
Smartcom5
First Strike said:
A firmware patch is a patch, as a basic fact.
Exactly! Meanwhile, Intel wants us to believe they already have a definite solution to those vulnerabilities in hardware (as @hat already pointed out) – which is highly douptful …
Posted on Reply
#14
efikkan
R0H1T said:
My initial assessment of smeltdown wrt Intel is that they know they skimped on security & probably did have a very good idea about these exploits, even if we discount the NSA baked deliberate holes theory. Now the fact that they've fixed holes as recent as L1TF in hardware, seems to support the theory. Which probably means that they skimped on some of the major (security) aspects of their hardware design by choice, perhaps in a race to beat AMD.
Both of these vulnerabilities are results of logical mistakes in the design process. Your theory is easily disproved by the fact that Spectre affects four different CPU makers, and Meltdown affects three. Some of these mistakes have been present in CPU designs since the 90s.

So why does multiple CPU makers do the same principal mistakes? It doesn't mean they steal from each other, but the following are major factors:
- Engineers think alike - Given similar training and experience, engineers tend to find similar solutions to the same problem. To make matters worse, I would claim ~90% of engineers overestimate their own rationality and wants to be "the smartest guy in the room" by rushing to conclusions, rather than doing the actual research.
- Switching jobs - The semiconductor world is very small (compared to e.g. the software world). Most of the people in Intel's and AMD's CPU teams have worked with one or more competitors in the past. Even though they don't steal IP, they do still bring experience and ideas, both the good and the bad.
- Knowledge sharing - There are conferences, academic research projects, and even voluntary sharing between companies in the industry. If one party shares a flawed idea, others might not challenge that.

These companies have some of the brightest engineers in the world, yet they manage to produce products year after year with the same design flaws. But why didn't anyone of them find these flaws? Chances are several of them either knew about the potential or have seen symptoms of these bugs throughout the development. But the structure of the departments, development teams and management can make it very hard to communicate the right information. Design choices, schedules, etc. are usually decided from the top down, while anyone finding such bugs will be at the very bottom, having to convince every superior about the severity of the flaw. I've experienced this several times first-hand in software development, once at a former employer I found a serious defect in a core library, but other team members dismissed it despite a proof-of-concept, because "the code had been used for years without any 'problems', so the new guy must be mistaken…", this code might still be used in equipment worth $B…
Posted on Reply
#15
hat
Enthusiast
Who knows. Maybe the engineer(s) saw a potential for some fuckery like this, but the big boss, like many of us here on TPU when discussing the flaws, said something like "fuck that, they'll never find it, and even if they do, it'll be ridiculously hard to attack, and we don't have time to redesign everything for such a silly flaw, especially when the fix could hinder performance anyway, just make them".

I don't make semiconductors, instead I work in a plastics plant, but even I see "defects" passed on as good product all the time. These defects are minor defects that nobody would ever find, or give a shit about if they did, but still, it's not "perfect" like it should be. And if you ask the production manager, he'll try to save as much as he possibly can, telling you to pass stuff you've been trained to know is bad.

Two vastly different products, but it's still in the world of manufacturing, where time literally is money. These guys have product to push out the door, so it wouldn't surprise me if someone knew, but thought it wasn't worth fixing, for one or more reasons... but now that it's been brought to light, they can't hide behind "security through obscurity", even if it would be hard to pull off, so now it has to be fixed.

Or maybe it really did slip by them for 20+ years... :p
Posted on Reply
#16
efikkan
hat said:
Who knows. Maybe the engineer(s) saw a potential for some fuckery like this, but the big boss, like many of us here on TPU when discussing the flaws, said something like "fuck that, they'll never find it, and even if they do, it'll be ridiculously hard to attack, and we don't have time to redesign everything for such a silly flaw, especially when the fix could hinder performance anyway, just make them".
Yes, for sure, but it doesn't even have to be the big boss, could just as well be team lead or someone in between. Unfortunately this is a cultural problem in many companies, and it usually doesn't change until there are major incidents, and even then there could be more panic reactions rather than rational solutions. It's actually quite "interesting" to watch from the inside when incidents happen, how things escalate, when different levels of management take action, jumping to conclusions and blaming, what's communicated internally vs. publicly and to clients, etc., it gives an idea of how these things may be playing out at Intel etc.

But it's worth mentioning that Computer Science as a field is much more deceptive than most people realize. The fundamentals are of course completely logical on the lowest level, but human's ability to comprehend it is very limited. In CS it's possible to design and make a completely broken product that looks fine on the surface, to a much larger extent than e.g. building a bridge, a giant ship or a space rocket. And design flaws in CS might be much harder to spot without comprehensive investigation. It shouldn't surprise anyone that when Intel or AMD releases a new CPU, it usually have around 20-30 know defects in their errata. Some of these are mitigated in firmware, and could be really serious security issues, but we usually never get to know. The difference with Spectre and Meltdown is that it was found externally, and that it was present in multiple consecutive CPU designs. This doesn't mean it's even close to the most serious flaws they've shipped in a CPU. And when it comes to software, it's much worse. This comic stripe is pretty spot-on when it comes to describing the state of the field.
Posted on Reply
#17
R0H1T
efikkan said:
Yes, for sure, but it doesn't even have to be the big boss, could just as well be team lead or someone in between. Unfortunately this is a cultural problem in many companies, and it usually doesn't change until there are major incidents, and even then there could be more panic reactions rather than rational solutions. It's actually quite "interesting" to watch from the inside when incidents happen, how things escalate, when different levels of management take action, jumping to conclusions and blaming, what's communicated internally vs. publicly and to clients, etc., it gives an idea of how these things may be playing out at Intel etc.

But it's worth mentioning that Computer Science as a field is much more deceptive than most people realize. The fundamentals are of course completely logical on the lowest level, but human's ability to comprehend it is very limited. In CS it's possible to design and make a completely broken product that looks fine on the surface, to a much larger extent than e.g. building a bridge, a giant ship or a space rocket. And design flaws in CS might be much harder to spot without comprehensive investigation. It shouldn't surprise anyone that when Intel or AMD releases a new CPU, it usually have around 20-30 know defects in their errata. Some of these are mitigated in firmware, and could be really serious security issues, but we usually never get to know. The difference with Spectre and Meltdown is that it was found externally, and that it was present in multiple consecutive CPU designs. This doesn't mean it's even close to the most serious flaws they've shipped in a CPU. And when it comes to software, it's much worse. This comic stripe is pretty spot-on when it comes to describing the state of the field.
I've talked about this at length numerous times. The lead GPZ investigator found smeltdown combing Intel manuals! If that doesn't hint at incompetence, at the very least, or deliberate unpatched hole (NSA?) at worst then you won't be convinced by anything. Btw Spectre is inherent to OoO CPU uarch, however at some point in time Intel decided that privilege checks should take a back seat ~ perhaps in search of performance? Form there, we've seen near double digits flaws that are exclusive to Intel, some of them so dangerous that they haven't been revealed as yet.
Posted on Reply
#18
Vayra86
dalekdukesboy said:
Simply put, Coffee lake gives you a caffeine buzz, Whiskey lake makes you puke and pass out.
Lmao

Whats next, Meth River? "For a complete Fix!"
Posted on Reply
#19
R0H1T
Vayra86 said:
Lmao

Whats next, Meth River? "For a complete Fix!"
Nah, Fentanyl is the new rage, all the rage ~ probably your last rage, ever!
Posted on Reply
#20
efikkan
R0H1T said:
Btw Spectre is inherent to OoO CPU uarch, however at some point in time Intel decided that privilege checks should take a back seat ~ perhaps in search of performance? Form there, we've seen near double digits flaws that are exclusive to Intel, some of them so dangerous that they haven't been revealed as yet.
Not quite, Spectre is due to lack of validation and sanitation in speculative execution, which is a part of OoO. Claiming it's an intentional move to gain extra performance is a stretch, especially if you don't have concrete evidence of that. Doing this properly from the start isn't costly or especially damaging to performance either, but if discovered after a completed design, then doing a proper redesign, calibration and testing of the whole front-end will be costly.
Posted on Reply
#21
R0H1T
efikkan said:
Not quite, Spectre is due to lack of validation and sanitation in speculative execution, which is a part of OoO. Claiming it's an intentional move to gain extra performance is a stretch, especially if you don't have concrete evidence of that. Doing this properly from the start isn't costly or especially damaging to performance either, but if discovered after a completed design, then doing a proper redesign, calibration and testing of the whole front-end will be costly.
I was talking more about meltdown & derivative flaws.

Well there's AMD, in case you forgot?

Yet some of the fixes found early in the year are already fixed in hardware for WHL, how much lead time did you think Intel had for L1TF?
Posted on Reply
#22
dalekdukesboy
Vayra86 said:
Lmao

Whats next, Meth River? "For a complete Fix!"
You have to admit product/company opinion aside, can you get a lamer more stupid naming scheme? How much money did the genius who came up with that dumbassness get paid to do it? Answer= TOO MUCH!

R0H1T said:
Nah, Fentanyl is the new rage, all the rage ~ probably your last rage, ever!
Good point...Intel's Fentanyl lake 2024, so good it kills you.
Posted on Reply
#23
R-T-B
R0H1T said:
My initial assessment of smeltdown wrt Intel is that they know they skimped on security & probably did have a very good idea about these exploits, even if we discount the NSA baked deliberate holes theory.
These are very clever timing based attacks that are very general in nature. Sorry, but that isn't the NSA's style at all.

If you ask me, these appear A LOT more like sn honest error in design.
Posted on Reply
#24
dalekdukesboy
R-T-B said:
These are very clever timing based attacks that are very general in nature. Sorry, but that isn't the NSA's style at all.

If you ask me, these appear A LOT more like sn honest error in design.
Better known as bad engineering.
Posted on Reply
#25
R-T-B
dalekdukesboy said:
Better known as bad engineering.
I mean, I'd never have thought to use timing based inference. People cannot possibly anticipate everything, even engineers. ARM, PPC etc made the same "bad engineering" mistakes afterall.
Posted on Reply
Add your own comment