Recognizing prefetching in flush and reload attack
We are trying to implement flush and reload attack for a project at the university.
The problem we are facing is prefetching to the cache. It seems that frequently after flushing the address, it gets back to the cache before we run the reload, effectively giving us a cache hit although the victim didn’t use the address. It happens frequently enough so the attack doesn't work. The article we are following did mention prefetching and said that in order to combat this, we should look for 3 consecutive cache hits. We tried it, and it didn’t work. We think that we are implementing the attacker side incorrectly.
The attacker side looks abstractly like this (this is pseudocode, the real program is in C):
While victim is running: reload_and_flush(adrs)
We understand that this implementation is problematic for the following reason: to get 3 cache hits seems more a thing of luck that between every loop of the while loop a context switch to victim will occur and the victim will load the address we are looking for. We tried adding a bit of sleep between flush and reload, but this gave us that everytime there is a cache hit, most likely because of prefetching.
In addition, we are not sure why, even without prefetching, we expect to get 3 consecutive cache hits. If we are spying over a function address, the victim will load it once it gets into the function and no more. So why do we expect him to load the address more than one time?
We chose an article demonstrating how to use flush and reload to attack some vulnerable implementation of TLS or DTLS server. Specifically, those who use dummy sleep to combat the Lucky13 attack. We are looking to see if they are using the dummy sleep function, thus inferring that the argument we have given to decryption had a valid padding, then using the oracle Lucky13 attack to decrypt the message.
The article(although I dont think this is necessery for answering the question I add it for completeness)
https://static.aminer.org/pdf/20170130/pdfs/ccs/hyjisbk0qsvct1wnf5gyhe4fzp28vecr.pdf