The execution behavior of a microprocessor$(\mu {P})$in the presence of a fault is difficult to predict because of the complex interactions across pipeline stages and between functional units within the architecture. In prior work, we have observed that fault effects do not introduce any type of anomaly in the input-output behavior for 10s of thousands to millions of clock cycles. These characteristics increase the difficulty of evaluating$\mu {P}$architectures for resilience to information leakage events, i.e., scenarios where a fault causes sensitive data, such as an encryption key, to be inadvertently diverted to a primary output channel. In this article, we use an accelerated fault emulation platform implemented on a Xilinx ZCU102 board to evaluate an ASIC implementation of the Potato RISC-V$\mu {P}$for information leakage events as faults from several different classes are introduced. The effectiveness and latency associated with a set of self-assertion-based countermeasures (SABCs), that perform simple consistency checks on instructions and datapath values, are investigated. The countermeasures are characterized as dynamic verification (or as a continuous symptom monitor) because detection occurs during program execution. The detection and latency results of the SABCs are compared against a periodic counter-based countermeasure proposed in previous work.

The RISC-V instruction set architecture open licensing policy has spawned a hive of development activity, making a range of implementations publicly available. The environments in which RISC-V operates have expanded correspondingly, driving the need for a generalized approach to evaluating the reliability of RISC-V implementations under adverse operating conditions or after normal wear-out periods. Fault injection (FI) refers to the process of changing the state of registers or wires, either permanently or momentarily, and then observing execution behavior. The analysis provides insight into the development of countermeasures that protect against the leakage or corruption of sensitive information, which might occur because of unexpected execution behavior. In this article, we develop a hardware–software co-design architecture that enables fast, configurable fault emulation and utilize it for information leakage and data corruption analysis. Modern system-on-chip FPGAs enable building an evaluation platform, where control elements run on a processor(s) (PS) simultaneously with the target design running in the programmable logic (PL). Software components of the FI system introduce faults and report execution behavior. A pair of RISC-V FI-instrumented implementations are created and configured to execute the Advanced Encryption Standard and Twister algorithms. Key and plaintext information leakage and degraded pseudorandom sequences are both observed in the output for a subset of the emulated faults.

While several applications exist to fault-test software at the abstract level, gate-level fault testing has traditionally been limited to injecting faults into small, dedicated circuits, due the computational time required for gate-level simulations and the logic resources (LUTs and registers) required for FPGA emulation. In our work, we leverage the extensive resources of the Ultrascale and Ultrascale+ platforms to systematically test faults on all gate-level inputs of an ASIC or FPGA implementation of an embedded processor running a user application. Using a configurable, synthesizable saboteur circuit connected using a scan chain and controlled with a state machine, we tested four different types of faults on each logic gate of the LEON3 CPU running an AES 256 application. The entire process took just under two hours, a 7200X speedup from gate-level simulation. Though neither the hardware nor software employed fault mitigation techniques, we were surprised to discover multiple stuck-at-0, stuck-at-1, and delay faults that resulted in total or partial key and plaintext leakage through the communications serial port. Overall, we identified 22 unique faulty behaviors, four of which involve some form of crypto or memory leakage. These occurred in roughly the same proportions in ASIC and FPGA netlists of the LEON3, suggesting robustness of the analysis to different implementations. Of the four static fault types tested, delay faults were the most effective at uncovering behaviors of concern.