Take a Way: Exploring the Security Implications of AMD’s Cache Way Predictors [pdf]
11–20 of 22 posts
Re: Take a Way: Exploring the Security Implications of AMD’s Cache Way Predictors [pdf]
#12AMD's response ( https://www.amd.com/en/corporate/product-security ): "Take A Way 3/7/20 We are aware of a new white paper that claims potential security exploits in AMD CPUs, whereby a malicious actor could manipulate a cache-related feature to potentially transmit user data in an unintended way. The researchers then pair this data path with known and mitigated software or speculative execution side channel vulnerab…
Re: Take a Way: Exploring the Security Implications of AMD’s Cache Way Predictors [pdf]
#13"Additional funding was provided by generous gifts from Intel" I want to know more ! Was Intel tired of this team finding a new CVE every 6 months they sent free AMD gears ? Edit: Intel is funding some of the Graz students (to work on anything) https://mobile.twitter.com/lavados/status/123608333055623168...
Re: Take a Way: Exploring the Security Implications of AMD’s Cache Way Predictors [pdf]
#14"Additional funding was provided by generous gifts from Intel" I want to know more ! Was Intel tired of this team finding a new CVE every 6 months they sent free AMD gears ? Edit: Intel is funding some of the Graz students (to work on anything) https://mobile.twitter.com/lavados/status/123608333055623168...
Google has Project Zero (a team dedicated to finding exploits in competitor products). The end result is safer products all around. I think it's better that your competitor finds flaws in your products and use that for self promotion than a 3rd party selling exploits.
https://bugs.chromium.org/p/project-zero/issues/list?can=1&q...
Re: Take a Way: Exploring the Security Implications of AMD’s Cache Way Predictors [pdf]
#15AMD's response ( https://www.amd.com/en/corporate/product-security ): "Take A Way 3/7/20 We are aware of a new white paper that claims potential security exploits in AMD CPUs, whereby a malicious actor could manipulate a cache-related feature to potentially transmit user data in an unintended way. The researchers then pair this data path with known and mitigated software or speculative execution side channel vulnerab…
Re: Take a Way: Exploring the Security Implications of AMD’s Cache Way Predictors [pdf]
#16"Additional funding was provided by generous gifts from Intel" I want to know more ! Was Intel tired of this team finding a new CVE every 6 months they sent free AMD gears ? Edit: Intel is funding some of the Graz students (to work on anything) https://mobile.twitter.com/lavados/status/123608333055623168...
Re: Take a Way: Exploring the Security Implications of AMD’s Cache Way Predictors [pdf]
#17Re: Take a Way: Exploring the Security Implications of AMD’s Cache Way Predictors [pdf]
#18I’m sort of disappointed that the title doesn’t start with “This is the way” :)
Re: Take a Way: Exploring the Security Implications of AMD’s Cache Way Predictors [pdf]
#19The attacks outlined in the paper all take the form of setting up an L1 cache structure in some way to induce collisions with other threads (or with the kernel running in the same thread), and then measure when collisions occurred in order to deduce bits of the memory addresses accessed by the other thread (or the kernel).
This type of attack has been known for a long time: you can do it just by making sure to evict all of the other thread's cache lines. It seems to be generally agreed upon that it is software's responsibility to guard against this kind of attack.
What's new in the paper is that instead of just bits 6 to 11, additional bits of the virtual memory addresses accessed by the other thread can be leaked. That's an interesting result, but I find it questionable how critical it is in practice. Making it easier to break ASLR feels like the biggest potential problem here, and I'm not sure it really is one.