Apparatus, method for operating the apparatus and computer program

Abstract

An apparatus, a method for operating the apparatus, and a computer program for controlling a host data processing apparatus to provide an instruction execution environment equivalent to the apparatus are provided. The apparatus includes a processing circuit configured to execute a series of program instructions to process a data item. The processing circuit is configured to generate a signature indicative of executed instructions in the series of program instructions and indicative of the data item. The apparatus also includes a verification circuit configured to perform a verification procedure. The verification procedure includes evaluating the signature against a predetermined policy to verify that the processing circuit has processed the data item using the series of program instructions, and, in response to a match between the signature and the predetermined policy, generating confirmation information indicative of the match.

Description

[Technical Field]

[0001] The present invention relates to a device, a method for operating a device and a computer program.

[0002] Apparatuses with processing circuitry are used to execute sequences of instructions in order to process data items, and in some cases it is important to be able to verify that the sequence of executed instructions is the intended sequence of instructions, and that the data items being processed are those intended, and to provide information indicative of verification.

[0003] In accordance with a first aspect of the present technique, there is provided an apparatus comprising: a processing circuit configured to execute a sequence of program instructions to process a data item, the processing circuit configured to generate a signature indicative of the executed instructions in the sequence of program instructions and indicative of the data item; An apparatus is provided that includes a verification circuit configured to perform a verification procedure to verify that the processing circuit has processed a data item using a series of program instructions, the verification procedure including evaluating a signature against a predetermined policy and, in response to a match between the signature and the predetermined policy, generating confirmation information indicative of the match.

[0004] According to a second aspect of the present invention there is provided a method of operating an apparatus comprising a processing circuit, the method comprising: using a processing circuit to execute a sequence of program instructions to process the data item and generate a signature indicative of the executed instructions in the sequence of program instructions and indicative of the data item; A method is provided that includes performing a verification procedure that includes evaluating a signature against a predetermined policy and, in response to a match between the signature and the predetermined policy, generating confirmation information indicative of the match to verify that a processing circuit has processed a data item using a series of program instructions.

[0005] According to a third aspect of the present invention there is provided a computer program for controlling a host data processing apparatus to provide an instruction execution environment, the computer program comprising: processing program logic configured to execute a series of program instructions to process a data item, the processing program logic configured to generate a signature indicative of the executed instructions in the series of program instructions and indicative of the data item; A computer program is provided comprising: verification program logic configured to perform a verification procedure to verify that processing program logic has processed a data item using a series of program instructions, the verification procedure including evaluating a signature against a predetermined policy, and in response to a match between the signature and the predetermined policy, generating confirmation information indicative of the match.

[0006] The technique will be further described, by way of example only, with reference to arrangements thereof illustrated in the accompanying drawings, in which: [Brief explanation of the drawings]

[0007] [Figure 1] 1A-1C schematically illustrate apparatus in accordance with various examples of the present technique; [Figure 2] 1A-1C schematically illustrate apparatus in accordance with various examples of the present technique; [Figure 3] 1A-1C schematically illustrate apparatus in accordance with various examples of the present technique; [Figure 4] 1A-1C schematically illustrate apparatus in accordance with various examples of the present technique; [Figure 5] 1A-1C schematically illustrate apparatus in accordance with various examples of the present technique; [Figure 6] 1A-1C schematically illustrate apparatus in accordance with various examples of the present technique; [Figure 7] 1A-1C schematically illustrate apparatus in accordance with various examples of the present technique; [Figure 8a] 1A-1C illustrate a schematic diagram of a comparison of execution paths and control flow graphs, according to various examples of the present technique; [Figure 8b] 1A-1C illustrate a schematic diagram of a comparison of execution paths and control flow graphs, according to various examples of the present technique; [Figure 8c] 1A-1C illustrate a schematic diagram of a comparison of execution paths and control flow graphs, according to various examples of the present technique; [Figure 8d] 1A-1C illustrate a schematic diagram of a comparison of execution paths and control flow graphs, according to various examples of the present technique; [Figure 9] 10A-10C illustrate a series of steps performed by an apparatus in accordance with various examples of the present technique; [Figure 10] 10A-10C illustrate a series of steps performed by an apparatus in accordance with various examples of the present technique; [Figure 11] 10A-10C illustrate a series of steps performed by an apparatus in accordance with various examples of the present technique; [Figure 12] 10A-10C illustrate a series of steps performed by an apparatus in accordance with various examples of the present technique; [Figure 13] 1A and 1B illustrate schematically a simulator implementation of an apparatus in accordance with various examples of the present technique;

[0008] According to some configurations, an apparatus is provided, the apparatus comprising: a processing circuit configured to execute a series of program instructions to process a data item, the processing circuit configured to generate a signature indicative of executed instructions in the series of program instructions and indicative of the data item; and a verification circuit configured to perform a verification procedure including evaluating the signature against a predetermined policy to verify that the processing circuit processed the data item using the series of program instructions, and in response to a match between the signature and the predetermined policy, generating confirmation information indicative of the match.

[0009] The processing circuit is configured to process a series of program instructions. The processing instructions specify one or more data items to be processed by the processing circuit in accordance with the processing instructions. To verify that the processing circuit has executed the required instructions and that it has processed the data items, the processing circuit is configured to generate a signature indicating the processing and subsequently used to verify execution of the series of instructions. The inventors recognized that to verify both that the correct instructions were executed and that the correct data was used, the signature should indicate both the instructions and the data items that were executed. Thus, the signature includes instruction signature data indicating which instructions were executed and data item signature data indicating which data items were processed when executing the series of instructions. Further, a verification circuit is provided that is configured to evaluate (compare) the signature against a predetermined policy, and if the verification circuit determines that there is a match between the predetermined policy and the signature, the verification circuit is configured to generate confirmation information. The confirmation information indicates that the verification circuit analyzed the signature generated by the processing circuit and that the series of instructions processed the data items as expected.

[0010] In some configurations, the processing circuit is configured to generate a signature based on a single-use code that indicates an instance of processing a data item using a sequence of program instructions. The single-use code may be a nonce (a number used once) and may be used to mitigate replay attacks in which an attacker attempts to transmit the same information a second time to determine information about the processing circuit or verification circuit. The presence of the single-use code prevents this type of attack because an entity relying on the signature can determine that the single-use code has already been used and can therefore ignore attempts to retransmit the data.

