Sorry I originally posted to a dead thread …
AMD’s response is entirely correct concerning latest so-called vulnerability by Austrian security researchers. Here is my synopsis of the issues presented
To summarize the paper’s side channel attack: 1) The user starts a browser and goes to a evil site that starts up a malware Javascript process thread L1 data cache of core “X”. 2) The user has another process thread using the the same core “X” that is encrypting/decrypting (i.e., using AES key encryption) some text. The malware site needs to install a “special timer” application on the users computer to time the cache collisions with encryption thread (to get around the Address-Space Layout Randomization ASLR). The malware is then able to determine parts of the private encryption/decryption key through cache hit timings.
The main problem with this the stock browsers “do not” have the required timers to perform the attack. Therefore, the only way to perform the attack is to “manually” install a timer that has enough granularity to perform the side channel attacks. The malware needs to break the browser’s sandbox or get the user to install some additional malware. This is identified in a referenced paper “ASLR on the Line: Practical Cache Attacks on the MMU,” (Ben Gras). To quote the paper:
“To implement AnC, we needed to implement better synthetic timers than the one provided by the current browsers.”
This attack appears not to hurt individual single user PCs, unless there was direct malware attack (i.e., broken sandbox, malware downloaded and installed). At that point your PC has already been pwnd. Then the side channel attack doesn’t matter anymore.
Where this attack would be possible would be on a multi-user server (unusual archaic use case) or on a multi-user virtual server (usual use case). Since the paper doesn’t include anything specific this type of attack, I can only assume companies that provide virtual services like AWS, Azure, Google Web Services, Citrix, and VMWare have mitigations for these types of attacks (i.e.,L1 data cache flushing between third party communal core usage). As for a multi-user system (rare case), I would suggest turning off multi-threading. I suspect an AMD 64 core system is plenty of horse power for most situations.
An additional security mitigation would to not provide a nanosecond timer to the user space without the user and/or executable having the appropriate kernel access permissions. The kernel could expose timers to the user space with the bottom 6-7 bits masked. Special applications that require high quality timers would be installed with that privilege (i.e., databases, real time systems). This wouldn’t stop malware attacking the kernel. If someone has Kernel level access, the game is over anyways.
