## 5 Experiments and Results
### Comparison with Other Integrity Protection Methods  
We compare HIIMA with recent integrity protection methods, mainly considering their security and practicability [1; 5; 10; 11; 12; 31; 32]. Their security means that the protection method can deal with multiple security threats and prevent attackers from tampering with data or hijacking the control flow. Practicality is evaluated through the resource overhead and performance overhead. Table 9 demonstrates the comparison results. Researchers usually use different metrics to evaluate the resource overhead of the proposed methods, such as the occupied slices, the increase in the code size or the binary size, the area, and the storage overhead. However, when evaluating the performance overhead, they usually use a metric such as CPI, which can illustrate the increase in the time it takes for the embedded system to execute the benchmarks before and after adding the proposed method. The purposes of [1; 11] are to protect the integrity and confidentiality of dynamic data when embedded systems execute programs. The purpose of [10] is to ensure the runtime code's integrity in the embedded systems. Ref. [5] proposed the MicroGuard to securely execute applications and resist code reuse attacks (CRAs). Ref. [23] aimed to protect the CFI of the executing program. Ref. [31] proposed the HCIC to resist CRAs \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Benchmarks** & **CPI without HMM** & **CPI with HMM** & **Performance Overhead** \\ \hline OpenECC & 2.94 & 3.07 & 9.52\% \\ SHA1 & 2.12 & 2.23 & 5.19\% \\ FFT & 2.32 & 2.41 & 6.03\% \\ CRC16 & 1.68 & 1.78 & 3.57\% \\ BasicMath & 2.41 & 2.53 & 8.71\% \\ AES & 3.46 & 3.59 & 6.36\% \\ Bitcount & 1.52 & 1.64 & 5.92\% \\ Blowfish & 3.54 & 3.87 & 4.80\% \\ Patricia & 1.52 & 1.65 & 7.89\% \\ QuickSort & 1.86 & 1.98 & 3.76\% \\ \hline Average & 2.34 & 2.48 & 6.18\% \\ \hline \hline \end{tabular}
\end{table} 
Table 8: The performance overhead of the processor configured with HMM. without extending ISAs, modifying the compiler, or leaking the encryption/decryption key. Ref. [12] proposed the Security-Monitoring Unit (SMU) to monitor both the DI and the CFI of running instructions. Ref. [32] proposed the Dynamic Sequence Checker (DSC) to verify the validity of the control flow, and the DSC could also check the DI of BBs. The methods proposed in [1, 10, 11], and [12] are the previously published results by members of our lab. Furthermore, the FPGA, benchmarks, and the design software used in these references are essentially the same as those used in this paper. These methods [1, 10, 11] mainly protect the data integrity. Both [1, 11] protect the normal operation of the program by checking the integrity of dynamic data. The performance overhead of [1] is only 2.65%, and the performance overhead of [11] is less than 2.27%. However, neither [1] nor [11] can prevent attackers from hijacking the control flow. Due to the protection object being outside the chip, both [1, 11] require additional encryption modules, which consume an amount of on-chip resources. In addition, Ref. [1] and Ref. [11] are also difficult to resist side-channel attacks. Ref. [10] checks the integrity of the binary code, and its performance overhead is less than 3.45%. Ref. [10] also cannot prevent attackers from destroying the CFI. These methods [5, 23, 31] mainly protect the control flow integrity. Ref. [5] can resist CRAs for large programs, but this method will greatly increase the program code size, and the performance overhead is more than 19%. Ref. [23] presents a lightweight CFI solution for bare-metal embedded systems. This method only needs an increase of less than 4% in additional code to resist ROP attacks and JOP attacks. However, its performance overhead is unstable. For some programs, the performance overhead of [23] is less than 1%, while for some programs, the performance overhead will be 193%. Ref.