[0011] The processing circuitry and verification circuitry may be included in the same hardware as the entity instructing the processing, but in some configurations, the processing circuitry is configured to at least one of receive a single-use code from an external party that instructs the processing of a data item using a series of program instructions and generate the single-use code as a code that is predictable by the external party. The external party, i.e., a party (entity or other device) implemented on a separate integrated circuit that is physically separate from the processing circuit, is potentially more vulnerable to replay attacks. In such cases, the signature and / or verification information is generated using the single-use code, and thus the inclusion of the single-use code prevents tampering with the data by reusing or retransmitting the signature and / or verification information, since the external party can determine that repeated information is an attempt to reuse the single-use code and can therefore ignore this information and / or otherwise take corrective action. The single-use code may be provided directly or indirectly from the external party, for example, as an encrypted single-use code and / or a randomly generated single-use code. Alternatively, the single-use code may be generated in a predictable manner by an external party, for example, the single-use code may be generated based on a previously shared secret modified based on a timestamp indicating the time or date at which processing of the data item occurred, or may be generated based on information supplied by the external party when commanding the processing.

[0012] The predetermined policy can be defined in several ways. In some configurations, the predetermined policy includes information indicating one or more possible execution paths of a sequence of instructions. The sequence of instructions can include several different types of instructions. In some configurations, the instructions are instructions of an instruction set architecture (ISA) that provides a complete set of instructions that can be provided by a compiler / programmer to instruct (control) a processing circuit. The instructions include control flow altering instructions, e.g., branch instructions that can result in a deviation of the execution order from a defined program counter order, and non-flow altering instructions, e.g., arithmetic instructions. When a flow altering instruction is present, the next instruction executed by the program depends on the result of the execution of the branch instruction, which may depend on a data item being processed. In this way, a single program can have multiple possible execution paths for different data items. These instruction execution paths can be combined into a policy that indicates multiple of these paths. The resulting policy can then be used to verify whether one of the multiple possible paths was taken. In some alternative configurations, the policy indicates portions of the sequence of instructions that correspond to portions of the execution paths that are the same for all possible execution sequences associated with the sequence of instructions. For example, in such an arrangement, the policy may include information indicating a sequence of instructions leading up to the first flow-altering instruction.

[0013] In some configurations, the one or more possible execution paths include all allowed execution paths. By providing a predetermined policy that indicates all possible execution paths, the likelihood of a false negative result being returned by the verification circuitry is reduced. In some configurations, all allowed execution paths include all possible execution paths.

[0014] In some configurations, information indicating one or more possible execution paths is provided as a control flow graph. The control flow graph illustrates each of one or more possible execution paths of a sequence of instructions. A node in the control flow graph corresponds to a flow-altering instruction, and an edge in the control flow graph connecting two nodes in the control flow graph corresponds to one or more non-flow-altering instructions that occur between two flow-altering instructions in the sequence of instructions. In some configurations, instructions that occur between two flow-altering instructions are represented by providing details of the type of each instruction and any data registers represented by the instruction. Such an implementation provides a high degree of assurance when verifying a signature against the control flow graph. In other configurations, instructions that occur between two flow-altering instructions are represented by providing an indication of the number of instruction cycles. In a further alternative configuration, instructions that occur between two flow-altering instructions are not directly represented by only the flow-altering instructions represented in the control flow graph. Providing less information in the control flow graph results in a more compact policy and a simpler verification process.

[0015] In some configurations, the signature comprises information indicative of an execution path taken by the processing circuit during execution of the sequence of instructions, and the verification procedure includes comparing the execution path with a control flow graph. At runtime, the processing circuit may not have knowledge of all permitted paths through the sequence of instructions. Thus, the signature includes only information regarding the path taken in the sequence of instructions during execution. Comparing the information indicative of the execution path with the control flow graph includes determining whether the execution path corresponds to one of the possible execution paths comprising the control flow graph. The comparison can be accomplished by a direct comparison to determine whether any of the possible paths is identical to the path taken by the processing circuit. Alternatively, the verification circuit can employ a sequential approach to determine whether following the execution path through the control flow graph, as indicated in the signature, deviates from the possible paths as indicated in the control flow graph.

[0016] In some configurations, the predetermined policy is generated based on at least one of static analysis of the sequence of program instructions and unit testing of the sequence of program instructions. The static analysis can be based on program source code and may be generated as part of a compilation process. Generating the policy in this manner provides an automated procedure that results in a policy that consistently reflects the sequence of instructions. In alternative configurations, the policy can be specified directly by a programmer. Unit testing involves running one or more tests to determine the behavior of the sequence of program instructions. Typically, unit testing is performed to ensure the correct behavior of the sequence of program instructions, but it can also be used to generate a policy that reflects the sequence of instructions.

[0017] The processing circuitry can be configured to generate the signature by obtaining information from various sources. In some configurations, the signature includes a representation of each of the executed instructions and a reversible representation of the data item. In this approach, the signature includes a comprehensive representation of the data item and the instructions used to process the data item. Such an approach provides high-level verification that the processing circuitry executed a sequence of instructions to process the data item.

[0018] In some configurations, the processing circuit includes a hash engine configured to generate the signature using an irreversible hash function. Using an irreversible hash function reduces the total amount of signature data, resulting in lower computational demands on the verification circuit and reduced data overhead. Furthermore, the use of an irreversible hash function reduces the amount of data that needs to be stored and increases the difficulty of reverse-engineering the hash function, thereby reducing the likelihood that the signature can be tampered with.

[0019] In some configurations, the processing circuitry includes a hash engine configured to generate the signature using a cryptographic hash function, the use of which further reduces the likelihood that the signature will be tampered with.

[0020] While some configurations provide a device in which the processing circuitry is constantly operating to generate signature data, in some configurations the processing circuitry is operable in a verification mode, where, when operating in the verification mode, the processing circuitry generates a signature indicative of an executed instruction in a sequence of program instructions and indicates a data item, and when operating in a mode other than the verification mode, the processing circuitry is configured to process the sequence of instructions without generating a signature. By providing these two modes, signature generation is performed specifically when processing a sequence of instructions for which verification is required. This approach reduces the generation of unnecessary data, resulting in lower computational cost and reduced power consumption of the processing device. Furthermore, by considering only the portion of the program operating in the verification mode, policy generation is simplified, as the policy need only cover the portion of the sequence of program instructions for which data processing operations are configured to operate in the verification mode.

[0021] In some configurations, the apparatus further includes a decoder circuit configured to receive a series of program instructions and generate a control signal that causes the processing circuit to execute the series of program instructions, the decoder circuit generating an enter verification mode control signal in response to the enter verification mode instruction, causing the processing circuit to operate in the verification mode. The decoder circuit converts each of the series of instructions into a control signal that can be used to cause the processing circuit to operate in accordance with the instruction. The instructions that the decoder circuit is configured to decode are instructions that form an instruction set architecture. The instruction set architecture is a complete set of instructions that can be specified by a programmer or compiler to control the processing circuit. In these configurations, the decoder circuit enters the verification mode in response to an enter verification mode instruction, which is an instruction of the instruction set architecture. In some configurations, the decoder circuit and the processing circuit are implemented as separate circuit blocks that interact with each other. In other configurations, the decoder circuit and the processing circuit are implemented as a single circuit that performs the functions of both the processing circuit and the decoder circuit.

