## 5 Use Cases of Attack Detection with Matana
### Use Case: Prime + Probe Cache Attack Detection
#### 5.2.3 Design of the Detection Algorithm  
In this section, we present the different heuristic patterns that we identified for Prime + Probe attack detection by following the aforementioned methodology described in Section 3.3. For this experiment, the reconfigurable hardware Detection Module is set at 1/16 of the processor's frequency. The clock cycle of the hardware Detection Module is called _DM cycle_ in the following. For each benchmark (including attack-related ones), the following steps were followed: (1) reset the internal state of the detection module and start monitoring; (2) execute the program under test; (3) stop monitoring and collect information stored in MMIO registers. To evaluate the impact of the experimental setup, we also executed the setup with no program executed, and to test the impact of the OS, we executed the standard system call sleep as in other benchmarks. During the run, the software Detection Module sends the PID at context switch to the hardware Detection Module to help identify kernel-related activities. The benchmarks are built by means of the same toolchain described in Section 5.1. The benchmarks include (1) all 3 CoreMark runs, (2) all 11 CoreMark-PRO programs for single context, (3) all 19 Embench programs with time measurement using rdcycles, (4) the Dhrystone benchmark, and (5) the Stream benchmark with DSTREAMARRAY_SIZE=32768. These benchmarks are selected in order to represent a large range of common algorithms that make use of the CPU and the main memory. 1. **Signal Selection. ** Three categories of signals seem relevant to detect Prime + Probe attacks. First, instruction-flow-related signals, i.e., the instruction currently executed as well as the instruction valid signal in the processor's pipeline are useful to identify instruction patterns. Second, as cache side-channel attacks perform a lot of carefully chosen memory access, the signals associated to the memory access seem relevant. We chose the virtual address sent in the processor's pipeline and the physical address obtained in the L1 data cache. Third, inspired by some detection techniques based on HPCs proposed in several research papers [12; 14], several cache events (cache miss, cache access, and cache TLB miss) are also relevant. 2. **Probe Connection. ** The instruction signals are collected by means of a Parallel Connection that is more suited in order to preserve the maximum value and time information. The address and the cache event signals are collected by means of an Extraction Connection, in such a way that we only keep one single valid address and one single cache event per _DM cycle_. This choice was purposely made because the memory accesses take multiple cycles in a cache hit and even more in a cache miss. This was confirmed by our experimentation, showing that one value per _DM cycle_ is enough to preserve sufficient information for detection. 3.4. **Detection Logic Design./ Benchmarking. ** Prime + Probe attacks are closely linked to the time measurement, which can be performed by means of various instructions that are dependent on the target processor ISA. By analyzing the code presented in Listing 1, we note that there are always two time measurement instructions (so-called timer instructions in the following) relatively close to each other used to measure the time to access 8 memory addresses. To identify this pattern, we developed two different heuristics: _InstTimer_, which analyses the use of specific instructions; _MemAccess_, which tries to identify patterns in memory access. For evaluation purposes, each heuristic has been associated to a counter to evaluate the occurrence of the corresponding pattern during the benchmark's execution. Table 2 provides the evaluation of the two heuristics for the proposed benchmarks. For _InstTimer_, we set a detection window and count the use of specific timer instructions within. The detection window starts at the first detection of a timer instruction; if another specific instruction occurs during the window, we increment the _InstTimer_ counter.