With the launch of Intel’s latest 8th Generation Core mobile processors, the 15W Whiskey Lake U-series and the 5W Amber Lake Y-series, questions were left on the table as to the state of the Spectre and Meltdown mitigations. Intel had, previously in the year, promised that there would be hardware fixes for some of these issues in consumer hardware by the end of the year. Nothing was mentioned in our WHL/AML briefing, so we caught up with Intel to find out the situation.

There Are Some Hardware Mitigations in Whiskey Lake

The takeaway message from our discussions with Intel is that there are some hardware mitigations in the new Whiskey Lake processors. In fact, there are almost as many as the upcoming Cascade Lake enterprise parts. Intel told us that while the goal was to be transparent in general with how these mitigations were being fixed - we think Intel misread the level of interest in the specifics in advance of the Whiskey Lake launch, especially when the situation is not a simple yes/no.

For the mitigations, here is the current status:

Spectre and Meltdown on Intel
AnandTech Cascade
Lake
Whiskey
Lake
Amber
Lake
Spectre Variant 1 Bounds Check Bypass OS/VMM OS/VMM OS/VMM
Spectre Variant 2 Branch Target Injection Hardware + OS Firmware + OS Firmware + OS
Meltdown Variant 3 Rogue Data Cache Load Hardware Hardware Firmware
Meltdown Variant 3a Rogue System Register Read Firmware Firmware Firmware
  Variant 4 Speculative Store Bypass Firmware + OS Firmware + OS Firmware + OS
  Variant 5 L1 Terminal Fault Hardware Hardware Firmware

What this means is that Whiskey Lake is a new spin of silicon compared to Kaby Lake Refresh, but is still built on that Kaby Lake microarchitecture. Intel confirmed to us that Whiskey Lake is indeed built on the 14++ process node technology, indicating a respin of silicon.

As a result, both CPU families have the all-important (and most performance degrading) Meltdown vulnerability fixed. What remains unfixed in Whiskey Lake and differentiates it from Cascade Lake CPUs is Spectre variant 2, the Branch Target Injection. This vulnerability has its own performance costs when mitigated in software, and it has taken longer to develop a hardware fix.

What About Amber Lake?

The situation with Amber Lake is a little different. Intel confirmed to us that Amber Lake is still Kaby Lake – including being built on the 14+ process node – making it identical to Kaby Lake Refresh as far as the CPU die is concerned. In essence, these parts are binned to go within the 5W TDP at base frequency. But as a result, Amber Lake shares the same situation as Kaby Lake Refresh: all side channel attacks and mitigations are done in firmware and operating system fixes. Nothing in Amber Lake is protected against in hardware.

Performance

The big performance marker is tackling Spectre Variant 2. 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. Neither Whiskey Lake nor Amber Lake have mitigations for v2, but Whiskey Lake is certainly well on its way with fixes to some of the more dangerous attacks, such as v3 and L1TF. Whiskey Lake is also offering new performance bins as the platform is also on 14++, which will help with performance and power.

Intel’s Disclosure in the Future

Speaking with Intel, it is clear (and they recognise) that they appreciate the level of interest in the scope of these fixes. We’re pushing hard to make sure that with all future launches, detailed tables about the process of fixes will occur. Progress on these issues, if anything, is a good thing.

Related Reading

Title image from PC Watch

POST A COMMENT

107 Comments

