Over the past three days, reports of new Spectre-class attacks emerged that supposedly break all previous speculative execution patches and require performance-crippling mitigation techniques. There’s just one problem: Intel and the researchers fundamentally disagree as to whether a flaw exists at all.
The research team from the University of Virginia has written a paper arguing that there are catastrophic flaws in the way AMD and Intel currently implement micro-op caches that allow them to leak data under certain circumstances. Both Zen 2 and Skylake-class architectures are said to be vulnerable; the paper does not reference any testing done on Ice Lake, Tiger Lake, Rocket Lake, or Zen 3 processors.
The micro-op cache on a modern x86 CPU stores decoded instructions so they can be promptly accessed again if needed. This improves power consumption by avoiding the need to repeatedly decode the same short set of instructions during certain operations. It can also improve performance because the already-decoded instructions can be accessed on-demand.
According to the research team, the solutions to this micro-op cache data leakage problem, such as constantly flushing its contents, “could severely degrade performance.”
“Furthermore,” they continue, “given that current processors require an iTLB flush to achieve a micro-op cache flush, frequent flushing of both structures would have heavy performance consequences, as the processor can make no forward progress until the iTLB refills.”
Sounds pretty bad. The only problem is, Intel completely disagrees. The company’s official statement reads as follows:
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.
We have reached out to AMD to see if the company had any comment to offer on the matter and will report back if we hear from them.
Intel has released a number of patches for various flaws related to the initial Spectre/Meltdown disclosure back in 2018. It has also released its own writeups, reports, and documentation. However one feels about the existence of these issues, Intel appears to have engaged with the process of fixing them in good faith.
Over the past year, I’ve criticized several PR-driven security disclosures. In some cases, the histrionic tones of the press release and/or blog post have not matched the more measured claims in the paper itself. This is different. The research paper doesn’t catastrophize, but it presents the team’s findings as proof of an ongoing problem. According to Intel, that problem is addressed in existing guidance.
Said guidance suggests developers mitigate side-channel data leakage by ensuring algorithms always execute operations performed on secret data in exactly the same amount of time, that the value of or values derived from a secret never affect a conditional branch or the target of an indirect branch, and that secret values should never “cause a change to the order of accessed addresses or the data size of loads/stores.”
It’s far from the world-ending sensationalism implied by the “Defenseless” language on the Virginia site, and in the press pick up thus far… There may be some cleanup needed in light of this latest paper, but there are mitigations available, albeit always at some performance cost. (Emphasis original)
The research lead, Ashish Venkat, has told Ars he believes the problem his team has located deserves a fix in microcode and argues that the constant time programming approach advocated by Intel is quite difficult.
For now, that’s where we’re going to leave this one. Intel’s guidance is that this is not an issue and third-party review classifies it as interesting but overhyped in most reports. The research team that brought it to light believes it deserves more of a fix than Intel does, and that Intel’s guidance on software programming is not practical enough to solve the problem. More than three years after Spectre and Meltdown, no one is known to have attempted to leverage a side-channel attack in the wild. There remain simpler and more straightforward ways of stealing data.