Runtime modification of field programmable gate array or coarseness reconfigurable array to replicate most vulnerable functional circuit behavior

Abstract

The invention provides a data processing device. A determination circuit performs a determination of a vulnerability of each of a plurality of functional circuits in a processing circuit, and a modification circuit modifies a behavior of a reprogrammable circuit to match an architectural behavior of a susceptible functional circuit of the functional circuits in response to the determination.

Description

Technical Field

[0001] The present disclosure relates to data processing, and in particular to the resilience of data processing circuits. Background Art

[0002] In safety-critical systems, it is important that the functional circuitry of the processing circuits is resilient to errors and therefore reliable. Such errors can be transient errors, such as bit flips that occur from particle impacts, or can be more permanent design errors that an attacker can exploit. It may be tempting to build in resilience by duplicating the processing circuits, running the same software on each processing circuit, and then arbitrating between the results of the operations performed by each of the two or even three different processing circuits. However, this requires considerable circuit space and power consumption. Furthermore, it does not help prevent permanent design errors that may be repeated in each processing circuit. Summary of the invention

[0003] From a first exemplary configuration, a data processing device is provided, which includes: a determination circuit, which is configured to perform a determination of the vulnerability of each of a plurality of functional circuits in a processing circuit; and a modification circuit, which is configured to modify the behavior of a reprogrammable circuit in response to the determination to match the architectural behavior of a vulnerable functional circuit in the functional circuit.

[0004] From the second exemplary configuration, a data processing method is provided, which includes: determining the vulnerability of each of a plurality of functional circuits in a processing circuit; and modifying the behavior of a reprogrammable circuit in response to the determination to match the architectural behavior of a vulnerable functional circuit in the functional circuit.

[0005] From a third exemplary configuration, there is provided a computer program for controlling a host data processing device to provide an instruction execution environment, the computer program comprising: determination logic configured to perform a determination of the vulnerability of each of a plurality of functional circuits in a processing circuit; and modification logic configured to modify the behavior of a reprogrammable circuit in response to the determination to match the architectural behavior of a vulnerable functional circuit in the functional circuit. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The present invention will now be further described, by way of example only, with reference to embodiments of the invention as shown in the accompanying drawings, in which:

[0007] Figure 1 A system including an apparatus according to some examples is shown;

[0008] Figure 2An example of different functional units and their vulnerabilities according to one example is shown;

[0009] Figure 3 shows how the fragility of a functional circuit can change over time;

[0010] Figure 4 Examples of assessments of change relative to vulnerability are given;

[0011] Figure 5 Examples are shown in which any number of single functional circuits can have their architectural behavior replicated by a reprogrammable circuit;

[0012] Figure 6 illustrates exemplary behavior of an arbitration circuit that arbitrates between results generated from a reprogrammable circuit and a CPU; and

[0013] Figure 7 A simulator implementation that can be used is shown. DETAILED DESCRIPTION

[0014] Before discussing the embodiments with reference to the drawings, the following description of the embodiments is provided.

[0015] According to an exemplary configuration, a data processing device is provided, which includes: a determination circuit configured to perform a determination of the vulnerability of each of a plurality of functional circuits in a processing circuit; and a modification circuit configured to modify the behavior of a reprogrammable circuit in response to the determination to match the architectural behavior of a vulnerable functional circuit in the functional circuit.

