## 6 Discussion  
MATANA is a framework suited for designing and implementing specific runtime detection logics (both hardware and software) for different classes of attacks. Even if we only described experiments for two specific attacks in this paper, we are highly confident \begin{table}
\begin{tabular}{l c c c c c c c c c} \hline \hline \multirow{2}{*}{**Program**} & \multicolumn{8}{c}{**GadgetSizeThreshold**} \\ \cline{2-10}  & **8** & **9** & **10** & **11** & **12** & **13** & **14** & **15** & **16** \\ \hline CoreMark * & 4 & 7 & 10 & 11 & 11 & 11 & 13 & 17 \\ CoreMark-PRO * & 4 & 7 & 10 & 11 & 11 & 11 & 13 & 54 \\ Embench wikisort & 4 & 758 & 788 & 800 & 801 & 801 & 801 & 801 & 801 \\ Embench others * & 4 & 7 & 10 & 11 & 11 & 11 & 13 & 17 \\ Dhrystone & 4 & 7 & 10 & 11 & 11 & 11 & 11 & 17 \\ STREAM & 4 & 7 & 7 & 11 & 11 & 11 & 11 & 17 \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Maximum value of _GadgetCounter_ observed with different values of _GadgetSizeThreshold_ configured in detection logic, during the non-attack-related benchmark’s execution. Sets of benchmarks are noted with a *. that some suited detection logics can be designed and integrated in MATANA for other classes of attacks. For instance, if we consider microarchitectural attacks such as Flush + Reload and Spectre, we can observe that they both exhibit short sequences of repeated instruction patterns and that they use hardware components such as the cache and the branch predictor in a particular way. As a consequence, there is a high probability that they are distinguishable from legitimate programs with patterns based on the instructions executed and hardware events even at low frequency. MATANA can of course be used along with other defense mechanisms to improve detection efficiency. Existing attack detection techniques, such as those cited in Section 2, can be a source of insight of probed signals and detection logics. Other classical detection or mitigation mechanisms such as Control Flow Integrity and shadow stack can be implemented in MATANA's Detection Module, by using an isolated hardware memory zone to store the control flow graph or shadow return address and performing a check when encountering jump instructions. Finally, let us note that in addition to attack detection, MATANA can be used to analyze the information leakage of hardware components or to design more secure hardware components and more security-oriented HPCs. Several limitations of MATANA can be identified. First, during the design phase, a deep understanding of target components and attacks is necessary, with possibly a large number of experiments required to identify interesting probed signals and design the appropriate detection logic. This limitation is not really specific to MATANA but is rather due to the complexity of attacks and defense mechanisms at the microarchitecture level. Second, if new classes of attacks are discovered, and if they only partially impact the implemented probed signals, the detection accuracy may be reduced compared with a detection system built with a more specific set of probes. Indeed, as explained in Section 4.1, for final product integration, we propose using a static set of limited probes and a reconfigurable Detection Module for the best balance between performance and detection efficiency. Nevertheless, in that case, we are still confident that the ability to build fine-tuned detection logics makes it possible to build suited detection logics, even if not perfect. Third, since the detection algorithms are both implemented in the hardware Detection Module and in a software kernel module, the kernel module must be trusted. Several solutions may be proposed for that purpose according to the architecture of the SoC considered. If the SoC embeds a Trusted Execution Environment (TEE)--which is quite realistic for embedded critical systems--which are the most likely to adopt protection mechanisms such as those proposed in this paper, the privileged software may be implemented in the TEE.