This morning has seen an interesting turn of events in the world of processor security. c't magazine has published an exclusive report stating that they got wind of a new series of Spectre-class vulnerabilities that are currently being investigated by the greater security community, and that these vulnerabilities are going to be announced in the coming days. Meanwhile, seemingly in response to the c't article, Intel has just published their own statement on the matter, which they’re calling “Addressing Questions Regarding Additional Security Issues.”

Diving right into Intel’s announcement:

Protecting our customers’ data and ensuring the security of our products are critical priorities for us. We routinely work closely with customers, partners, other chipmakers and researchers to understand and mitigate any issues that are identified, and part of this process involves reserving blocks of CVE numbers. We believe strongly in the value of coordinated disclosure and will share additional details on any potential issues as we finalize mitigations. As a best practice, we continue to encourage everyone to keep their systems up-to-date.

For more information on how we approach product security at Intel, please see my recent blog, “Bringing the Security-First Pledge to Life with New Intel Product Assurance and Security Group.”

— Leslie Culbertson

As things are currently unfolding, this is a very similar trajectory to the original announcement of the Meltdown and Spectre vulnerabilities, in which information about those vulnerabilities was leaked and pieced together ahead of the official coordinated announcement. Philosophies on disclosure policies notwithstanding, what we eventually saw was an accelerated release of information on those vulnerabilities, and a good bit of chaos as vendors suddenly had publish materials they were still preparing for a few days later. Intel’s early response here seems to be an effort to avoid chaos that by getting on top of things early, acknowledging the public's concerns and responding by outlining their coordinated release plans so that they can move ahead with things as-planned.

Which is to say that while Intel’s announcement confirms that something is up, it doesn’t offer any concrete details about what’s going on. For that – and assuming things don’t fall apart like the Meltdown/Spectre coordination – we’re presumably going to be waiting until next week on proper details.

As for the c't report, sources point to 8 individual CVE-assigned Spectre-class attacks, which for the moment they’re calling Spectre-NG. According to the site, Intel is working on two waves of patches, with the first wave currently set to be released in May, and c't is further speculating that information on the first wave will be released just ahead of May’s Patch Tuesday. Meanwhile information on a second flaw could be released “any day now.” And while the bulk of the report focuses on Intel – as this would seem to be the information c't had at hand – the site notes that ARM looks to be impacted as well, and AMD is likely but to-be-determined.

Of particular interest, the one exploit which c't is providing any details about is another VM-host attack, making it similar in risk to cloud server hosts as the original Meltdown. As these customers are Intel's bread & butter from a profitability standpoint, Intel will want to move very quickly to fix the issue before it can be exploited on customers’ servers, and to soothe their customers' concerns in the process.

Overall, while the nature of the report means we can’t confirm anything about their claims, on the whole it appears sound, and these claims are consistent with prior concerns raised by security researchers. Researchers have warned as far back as the original Spectre whitepaper that Spectre is a whole class of attacks – that it would be the ghost that wouldn't go away – as new ways are found to exploit the same fundamental weakness. Similar to other pivotal vulnerability discoveries, the nature of these side-channel attacks means that they are very powerful and still new enough that they’re not very well understood. So there has been and continues to be an ongoing concern that researchers and criminals alike will continue to find ways to use side-channel attacks against speculative execution, as seems to be the case now.

Ultimately, all of this is going to put increasing pressure on all CPU vendors to definitively answer a critical question: is speculative execution fundamentally unsafe, or can it be retained while it’s made safe? As one of the cornerstones of modern high-performance processors, the answer to that could shape the face of CPUs for years to come…

Comments Locked


View All Comments

  • willis936 - Thursday, May 3, 2018 - link

    I don't see a reason why speculative execution would be inherently unsafe. Has anyone presented this idea with a good argument?
  • Ryan Smith - Thursday, May 3, 2018 - link

    Right now it can be used to infer the contents of other programs, including those running at other privilege levels. It's a serious issue with no obvious hardware solution. Developers can write software to essentially fence off things that are at risk, but requiring software developers to protect against hardware flaws is not a good long-term solution.
  • willis936 - Thursday, May 3, 2018 - link

    I agree. I'm specifically curious about a proof that shows that future speculative execution designs could not be made more secure. Intuitively I feel that speculative execution could be patched up but I have not put a lot of thought into it.
  • Reflex - Thursday, May 3, 2018 - link

    You can't prove a negative. There is no way to 'prove' that future designs can't be exploited. While its possible that you could secure speculative execution in such a way that it could not be exploited the ways we know of currently, we can't really guard against a future we don't know and there is always the question of whether or not the performance tradeoffs of such security won't themselves cost more in perf than the feature gains.

    Nothing is free.
  • Billy Tallis - Thursday, May 3, 2018 - link

    I think you're underestimating what is possible with a formal analysis of CPU architecture. This kind of property can be proven in the mathematical sense, but full formal analysis of systems with this much complexity is almost always regarded as cost-prohibitive. And it would be an even bigger task to make backwards-compatible modifications to a current architecture to produce one that is completely immune to speculation-related information leaks but still has similar performance to current speculative architectures. It's probably easier to build a new architecture from scratch, even including the costs of breaking compatibility with all existing software.
  • FunBunny2 - Friday, May 4, 2018 - link

    "This kind of property can be proven in the mathematical sense, but full formal analysis of systems with this much complexity is almost always regarded as cost-prohibitive."

    oops. didn't read far enough ahead. :)
  • FunBunny2 - Friday, May 4, 2018 - link

    "You can't prove a negative. "

    you sort of can. it's called a maths proof. cpu is a manifestation of symbolic logic problem. that's how von Neumann devised the computer in the first place. somewhere along the line, the maths failed. fixing hardware problems (design, not manufacturing) is a white board problem. it's in the maths.
  • peevee - Friday, May 4, 2018 - link

    "And yet despite this, you likely don't want a CPU that can't do speculative execution"

    I do, if done properly. Speculative execution (beyond conditional branches) is a kludge for outdated processor architectures which place memory too far from cores, and very obvious power waste. Given that even now performance is TDP-limited, days of speculative execution need to come to their end.
  • willis936 - Saturday, May 5, 2018 - link

    Not at all. There is no know alternative, within the current paradigm, to exploit the instruction level parallelism that speculative execution does. For there to not be a benefit you’d have to abandon the very idea of pipelined architectures.
  • HStewart - Thursday, May 3, 2018 - link

    I think we should ask the big question, are these researchers helping or hurting the industry?

    Especially giving rewards to people who find such issues?

    What should be look at root of why people create such problems to attack in first place and create stupid Virus and malware in the first place. It has to be download from internet some where - awards should be given to prevent such activity. Not on optimizations of processer to improved performance.

    Site is a little bias - it mention Intel in big print at top - but in smaller print mentions that ARM and AMD could also be effected.

    Also there is nothing that provide legitimate description of what these issues are. Unless this is provided - how can we trust it.

Log in

Don't have an account? Sign up now