[0016] The above embodiments utilize reprogrammable circuits to replicate the architectural behavior (but not necessarily other behaviors) of the functional circuits in the processing circuit that are determined to be vulnerable. Functional circuits can be considered as elements of the processing circuit that perform specific functions. For example, this can be an integer unit, a floating point unit, a load / store unit, and the like. When replicating the architectural behavior, the circuit is modified so that the reprogrammable circuit acts in a manner consistent with the requirements of the vulnerable functional circuit. That is, for the two circuits, the input-output mapping will be the same. However, other behaviors (for example, a specific way of generating outputs for specific inputs) may be different. Since the functionality of a specific functional circuit is reproduced, energy is saved compared to the case of replicating the entire processing circuit (possibly multiple times). For example, this is helpful when not every part of the processing circuit may be vulnerable at the same time. This depends not only on the natural vulnerability of the circuit, but also on the actual instructions being executed at a particular moment. For example, if most of the instructions being executed at a particular moment are integer instructions, the vulnerability of the floating point processor may be lower. As another example, if all instructions being executed at a particular moment are integer instructions, then in the case where the natural fragility of the circuit for integer operations is low (for example, in the case where there are few flip-flops / transistors, etc.), the fragility may still not be low. Since only the architectural behavior is replicated, design errors in vulnerable functional circuits can be avoided. In addition, since the behavior of the reprogrammable circuit can be programmably modified, the exact behavior can be changed after the processing circuit has been manufactured. Therefore, design errors that become obvious after manufacturing can be solved, and errors can be detected and recovered from. Fragility can be measured in many ways. However, one way to measure this is through the architectural vulnerability factor (AVF). This measurement represents the probability that a fault in the structure of the circuit will be visible within the program being executed. This not only takes into account the above-mentioned considerations about fragility, but also recognizes the fact that not every error that occurs will inevitably lead to observable faults at the program level. For example, an error that occurs in prefetching will simply cause the wrong data to be prefetched. However, this does not inevitably lead to any observable problems in the underlying program. Similarly, in the case of a branch predictor. While such a failure may result in inefficient computation, it is not inevitably detectable.AVF (and other measures of vulnerability) may be performed offline or may be determined "live".

[0017] In some examples, the data processing apparatus includes arbitration circuitry configured to arbitrate between results for a vulnerable functional circuit and between reprogrammable circuitry that matches the architectural behavior of the vulnerable functional circuitry. The arbitration circuitry determines how to coordinate the vulnerable functional circuitry with the reprogrammable circuitry whose behavior has been reprogrammed to act architecturally in the same manner as the vulnerable functional circuitry. There are a variety of ways in which this can be done.

[0018] In some examples, in the cross-check mode, the arbitration circuit is configured to compare the results of the reprogrammable circuit that matches the architectural behavior of the vulnerable functional circuit with the results of the vulnerable functional circuit and perform an error action in response to a mismatch. In these examples, both the vulnerable functional circuit and the reprogrammable circuit that is reprogrammed to match the architectural behavior of the vulnerable circuit are used to perform a specific operation. The results are then compared to each other. If the results match, the results are allowed to continue. Otherwise, an error action occurs. In some examples, some preemption elements can be allowed. That is, it can be assumed that the operation is correctly performed by the vulnerable functional circuit. Once the results from the reprogrammable circuit are available (which may occur at a later time), any mismatch in the results will cause an error to occur.

[0019] In some examples, the error action includes activating a replacement mode in which results of the vulnerable functional circuit are replaced with results of a reprogrammable circuit that matches the architectural behavior of the vulnerable functional circuit. Having determined that there is a mismatch between results produced by the vulnerable functional circuit and the reprogrammable circuit that was reprogrammed to match the architectural behavior of the vulnerable functional circuit, the reprogrammable circuit effectively "replaces" the vulnerable functional circuit whose architectural behavior has been determined to be potentially unreliable.

[0020] In some examples, the error action includes generating an exception. In this way, specific behaviors can be programmed into the software to handle in the most appropriate way given the situation where the software is being executed. This also makes it possible to, for example, warn the user.

[0021] In some examples, a reprogrammable circuit that matches the architectural behavior of a vulnerable functional circuit has a different microarchitectural behavior from the vulnerable functional circuit. Microarchitectural behavior can be considered to include implementation details about how to precisely implement the architectural behavior. This can include optimizations and improvements to system operations that do not affect the overall results produced for a particular input. An example of a microarchitectural improvement can be in a multiplication circuit, where the detection of an input parameter "0" immediately results in an output result of "0" (because any product multiplied by 0 is 0). This optimization can improve the speed of performing a particular multiplication (particularly multiplication by zero). However, the architectural behavior remains the same (multiplication is still correct - it is simply performed in a different way). Therefore, in these embodiments, the vulnerable circuit may have optimizations, while the reprogrammable circuit may have removed such microarchitectural improvements. Therefore, the structural behavior of the two devices will remain the same, but the microarchitectural behavior is different.

[0022] In some examples, the modification circuitry is configured to dynamically modify the architectural behavior of the reprogrammable circuitry at runtime. Thus, the reprogrammable circuitry can be changed to match the architectural behavior of one functional circuitry at one particular time and to match the architectural behavior of another functional circuitry at a different time while the data processing apparatus is in active use.