[0022] In some configurations, the decoder circuit prevents the processing circuit from accessing addresses outside the region of memory in response to an instruction to enter the verification mode that specifies the region of memory. The region of memory can be specified, for example, by providing at least one range of memory addresses that are accessible to the processing circuit when operating in the verification mode. The at least one range of memory addresses can be provided as an additional argument specified as part of the instruction to enter the verification mode. Alternatively, the region of memory can be specified in a register referenced in the instruction to enter the verification mode or can be provided as a special function register implicitly through use of the instruction to enter the verification mode. When operating in the verification mode using the specified range of addresses, the processing circuit is configured to monitor load and store requests to determine whether an attempt has been made to access an address outside the range of addresses, for example, by monitoring addresses accessed by the load / store unit. In some configurations, the processing circuit generates an exception in response to an attempt to access an address outside the range of addresses. Providing a limit within the region of memory provides further assurance that the processing circuit has processed the data item as expected. In some configurations, the verify mode enter instruction is configured to indicate the duration of the verify mode, for example, as a number of instruction cycles.

[0023] In some configurations, the decoder circuit generates an exit verify mode control signal in response to an exit verify mode instruction to cause the processing circuit to cease operation in the verify mode. The exit verify mode instruction is an instruction of an instruction set architecture. When combined with the enter verify mode instruction, the exit verify mode instruction provides a tool that can be used by a programmer to control when the device is configured to perform verification of a sequence of instructions.

[0024] In some configurations, the processing circuit, when in the validation mode, is configured to postpone action on any interrupts until the processing circuit stops operating in the validation mode. For interrupts generated as a result of the sequence of program instructions for which a signature is being generated, the processing circuit is configured to first postpone the interrupts and then exit the validation mode to process those interrupts. In this manner, interrupts generated by the program instructions are also postponed until the processing circuit stops operating in the validation mode. Deferring instructions may include, for example, deferring interrupts in time until the processing circuit stops operating in the validation mode or to defer the interrupt to another core in a multi-core system. Deferring interrupts received while the processing circuit is in the validation mode can provide further assurance that the processing circuit performed processing of the data item as expected. Furthermore, deferring interrupts while operating in the validation mode prevents the flow of instructions from being misdirected, thereby increasing security. In some configurations, a buffer is provided to buffer interrupts until the processing circuit stops operating in the validation mode.

[0025] The apparatus provides assurance that the processing circuitry executed the processing of a sequence of instructions on a data item. In particular, verifying a signature generated against the policy provides verification that the processing circuitry operated as expected. In some configurations, this can be performed directly by the processing circuitry, including the verification circuitry. In other configurations, the policy is accessible to the verification circuitry but inaccessible outside of the verification circuitry. By restricting the policy so that it is inaccessible outside of the verification circuitry, further assurance can be obtained that the policy has not been maliciously modified by the processing circuitry to tamper with the confirmation information. In some configurations, the policy is accessible and writable by the verification circuitry when the verification circuitry is in a mode other than verification mode, and is accessible as a read-only policy when the verification circuitry enters verification mode. In configurations where the policy is provided by an external party (outside entity), the policy can be a cryptographically signed policy indicating that the policy can be trusted by the verification circuitry.

[0026] Restricting the policy to the verification circuit can be achieved in various ways. In some configurations, the processing circuit comprises the verification circuit, the verification procedure is performed within the processing circuit's realm, and the policy is accessible to the realm and inaccessible outside the realm. A realm is typically an isolated environment allocated its own region of address space that is often inaccessible from outside the realm. Providing a realm in which the verification procedure is performed provides a guarantee that access to the policy is restricted so that it is only accessible within the realm and inaccessible outside the realm. This approach provides a particularly lightweight implementation of the verification circuit while maintaining the additional guarantee that the policy cannot be tampered with by the processing circuit.

[0027] In some configurations, the processing circuit is implemented within an integrated circuit, the verification circuit is a non-local verification circuit that is external to the integrated circuit, and the processing circuit is configured to transmit the signature to the non-local verification circuit. The verification circuit may be provided, for example, within a separate processor core, on a separate computer, or as part of a cloud computing environment. As a result, the verification procedure is performed outside of the processing circuit, thereby reducing the likelihood that the results of the verification procedure can be tampered with.

[0028] In some configurations, the processing circuit is configured to perform a cryptographic authentication process to generate a cryptographically authenticated signature as the signature prior to transmission of the signature to the non-local verification circuit. The process of cryptographically signing the signature provides assurance to the verification circuit that the signature was generated by a processing circuit that processed the data item using the set of instructions. In some configurations, the processing circuit is provided with a nonce (a number used once) upon which the cryptographic authentication is based, thereby providing a further means of assurance to the verification circuit that the signature was generated by a processing circuit that processed the data item using the set of instructions.

[0029] The signature data can include data from a variety of sources. In some configurations, the processing device further comprises a trace circuit configured to output trace data indicating trace waypoints within the sequence of instructions, the processing circuit configured to generate a signature including the trace data. The trace circuit is often provided for the purpose of analyzing the execution of the software following its execution without interrupting its execution. The trace waypoints define instructions within the sequence of instructions that can be used to reconstruct the complete sequence of instructions executed by the processing circuit (e.g., a trace waypoint may record the execution of a flow-altering instruction such as a branch instruction). A particularly lightweight implementation can be provided by reusing existing trace circuitry to provide the waypoint data used to form the signature.

[0030] In some configurations, the apparatus further comprises an instruction cache, and the processing circuitry is configured to generate a signature including information indicative of instructions stored in the instruction cache that are scheduled for operation between the trace waypoints. It is technically possible for two different sequences of instructions to generate the same trace waypoint (e.g., by generating a modified instruction set through substitution of non-flow-altering instructions in the existing instruction set). By combining the trace waypoint information with information indicative of the instructions stored in the instruction cache, the complete sequence of instructions executed by the processing circuitry can be encoded into the signature, thereby providing further assurance that the expected code was executed while maintaining advantageous use of the existing trace circuitry. In some configurations, the information indicative of the instructions is incorporated into the signature as a complete list of instructions occurring between the waypoints. In some configurations, the information indicative of the instructions is encoded, for example, using an irreversible hash function, before being incorporated into the signature.

[0031] In some configurations, the signature includes a hash of the data item. In some configurations, the signature includes information indicative of the regions of memory used by the series of program instructions. The information indicative of the regions of memory may be embodied as a complete list of addresses accessed, a range of addresses accessed, or a hash of the range / address information. The hash used may be an irreversible hash or a cryptographic hash.

