# 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  
In this subsection, we provide a detailed explanation of our detection mechanism in order to thwart the memory and cache contention DoS attack. Our detection mechanism focuses on the specific behavior of the malicious codes for the memory and cache contention DoS attack. For a successful memory and cache contention DoS attack, the malicious code must intensively and steadily generate access requests to the shared resources (L2 cache or main memory). Consequently, it generates access requests to the L2 cache with a stable (i.e., not much fluctuating) request interval pattern. Based on this insight, we detect how steadily and intensively L1 data cache miss requests are generated from a certain core and issued to the L2 cache within a certain time interval, since the malicious code issues the requests with a relatively fixed rate when compared to the normal programs. Figure 5 shows our L1 data cache miss request interval detection mechanism with a hardware block diagram. The detection is carried out, as follows. Our detection hardware monitors miss requests from the L1 data caches from the core. Once a miss request is generated and sent to the L2 cache, we increment RCounter by one. CCounter is also incremented by one every clock cycle. Once the CCounter value becomes greater than the _Thresint_, we check whether the following condition is met or not:  
\[\textbf{{Thres}}_{\textit{lower}}<\textbf{{RCounter}}<\textbf{{Thres}}_{ \textit{upper}} \tag{1}\]  
If the condition is met, then we increment ACounter value by one. Otherwise, we reset the ACounter value to '0'. Once the ACounter value hits _Thresacc_, the mitigation trigger signal is asserted. In other words, our mitigation mechanism is triggered when the condition in Equation (1) is consecutively satisfied by _Thresacc_ times. In this work, the threshold values (_Thresint_, _Threslower_, _Thresupper_, and _Thresacc_) are determined, as shown in Table 2. Because our detection method is novel and the threshold values are newly introduced in this paper, we use an empirical method by running the simulations to determine the threshold values without referring to the results from the literature. The _Thresint_ determines how frequently the detection mechanism is carried out. The lower _Thresint_, the more frequent detection mechanism we can perform. However, low _Thresint_ may increase the false alarm rates because of the short detection time intervals. Through architectural simulation, we empirically determine _Thresint_ as 100,000. The _Threslower_, _Thresupper_, and _Thresacc_ should be determined by considering the program characteristics. _Threslower_ and _Thresupper_ are related with the intensiveness of the shared resource accesses that are caused by the malicious codes. Figure 6 shows the range of the  
Figure 5: Hardware block diagram for our proposed detection mechanism. The detection hardware is installed in each core. RCounter for each workload (malicious codes and selected SPEC2006 workloads). The normal workloads show wider ranges of the RCounter values, while the malicious code only shows a limited range (roughly 600-1200). Based on this observation, we conservatively set the \(\textbf{{Thres}}_{lower}\) and \(\textbf{{Thres}}_{upper}\) as 600 and 1200, respectively. \(\textbf{{Thres}}_{acc}\) is related to the steadiness of the shared resource accesses caused by the malicious codes. From the simulations, we confirm that the normal programs are not likely to satisfy the condition in Equation (1) consecutively by 400. Thus, we conservatively set the \(\textbf{{Thres}}_{acc}\) as 500 to minimize the false alarm. Although there could be a little better threshold values for our environment (because our work determines the threshold values not formally, but empirically), our detection and mitigation techniques can still successfully thwart the attack, as will be shown in Sections 5.2 and 5.3.