[0023] In some examples, the determining circuit includes storage circuitry for storing heuristic data, and uses the heuristic data to make a determination of vulnerability. The heuristic data may be derived, for example, via offline analysis of a particular program or a broad range of different programs, and may be used to indicate situations in which a particular circuit may become vulnerable.

[0024] In some examples, the heuristic data includes an instruction sequence that increases the vulnerability of at least some of the functional circuits. Offline heuristic analysis may indicate that certain instruction sequences or combinations lead to increased vulnerability of the functional circuit. For example, this may be due to the need to activate certain subcircuits within the functional circuit, which leads to increased vulnerability, because as more subcircuits are activated, the number of transistors and flip-flops used increases. This increase results in a larger number of attack vectors available, and the increased number of transistors and flip-flops means that more transistors / flip-flops become susceptible to errors caused by transient unintentional bit transfers. Another possibility is that a particular code sequence may have been identified as a possible attack vector by a malicious third party. Another possibility is that a particular code sequence causes a slightly higher risk of behavior, for example, data speculation may need to be used for certain code sequences. Architecturally, incorrect data speculation should eventually be eliminated. However, it can be said that the fact that incorrect data values ​​may be used for a short period of time increases the vulnerability of the functional circuit. Therefore, the heuristic data may indicate that, for example, the instruction sequence SUB, ADD, MUL leads to increased vulnerability. Therefore, the sequence can be detected at the decoder, and the result increase can be notified to the determination circuit.

[0025] In some examples, the data processing apparatus includes: compression circuitry for compressing one or more signals of a vulnerable functional circuit to produce one or more compressed signals; and decompression circuitry for decompressing the one or more compressed signals and providing the one or more decompressed signals to a reprogrammable circuit that matches the architectural behavior of the vulnerable functional circuit. Thus, the reprogrammable circuitry can be caused to operate on the same signals provided to the vulnerable functional circuit, even if the extent (number of bits to be transmitted) of those signals is larger.

[0026] In some examples, one or more signals of the vulnerable functional circuit are signals generated internally in the processing circuit. Typically, since the internal bandwidth of the processing circuit is very high, the signals between the functional circuits may be extensive. Therefore, in order to emulate or replicate the behavior of the vulnerable functional circuit, a large number of signals provided to the vulnerable functional circuit may need to be replicated. This is different from the case where the processing circuit itself is replicated. In this case, only the interface signals to the processing circuit (which is typically smaller) need to be replicated. Because, in these examples, the signals are dense, providing compression circuits and decompression circuits can be used to reduce bandwidth requirements.

[0027] In some examples, the reprogrammable circuit is a field programmable gate array or a coarse-grained reconfigurable array. Other types of reprogrammable computing circuits or general-purpose processors may be provided that enable the exact functionality of the circuit to be controlled and / or changed at run time, thereby enabling the system to arbitrarily change which functional circuits are replicated. Thus, a reprogrammable circuit may not have a single function, but may have many possible functions.

[0028] In some examples, the modification circuit is configured to modify the behavior of the reprogrammable circuit to match a plurality of architectural behaviors of a vulnerable one of the functional circuits in response to the determination. The reprogrammable circuit is thus able to replicate several functional circuits simultaneously, particularly when those functional circuits have been identified as vulnerable.

[0029] In some examples, the vulnerable functional circuits constitute at most a subset of the functional circuits. That is, the reprogrammable circuits are not used to architecturally replicate the entire functionality of the processing circuits, but rather only a portion of the circuits are architecturally replicated based on those circuits that are deemed most vulnerable at a particular moment.

[0030] In some examples, in response to the determining circuit determining that multiple functional circuits of the multiple functional circuits are vulnerable, the modifying circuit is configured to modify those functional circuits of the functional circuits determined to be most vulnerable. This can be done by "synthesizing" the behavior of all functional circuits whose vulnerability exceeds a threshold, or by "synthesizing" the behavior of the top x most vulnerable functional circuits.

[0031] Specific embodiments will now be described with reference to the accompanying drawings.

