Leaking Secrets via Intel/AMD Micro-Op Caches


Level 38
Jan 9, 2020
A team of University of Virginia School of Engineering computer science researchers has uncovered a line of attack that breaks all Spectre defenses, meaning that billions of computers and other devices across the globe are just as vulnerable today as they were when Spectre was first announced. The team reported its discovery to international chip makers in April and will present the new challenge at a worldwide computing architecture conference in June.
This newly discovered vulnerability will be much harder to fix.
They have detailed the FINDINGS IN THEIR PAPER: “I See D3ad µops: Leaking Secrets via Intel/AMD Micro-Op Caches”


Level 47
Content Creator
Apr 24, 2016
Intel's response:
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.
Response on that from Ashish Venkat, a computer scientist from UVA with a credit on the research paper:
We're aware of these guidelines from Intel suggesting software developers to write code in a way that is not vulnerable to side-channel attacks. Here's an excerpt from the Intel article -- 'Developers who wish to protect secret data against timing side channel methods should ensure that their code runtime, data access patterns, and code access patterns are identical independent of secret values.'

Certainly, we agree that software needs to be more secure, and we agree as a community that constant-time programming is an effective means to writing code that is invulnerable to side-channel attacks. However, the vulnerability we uncover is in hardware, and it is important to also design processors that are secure and resilient against these attacks.

In addition, 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. 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.