[0032] In addition to, or instead of, direct measurements of executed instructions, indirect measurements of executed instructions can be used. In some configurations, the signature includes information indicative of performance characteristics of the processing circuit during execution of the sequence of instructions. The information indicative of performance characteristics can include an indication of the number of instruction cycles that occur between branch instructions, or an indication of the number of instruction cycles in which a particular resource of the processing circuit was used.

[0033] In addition to generating information indicating a match between the signature and the predetermined policy, in some configurations, the verification circuit generates information indicating the lack of match in response to a lack of match between the signature and the predetermined policy. The information indicating the lack of match provides a direct measure that the processing circuit did not process instructions as expected and / or did not use expected data items. Such information may be used to inform decisions regarding the trustworthiness of a particular processing device. In some configurations, the device is configured to perform a specific error action in response to the information indicating the lack of match. In some configurations, the specific error action is to raise an exception. In some configurations, the information indicating the lack of match may include a signed indication that no match was found. In other configurations, the information indicating the lack of match includes information indicating the actual path (signature) and information indicating the expected path within the cryptographically signed data structure.

[0034] A specific example will now be described with reference to the figures.

[0035] FIG. 1 schematically illustrates an apparatus 10 including a processing circuit 12 and a verification circuit 16. The processing circuit 12 is configured to receive a sequence of program instructions and one or more data items to be processed by the processing circuit 12 in a manner defined by the sequence of program instructions. The processing circuit 12 is configured to generate a signature that is characteristic of the processing instructions being executed and of the data items being processed. The signature may be generated based directly on the instructions, based on control signals within the processing circuit 12, and / or using any other data indicative of the behavior of the processing circuit 12 during execution. The signals used to generate the signature may optionally be passed through a hash circuit 14 to generate a hashed version of the signature. In this example, the hash circuit 14 is shown as part of the processing circuit 12, but of course, those skilled in the art will understand that the hash circuit may be external to the processing circuit 12. The apparatus 10 is configured such that the signature is passed to a verification circuit 16. The purpose of the verification circuit is to determine whether the signature generated by the processing circuit matches a predetermined policy 18. The predetermined policy 18 is accessible to the verification circuit 16 but not to the processing circuit 12. The verification circuitry is also configured to output confirmation information in response to a match between the signature and the predetermined policy to provide verification as to whether processing circuitry 12 processed the data item using the set of instructions. Again, the location of the predetermined policy is not limited to the particular example shown in Figure 1 and can be located outside the verification circuitry.

[0036] FIG. 2 shows a detailed schematic diagram of an apparatus in which processing circuitry and verification circuitry 20 are combined according to some configurations of the present technique. The processing circuitry 20 is configured to perform processing in several discrete realms. Specifically, the processing circuitry 20 hosts a non-secure realm 22. Software operating in the non-secure realm optionally has access to a hash circuit 24. Execution of a sequence of program instructions for processing a data item occurs in the non-secure realm 22, outputting a signature that is characteristic of the data item and the sequence of processing instructions. The processing circuitry 20 also hosts a secure realm 26. The secure realm 26 is configured to have access to a specific region of memory in which a predetermined policy 28 is stored. The specific region of memory accessible to the secure realm 26 is not accessible to the processing circuitry 20 when the processing circuitry 20 is not operating in the secure realm 26. The processing circuitry 20 operating in the secure realm 26 performs the functionality of the verification circuitry 16 referenced in FIG. 1. In particular, the secure realm 26 performs a verification procedure to determine whether there is a match between a signature generated in the non-secure realm and the predetermined policy 28. In response to a match between the signature and the predetermined policy 28, the processing circuitry 20 operating in the secure realm 26 generates and outputs confirmation information.

[0037] FIG. 3 schematically illustrates details of processing circuitry 30 according to some configurations of the present technique. Processing circuitry 30 is configured to execute a series of program instructions to process a data item and generate a signature, which may optionally be provided as a hash generated from information characteristics of the data item and from information characteristics of the series of program instructions generated by processing circuitry 30. In the apparatus of FIG. 3, the verification procedure is not performed locally on processing circuitry 30. Instead, processing circuitry 30 is configured to transmit the signature off-chip to external verification circuitry 34. In the illustrated configuration, verification circuitry 34 is implemented in a cloud computing environment 38 external to processing circuitry 30. Verification circuitry 34 is configured to compare the signature to a predetermined policy 36 and generate confirmation information based on an indication of whether the signature matches the predetermined policy 36.

[0038] FIG. 4 schematically illustrates further details of the processing circuitry 40 and decoder circuitry 42 according to various exemplary configurations. The decoder circuitry 42 is configured to receive a series of program instructions and decode (interpret) the series of program instructions, which may be provided by a programmer or compiler, to generate control signals that are routed to the processing circuitry 40 to control which circuit blocks are activated to process a data item. The processing circuitry 40 is operable in a verify mode when a verify bit 44 is set. The value of the verify bit is set in response to an enter verify mode instruction in the series of program instructions to generate an enter verify mode control signal that modifies the value of the verify bit 44 to indicate that the processing circuitry 40 should operate in verify mode. The decoder circuitry 42 also generates an exit verify mode control signal in response to an exit verify mode instruction that modifies the value of the verify bit 44 to indicate that the processing circuitry 40 is to operate in a mode other than verify mode. Of course, in other embodiments, the verify mode can be entered by clearing the verify bit.

[0039] When operating in the verify mode, switches 50 and 52 are activated such that the control signals generated by decoder circuit 40, in addition to causing processing circuit 40 to operate in a particular manner in response to a sequence of program instructions, are passed to hash circuit 48 via switch 50. Similarly, a data item, in addition to being used as a data input to processing circuit 40, is passed to hash circuit 48 via switch 52. Hash circuit 48 combines the data item with the control signals to generate a hash indicative of the data item and the sequence of program instructions provided to the decoder circuit.

[0040] Processing circuit 40 is also configured so that when validation bit 44 indicates that processing circuit 40 is operating in validation mode, any interrupts received by processing circuit 40 are not immediately acted upon, but instead are stored in interrupt buffer 46 to be acted upon when processing circuit 40 is configured to operate in a mode other than validation mode.

[0041] In some configurations, the verification bits 44 may be implemented as a control register or as a logic signal that is held at a set value (e.g., logic 1 or logic 0) when the processing circuitry 40 is operated in a verification mode and is held at a clear value (e.g., the other of logic 1 and logic 0) when the processing circuitry 40 is operated in a mode other than the verification mode. The verification bits may be provided as individual bits that are stored by the processing circuitry 40 for the purpose of indicating whether the processing circuitry 40 is in the verification mode. Alternatively, the verification bits may be encoded as part of a general-purpose control register accessible to the processing circuitry 40.

