# Memory and Cache Contention Denial-of-Service Attack in Mobile Edge Devices
## 4 Hardware-Based Countermeasures for Memory and Cache Contention DoS Attack
### Our Proposed Detection Method
We will further investigate how to formally find the optimal threshold values for a certain environment and architecture as our future work. In terms of the hardware costs, the main part of our detection mechanism only requires three counters (RCounter, CCounter, and ACounter), three magnitude comparators, one multiplexor, and four registers (for threshold values). The hardware cost for our detection mechanism is negligible when considering that the modern mobile CPUs are already adopting an order of megabyte on-chip cache memories. Although our example malicious codes regularly and steadily issue L1 data cache miss requests to the shared L2 cache, the average RCounter values of some applications (e.g., bwaves, leslie3d, and namd) are actually higher than those of the malicious codes. These applications, which show higher RCounter values than the malicious codes, have two important characteristics: (1) high L1 data cache misses per cycle (intensiveness of the L1 data cache misses) and (2) low average L1 data cache miss latency (latency to obtain the data from the lower-level memories after the L1 data cache miss). Higher L1 data cache misses per cycle means that more L1 data cache miss requests are issued for a certain time period, which, in turn, leads to higher RCounter values. Low average L1 data cache miss latency means that many of the L1 data cache miss requests are served from the L2 cache (i.e., relatively low L2 cache miss rates) instead of the main memory, which implies that these workloads do not intensively access the main memory as much as our malicious \begin{table}
\begin{tabular}{c c} \hline \hline \multicolumn{2}{c}{**Values Used in This Work**} \\ \hline \(\textbf{{Thres}}_{int}\) & 100,000 \\ \hline \(\textbf{{Thres}}_{lower}\) & 600 \\ \hline \(\textbf{{Thres}}_{upper}\) & 1200 \\ \hline \(\textbf{{Thres}}_{acc}\) & 500 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Threshold values used for our detection mechanism. Figure 6: The ranges of RCounter values for each workload. The black-colored dot corresponds to the average value of RCounter while the gray bar corresponds to the range (i.e., min to max) of RCounter values. codes or other applications. In the case of low average L1 data cache miss latency, the CPU core pipeline or dependent instruction execution is likely to be stalled much less than in the case of high average L1 data cache miss latency. It makes the successive load/store instructions, which also have a high possibility to result in the L1 data cache miss, be issued relatively faster, which eventually increases RCounter values. On the other hand, when running the malicious codes, the average L1 data cache miss latency is much higher than those three applications. It means a non-negligible portion of the data requested from the L1 data cache is served from the main memory, resulting in resource contention in both L2 cache and main memory. There would be a concern regarding how we can effectively detect variants of our malicious programs. For example, we could make our malicious codes fit into L2 caches (in order to cause L2 cache hits and try to evict the cache blocks of other programs), trying to prevent the malicious codes from accessing the main memory. In this case, we only cause DoS in the shared L2 caches. In addition, we may construct a malicious code to access memory arrays with irregular indexing sequences to increase row buffer misses in the DRAM main memory instead of linearly increasing the index with a certain stride. It may cause the higher latency to serve the data from the main memory, which also wastes more main memory bandwidth for benign programs. However, the main characteristic of our malicious code and its variants is to execute the load/store instruction regularly and consecutively (i.e., steadily), which causes DoS to the shared resources in the system.