[0032] Figure 1A system 100 is shown, which includes an apparatus 105 according to some examples, a reprogrammable circuit 150 used by the apparatus 105, a CPU 110, and a memory (which may be a cache, a DRAM-backed memory, another type of memory, or a hierarchical structure or hybrid system including several such memory circuits). The processing circuit includes a plurality of functional circuits 115, 120, 125. Each of these functional circuits may be responsive to executing a different operation within the CPU 110. For example, one of the functional circuits 115 may perform integer operations, while another functional circuit 120 may be responsible for memory operations. In operation, a determination circuit 130 in the apparatus 105 may determine that one or more of these functional circuits 115, 120, 125 are vulnerable. In particular, the determination circuit 130 may determine that there is a possibility of an error occurring that is visible to the underlying program executed using the CPU 110. This determination may be made using heuristic data stored in the storage circuit 135. The heuristic data may contain, for example, details about the number of flip-flops or transistors in each functional circuit 115, 120, 125 of the CPU 110 and / or details about specific instruction sequences, behaviors, parameters (or combinations of parameters), etc. that are known to reproduce or may increase the probability of a functional circuit 115, 120, 125 becoming vulnerable. If and when it is determined that a functional circuit 115, 120, 125 is currently considered vulnerable, the modification circuit 140 is instructed to modify the reprogrammable circuit 150 to adopt the same architectural behavior of the vulnerable circuit. This may be achieved using configuration data 145 stored in a configuration storage device 145 that stores hardware description language (HDL) files for versions of the functional circuits 115, 120, 125.

[0033] In this example, the reprogrammable circuit 150 is demonstrated to have architectural equivalents 155, 160 of both of the functional circuits 115, 125. Such "copies" are architecturally identical in that for a given set of input signals, they will produce the same outputs. However, the manner in which those outputs are produced may not be performed, and in particular, the optimizations that may be performed in the functional circuits 115, 125 (that is, there may be differences in micro-architecture).

[0034] An arbitration circuit is provided to arbitrate between the result produced by the CPU 110 and the "copy" within the reprogrammable circuit 150. There are a variety of ways to perform this arbitration, as will be discussed in more detail below. The result of the arbitration may, for example, be written to the memory system 180 (or cause to be read from the memory system).

[0035] Figure 1A further (optional) functionality of the device 105 shown is the presence of compression circuitry 165 and decompression circuitry 170. Since the device 105 modifies the reprogrammable circuitry 150 to architecturally correspond to the behavior of the individual functional circuits 115, 120, 125 of the processing circuitry, it may be necessary to provide signal inputs to the individual functional circuits 115, 120, 125 to portions of the reprogrammable circuitry 155, 160. However, the width of the data bus within the CPU 110 tends to be very large compared to the width of the data bus on which the CPU 110 and the reprogrammable circuitry 150 are located. Thus, while this bus may be sufficient if the CPU 110 were to be replicated on a large scale, it may (in some cases) be disadvantageously insufficient to support replication of the architectural behavior of the individual functional circuits 115, 125. Therefore, compression circuitry 165 and decompression circuitry 170 are provided so that signals internal to the CPU 110 can be compressed when passed to the reprogrammable circuitry 150 along the narrow width bus.

[0036] Figure 2 2 is a table 200 showing examples of different functional units 210 and an architectural vulnerability factor (AVF), which is a specific way of characterizing the probability that a fault in the structure (e.g., flip-flops) of the functional circuit will result in an error visible at the application level. Thus, a higher score indicates a more vulnerable circuit. It should be understood that the number of flip-flops in each structure can provide an indication of the vulnerability of the functional circuit. Figure 2 A number of different AVF values ​​230 are shown for different components in the CPU design when executing different benchmarks.

[0037] Figure 3 It is shown how the vulnerability of specific functional circuits for a given processing circuit may vary over time. Figure 3 The graph has been generated according to the technology described in US10,747,601 (its content is incorporated herein), which describes how reliability can be expressed using formal methods rather than fault injection experiments. In short, these techniques focus on a series of instructions, and first determine the contribution of each circuit block in a set of circuit blocks according to the frequency of using each circuit block in the execution of the series of instructions. Then, the failure mode for each instruction can be determined by considering the failure rate of each block used by the instruction divided by the total number of circuit blocks used by each instruction in the instruction in the series of instructions. Therefore, if each instruction in the three instructions in the series of instructions uses two blocks, a total of six circuit blocks are used. If the ADD instruction uses an issue block and an add block, and if the failure rate of the ADD instruction is 0.8 for the issue block and 0.2 for the add block, then the failure mode (vulnerability) for the ADD instruction in the series of instructions is (0.8+0.2) / 6.

