• The main idea behind the “mitigation of timing side channel attack on DRAM” is traffic management so that request patterns should be indistinguishable. Attacker can’t discern the victim’s detailed memory request patterns based on its own response latencies (based on the latency of its own requests).
• And, the main idea of mitigation of RowHammer is not to induce the bitflip in near-by aggressor rows. In current scenario, industries have deployed the hardware tracker (Ideal tracker also called as one counter per row) in DRAM and mitigation action (TRR) in memory controller. Whenever attacker tries to generate the complex request pattern to access the particular row frequently which crosses the threshold, memory controller automatically sends the refresh command to refresh the near-by aggressor rows.
• Now, idea is to implement both the mitigations (timing + RH) and have a look what could be the overall behavior of the system. We can use any aggressive workload (like mcf) that has high row-locality which accessed a particular row repeatedly. When both the mitigations come into play, the request patterns should be distinguishable and simultaneously memory controller sends the refresh commands to mitigate the RH. It is possible that command queues can contain both the mitigations commands and memory controller gives priority to the refresh commands of the RH so that bitflips cannot be induced in DRAM. Refresh commands of the RH may unnecessarily generate the traffic in the command queue and can be the distinguishability.