View All Comments

  • rocky12345 - Thursday, August 30, 2018 - link

    They were not vulnerable to these exploits until they were made public because no one was aware of them including hackers but then they were given names and pretty much told the world exactly what to and where to look if you wanted the frack over someones CPU/system. Yes the exploits were there but no one was aware of them.

    You also can not call them exploits that were built into the CPU's because at the time these cpu's were designed the designers had no clue there would be aholes out there trying to pick apart their designs to use them for no good such as screwing peoples systems over. Sorry to say this but if they keep digging they probably will find a few hundred more problem areas in cpu's as well as GPU's as well that could become exploits all of which most likely would slow our hardware down and at some point set us back to stone age computing once all of them are patched and fixed.

    For me personally I hope they stop looking so hard because every time they find something and it gets patched we the user lose a little bit of our systems and at this point we got evry tom,dick,harry,sally looking for something so if they find it they get 15 minutes of fame and get to bolster their resume a bit.
    Reply
  • aebiv - Thursday, August 30, 2018 - link

    This is the dumbest comment ever @rocky12345

    If Intel had done proper vetting, and looked at the processes for how they were handling those calls, these bugs would NEVER have made it to production. I think it's far more likely they did know of the issue, but didn't think it would ever be one, because it just made them faster.

    Someone, somewhere, is always going to find one of these bugs, and I'd rather it be the good guys who announce it to everyone so it can be fixed, than the bad guys who will just exploit it. It's a race.
    Reply
  • Holliday75 - Thursday, August 30, 2018 - link

    And who is to say that no state sponsored or private groups were not aware of them? If they were they aren't telling anyone. They just quietly use them as they see fit. We do not think they were ever exploited, but you never truly know. Reply
  • HStewart - Thursday, August 30, 2018 - link

    "If Intel had done proper vetting, and looked at the processes for how they were handling those calls, these bugs would NEVER have made it to production."

    It has already been problem that it not just Intel, but people seem to only think it is Intel and when Intel fixes the issue - they ignore it - it has been proven that both AMD and even ARM have such issue.
    Reply
  • HStewart - Thursday, August 30, 2018 - link


    "It has already been proven that it not just Intel"

    I wish this site have edit command for only Author.
    Reply
  • Manch - Friday, August 31, 2018 - link

    As always defender of Intel's virtue, you're not being forthright.

    It's true that Intel isn't alone in the vulnerabilities but Intel has the worst of the two vulnerabilities, Meltdown although it does affect a few ARM CPU's. Spectre affects Intel/AMD/ARM but it affect AMD and ARM to a much lesser degree.
    Reply
  • rahvin - Friday, August 31, 2018 - link

    Of the 11 Spectre exploits AMD has only been vulnerable to 3 of them, these are the 3 that every out of order processor were vulnerable to as they attack the fundamental idea of executing code out of order. The 3 are very difficult to execute and will require good access to even try.

    Of the 8 remaining Spectre vulnerabilities most of them are Intel only, and some of them like the Meltdown Spectre exploit are extremely easy to exploit. Don't be a fan boy about this, Intel clearly prioritized speed over security and as a result they are suffering from vulnerabilities that the other chip designers aren't. Intel will fix these in upcoming silicon but we shouldn't hand wave away how serious these vulnerabilities are. Meltdown in particular is a very serious vulnerability that can be exploited by something as simple as Javascript that's part of an ad on a website. That's as close to a drive-by exploit as you can get.
    Reply
  • chrcoluk - Wednesday, September 26, 2018 - link

    meltdown is not easy to exploit, the machine has to be already compromised.

    No malware has even attempted to use meltdown as its too complicated to successfully execute. Much easier fish to fry.
    Reply
  • voicequal - Thursday, August 30, 2018 - link

    "these bugs would NEVER have made it to production"

    I'm pretty sure by your logic no hardware or software would ever be released because none can be proven 100% secure.

    Traditionally SW has been so rich with exploits that there was no need to go after HW. After a few decades of improving SW security, this is beginning to change, and HW vulnerabilities are now lower hanging fruit for researchers and hackers alike.
    Reply
  • Dr.X - Monday, September 3, 2018 - link

    @rocky12345 & @aebiv
    Gentlemen you both make very valid points. It is impossible to vet any design for an unknown future use case that exposes vulnerabilities. VM's are such a use case, which has only become popular in the last 10 years. Intel architectures are much older (Pentium Pro, etc), and as such errors of omission are to be expected with new use cases.
    Reply

Log in

Don't have an account? Sign up now