[0042] FIG. 5 schematically illustrates details of processing circuitry 60 according to some configurations of the present technique. In addition to processing circuitry 60, a trace circuit 62 and an instruction cache 64 are provided. Trace circuitry 62 is configured to receive instructions of a sequence of instructions and generate trace waypoints that indicate the order of execution of the sequence of program instructions. The trace waypoints, when combined with the sequence of instructions in their original program order (i.e., the order in which the instructions are originally written, but not necessarily the order in which the instructions are executed), contain sufficient information to enable the order of execution to be determined. For example, the sequence of instructions may include one or more flow-altering instructions, such as branch instructions. Trace circuitry 62 records as trace waypoints an indication of the flow-altering instruction (e.g., a program counter value) and an indication of where the flow-altering instruction causes the flow to branch (e.g., a program counter value). The trace waypoints are provided from trace circuitry 62 to processing circuitry 60, which, when operating in verification mode, passes the trace waypoints to hash circuitry 68 to be combined using combiner circuitry 72 to generate a signature.

[0043] Trace waypoints provide information that is characteristic of a sequence of program instructions. However, in the illustrated configuration, further information about the sequence of program instructions is provided from instruction cache 64. Trace waypoints are passed from trace circuitry 62 to instruction cache 64 to retrieve blocks of instructions to be executed by processing circuitry 60. The blocks of instructions are provided to hash circuit 66 of processing circuitry 60 before being combined in combine circuit 72 to form part of a signature. Additionally, data items processed by processing circuitry 60 are passed through hash circuit 70 and provided to combine circuit 72 to form part of the signature.

[0044] In an alternative configuration, hash circuits 66, 68, 70 are provided as a single hash circuit located before or after combiner circuit 72. Furthermore, hash circuits 66, 68, 70 and combiner circuit 72 may be provided as a single circuit block that performs the functions of hash circuits 66, 68, 70 and combiner circuit 72.

[0045] The specific data set used to generate the signature can be variously defined and is not limited to the data sets shown in FIGS. 4 and 5. FIG. 6 schematically illustrates further alternative examples of data items illustrating the operation of processing circuit 80 according to some configurations. In addition to processing circuit 80, the apparatus includes trace circuitry 88 and load / store unit 90. Processing circuit 80 and trace circuitry are configured to interact with each other as described in connection with FIG. 5. Processing circuit 80 is further configured to receive information indicative of addresses accessed by load / store unit 90 in response to the series of instructions. Load / store unit 90 is configured to access addresses generated by the processing circuit in response to the series of instructions and pass information indicative of the accessed addresses to processing circuit 80. Processing circuit 80 is configured to generate, using hash circuit 86, hashes of addresses accessed by processing circuit 80 that are combined with hashes of trace waypoints generated by hash circuit 82 and hashes of data items generated by hash circuit 84 to generate a signature.

[0046] Processing circuitry 80 generates hashes of accessed addresses by performing a hash of each accessed address. In an alternative configuration, processing circuitry 80 maintains a record of ranges of addresses accessed, for example, by storing range information indicating the lowest and highest addresses accessed by the processing circuitry.

[0047] FIG. 7 schematically illustrates a processing circuit 100 according to various configurations of the present technique. The processing circuit 100 includes a performance monitoring circuit 102 configured to generate a performance characteristic of the processing circuit 100 as it executes a sequence of program instructions to process a data item. The performance monitoring circuit 102 tracks the number of instruction cycles required between particular instructions and outputs this information to a hashing circuit 106. The hash of the performance characteristic generated by the hashing circuit 106 is combined by a combining circuit 108 with the hash of the data item generated by the hashing circuit 104 to generate a signature. It will be readily apparent to those skilled in the art that the different data sources combined to generate the signature can be combined in any order and are not limited to the combinations described in the specific examples provided in FIGS. 4-7.

[0048] 8a-8d schematically illustrate the use of a control flow graph 110 to verify a characteristic signature output by a processing circuit. The control flow graph 110 is pre-generated by static analysis of a sequence of instructions to be executed. The control flow graph 110 includes information indicating all allowed paths through the sequence of program instructions. By way of example, the control flow graph 110 includes a start point 112 that indicates the beginning of the sequence of program instructions whose execution is to be verified. The start point 112 is optionally followed by one or more instructions that are non-flow-altering instructions 113. Digests of these instructions (information indicating these instructions) are included in the control flow graph.

[0049] A non-flow-altering instruction is followed by a branch point, which is recorded in the control flow graph as branch point 114. Depending on the data to be executed, the flow of instructions can take one of two possible paths at branch point 114. In a first instance, the flow of instructions continues to branch point 118, optionally via one or more non-flow-altering instructions 115, 117. In a second instance, the flow of instructions branches from branch point 114 via branch path 111 (which is shown in the figure as a dashed line and does not include any executed instructions), optionally to one or more non-flow-altering instructions 116 and to the end 120 of the series of program instructions for which the control flow graph is being generated.

[0050] When the flow of instructions reaches branch point 118, the flow of instructions takes one of two possible paths. In the first instance, the flow continues from branch point 118, optionally through one or more non-flow-altering instructions 119, 116, to the end 120 of the set of flow-altering instructions for which the control flow graph is being generated. In the second instance, the flow branches from branch point 118 via branch path 123 and optionally returns to branch point 118 via one or more non-flow-altering instructions 117.

[0051] Depending on the data received by the processing circuitry, any execution of a series of instructions will follow a path between the start 112 of the control flow graph and the end 120 of the control flow graph. As a result, the processing circuitry generates a signature indicating a flow path between the start 112 and the end 120 that can be mapped onto the control flow graph 110 when the series of instructions corresponding to the control flow graph are executed. The control flow path incorporates information indicating at least some of the non-flow-altering instructions 113, 115, 116, 117, 119 and at least some of the branch points 114, 118 that occur between the start 112 and the end 120.

[0052] 8a schematically illustrates a first example of an execution path 130 generated by the processing circuitry when processing a sequence of instructions. The execution path 130 includes a start point 132, information indicating one or more non-flow-altering instructions 131, information indicating a branch point 134 that causes the flow path to jump (via branch path 133), information indicating one or more non-flow-altering instructions 135, and information indicating an end point 136. The signature and control flow graph 110, including the execution path 130, are compared by the verification circuitry using a comparison circuitry 140. The comparison circuitry 140 determines whether the execution path 130 can be mapped to the control flow graph 110.