[0038] Specifically, Figure 3 It is shown how the vulnerability of a data processing unit (expressed as 1-Fsafe, which is approximately the same as AVF) changes over a number of clock cycles depending on whether the vulnerability is estimated according to a more conservative or a less conservative approach. Figure 3 The current vulnerability used to illustrate a given circuit depends not only on the nature of the circuit, but also on the actual code being executed.

[0039] Figure 4 An example of a change assessment with respect to vulnerability is given. In this example, two applications (APP1 and APP2) are executed. Each application has multiple stages (P1 and P2 in the case of APP1, and P1, P2 and P3 in the case of APP2). This example assumes that there are three functional circuits (FUNCTION A, FUNCTION B, FUNCTION C) and that the reprogrammable circuit 150 is able to replicate the architectural functionality of exactly one of these circuits. In the first stage of the first application, functional circuit A is considered to be highly vulnerable, functional circuit C is considered to be moderately vulnerable, and functional circuit B is considered to have low vulnerability. Therefore, functional circuit A is selected to replicate its architectural behavior in the reprogrammable circuit 150. In the second stage of the first application, functional circuit C is considered to be highly vulnerable, functional circuit B is considered to be moderately vulnerable, and functional circuit A is considered to have low vulnerability. Therefore, the reprogrammable circuit 150 is reprogrammed to replicate the architectural behavior of functional circuit C. In the first stage of the second application, functional circuit B is high-fragility, functional circuit A is medium-fragility, and functional circuit C is low-fragility, resulting in duplication of the architectural behavior of functional circuit B. Then, in the second stage of the second application, functional circuit A becomes highest-fragility, and in the third stage of the second application, functional circuit B becomes highest-fragility, resulting in architectural duplication of functional circuits A and B in the second and third stages of the second application, respectively.

[0040] Of course, in other examples, reprogrammable circuit 150 may be able to replicate the architectural behavior of two of the functional circuits, in which case the architectural behavior of a high-fragility circuit and a medium-fragility circuit may be replicated.

[0041] Figure 5An example is shown in which any number of single functional circuits can have their architectural behavior replicated by a reprogrammable circuit. In flowchart 500, at step 510, operations performed on a given functional circuit are considered. This can be achieved by calculating, for example, the AVF for the component at the current moment in the runtime of the system. Although this value is calculated at runtime (because the instructions being executed and therefore the vulnerability will change with the runtime of the application), it can utilize heuristic data or structural data that can be determined offline. For example, heuristic data may consider potential vulnerabilities in each functional circuit (e.g., the number of triggers). Heuristic data may alternatively or in addition consider specific instruction sequences or behaviors that change the vulnerability profile. This may include not only, for example, the recognition that a code sequence that does not use a vulnerable circuit substantially makes the circuit have a low vulnerability, but may also include code sequences that are known to be problematic or represent (for example) known attack vectors against malicious third parties. In any case, all of these factors are combined to produce a vulnerability score. At step 520, the vulnerability score (AVF in this example) is compared to a threshold, and if the threshold is exceeded, then at step 530, the architectural behavior of the circuit (not its microarchitectural behavior) is replicated by reprogramming the reprogrammable circuit. The process then proceeds to step 550. If the threshold is not exceeded, then at step 540, the replicated behavior is removed from the reprogrammable circuit (if present), and the process continues to step 550. At step 550, it is determined whether there are more functional circuits to consider. If so, the process returns to step 510. Otherwise, the process ends at step 560 until the next evaluation cycle.

