## 5 Use Cases of Attack Detection with Matana
### Use Case: Return-Oriented Programming Attack Detection
#### 5.3.3 Design of the Detection Algorithm  
For this use case, the hardware Detection Module is synchronized with the processor, which means that the _DM cycle_ is equal to the processor cycle. This configuration allows us to simplify some part of the detection algorithm while the methodology can be adapted to slower frequencies. 1. **Signal Selection. ** As we were confident in the fact that ROP attacks can be detected mainly by analyzing the instructions flow and identifying jump instructions, we only selected signals related to this flow: 32-bit instruction signal and 1-bit instruction valid signal. 2. **Probe Connection. ** As the hardware Detection Module is synchronized with the processor, no special Probe Connection is needed, which means that the probed signals are directly connected to the hardware Detection Module's inputs. 3. **Detection Logic Design. ** A ROP attack is characterized by a certain number of consecutive short instruction sequences (so-called gadgets) that always ends with an indirect jump instruction (jalr instruction). To detect this behavior, the number of instructions between two jalr is traced at runtime. When a jalr occurs, we compare the current instruction count to a threshold value called _GadgetSizeThreshold_ to determine if it is a short gadget (_GadgetSizeThreshold_ is empirically determined). We keep track of the successive short gadgets executed in a dedicated register _GadgetCounter_ and consider an attack when a threshold value _AttackThreshold_ is reached (this value is also empirically determined). To take into account ROP chains that sometimes include longer gadgets, we do not reset to 0 _GadgetCounter_ when a long gadget is detected but decrement the counter by 2 instead. 4. **Benchmarking** The test campaign was carried out in the same way as for the previous use case: (1) reset all detection logic and start monitoring; (2) execute the program under test; (3) stop monitoring and collect information (typically the _GadgetCounter_ value) stored in MMIO registers. The benchmarks used are also the same as in the previous use case. The determination of a suitable _GadgetSizeThreshold_ is highly dependent on existing ROP attacks on a given ISA. To the best of our knowledge, there has been no exhaustive study on the maximum size of the small gadgets used in ROP for RISC-V but some papers show some proof of concept. Studies on x86 ISA [38,39] show that practical ROP attacks generally require a gadget chain longer than 15 with at most 5 instructions for the small gadgets (equivalent to 7 instructions in RISC-V due to the additional 2 instructions for the management of return address register). For this reason, we studied several scenarios with _GadgetSizeThreshold_ ranging from 8 to 16. We evaluated the maximum _GadgetCounter_ values for all non-attack-related benchmarks. Results are provided in Table 4. From this table, the determination of a suited _AttackThreshold_ is quite straightforward and can be set as the maximum value of the measured _GadgetCounter_ of all benchmarks plus one. For instance, for ROP attacks crafted with quite short gadgets (e.g., _GadgetSizeThreshold_ set to 8) we can observe that all benchmarks exhibit a maximum _GadgetCounter_ value less than 5. In that case, a _AttackThreshold_ value of 5 is suited to detect ROP attacks with at least 5 small gadgets of at most 8 instructions. If we increase the threshold of the number of instructions for small gadgets, we observe that the minimal number of small gadgets required to avoid false positives on the non-attack-related benchmarks (i.e., _AttackThreshold_) also increases. Consequently, we can conclude that the accuracy of the detection depends on the typical value of the maximum number of instructions in short gadgets. For instance, for a _GadgetSizeThreshold_ of 14, the detection covers ROP attacks of at least 12 chained short gadgets.