[0053] In the case of Figure 8a, the start point 132 of the execution path is compared to the start point 112 of the control flow graph, one or more non-flow-altering instructions 131 of the execution path 130 are compared to the non-flow-altering instructions 113 of the control flow graph 110, and a branch point 134 of the execution path 130 is compared to the branch point 114 of the control flow graph 110. In this case, a match is determined between these portions of the execution path 130 and the corresponding portions of the control flow graph 110. Up to this point, the control flow graph 110 indicates that there is only one possible execution path. Following the branch point 114, there are multiple possible execution paths that could result in a match between the execution path 130 and the control flow graph 110. As a result, the non-flow-altering instruction 135 of the control flow path is compared to the non-flow-altering instructions 115 and 116 of the control flow graph 110. In the illustrated configuration, there is no match between the non-flow-altering instructions 135 of the execution path 130 and the non-flow-altering instructions 115 of the control flow graph 110. However, there is a positive match between non-flow-altering instruction 135 of execution path 130 and non-flow-altering instruction 116 of control flow graph 110. Therefore, comparison circuit 140 now considers termination point 136 of execution path 130 compared to termination point 120 of control flow graph 110. In the illustrated configuration, there is a positive match between termination point 136 of execution path 130 and termination point 120 of control flow graph 110. Thus, there is an overall positive match between execution path 130 and control flow graph 110 (shown in the figure as a path that visually resembles one of the possible paths of the control flow graph). As a result, comparison circuit 140 determines that the execution path and control flow graph 110 match and outputs confirmation information indicating the match. In other words, comparison circuit 140 can determine that the characteristic signature including execution path 130 was generated by a sequence of instructions that includes the sequence of instructions used to generate control flow graph 110.

[0054] 8b schematically illustrates a second example of an execution path 150 generated by the processing circuitry when processing a sequence of instructions. Execution path 150 includes a start point 152, information indicating one or more non-flow-altering instructions 153, information indicating a branch point 154, information indicating one or more non-flow-altering instructions 155, information indicating a branch point 156, information indicating one or more flow-altering instructions 159, and information indicating an end point 160. The signature and control flow graph 110, including execution path 150, are compared by the verification circuitry using comparison circuitry 140. The comparison includes determining whether execution path 150 can be mapped to any portion of control flow graph 110.

[0055] In the illustrated example, a start point 152 of execution path 150 is compared to a start point 112 of control flow graph 110. One or more non-flow-altering instructions 153 of execution path 150 are compared to one or more non-flow-altering instructions 113 of control flow graph 110. A branch point 154 of execution path 150 is compared to a branch point 114 of control flow graph 110. In this case, a match is determined between these portions of execution path 150 and the beginning of control flow graph 110. Up to this point, control flow graph 110 indicates that there is only one possible execution path. Following branch point 114, there are multiple possible execution paths that could result in a match between execution path 150 and control flow graph 110. Therefore, a non-flow-altering instruction 155 of execution path 150 is compared to non-flow-altering instructions 115, 117 and non-flow-altering instruction 116 of control flow graph 110. In the illustrated example, it is determined that non-flow altering instruction 155 of control flow path 150 corresponds to non-flow altering instructions 115, 117 of control flow graph 110, but not to non-flow altering instruction 116 of control flow graph 110. Therefore, it is determined that execution path 150 cannot correspond to a path through control flow graph 110 in which one or more non-flow altering instructions 116 are the next instructions to be executed following branch instruction 114. Branch point 156 of execution path 150 is compared to branch point 118 of the control flow graph. Again, at this point, there are two possible routes that execution path 150 can take through control flow graph 110. Therefore, non-flow altering instruction 159 of control flow path 150 is compared to non-flow altering instructions 117 and non-flow altering instructions 119, 116 of control flow graph 110. In the illustrated example, it is determined that non-flow altering instruction 159 of control flow path 150 corresponds to non-flow altering instructions 119, 116 of control flow graph 110, while non-flow altering instruction 151 of execution path 150 does not correspond to non-flow altering instruction 117 of control flow graph 110. Therefore, it is determined that execution path 150 cannot correspond to a path through control flow graph 110 where one or more non-flow altering instructions 117 are the next instructions to be executed after branch point 118. Finally, exit point 160 of execution path 150 is compared to exit point 120 of control flow graph 110.

[0056] In the illustrated configuration, there is a positive match between branch points 154, 156, non-flow-altering instructions 153, 155, and 159, and start point 152 and end point 160 of execution path 150 and control flow graph 110 (shown in the figure as a path that visually resembles one of the possible paths in the control flow graph). As a result, comparison circuit 140 determines that execution path 150 and control flow graph 110 match and outputs confirmation of the match. In other words, comparison circuit 140 can determine that a characteristic signature that includes execution path 150 was generated by a sequence of instructions that includes the sequence of instructions used to generate control flow graph 110.

[0057] 8c schematically illustrates a third example of an execution path 170 generated by processing circuitry in accordance with some configurations of the present technique. Execution path 170 includes a start point 172, branch points 174, 176, non-flow-altering instructions 171, 175, 179, 169, and an end point 178. The signature and control flow graph 110, including execution path 170, are compared by verification circuitry using comparison circuitry 140. The comparison includes determining whether execution path 170 can be mapped to any portion of control flow graph 110.

[0058] In the illustrated configuration, a start point 172 of an execution path 170 is compared to a start point 112 of the control flow graph 110. From the start point 172, the execution path 170 includes non-flow-altering instructions 171, 179 that are compared to non-flow-altering instructions 113 of the control flow graph 110. If the non-flow-altering instructions 171, 179 of the execution path 170 do not match the non-flow-altering instructions 113 of the control flow graph 110, then no possible path through the control flow graph 110 corresponds to the execution path 170. If the non-flow-altering instructions 171, 179 of the execution path 170 match the non-flow-altering instructions 113 of the control flow graph 110, then further comparison is required. An iteration branch point 174, which causes a repetition of the non-flow-altering instructions 179 of the execution path 170 (via path 173), is compared to a branch point 114 of the control flow graph 110. Comparison circuitry 140 can determine that execution path 170 cannot be mapped to control flow graph 110 because the differences between control flow graph path 111 and execution path 173 distinguish branch point 114 of control flow graph 110 from execution path 170, and outputs confirmation information indicating a lack of match. In other words, comparison circuitry can determine that the characteristic signature containing execution path 170 was generated by a different sequence of instructions than the sequence of instructions analyzed to generate control flow graph 110.

[0059] 8d schematically illustrates a fourth example of an execution path 180 generated by processing circuitry in accordance with some configurations of the present technique. Execution path 180 includes a start point 182, a branch point 184, non-flow-altering instructions 181, 183, and an end point 188. The signature and control flow graph 110, including execution path 180, are compared by verification circuitry using comparison circuitry 140. The comparison includes determining whether execution path 180 can be mapped to any portion of control flow graph 110.