[0042] Figure 6An exemplary behavior of an arbitration circuit 175 that arbitrates between results generated from a reprogrammable circuit 150 and a CPU 110 is shown. The exemplary behavior is shown in the form of a flowchart 600. At step 610, the results from the CPU 110 and the reprogrammable circuit 150 are provided to the arbitration circuit 175. At step 620, it is determined in what mode the arbitration circuit 175 is operating. If the mode is a replace mode, then at step 630, the reprogrammable circuit 150 result is used, and the process returns to step 610. Otherwise, if the mode is a cross-check mode, the arbitration circuit compares the two results. Step 640 determines whether the results are the same. If so, the CPU result is used at step 650. This is because the result is considered correct, and the CPU is able to take advantage of microarchitectural improvements that mean the result has been used, or may allow future operations to be performed more efficiently. The process then returns to step 610. If the results are not the same, an error action occurs. In this example, the error action contains three parts. First, at step 660, an exception is raised. This allows the user (or underlying program) to be warned of the vulnerability. Thus, the program may decide whether to take further action, depending on the nature of the operation being performed and how critical it is (e.g., tuning the radio in a car may not be considered safety critical enough to disturb anything, while an air bag deployment system may be considered critical such that some action must be taken). Then, at step 670, the results of the reprogrammable circuit 150 are used. This is selected on the CPU 110 because the lack of optimization makes the results of the reprogrammable circuit 150 more likely to be correct. Then, at step 680, the override mode is activated. This means that the reprogrammable circuit 150 will continue to be used over the functional circuits in the CPU 110 until deactivated. Depending on any underlying policies, this process may continue indefinitely, until a firmware "fix" is implemented, for a period of time, until the software indicates otherwise, and so on. The process then returns to step 610.

[0043] Of course, it should be understood that, depending on the underlying policy, the override mode may be enabled immediately. For example, if certain attack vectors become known such that certain functional circuits are "always" vulnerable, the override mode may be permanently enabled for that functional circuit (or perhaps until / unless a firmware fix can be provided).

[0044] In some implementations, in replacement mode, operation of the original vulnerable functional circuit is disabled and thus no results are produced.

[0045] Figure 7A simulator implementation 700 that can be used is shown. Although the previously described embodiments implement the present invention in terms of apparatus and methods for operating specific processing hardware that supports the technology involved, an instruction execution environment according to the embodiments described herein can also be provided, which is implemented by using a computer program. Such computer programs are generally referred to as simulators, to a certain extent because such computer programs provide software-based implementations of hardware architectures. The types of simulator computer programs include emulators, virtual machines, models, and binary converters, which include dynamic binary converters. Typically, the simulator implementation can be run on a host processor 740 that supports the simulator program 720, optionally running a host operating system 730. In some arrangements, multiple simulation layers may exist between the hardware and the provided instruction execution environment and / or multiple different instruction execution environments provided on the same host processor. Historically, powerful processors were required to provide a simulator implementation that was executed at a reasonable speed, but this approach may be reasonable in certain circumstances, such as when it is desired to run another processor local code for compatibility or reuse reasons. For example, the simulator implementation can provide additional functionality that is not supported by the host processor hardware to the instruction execution environment, or provide an instruction execution environment that is generally associated with different hardware architectures. An overview of simulation is given in: "Some Efficient Architecture Simulation Techniques", Robert Bedichek, Winter 1990 USENIX Conference, pages 53-63.

[0046] To the extent that embodiments have been previously described with reference to specific hardware constructs or features, in simulated embodiments, equivalent functionality may be provided by suitable software constructs or features. For example, specific circuits may be implemented as computer program logic in simulated embodiments. Similarly, memory hardware such as registers or cache memory may be implemented as software data structures in simulated embodiments. One or more of the hardware elements referenced in the previously described embodiments are present in an arrangement on host hardware (e.g., host processor 740), and some simulated embodiments may utilize host hardware where appropriate.

[0047] The simulator program 720 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (instruction execution environment) to the target code 710 (which may include an application, an operating system, and a hypervisor) that is the same as the interface of the hardware architecture modeled by the simulator program 720. Therefore, the simulator program 720 can be used to execute program instructions of the target code 710 from within the instruction execution environment so that the host computer 730, which does not actually have the hardware features of the device 105 discussed above, can simulate these features. In this example, the simulator code 720 includes a determination logic 750, which is used to determine the vulnerability of the (simulated) functional components within the processing circuit logic 760. Modification logic 770 is also provided for dynamically reprogramming the reprogrammable logic 780 to (architecturally) perform the same behavior as one or more of the functional components within the (simulated) processing circuit logic 760. This can be achieved by generating programming or by activating a specific code library that can be used to simulate the architectural behavior of the (simulated) processing circuit logic 760, which is the code in the simulator used to execute the target code 710.

[0048] By way of example, a dynamic determination that a functional component of a processing circuit or circuit is vulnerable can be responded to by selectively reprogramming a reprogrammable circuit to replicate the architectural behavior of the vulnerable circuit. Thus, changes in the vulnerability can be detected and responded to at a relatively low power cost and without using a large circuit footprint in order to provide resilience to such a vulnerability.

