## 3 Preliminaries
### Program Execution Monitoring Based on Basic Block
#### 3.1.1 Partition of the Program Basic Block  
According to our previously-reported literature of instruction execution security [26], hardware-assisted integrity signature monitoring is an effective technique to monitor unintended program behaviors. In that scheme, the program basic block (BB) is defined as a sequence of consecutive instructions, which starts from the program's first instruction and ends with the branch or jump instruction. Each BB block is assigned with an integrity signature for the real-time BB integrity verification. The integrity signatures of the BBs are calculated beforehand from the associated instruction information and then copied onto the monitor memory before the program is loaded for execution. During program execution, the integrity signature of each BB is recalculated from the executed instructions and compared with the previously-stored ones to validate the BB instruction integrity. In general, the performance overhead of hardware monitoring is relevant to the integrity signature checking speed, and further, the speed of integrity validation depends on the BB granularity. Therefore, we partition programs strictly according to the transfer type instructions, where BB is a fine-grained partition scheme to monitor the potential instruction modified issues of deletion, tampering, and injection, and it can keep up with the CPU's execution pipeline. The program execution order can be regarded as having a natural hierarchical structure according to the instruction transfer operations. Taking the six transfer instructions from the OpenRISC ISA as an example, their instruction jump operations are described in Table 1. The six transfer instructions can be conveniently categorized into the direct branch (\(l.bfN\) and \(l.bfN\)), direct jump (\(l.j\)\(N\) and \(l.jal\)\(N\)), and indirect jump (\(l.jalr\)\(rB\) and \(l.jr\)\(rB\)) according to the instruction transfer types. In this, when the direct branch instructions of \(l.bfN\) and \(l.bfN\) branch or not (depending on whether the status register (SR)'s flag-bit are set or cleared), the effective branch address (EBA) after instruction operation will be sent to the program counter (PC); the direct jump instructions of \(l.j\)\(N\) and \(l.jal\)\(N\) directly send their jump target addresses to PC; and the indirect jump instructions of \(l.jalr\)\(rB\) and \(l.jr\)\(rB\) jump to the jump target address in the rB register. The \(l.jalr\)\(rB\) instruction stores the next instruction address of the delay instruction into the link-address register (LR). Depending on these six transfer type instructions, the GNU Cross Compilation Toolchain of or32-elf-gcc matched with OpenRISC ISA is utilized to generate a binary executable file; and the GNU tool or32-elf-objdump is utilized to disassemble the binary executable file into a text file. We can employ regular expressions to search all the function entries, jump instructions, and target addresses; therefore, we can partition programs into BB segments from disassembling text files at the offline preparation phase. Consequently, a sequence of consecutive instructions of each BB starts from the program's first instruction (or the last jump instruction's target address) and ends with the next transfer instruction; therefore, there is no branch or jump transfer operation in the middle of each BB. It is noteworthy that, in the five-stage execution pipeline of OpenRISC CPU, it takes at least two clock cycles between fetching instruction from the target transfer address and entering the instruction execution that will cause CPU execution pipeline discontinuity, where the branch delay slot is the wasted clock spaces following the conditional branch and jump instructions. We considered the delay slot mechanism to reduce processor performance loss. To improve the execution efficiency of CPU, the delay slot instruction was also partitioned into each BB for filling the execution pipeline clock gap to follow the branch or jump instruction as the end boundary of each BB.