[0060] In the illustrated configuration, start point 182 of execution path 180 is compared to start point 112 of control flow graph 110. Next, non-flow-altering instructions 181 are compared to flow-altering instructions 113 of control flow graph 110. As shown schematically through the visual difference between non-flow-altering instructions 181 of execution path 180 and non-flow-altering instructions 113 of control flow graph 110, there is no match between execution path 180 and control flow graph 110. Thus, comparison circuit 140 can determine that no portion (edge) of control flow graph 110 corresponds to non-flow-altering instruction 181 of execution path 180, and the comparison circuit outputs confirmation of the lack of match. In other words, the comparison circuit can determine that the characteristic signature comprising execution path 180 was generated by a different sequence of instructions than the sequence of instructions analyzed to generate control flow graph 110.

[0061] 8a-8d are described sequentially from the start point 112 of the control flow graph 110 to the end point 120 of the control flow graph 110, it will be readily apparent to one skilled in the art that such comparisons may be determined in parallel, for example, by comparing the execution paths of FIGS. 8a-8d with each possible path of the control flow graph 110. Furthermore, in some configurations, the comparisons are based on waypoints that indicate flow-altering instructions, which provide an indication as to the outcome (e.g., adoption or non-adoption) of the flow-altering instructions. In such configurations, the verification circuitry may perform verification based solely on waypoint information, thereby reducing the need to compare a series of non-flow-altering instructions.

[0062] 9 generally illustrates a series of steps performed by a processing circuit according to various configurations of the present technique. Flow begins at step S90, where the processing circuit receives a data item and a series of instructions. The processing circuit executes the series of instructions to process the data item. Flow then proceeds to step S92, where the processing circuit determines whether the processing circuit is operating in verification mode. If it is determined that the processing circuit is not operating in verification mode, flow returns to step S90. On the other hand, if it is determined in step S92 that the processing circuit is operating in verification mode, flow proceeds to step S94, where the processing circuit generates a signature indicative of the series of instructions and indicative of the data item. Flow then returns to step S90.

[0063] FIG. 10 illustrates a series of steps performed by a verification circuit according to various configurations of the present technique. Flow begins at step S100, where it is determined whether a signature has been received by the verification circuit. If no, the flow remains at step S100 until a signature is received. On the other hand, if it is determined that a signature has been received, the flow proceeds to step S102. In step S102, it is determined whether the received signature matches a predetermined policy. If there is a match between the signature and the predetermined policy in step S102, the flow proceeds to step S106, where the verification circuit generates confirmation information indicating a match between the signature and the predetermined policy before returning to step S100. If it is determined in step S102 that the signature does not match the predetermined policy, the flow proceeds to step S104, where the verification circuit generates confirmation information indicating a lack of match between the signature and the predetermined policy before returning to step S100.

[0064] FIG. 11 illustrates a series of steps performed by the decoder circuit to determine whether the processing circuit is operating in verify mode. Flow begins at step S110, where the decoder circuit determines whether an instruction to enter verify mode has been received. If yes, flow proceeds to step S112, where the decoder circuit generates a control signal to enter verify mode, causing the processing circuit to operate in verify mode. Flow then proceeds to step S114, where it is determined whether the instruction to enter verify mode defines a region of memory that is accessible to the processing circuit while it is operating in verify mode. If it is determined in step S114 that there is no defined region of memory, flow returns to step S110. If it is determined in step S114 that there is a defined region of memory, flow proceeds to step S116, where the decoder circuit generates a control signal to prevent the processing circuit from accessing addresses outside the region of memory defined in the instruction to enter verify mode. Flow then returns to step S110. If it is determined in step S110 that a command to enter verification mode has not been received, then the flow proceeds to step S118, where it is determined whether a verification mode exit command has been received. If "No," then the flow returns to step S110. If it is determined in step S118 that a verification mode exit command has been received, then the flow proceeds to step S120, where the decoder circuit generates a verification mode exit control signal to cause the processing circuit to cease operation in verification mode. Then, the flow returns to step S110.

[0065] 12 is a diagram illustrating a sequence of steps performed by an apparatus according to various configurations of the present technique. Flow begins in step S130, where the apparatus uses a processing circuit to execute a series of program instructions for processing a data item and generates a signature indicative of the executed series of instructions and indicative of the data item. Flow then proceeds to step S132, where a verification procedure is performed, which includes evaluating the signature against a predetermined policy to verify that the processing circuit has processed the data item using the series of program instructions, and in response to a match between the signature and the predetermined policy, confirmation information indicative of the match is generated.

[0066] FIG. 13 illustrates a simulator implementation that may be used in some configurations. While the foregoing examples embody the present invention in terms of apparatus and methods for operating specific processing hardware that supports the techniques, it is also possible to provide an instruction execution environment according to the examples described herein, where the instruction execution environment is implemented using a computer program. Such computer programs are often referred to as simulators, insofar as they provide a software-based implementation of a hardware architecture. Various simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may execute on a host processor 515, which optionally runs a host operating system 510 and supports a simulator program 505. In some configurations, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or multiple different instruction execution environments may be provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations that run at reasonable speeds, but such an approach may be justified in certain situations, such as when it is desirable to execute code native to another processor for compatibility or reuse reasons. For example, a simulator implementation may provide an instruction execution environment with additional functionality not supported by the host processor hardware, or may provide an instruction execution environment typically associated with a different hardware architecture. An overview of simulation is given in "Some Efficient Architecture Simulation Techniques," Robert Bedichek, Winter 1990, USENIX Conference, pp. 53-63.

[0067] To the extent that examples are described above with reference to particular hardware constructs or features, equivalent functionality may be provided in a simulated implementation by suitable software constructs or features. For example, a particular circuit may be provided as computer program logic in a simulated implementation. Similarly, memory hardware such as registers or cache may be provided as software data structures in a simulated implementation. Additionally, the devices shown generally in FIGS. 1-7 may be emulated by simulator 505 as simulated devices used by host operating system 510. In configurations where one or more of the hardware elements referred to in the preceding examples reside in host hardware (e.g., host processor 515), some simulated implementations may use the host hardware, if preferred.

[0068] The simulator program 505 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a virtual hardware interface (an instruction execution environment) to the target code 500 (which may include an application, an operating system, and a hypervisor), the virtual hardware interface being the same as the hardware interface of the hardware architecture modeled by the simulator program 505. Thus, program instructions of the target code 500 may be executed from within the instruction execution environment using the simulator program 505, thereby enabling a host computer 515 that does not actually have the hardware features of the devices described in connection with the above figures to emulate those features. By way of example, the simulator program may include processing program logic 512 for emulating the behavior of the processing circuit 12, verification logic 516 for emulating the behavior of the verification circuit, and, optionally, hash logic 514 for emulating the behavior of the hash circuit 14. Additionally, the simulator program may include processing program logic for emulating the behavior of additional features described in connection with any of FIGS. 2-7. Thus, the techniques described herein may be performed in software by simulator program 505 in the example of FIG.

