Researchers investigating security flaws have found a problem with AMD chips that affects all CPUs going back to Bulldozer. Whether this represents an issue you should practically take note of is something we will discuss below. The research funding question will also be addressed below.
For the last two years, there’s been a steady stream of security disclosures around Intel CPUs, emphasizing that some of the ways these chips handle data leaves them susceptible to side-channel attacks. While attacks like Spectre and Meltdown have affected CPUs from multiple companies, many of the follow-up attacks have been specific to Intel CPUs. Once it became clear that Intel was hitting far more problems than AMD or ARM CPUs were, a narrative began to grow that Intel chips had been designed in a fundamentally unsafe way.
There was, however, always another possibility. It was always possible that the reason researchers were finding flaws in Intel chips but not in AMD CPUs is that they were focusing their research on the CPUs that people actually owned and used. In this telling, the fact that Intel security vulnerabilities didn’t work on AMD chips wasn’t really proof of anything except the fact that AMD CPUs
don’t use many of the same microarchitectural techniques to improve performance that Intel did. It’s possible that AMD avoided certain techniques because of security reasons. It’s also possible it avoided them because Intel held specific patents that it wasn’t willing to license. Either way, AMD chips haven’t been impacted by a number of fixes.
While AMD has certainly talked up the security features on Ryzen CPUs, it has made little to nothing over the specific issues Intel has had with Spectre and Meltdown. This is deliberate. Going to war with Intel over the issue of Spectre and Meltdown would have opened the door to Intel going after AMD in the same fashion, only using Chipzilla’s marketing budget. Not a great plan. Today’s disclosure demonstrates why. The authors specifically note that they are researching AMD CPUs because AMD CPUs are increasingly deployed in cloud data centers and in consumer systems.
The Takeaway on ‘Take A Way’
The team of researchers (unaffiliated, Graz University of Technology, and the University of Rennes) found a new way to extract data from AMD CPUs, dubbed “Take A Way.” They did this through the application of a new and novel idea: Studying the hell out of AMD’s processors, rather than focusing on Intel chips and then attempting to apply those techniques (plus maybe a little bit of experimentation) on AMD CPUs. The authors write:
In this paper, we present the first attacks on cache way predictors. For this purpose, we reverse-engineered the undocumented hash function of AMD’s L1D cache way predictor in microarchitectures from 2001 up to 2019. We discovered two different hash functions that have been implemented in AMD’s way predictors. Knowledge of these functions is the basis of our attack techniques. In the first attack technique, Collide+Probe, we exploit µTag collisions of virtual addresses to monitor the memory accesses of a victim timesharing the same logical core.
CPU caches are designed to be n-way set associative, meaning that each cache address can contain data from a certain number of locations in memory. A cache that is 16-way associative has 16 potential memory locations it maps to. Higher associativity reduces the likelihood of a cache miss, since there’s a larger chance the correct data is loaded. Here are the researchers again:
Since the Bulldozer microarchitecture [6], AMD uses an L1D cache way predictor in their processors. The predictor computes a µTag using an undocumented hash function on the virtual address. This µTag is used to look up the L1D cache way in a prediction table. Hence, the CPU has to compare the cache tag in only one way instead of all possible ways, reducing the power consumption.
This is an optimization AMD clearly introduced in an attempt to reduce power consumption, and God knows, Bulldozer needed it. The authors step through the process of reverse-engineering the attack and their analysis of AMD’s branch prediction mechanisms.
Every cache line in the L1D cache is tagged with a linear-address based µTag. This µTag is computed using an undocumented hash function, which takes the virtual address as the input. For every memory load, the way predictor predicts the cache way of every memory load based on this µTag. As the virtual address, and thus the µTag, is known before the physical address, the CPU does not have to wait for the TLB lookup.
What the researchers collectively found, in aggregate, is that it is possible to use various cache attacks against AMD to extract data from the CPU. At least some of these attacks assume that ASLR (Address Space Layout Randomization) has either been broken or isn’t operating, but ASLR, in and of itself, is not a bulletproof security measure. AMD has other features, like Secure Memory Encryption and Secure Encrypted Virtualization, but these are reserved for servers. It is not clear if these features could prevent ‘Take A Way’ from functioning properly or not.
Side-Channel Attacks are Here to Stay
I want to return to an issue I raised last week when another Intel security flaw was discovered. The fact is, while many of these bugs could be used for various nefarious purposes, nobody has seen them in public malware.
The technical definition of a computer security side-channel attack is “any attack based on information gained from the implementation of a computer system, rather than weaknesses in the implemented algorithm itself.”
Expand the concepts of the definition a little, and you can see how difficult it is to prevent this sort of thing. One could argue that we use side-channel observations when we peer through dust clouds to see stars that are invisible to the naked eye but can still be detected through infrared. Entire research installations and radio telescopes have been devoted to gathering information that humans are completely unable to perceive without these highly specialized tools. The universe, as a general rule, leaks information into the surrounding medium, and humans are getting pretty good at extrapolating data from it.
All of which is to say: Side-channel attacks are never going to go away. They cannot, by definition, go away. AMD and Intel can secure a CPU architecture against every single attack vector known to man at the moment of its launch, but they cannot know that their lockdown will not inspire someone else to find a flaw or workaround that hadn’t previously been known. White hat security is fundamentally reactive. Furthermore, the fact that AMD adopted this fix as a power-reducing measure emphasizes that there are tradeoffs beyond just speed that have to be made when evaluating the risk.
Security researchers are turned on to the fact that side channels offer a more-or-less infinite field of opportunity. When Intel unveiled Spectre, it made it clear that Spectre was one example of a new type of attack. Two and a half years later, we’ve seen quite a few “Spectre-class” attacks focused on Intel. It is the least surprising thing in the world that a detailed analysis of AMD CPUs reflected the same problem on an AMD chip.
How Much of a Threat Is This?
According to one of the study authors, it basically isn’t:
More broadly, since Meltdown and Spectre, we’ve seen a number of security issues that affected Intel CPUs going back years. but not one of those attacks has been used in real-life malware. The most surprising thing about the fact that someone found a bug in an AMD CPU is that it took 2.5 years for people to really start looking. The team points out that they’ve been able to extract secret keys from AES T-tables, but they also note:
While cache attacks have already been demonstrated against T-table implementations and appropriate countermeasures, e.g., bit-sliced implementations, have been presented, they serve as a good example to demonstrate the applicability of the side channel and allow to compare it against other existing cache side-channels.
The implication here is that the AES T-table attack is something of a theoretical proof of concept, not a five-alarm fire, as are all the other AMD attacks.
According to AMD, it does not believe this attack is significant and argues that it is already protected against by previous patches. The research team disagrees that the issue is patched, but at least some members clearly don’t see the problem as any kind of threat.
Who Funded the Research?
In the few days since this report was first published, people have noticed that some of the work was funded by Intel and leaped to the conclusion that the entire study was written in skullduggerous bad faith. The relevant line in the Acknowledgments reads: “Additional funding was provided by generous gifts from Intel.”
This is not evidence of bad behavior. It’s a bog-standard notification that Intel helped fund this security research, as they help fund a lot of security research.
You will find this in almost all of my papers, finding flaws in various processors and other things. Intel funds some of my students. If one of these students co-authors a paper, we acknowledge the gift of course.
— Daniel Gruss (@lavados) March 7, 2020
The same author who point-blank states that this issue is not a major threat is the one who says the funding notification re: Intel is required by disclosure laws. There’s no evidence that this was some kind of attack by Intel on AMD, and while the bugs themselves are real, they reflect the fact that people are finally taking a deep look at AMD CPUs.
Now Read:
- Intel Has an Unfixable Chipset Security Flaw. Is it a Risk?
- AMD’s Secure Processor Firmware Is Now Explorable Thanks to New Tool
- Intel Patches Zombieload Security Threat Again
No comments:
Post a Comment