[0049] In this application, the words "configured to..." are used to mean that elements of a device have a configuration that enables the performance of a defined operation. In this context, "configuration" means the arrangement or manner of interconnection of hardware or software. For example, the device may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to" does not mean that the device elements need to be changed in any way in order to provide the defined operation.

[0050] Although exemplary embodiments of the present invention have been described in detail herein in conjunction with the accompanying drawings, it should be understood that the present invention is not limited to those precise embodiments, and that various changes, additions and modifications may be implemented therein by those skilled in the art without departing from the scope and spirit of the present invention as defined in the appended claims. For example, the features of the dependent claims may be combined in various ways with the features of the independent claims without departing from the scope of the present invention.

Claims

1. A data processing device, comprising: a determination circuit configured to perform a determination of a vulnerability of each of a plurality of functional circuits in the processing circuit; and Modification circuitry is configured to modify behavior of the reprogrammable circuitry to match architectural behavior of a vulnerable one of the functional circuits in response to the determination.

2. The data processing device according to claim 1, comprising: An arbitration circuit is configured to arbitrate between the results of the vulnerable functional circuit and between the reprogrammable circuits that match the architectural behavior of the vulnerable functional circuit.

3. The data processing apparatus according to claim 2, wherein In a cross-check mode, the arbitration circuit is configured to compare a result of the reprogrammable circuit that matches the architectural behavior of the vulnerable functional circuit with a result of the vulnerable functional circuit and perform an error action in response to a mismatch.

4. The data processing apparatus according to claim 3, wherein The error action includes activating a replacement mode in which results of the vulnerable functional circuit are replaced with results of the reprogrammable circuit that match the architectural behavior of the vulnerable functional circuit.

5. The data processing device according to any one of claims 3 to 4, wherein The error action includes generating an exception.

6. The data processing device according to any one of claims 3 to 5, wherein The reprogrammable circuit that matches the architectural behavior of the vulnerable functional circuit has a different micro-architectural behavior than the vulnerable functional circuit.

7. A data processing apparatus according to any preceding claim, wherein The modification circuitry is configured to dynamically modify the architectural behavior of the reprogrammable circuitry at runtime.

8. A data processing apparatus according to any preceding claim, wherein The determining circuitry includes storage circuitry for storing heuristic data, and uses the heuristic data to make the determination of the vulnerability.

9. The data processing apparatus according to claim 8, wherein The heuristic data includes a sequence of instructions that increases the vulnerability of at least some of the functional circuits.

10. A data processing apparatus according to any preceding claim, comprising: a compression circuit for compressing one or more signals of the vulnerable functional circuit to generate one or more compressed signals; and A decompression circuit is provided for decompressing the one or more compressed signals and providing the one or more decompressed signals to the reprogrammable circuit, the reprogrammable circuit matching the architectural behavior of the vulnerable functional circuit.

11. The data processing apparatus according to claim 10, wherein The one or more signals of the vulnerable functional circuit are signals generated internally to the processing circuit.

12. A data processing apparatus according to any preceding claim, wherein The reprogrammable circuit is a field programmable gate array or a coarse-grained reconfigurable array.

13. A data processing apparatus according to any preceding claim, wherein The modification circuitry is configured to modify the behavior of the reprogrammable circuitry to match a plurality of architectural behaviors of a vulnerable one of the functional circuits in response to the determination.

14. The data processing apparatus according to claim 13, wherein The vulnerable functional circuits constitute at most a subset of the functional circuits.

15. A data processing apparatus according to any preceding claim, wherein In response to the determination circuitry determining that a plurality of the plurality of functional circuits are vulnerable, the modification circuitry is configured to modify those of the functional circuits that are determined to be most vulnerable.

16. A data processing method, the data processing method comprising: performing a determination of a vulnerability of each of a plurality of functional circuits in the processing circuit; as well as The behavior of the reprogrammable circuit is modified in response to the determination to match an architectural behavior of a vulnerable one of the functional circuits.

17. A computer program for controlling a host data processing device to provide an instruction execution environment, and comprising: determination logic configured to perform a determination of a vulnerability of each of a plurality of functional circuits in the processing circuit; and Modification logic is configured to modify behavior of the reprogrammable logic to match architectural behavior of a vulnerable one of the functional circuits in response to the determination.

Images