[0069] In summary, there are provided an apparatus, a method for operating the apparatus, and a computer program for controlling a host data processing apparatus to provide an instruction execution environment equivalent to the apparatus. The apparatus comprises a processing circuit configured to execute a series of program instructions to process a data item. The processing circuit is configured to generate a signature indicative of executed instructions in the series of program instructions and indicative of the data item. The apparatus also comprises a verification circuit configured to perform a verification procedure. The verification procedure includes evaluating the signature against a predetermined policy to verify that the processing circuit has processed the data item using the series of program instructions, and, in response to a match between the signature and the predetermined policy, generating confirmation information indicative of the match.

[0070] In this application, the term "configured to" is used to mean that elements of a device have a configuration that is capable of performing a defined operation. In this context, "configuration" refers to a manner of arrangement or interconnection of hardware or software. For example, a 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 imply that the device elements need to be modified in any way to provide the defined operation.

[0071] Although exemplary configurations have been described in detail herein with reference to the accompanying drawings, it will be understood that the invention is not limited to exact configurations thereof, and that various changes, additions, and modifications may be made by those skilled in the art without departing from the scope and spirit of the invention as defined by the appended claims. For example, various combinations of the features of the following dependent claims may be made with the features of the independent claims without departing from the scope of the invention.

Claims

1. It is a device, A processing circuit configured to execute a series of program instructions to process a data item, wherein the processing circuit is configured to indicate the executed instructions within the series of program instructions and to generate a signature indicating the data item, A verification circuit is configured to perform a verification procedure that includes evaluating the signature against a predetermined policy and generating confirmation information indicating the match in response to a match between the signature and the predetermined policy, in order to verify that the processing circuit has processed the data item using the series of program instructions. A device equipped with the following features.

2. The apparatus according to claim 1, wherein the processing circuit is configured to generate the signature based on a one-use code indicating an instance of processing the data item using the series of program instructions.

3. The aforementioned processing circuit is Receiving the one-time use code from an external party that commands the processing of the data item using the aforementioned series of program instructions, To generate the one-use code as a code that can be predicted by the aforementioned external parties. The apparatus according to claim 2, configured for at least one of the following.

4. The apparatus according to any one of claims 1 to 3, wherein the predetermined policy includes information indicating one or more possible execution paths for the series of instructions.

5. The apparatus according to claim 4, wherein the one or more possible execution paths include all permitted execution paths.

6. The apparatus according to claim 4, wherein the information indicating one or more possible execution paths is provided as a control flow graph.

7. The apparatus according to claim 6, wherein the signature includes information indicating an execution path taken by the processing circuit during the execution of the series of instructions, and the verification procedure includes comparing the execution path with the control flow graph.

8. The aforementioned policy is, Static analysis of the aforementioned series of program instructions, Unit testing of the aforementioned series of program instructions and The apparatus according to any one of claims 1 to 3, which is generated based on at least one of the following.

9. The apparatus according to any one of claims 1 to 3, wherein the signature includes a representation of each of the executed instructions and a reversible representation of the data item.

10. The processing circuit includes a hash engine, and the hash engine is Irreversible hash functions and, Cryptographic hash functions and The apparatus according to any one of claims 1 to 3, configured to generate the signature using at least one of the following.

11. The processing circuit is capable of operating in verification mode, and the processing circuit is When operating in the verification mode, it generates the signature that indicates the executed instructions within the series of program instructions and the data items, When operating in a mode other than the verification mode, the series of instructions are processed without generating the signature. The apparatus according to any one of claims 1 to 3, configured as described above.

12. The apparatus according to claim 11, further comprising a decoder circuit configured to receive the series of program instructions and generate a control signal for the processing circuit to execute the series of program instructions, wherein the decoder circuit generates a control signal for the processing circuit to enter verification mode in response to an instruction to enter verification mode, causing the processing circuit to operate in verification mode.

13. The apparatus according to claim 12, wherein the decoder circuit prevents the processing circuit from accessing an address outside the memory region in response to an instruction to enter the verification mode which specifies a memory region.

14. The apparatus according to claim 12, wherein the decoder circuit generates a verification mode termination control signal for the processing circuit to stop operation in the verification mode in response to a verification mode termination command.

15. The apparatus according to claim 11, wherein the processing circuit is configured to postpone operation in response to any interrupt when in the verification mode until the processing circuit stops operating in the verification mode.

16. The apparatus according to any one of claims 1 to 3, wherein the policy is accessible from the verification circuit but inaccessible from outside the verification circuit.

17. The apparatus according to any one of claims 1 to 3, wherein the processing circuit comprises the verification circuit, the verification procedure is performed within the realm of the processing circuit, and the policy is accessible within the realm but inaccessible outside the realm.

18. The aforementioned processing circuit is implemented within an integrated circuit. The verification circuit is a non-local verification circuit located outside the integrated circuit. The processing circuit is configured to transmit the signature to the non-local verification circuit. The apparatus according to any one of claims 1 to 3.

19. The apparatus according to claim 18, wherein the processing circuit is configured to perform an encryption authentication process before transmitting the signature to the non-local verification circuit to generate a cryptographically authenticated signature as the signature.

20. The apparatus according to any one of claims 1 to 3, further comprising a trace circuit configured to output trace data indicating trace waypoints in the series of instructions, wherein the processing circuit is configured to generate the signature including the trace data.

21. The apparatus according to claim 20, further comprising an instruction cache, wherein the processing circuit is configured to generate the signature, which includes information indicating an instruction stored in the instruction cache scheduled for operation between the tracewaypoints.

22. The aforementioned signature is The hash of the data item, information indicating the memory region used by the series of program instructions, Information indicating the performance characteristics of the processing circuit during the execution of the series of instructions, The apparatus according to any one of claims 1 to 3, comprising at least one of the following.

23. The apparatus according to any one of claims 1 to 3, wherein the verification circuit generates information indicating the lack of a match between the signature and the predetermined policy in response to the lack of a match.

24. A method for operating a device equipped with a processing circuit, wherein the method is Using the processing circuit, execute a series of program instructions to process a data item, indicate the executed instructions within the series of program instructions, and generate a signature indicating the data item. To verify that the processing circuit has processed the data item using the series of program instructions, a verification procedure is performed which includes evaluating the signature against a predetermined policy and generating confirmation information indicating the match in response to a match between the signature and the predetermined policy. Methods that include...

25. A computer program that causes a host data processing device to perform processing in order to provide an instruction execution environment, Processing program logic configured to execute a series of program instructions to process a data item, wherein the processing program logic is configured to indicate the executed instructions within the series of program instructions and to generate a signature indicating the data item, Verification program logic is configured to perform a verification procedure that includes evaluating the signature against a predetermined policy and generating confirmation information indicating the match in response to a match between the signature and the predetermined policy, in order to verify that the processing program logic has processed the data item using the set of program instructions. A computer program that includes the following features.

Images