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"

#26
hat
Enthusiast
It's true that shit just happens. I've seen new injection molds come in that didn't work right, and new presses that usually seem to take months of troubleshooting before they work properly for some reason. Again totally different beast but it still comes down to the same... somebody made something and it sucks, needs work before it's ready...

As for product names, look out for Intel Flacca Lake, it'll make you lose your mind :laugh:
Posted on Reply
#27
efikkan
R-T-BThese 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.
Yes, as I've mentioned, until someone comes up with evidence otherwise, there is no basis for calling this an intentional exploit.

And yes, while these timing attacks might be easy to "exploit" in test cases, they are hard to exploit for something useful. It seems like most of these may be leaking a few bytes at the time, some may not work reliably, and may not even be able to target arbitrary addresses. And even then, we are still talking about just a few bytes/sec for a thread eating up a core, so if your plan was to dump the memory of an Amazon EC2 hypervisor, let's say 1 TB of data, you're going to be busy for a while. Memory in the OS kernel is divided into small blocks called pages, and even if you manage to dump most of these intact, you still have the problem of the page table constantly changing while dumping, so you essentially have no way of reassembling it, and any useful data you can find have to be limited to single memory pages which are readable without the rest of the file. Bugs are of course bad and should be fixed, but we're still talking about an absolute edge case here, which will be much harder to execute successfully in uncontrolled environments.
Posted on Reply
#28
dalekdukesboy
R-T-BI 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.
"God help us we're in the hands of engineers" one of my favorite movie quotes of all time.
Posted on Reply
#29
HTC
efikkanYes, as I've mentioned, until someone comes up with evidence otherwise, there is no basis for calling this an intentional exploit.

And yes, while these timing attacks might be easy to "exploit" in test cases, they are hard to exploit for something useful. It seems like most of these may be leaking a few bytes at the time, some may not work reliably, and may not even be able to target arbitrary addresses. And even then, we are still talking about just a few bytes/sec for a thread eating up a core, so if your plan was to dump the memory of an Amazon EC2 hypervisor, let's say 1 TB of data, you're going to be busy for a while. Memory in the OS kernel is divided into small blocks called pages, and even if you manage to dump most of these intact, you still have the problem of the page table constantly changing while dumping, so you essentially have no way of reassembling it, and any useful data you can find have to be limited to single memory pages which are readable without the rest of the file. Bugs are of course bad and should be fixed, but we're still talking about an absolute edge case here, which will be much harder to execute successfully in uncontrolled environments.
The problem is Intel seems to have chosen to do some security checks after certain operations, to increase performance. Unfortunately for Intel, these security checks can be bypassed by these exploits, even if "slowly", but they can be.
"We believe Intel CPUs do almost no security checks up-front, but defer checks until instruction retire. As a result we believe similar issues will be coming in the future.

"We asked repeatedly, but Intel provided no advance notice. We did not even receive replies to our requests for dialogue."
If indeed this is the case, Intel is @ fault here because they opted for a way of doing things that was less secure just to have more performance.

www.itwire.com/security/84056-openbsd-chief-says-more-intel-cpu-flaws-likely-to-be-found.html
Posted on Reply
#30
Octopuss
jaggerwildHow Very boring, seeing AMD people posting in an Intel Thread.
How very boring, seeing people post stupid offtopic nonsense.
Posted on Reply
#31
John Naylor
From the moment I see Spectre or meltdown mentioned, I stop reading ... at least until I read that 1st "Oh crap, look what happened to be because of..." story.

As for the naming schemes,I was hoping that one of them would clean up up posts and type / input what I intende but screwed up cuz was "into the cups" and had a few.
Posted on Reply
#32
dalekdukesboy
dalekdukesboy"God help us we're in the hands of engineers" one of my favorite movie quotes of all time.
I don't often quote myself, but when I do, it's to re-quote Jurassic Park.
Posted on Reply
Add your own comment
Nov 18th, 2024 23:35 EST change timezone

New Forum Posts

Popular Reviews

Controversial News Posts