## 5 Use Cases of Attack Detection with Matana
### Use Case: Prime + Probe Cache Attack Detection
#### 5.2.3 Design of the Detection Algorithm
For the Target processor ISA (i.e., RISC-V), the set of instructions are rdcycle, rdtime, and rdinstret. As we can see in Table 2, this approach is very effective and does not exhibit false positives. For _MemAccess_, since the number of cache lines in a set is 8 in our implementation, the pattern detection tries to identify the presence of 8 consecutive memory accesses typically used in Prime. More precisely, we extract from the memory address the cache tag and cache set index, and increment the counter when the target set has been recently used but not the tag. For this second heuristic, we also obtained interesting results: as it can be observed in Table 2, this heuristic exhibits some false positives, but the occurrence of the pattern is much more important in case of an attack. In addition, the mean number of cycles between two increments of _MemAccess_ is much shorter than for _InstTimer_, which means that _MemAccess_ is also very sensitive. This can be an interesting approach when, for instance, an untrusted black box software must be executed and we want to carefully analyze its behavior related to cache attack. Let us note that:  
* Regarding _InstTimer_, the timer-instruction-based pattern may be limited when cache attacks are not based on such timer instructions, but adopt a less-accurate timing measurement strategy by using other mechanisms such as a kernel library or a counter in a loop in a different core. To cover this kind of attack, it is possible to check the physical address of the library function (provided by the software Detection Module) or the loop counter (found using instruction-based or address-based pattern matching) and look for access to these suspicious addresses instead of timer instruction. * Some attacks, such as rowhammer, only use cache eviction and do not need any time measurement. Thus, the timing-instruction-based approach is not effective and the memory-access-instruction-based approach should be investigated instead. * The _MemAccess_ is indirectly an estimation of the misuse of the cache. Basically, accessing data within a specific set but with addresses with different tags very often breaks both temporal and spatial locality principles. As a consequence, an investigation on the adaptation of software to carefully use the cache would be an interesting approach to take advantage of the sensitivity of _MemAccess_ to secure the execution, especially for critical systems that have dedicated software. * We also tested other heuristics, such as detection strategies based on cache event occurrence per _DM cycle_ or based on consecutive load instruction to access a list of address. However, as these detection patterns exhibited false positive and negative rates that were not satisfying, they were not sufficiently relevant to discriminate \begin{table}
\begin{tabular}{l r r r r r} \hline \hline  & & \multicolumn{2}{c}{**InstTimer**} & \multicolumn{2}{c}{**MemAccess**} \\ \cline{3-5}
**Program** & **Cycles** & \multicolumn{1}{c}{**Nb. of Detection**} & \multicolumn{1}{c}{**Mean Period**} & \multicolumn{1}{c}{**Nb. of Detection**} & \multicolumn{1}{c}{**Mean Period**} \\ \hline CoreMark * & 53,452,817 & 0 & N/A & 161 & 332,005 \\ CoreMark-PRO parser & 67,632,009 & 0 & N/A & 29,174 & 2318 \\ CoreMark-PRO others * & 1,163,695,064 & 0 & N/A & 7854 & 148,166 \\ Embench * & 43,957,696 & 0 & N/A & 162 & 271,344 \\ Dhrystone & 11,242,585 & 0 & N/A & 175 & 64,243 \\ STREAM & 40,513,182 & 0 & N/A & 140 & 289,380 \\ Attack SingleProcess & 108,337,476 & 572,429 & 189 & 1,339,213 & 81 \\ Attack SharedMemory & 724,951,250 & 553,060 & 1311 & 926,154 & 783 \\ Cache Profiling set 0 & 976,975 & 39,985 & 24 & 118,522 & 8 \\ Cache Profiling set 1 & 816,452 & 39,985 & 20 & 116,022 & 7 \\ Cache Profiling all set & 15,594,885 & 1,299,297 & 12 & 5,294,473 & 3 \\ No program & 112,200 & 0 & N/A & 77 & 1457 \\ Sleep 1 & 168,206 & 0 & N/A & 96 & 1752 \\ \hline \hline \end{tabular}
\end{table}