A few days ago, a report was published detailing three novel Spectre vulnerabilities that exist inside the micro-op cache of all modern processors. Shortly after we wrote about it, Intel reached out to say that they don’t think the new vulnerabilities are a big problem. Their official statement reads: "Intel reviewed the report and informed researchers that existing mitigations were not being bypassed and that this scenario is addressed in our secure coding guidance. Software following our guidance already have protections against incidental channels including the uop cache incidental channel. No new mitigations or guidance are needed."
Put simply, updated software running on updated hardware should be impervious to the new exploits. I asked Assistant Professor Ashish Venkat, who lead the team that discovered the vulnerabilities and exploits, for his opinion on Intel’s statement. He conceded that Intel is right about the effectiveness of some existing countermeasures.
Intel’s secure coding guidance recommends three principles to prevent side-channel attacks. They’re for programmers to implement. If they’re all employed correctly, then they protect the software from all traditional side-channel attacks and most speculative execution side-channel attacks including micro-op cache attacks.
The principles:
- Ensure runtime is independent of secret values.
- Ensure code access patterns are independent of secret values.
- Ensure data access patterns are independent of secret values.
In theory, they’re simple enough, but Intel admits that they can be difficult to implement in practice. Compilers with optimizers will sometimes break the principles to make the code more efficient, thus reintroducing the vulnerabilities. Venkat and his team don’t like that Intel is relying on programmers to update their software when the vulnerabilities they’ve discovered are ultimately a hardware issue.
"Constant-time programming is not only hard in terms of the actual programmer effort, but also entails high performance overhead and significant deployment challenges related to patching all sensitive software," Venkat said. "The percentage of code that is written using constant-time principles is in fact quite small. Relying on this would be dangerous. That is why we still need to secure the hardware."
The reluctance of government branches, banks, and large companies to update their low-level software is infamous. And it’s these sorts of organizations that these vulnerabilities pose the most risk to, because their servers are running a lot of different software all at once, and because they deal with a large volume of secrets.
When I spoke to Venkat, I asked if the average user should be worried, and he said that they "should continue to focus on where they’re most vulnerable, including viruses and malware on the internet." But to secure the digital services everyone uses, hardware vendors need to place a renewed emphasis on hardware security moving forward.
Image credit: Ryan
