Patent Application
20250199065
Fault injection simulation is a testing technique used in software and hardware development to evaluate how a target system behaves when subjected to errors. The technique involves intentionally injecting faults or errors into the target system to assess its robustness, reliability, and fault tolerance. However, fault injection simulation on a full system with peripherals and cycle accuracy is difficult to achieve, and thus, results in less realistic testing (e.g., simulating interrupt mechanisms).
Fault injection emulation through debugger on hardware may be used to achieve better results. However, using such a debugger is also not ideal due to a typically slow connection and many communication cycles. Additionally, complex fault modelling impacts negatively on testing time since parameter search space increases exponentially for various fault types, such as memory corruption, or multiple instruction skips and wrong branching.
Device under test, fault injection (FI) testing system and method for FI testing uses an on-device FI module operable to execute FI testing on a processor core on the device under test through a debug module. The device under test includes a debug port designed to receive external protocol-specific debug signals and a debug transport module connected to the debug port. The debug module is connected to the debug transport module to receive the core-specific debug signals.
In an embodiment, a device under test comprises a debug port designed to receive external protocol-specific debug signals, a debug transport module connected to the debug port, the debug transport module being operable to translate protocol-specific debug signals into core-specific debug signals, a debug module connected to the debug transport module to receive the core-specific debug signals, a processor core operatively connected to the debug module, and an on-device FI module operable to execute FI testing on the processor core through the debug module.
In an embodiment, the FI testing system further comprises a multiplexer connected to the debug port and the on-device FI module to selectively connect one of the debug port and the on-device FI module to the debug transport module to access the processor core.
In an embodiment, the on-device FI module is operable to generate internal protocol-specific serial debug signals to be translated into the core-specific debug signals to control the debug module for the FI testing.
In an embodiment, the FI testing system further comprises a multiplexer connected to the debug transport module and the on-device FI module to selectively connect the debug transport module or the on-device FI module to the debug module to access the processor core, wherein the multiplexer is controlled by the on-device FI module.
In an embodiment, the on-device FI module is operable to generate particular core-specific debug signals to control the debug module for the FI testing.
In an embodiment, the on-device FI module is operable to generate testing-related signals to execute steps of the FI testing for each fault address being tested by the on-device FI module.
In an embodiment, the on-device FI module is operable to inject a fault when a breakpoint at a fault address is triggered to determine whether a breakpoint is triggered at a positive or negative path address, wherein the positive path address is an address where an execution is supposed to go in case of a fault injection attack and the negative path address is an address wherein the execution is not supposed to go in case of a fault injection attack.
In an embodiment, the on-device FI module is operable to compare contents of memory or registers when a breakpoint is triggered at a particular positive path address or for timeouts.
In an embodiment, a method for performing FI testing on a device under test (DUT) comprises configuring an on-device FI module on the DUT from a host computer connected to the on-device FI module without using a debug port of the DUT, generating testing-related signals to execute steps of the FI testing for each fault address being tested by the on-device FI module, transmitting the testing-related signals to a processor core on the DUT from the on-device FI module through a debug module on the DUT, generating a report for all the fault addresses tested at the on-device FI module, and downloading the report from the on-device FI module to the host computer for analysis.
In an embodiment, the method further comprises connecting the on-device FI module to a debug transport module on the DUT through a multiplexer on the DUT to transmit internal protocol-specific serial debug signals generated by the on-device FI module to the debug module for the FI testing.
In an embodiment, the method of claim further comprises connecting the on-device FI module to the debug module through a multiplexer to transmit testing-related core-specific debug signals generated by the on-device FI module to control the debug module for the FI testing.
In an embodiment, the transmitting the testing-related signals to the processor core on-device FI module includes injecting a fault when a breakpoint at a fault address is triggered to determine whether a breakpoint is triggered at a positive or negative path address, wherein the positive path address is an address where an execution is supposed to go in case of a fault injection attack and the negative path address is an address wherein the execution is not supposed to go in case of a fault injection attack.
In an embodiment, the method of claim further comprises comparing contents of memory or registers when a breakpoint is triggered at a particular positive path address or for timeouts.
In an embodiment, an FI testing system comprises a host computer including a debugger and an FI testing manager, and a device under test comprising a debug port designed to receive external protocol-specific debug signals managed by the debugger, a debug transport module connected to the debug port, the debug transport module being operable to translate protocol-specific debug signals into core-specific debug signals, a debug module connected to the debug transport module to receive the core-specific debug signals, a processor core operatively connected to the debug module, and an on-device FI module operable to execute FI testing on the processor core through the debug module, the on-device FI module being directly connected to the FI testing manager to receive signals from the FI testing manager.
In an embodiment, the FI testing system further comprises a multiplexer connected to the debug port and the on-device FI module to selectively connect one of the debug port and the on-device FI module to the debug transport module to access the processor core.
In an embodiment, the on-device FI module is operable to generate internal protocol-specific serial debug signals to be translated into the core-specific debug signals to control the debug module for the FI testing.
In an embodiment, the FI testing system further comprises a multiplexer connected to the debug transport module and the on-device FI module to selectively connect the debugger or the on-device FI module to the debug module to access the processor core, wherein the multiplexer is controlled by the on-device FI module.
In an embodiment, the on-device FI module is operable to generate particular core-specific debug signals to control the debug module for the FI testing.
In an embodiment, the on-device FI module is operable to generate testing-related signals to execute steps of the FI testing for each fault address being tested by the on-device FI module.
In an embodiment, the on-device FI module is operable to inject a fault when a breakpoint at a fault address is triggered to determine whether a breakpoint is triggered at a positive or negative path address, wherein the positive path address is an address where an execution is supposed to go in case of a fault injection attack and the negative path address is an address wherein the execution is not supposed to go in case of a fault injection attack.
These and other aspects in accordance with embodiments will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrated by way of example of the principles of the embodiments.
Throughout the description, similar reference numbers may be used to identify similar elements.
It will be readily understood that the components of the embodiments as generally described herein and illustrated in the appended Figs. could be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of various embodiments, as represented in the Figures, is not intended to limit the scope of the present disclosure, but is merely representative of various embodiments. While the various aspects of the embodiments are presented in drawings, the drawings are not necessarily drawn to scale unless specifically indicated.
The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the embodiments is, therefore, indicated by the appended claims rather than by this detailed description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.
Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present invention should be or are in any single embodiment. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present invention. Thus, discussions of the features and advantages, and similar language, throughout this specification may, but do not necessarily, refer to the same embodiment.
Furthermore, the described features, advantages, and characteristics of the invention may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize, in light of the description herein, that the invention can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the invention.
Reference throughout this specification to “one embodiment”, “an embodiment”, or similar language means that a particular feature, structure, or characteristic described in connection with the indicated embodiment is included in at least one embodiment of the present invention. Thus, the phrases “in one embodiment”, “in an embodiment”, and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.
Turning now to
As shown in
The DUT 104 further includes a debug port 122, which allows the debugger 106 in the host computer to access the CPU core 110 via a multiplexer 124, a debug transport module (DTM) 126 and debug module 128. The DUT also includes an on-device fault injection module (OFIM) 130 that can execute FI testing on the CPU core 110 via the multiplexer, the DTM and the debug module.
The debug module 128 is a core-specific hardware component that operates to assist in debugging and testing the CPU core 110. The debug module can perform tasks, such as halting the core's execution, inspecting registers and memory, setting breakpoints and tracing program execution. The DTM 126 operates to convert or translate protocol-specific serial debug signals (e.g., Joint Test Action Group (JTAG) signals) into core-specific debug signals (e.g., Debug Module Interface (DMI) signals) for the debug module 128. The protocol-specific serial debug signals may originate from the debugger 106 as external signals or from the OFIM 130 as internal signal, which are selectively transmitted to the DTM 126 through the multiplexer 124. The multiplexer 124 is controlled by the OFIM 130. In an embodiment, the debugger 106 may be used as a debug controller to control the debugging and testing of the CPU core 110.
The OFIM 130 operates to automatically execute a test binary and inject different faults at different locations. These faults are software faults and, hence, are restricted to programmer's model and can be induced using debugging capabilities, which include data and instruction flow modifications, and exclude direct faulting of internal registers (Register Transfer Level-RTL, non-observable by software). The emulated faults are injected while the CPU core 110 is halted, which can happen due to a triggered breakpoint at a desired location within the test binary. Thus, the injection mechanism of the OFIM requires an access to basic debugging capabilities using the debug module 128. In particular, the OFIM 130 may be designed to:
Using the OFIM 130, a security analyst can efficiently test the behavior of the embedded software in the presence of different types of faults. The OFIM provides an automation of fault injection at different locations within a binary. The locations (i.e., instruction addresses) and the type of injected faults are specified by the user in advance.
In an embodiment, the FI testing manager 108 located on the host computer 102 operates to configure the OFIM 130 over a communication channel 132, which may be a dedicated high speed serial communication channel, such as a Serial Peripheral Interface (SPI) bus. Thus, the OFIM 130 includes an interface 134 to connect to the FI testing manager 108 via the communication channel 132. The communication interface and protocol between the host computer and the OFIM can vary. The configuration of the OFIM 130 may include sending over data that includes, but not limited to, (1) a fault address list, (2) positive path addresses, (3) negative path addresses, and (4) a timeout parameter, and (5) expected memory and register content. The fault address list is a list with instruction addresses, a.k.a. fault locations and a fault type per fault location. The user would need to manually analyze the tested code for potential fault injection locations and retrieve the addresses from the binary. The positive path addresses include a list of addresses where the execution is supposed to go in case of a fault injection attack, which means that no vulnerability is detected if one of the positive addresses is reached. The negative path addresses include a list of addresses where the execution is not supposed to go in case of a fault injection attack, which means that a vulnerability is discovered if one of the negative addresses is reached. The timeout parameter is the amount of time (e.g., in cycles or seconds) the OFIM will wait for the breakpoints at positive and negative addresses to trigger. The expected memory and register content is an optional configuration in which a user can specify what values certain portions of memory and GPRs may contain after a successful fault injection.
Once the OFIM 130 has been configured, the FI testing manager 108 sends a “start signal” after which the OFIM automatically performs execution and fault injection of the software under test. After the tests are performed, the FI testing manager downloads the results of the fault injection campaign and provides them to the user for further investigations.
As described above, the OFIM 130 receives the configuration data over the communication channel 132 and stores the data internally. For each address in a fault address list, the OFIM performs the following actions using the debug access port of the CPU core 110:
After all the addresses in the fault address list have been tested, a campaign report is prepared by the OFIM for download.
Turning now to
Next, at step 206, a start signal is transmitted to the OFIM 130 from the FI testing manager 108 to start the FI campaign. In response to the start signal, the OFIM performs steps 208-224 for each fault address.
At step 208, the CPU core 110 is reset and halted by the OFIM 130. Next, at step 210, timeout and breakpoints are configured in the CPU core 110 by the OFIM. Next, at step 212, the CPU core is resumed by the OFIM. Next, at step 214, a breakpoint at the fault address in the CPU core is triggered by the CPU core, which is detected by the OFIM Next, at step 216, a fault is injected in the CPU core by the OFIM.
In response to the fault injection, a breakpoint is triggered in the CPU core 110, at step 218, which is detected by the OFIM 130. Next, at step 220, memory/register contents are retrieved from the CPU core by the OFIM. Next, at step 222, the retrieved contents are compared to reference values by the OFIM. Next, at step 224, the results of the run are saved by the OFIM, which will be used to produce the FI campaign report.
After all the fault addresses have been tested, an FI campaign report is downloaded from the OFIM 130 by the FI testing manager 108, at step 226, which completes the FI testing process.
Turning now to
As shown in
The FA ENCOUNTER state 312 is the state when a fault location is encountered. While the core is executing the code, the core will eventually encounter a fault location. At this point, the CPU core 110 is halted and a fault can be injected. The RUN FAULTED state 314 is the state at which the fault has been injected and the execution can be continued. The NP ENCOUNTER state 316 is the state at which a negative path has been executed, which means that a vulnerability has been discovered and the current fault address needs to be stored for the report. The PP ENCOUNTER state 318 is the state at which a positive path has been triggered by a breakpoint, which means that the program behaved as expected. Thus, the OFIM 130 needs to examine the contents of the memory and GPRs. The TIMEOUT state 320 is the state at which neither a positive or negative path has been executed, and an internal OFIM counter/timer has expired. At this state, the contents of the memory and/or GPRs can be verified. The VALUES CHECKED state 322 is the state at which the contents of the memory and/or GPRs have been compared to the reference value. Thus, the current fault address should be saved in case of a deviation in the contents, and the campaign can continue with the next test run. The TEST END state 324 is the state at which the FI campaign has been executed, and the user can download the results. The ERROR state 326 is the state to which any unhandled event at one of the other state is transitioned, as represented by the open-ended arrows in
There are two ways the OFIM 130 can be connected to the debug module 128 in order to control the CPU core 110 for fault injection testing. The first option involves connecting the OFIM to the DTM 126 directly via the multiplexer 124 and using a unified debug protocol, such as JTAG, as illustrated in
With respect to the first option, the OFIM 130 is directly connected to the DTM 126, which converts protocol-specific serial debug signals (e.g., JTAG) generated by the OFIM into core-specific debug signals, as shown in
Using this approach, a standardized protocol can be used to control the CPU core 110, which increases the portability of the OFIM 130 since few changes are required to deploy the OFIM for different DUTs. In addition, connecting the OFIM to the DTM 126 is less invasive because the OFIM only uses public interfaces of the debug components. Furthermore, this approach can be applied to closed core developments (e.g., ARM cores). However, the use of the DTM reduces the debug performance because the DTM has to translate the protocol-specific debug commands into the core-specific signals, also because the transport protocol used to communicate to the debug module 128 is often times slower than counterparts (e.g., SPI>JTAG).
With respect to the second option, the OFIM 130 is attached to the debug module 128 directly and has the same capabilities as the DTM 126, as illustrated in
An advantage of this approach is that it is significantly faster because the DTM 126 is not involved. However, this option is only available if the DTM and the debug module 128 can be decoupled (e.g., RISC-V architecture). In addition, this approach is less portable as the OFIM 130 uses one or more internal interfaces of the debug module which may differ for different architectures. Furthermore, this approach is more invasive as the OFIM accesses the internal interfaces of the debug module.
A method for performing FI testing on a DUT such as the DUT 104, in accordance with an embodiment of the invention is described with reference to a process flow diagram of
Although the operations of the method(s) herein are shown and described in a particular order, the order of the operations of each method may be altered so that certain operations may be performed in an inverse order or so that certain operations may be performed, at least in part, concurrently with other operations. In another embodiment, instructions or sub-operations of distinct operations may be implemented in an intermittent and/or alternating manner.
It can also be noted that at least some of the operations for the methods described herein may be implemented using software instructions stored on a computer useable storage medium for execution by a computer. As an example, an embodiment of a computer program product includes a computer useable storage medium to store a computer readable program.
The computer-useable or computer-readable storage medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device). Examples of non-transitory computer-useable and computer-readable storage media include a semiconductor or solid-state memory, magnetic tape, a removable computer diskette, a RAM, a ROM, a rigid magnetic disk, and an optical disk. Current examples of optical disks include a compact disk with read only memory (CD-ROM), a compact disk with read/write (CD-R/W), and a digital video disk (DVD).
Alternatively, embodiments of the invention may be implemented entirely in hardware or in an implementation containing both hardware and software elements. In embodiments that use software, the software may include but is not limited to firmware, resident software, microcode, etc.
Although specific embodiments of the invention have been described and illustrated, the invention is not to be limited to the specific forms or arrangements of parts so described and illustrated. The scope of the invention is to be defined by the claims appended hereto and their equivalents.
