## 5 Experiments and Results
### Security Capability Evaluation  
An important consideration of the CPU-SPU collaborative SoC is its security capability. In order to validate the effectiveness of the proposed SPU on program execution monitoring and fault self-repairing, we utilized the OpenRISC debugging system of OR1K to observe the program execution, instruction modification, exception output, and interrupt location. This debugging system consists of the Joint Test Action Group (JTAG)-TAP module and the Advanced debug interface (ADI), which acts as an interface to directly communicate with the processor core and Wishbone system bus so that we can start and break the execution pipelines of programs and read or write processor internal registers by accessing the CPU. We performed instruction tampering evaluations aimed at both nontransfer instruction tampering and transfer instruction tampering from the different locations of processor core, I-Cache, flash memory, and source program code. Conveniently, we also selected the partial instructions from the instruction stream of benchmark OpenECC (as shown in Figure 2) as an example, in which, the nontransfer instruction _l.nop 0x0_ was artificially tampered with as _l.nop 0x1_ and the branch transfer instruction _l.bf 1f730_ was modified to the different branch address of _l.bf 1f734_. Table 4 presents the security capability evaluations of the CPU-SPU collaborative SoC under different instruction tampering attacks. Figure 12: Performance overheads of ten selected benchmarks under the different sizes of I-Cache. The exception binary results from serial port printing were analyzed and displayed in the upper computer, and their corresponding error_log files were generated for examination. Ultimately, the instruction fault recovery was completed within three clock cycles after the delay slot instruction execution. While the CPU executed the programs of selected benchmarks on the FPGA development platform and printed the control scripts of exception statuses into the upper computer, we can track the embedded system for a malicious attack as shown in Figure 13. The integrity signature validations for the above binary instruction codes at the granularity of BBs can recognize any instruction tampering behaviors in transfer and nontransfer instructions. When the adversary tampered with the nontransfer instruction, the SPU asserted a BB LHash verification error and reported the corresponding BB integrity recalculated value and its correct LHash digest. There was only exception error (\"01\") for nontransfer instruction tampering when the BB integrity checking failed. In addition, there were two invalid statuses for the transfer instruction tampering: the SPU first asserted the exception error (\"01\") when the current BB integrity checking failed, and then another BB absence (\"10\") was reported when the next BB start address (target address of branch/jump) searching missed. We can benefit from the error_logs of both the nontransfer and transfer instruction attacks regarding the BB LHash recognition. From the theory of probability, the anticollision capability of the LHash engine integrity signature for each BB in the hardware-implemented SPU can be represented as follows. \[P(m,n)=\frac{1}{C(m,n)\times 2^{n}} \tag{1}\]  
where \(P(m,n)\) denotes the success probability for adversaries to correctly guess the integrity signature of each BB, in which \(m\) represents the initial digest size of LHash algorithm, and \(n\) represents the length of RNG-selected LHash bits from the \(m\) digest size. In our CPU-SPU design, the success probability for an adversary to reversely derive BB integrity signature is \(\frac{1}{C(96,16)\times 2^{16}}\), which makes it impossible for the adversary to actualize instruction tampering attacks without being detected during the period of each BB execution. Hence, the LHash integrity signature has a good robustness in resisting instruction tampering attacks.