Apparatus and method for handling exceptions

Abstract

The invention provides apparatus and methods for handling exceptions. The apparatus has processing circuitry operable in at least one secure domain to execute program code comprising a plurality of exception handling routines for execution in response to corresponding exceptions, and a plurality of registers for storing data for access by the processing circuitry when executing the program code. In response to a given exception from background processing occurring, exception control circuitry is arranged to trigger a state save operation to save data from the plurality of registers before triggering the processing circuitry to execute a given exception handling routine. Configuration storage provides configuration information for categorising exception handling routines. The exception control circuitry is arranged to reference the configuration information to determine whether the given exception handling routine belongs to a first category or a second category within the secure domain in which the given exception handling routine is to be executed. The exception control circuitry then triggers saving of the data from the first subset of registers when the given exception handling routine belongs to the first category, and triggers saving of the data from both the first subset of registers and the second subset of registers when the given exception handling routine belongs to the second category when triggering the state save operation. This approach can significantly reduce interrupt latency in systems supporting execution of both trusted and untrusted exception handling routines.

Description

Background Technology

[0001] This technology relates to apparatus and methods for handling anomalies.

[0002] When a processor executes program code, it typically accesses multiple registers that store data used by the processor during execution. In the event of an exception from background processing, it is known that exception control circuitry is provided in the hardware, configured to perform a state save on data from a first subgroup of registers before triggering the processor to execute an exception handling routine to handle the exception. By doing so, the exception handling routine can utilize the first subgroup of registers without performing any state saves on the data in those registers, and if the exception handling routine needs to interact with these registers, it only needs to perform state saves for any additional registers not in the first subgroup.

[0003] When an exception occurs, it's common for the exception handling routine to execute at the same or higher privilege level as the background code, and thus allowing the exception handling routine to have visibility into the contents of registers outside the first subgroup (i.e., data in registers whose state hasn't yet been saved by the exception control circuitry hardware) is considered acceptable. However, in modern systems, it's also desirable to support the use of untrusted exception handling routines, for example, because these routines are provided by third-party vendors. In such cases, steps are needed to prevent untrusted exception handling routines from gaining access to data they shouldn't. However, interrupt latency is also becoming a significant issue in modern systems, and therefore, it's desirable to provide a system that supports both trusted and untrusted exception handling routines while mitigating interrupt latency. Summary of the Invention

[0004] In a first exemplary arrangement, an apparatus is provided, comprising: processing circuitry operable in at least one security domain to execute program code including a plurality of exception handling routines executed in response to a corresponding exception; a plurality of registers for storing data accessible by the processing circuitry during execution of the program code, the registers including a first register subgroup and a second register subgroup not overlapping the first subgroup; and exception control circuitry configured to trigger a state saving operation to save data from the plurality of registers before triggering the processing circuitry to execute a given exception handling routine corresponding to the given exception, in response to the occurrence of a given exception from background processing. The exception control circuitry is configured to: refer to the configuration information to determine whether a given exception handling routine belongs to a first category or a second category within the security domain in which the given exception handling routine will be executed, and when the state saving operation is triggered, to: trigger the saving of the data from the first register subgroup when the given exception handling routine belongs to the first category, and trigger the saving of the data from both the first register subgroup and the second register subgroup when the given exception handling routine belongs to the second category.

[0005] In another exemplary arrangement, a method for handling exceptions within a device is provided, the method comprising: executing program code on processing circuitry capable of operating in at least one security domain, the program code including a plurality of exception handling routines executed in response to a corresponding exception; storing data in a plurality of registers for access by the processing circuitry during the execution of the program code, the registers including a first register subgroup and a second register subgroup not overlapping the first subgroup; and employing exception control circuitry to trigger a state saving operation prior to triggering the processing circuitry to execute a given exception handling routine corresponding to the given exception in response to the occurrence of a given exception from background processing, so as to... The system saves data from the plurality of registers; stores configuration information for classifying exception handling routines within the plurality of exception handling routines; refers to the configuration information to determine whether a given exception handling routine belongs to a first category or a second category within the security domain in which it will be executed; and when the state save operation is triggered, causes the exception control circuitry to trigger the saving of data from the first register subgroup when the given exception handling routine belongs to the first category, and to trigger the saving of data from both the first register subgroup and the second register subgroup when the given exception handling routine belongs to the second category.

[0006] In another exemplary arrangement, an apparatus is provided, comprising: a processing member for executing program code in at least one security domain, the program code including a plurality of exception handling routines executed in response to a corresponding exception; a plurality of register members for storing data accessible to the processing member during the execution of the program code, the register members including a first register member subgroup and a second register member subgroup that do not overlap with the first subgroup; and an exception control member for triggering a state saving operation to save data from the plurality of registers before triggering the processing member to execute a given exception handling routine corresponding to the given exception in response to a given exception occurring from a background process. The component includes data; and a configuration storage device component for storing configuration information for classifying exception handling routines within the plurality of exception handling routines; wherein the exception control component is configured to refer to the configuration information to determine whether a given exception handling routine belongs to a first category or a second category within the security domain in which the given exception handling routine will be executed, and when the state save operation is triggered, to trigger the saving of the data from the first register component subgroup when the given exception handling routine belongs to the first category, and to trigger the saving of the data from both the first register component subgroup and the second register component subgroup when the given exception handling routine belongs to the second category.

[0007] In another exemplary arrangement, a computer program is provided for controlling a host data processing device to provide an instruction execution environment. The computer program includes: process logic operable in at least one security domain to execute program code, the program code including a plurality of exception handling routines executed in response to corresponding exceptions; data structure emulation program logic for maintaining a plurality of register data structures to store data for access by the process logic during the execution of the program code, the register data structures including a first data structure subgroup and a second data structure subgroup not overlapping the first subgroup; and exception control program logic, in response to a given exception occurring from a background process, for triggering the process logic to execute a given exception corresponding to the given exception. A state save operation is triggered before a processing routine to save data from the plurality of register data structures; wherein the data structure emulation program logic is further arranged to maintain a configuration data structure to store configuration information for classifying exception handling routines within the plurality of exception handling routines; and wherein the exception control program logic is arranged to refer to the configuration information to determine whether a given exception handling routine belongs to a first category or a second category within the security domain in which the given exception handling routine will be executed, and when the state save operation is triggered, it is arranged to: trigger the saving of the data from the first data structure subgroup when the given exception handling routine belongs to the first category, and trigger the saving of the data from both the first data structure subgroup and the second data structure subgroup when the given exception handling routine belongs to the second category. A computer-readable medium may be provided to store such a computer program, and the computer-readable medium may be in a non-transitory form or a transient form. Attached Figure Description

[0008] The present technology will be further described by way of illustration only, with reference to examples of the present technology shown in the accompanying drawings, wherein:

[0009] Figure 1 An example of a data processing system according to an exemplary arrangement is shown schematically;

[0010] Figure 2 This illustrates an exemplary arrangement. Figure 1 Examples of different domains and modes of operation of the processing circuit;

[0011] Figures 3A to 3C It shows Figure 1 Different exemplary implementations of the configuration storage device;

[0012] Figure 4 This is a flowchart illustrating the steps performed when an exception occurs from a background process, according to an exemplary arrangement;

[0013] Figure 5 This is shown as an exemplary implementation that can be executed in order to be carried out. Figure 4 A flowchart of the step sequence for step 105;

[0014] Figure 6 This is a flowchart illustrating the steps performed in an exemplary arrangement to implement exception return handling;

[0015] Figure 7 This is shown in more detail in an exemplary arrangement for implementation. Figure 6 A flowchart of the step sequence in step 230;

[0016] Figure 8 This is a flowchart illustrating the pre-emptive process in an exemplary arrangement;

[0017] Figures 9A to 9C The process of saving the state of the caller register and callee register is illustrated for various specific exemplary scenarios; and

[0018] Figure 10 An example of a usable simulator is shown. Detailed Implementation

[0019] As previously mentioned, in modern systems, it is possible that not all exception handling routines are trustworthy, and alternatively, it may be desirable to allow the use of one or more untrusted exception handling routines, for example, because these routines are provided by third-party vendors. To accommodate such untrusted exception handling routines, a trustworthy software wrapper can be provided, such that, on the entry for the exception handling routine, the wrapper software is executed first to perform some initial tasks before allowing the execution of the body of the untrusted exception handling routine. Similarly, the wrapper software can be executed to perform some additional operations before returning from such an exception handling routine. As an example of operations that can be performed by such wrapper software, the wrapper software can be responsible for saving the state of at least some other registers not in the previously mentioned first subgroup, the state saving of which is performed by the exception control circuitry in the hardware. The wrapper can also clear registers before executing the body of the exception handling routine, thereby ensuring that the untrusted exception handling routine has no visibility into the contents of any registers associated with background processing. The wrapper software can also be used to restore the contents of such registers after the completion of the untrusted body but before returning from the exception.

[0020] However, interrupt latency is becoming a significant issue in modern systems, and the execution of the above steps by the wrapper software can significantly impact interrupt latency. Therefore, it is desirable to provide a system that supports both trusted and untrusted exception handling routines while mitigating the interrupt latency problem.

[0021] According to the technology described herein, an apparatus is provided comprising: processing circuitry capable of operating in at least one security domain to execute program code including a plurality of exception handling routines executed in response to corresponding exceptions. The processing circuitry is capable of operating, for example, in one of a plurality of different security domains comprising at least a secure domain and a less secure domain, and access to memory can be controlled depending on which security domain the processing circuitry operates in. However, it should be noted that the processing circuitry does not need to operate in multiple security domains, and the general techniques described herein can also be used in systems where only a single security domain exists.

[0022] In addition to the processing circuitry, the device includes multiple registers for storing data accessible to the processing circuitry during program code execution. These registers are arranged to include a first register subgroup and a second register subgroup that does not overlap with the first subgroup. Furthermore, exception control circuitry hardware is provided that, in response to a given exception from background processing, triggers a state save operation to save data from the multiple registers before the processing circuitry executes a given exception handling routine corresponding to the given exception. Specifically, by default, the exception control circuitry triggers a state save operation with respect to the first register subgroup; however, as will be discussed further herein, depending on the exception handling routine to be triggered to handle the given exception, the exception control circuitry hardware may also trigger a state save operation with respect to the second register subgroup.

[0023] Specifically, the device also includes a configuration storage device for storing configuration information for classifying exception handling routines within a plurality of exception handling routines. The configuration information provided in the configuration storage device can be used to classify each exception handling routine, or alternatively, there may be a subgroup of exception handling routines that always effectively belong to a predetermined category, and therefore, for that predetermined category, the configuration information in the configuration storage device is not required.

[0024] Furthermore, the exception control circuitry is configured to determine, with reference to configuration information, whether a given exception handling routine belongs to a first category or a second category within the security domain in which it will execute. Then, when a state save operation is triggered, the exception control circuitry is configured to trigger a save of data from a first register subgroup if the given exception handling routine belongs to the first category, and is configured to trigger a save of data from both the first and second register subgroups if the given exception handling routine belongs to the second category. Data can be saved in various ways, but in one exemplary embodiment, the data is saved to a stack in memory, and therefore such a save operation may be referred to herein as "stack." Additionally, subsequently restoring the data to the registers may be referred to as "destack."

[0025] This approach can provide significant performance benefits within systems that support both trusted and untrusted exception handling routines. For example, a first category can be used to indicate trusted exception handling routines, while a second category indicates those to be handled as untrusted. Depending on the form of the configuration information used, in some instances, a trusted exception handling routine might be identified as belonging to the second category and therefore handled as untrusted. However, this does not introduce a security risk and simply means that the exception control circuitry can also retain the data even when it does not actually need the data from the second register subgroup.

[0026] By identifying untrusted exception handling routines as belonging to the second category, it is ensured that the exception control circuitry hardware is responsible for saving the state of not only the first register subgroup but also the state of the second register subgroup. This significantly reduces the tasks required by the previously mentioned trusted wrapper software, which can be used in conjunction with the untrusted exception handling routines, and thereby significantly reduces the interrupt latency of processing such untrusted exception handling routines. In some implementations, the hardware state saving of the registers can be performed at least partially in parallel with other exception entry tasks, such as fetching the address of the exception handler and fetching the first instruction of the exception handler to be executed. Such implementations can have significant interrupt latency advantages over systems in which state saving must be performed by the exception handler itself.

[0027] Furthermore, by ensuring that the exception control circuitry hardware not only consistently triggers saving of state from both the first and second register subgroups, any performance impact on trusted exception handling routines is avoided. Specifically, for a trusted exception handling routine identified in the first category, if the exception handling routine is trusted, the exception control circuitry only continues to trigger saving of data from the first register subgroup and therefore does not trigger saving of data from any other registers that do not need to be saved. Thus, this approach maintains the speed of trusted exception handling routines while reducing the latency associated with untrusted exception handling routines by allowing the exception control hardware to save state that would otherwise need to be saved by software.

[0028] In one exemplary arrangement, at least when a given exception handling routine belongs to the second category, the exception control circuit is further arranged to trigger the clearing of registers whose data was saved during the state saving operation before triggering the processing circuit to execute the given exception handling routine. As previously discussed, if an exception handling routine is classified in the second category, the exception handling routine is treated as untrusted, and therefore it is appropriate for the exception control circuit not only to trigger the saving of the state of registers present in background processing, but also to trigger the clearing of the contents of those registers, so that those contents are not visible to the exception handling routine when the processing circuit begins to execute the exception handling routine. If necessary, for example, to simplify operation, the exception control circuit can be arranged to always trigger the clearing of the contents of any saved registers, and thus, for example, may also trigger the clearing of the contents of the first register subgroup when saving the state before switching the processing circuit to execute an exception handling routine of the first category.

[0029] Processing circuitry can be arranged to execute untrusted exception handling routines in various ways. However, in one exemplary embodiment, the processing circuitry can operate in both a non-privileged state and a privileged state, and is operable to execute at least the body of an untrusted exception handling routine when in a non-privileged state. Thus, for example, the previously mentioned wrapper software can be executed by the processing circuitry in a privileged state, and then the processing circuitry can transition to a non-privileged state to execute the body of the untrusted exception handling routine. Regardless of whether the background processing is in a privileged or non-privileged state, the techniques described above ensure that the body of the untrusted exception handling routine cannot access data stored in any registers during background processing, because the exception control circuitry will trigger the saving of the state of both the first register subgroup and the second register subgroup before triggering the processing circuitry to execute such an untrusted exception handling routine. In some specific implementations, since the background state and the exception handler may belong to different mutually untrusted software processes, protecting the unprivileged background state from the unprivileged exception handler can be an important security property.

[0030] The configuration storage device can be organized in various ways, but in one example it is arranged to store corresponding configuration information items for one or more exception handling routines. In a particular exemplary implementation, a corresponding configuration information item may be provided for each exception handling routine. However, alternatively, as previously mentioned, the category of one or more particular exception handling routines can be effectively hardwired (e.g., fault handler or administrator call (SVC)), and in these cases, configuration information may not need to be mentioned to determine the category of the exception handling routine. Such fault handler and administrator call exceptions may be associated with the operating system and therefore can always be trusted and handled as part of the first category.

[0031] In such implementations, for one or more exception handling routines, corresponding configuration information entries are stored in a configuration storage device, and this configuration information can take various forms. However, in one exemplary embodiment, the configuration information entry is set to a first value to indicate that the corresponding exception handling routine is trustworthy, and is set to a second value to indicate that the corresponding exception handling routine is handled as untrustworthy. Therefore, by referring to the relevant configuration information entries in the configuration storage device, the exception control circuit can easily determine whether a given exception handling routine belongs to the first category or the second category, and thus perform an appropriate state saving operation regarding the contents of the registers.

[0032] However, it is not necessary to configure the storage device to store configuration information items for individual exception handling routines. For example, in some implementations, a very large number of exception handling routines may be supported, and therefore the size requirement of such a configuration storage device can be large. To attempt to reduce storage requirements, in one exemplary implementation, an alternative form of storing configuration information is used when evaluating whether an exception handling routine belongs to a first or second category. Specifically, it is noted that in many systems, untrusted exception handling routines are naturally given lower priority compared to trusted exception handling routines. This approach, for example, helps prevent blocking-of-service (DoS) attacks by unprivileged exception handling routines. Therefore, in such implementations, priority information associated with an exception can be used as a proxy to infer whether the associated exception handling routine is trusted or untrusted. Thus, in one such exemplary implementation, the configuration storage device is arranged to identify threshold priorities, and each exception has an associated priority. The exception control circuit is then arranged to determine whether a given exception handling routine belongs to a first or second category based on a comparison between the value derived from the associated priority of a given exception and the value derived from the threshold priority. This provides a significantly reduced storage requirement for the configuration storage device because a single piece of information (i.e., the threshold priority) can be stored and then used when evaluating each exception. Furthermore, systems that handle exceptions typically assign different priorities to those exceptions, and thus priority information for each exception already exists. In another implementation, the threshold priority can be fixed, and the configuration storage device consists of a priority field associated with each exception.

[0033] In one exemplary arrangement, the exception control circuitry is configured to determine that a given exception handling routine belongs to the second category when the associated priority of the exception is less than a threshold priority. It should be noted that, depending on the specific implementation, higher-priority exceptions may be assigned a higher numerical priority value, but in alternative implementations, higher-priority exceptions may be assigned a lower numerical priority value. Therefore, for example, in a latter implementation, an exception with priority 2 might be considered a higher-priority interrupt compared to an exception with priority 4.

[0034] As mentioned above, priority can often be used as a good proxy for determining whether an exception handling routine is trusted or untrusted. If, by setting a threshold priority, a low-priority exception triggers a trusted exception handling routine, treating that routine as untrusted will not produce any problematic behavior, and since the state of the second register subgroup is saved by the exception control circuitry hardware when it is not actually necessary, there will be only a slight performance impact. Since this situation only occurs for low-priority processors, this minor performance impact may not be significant. Furthermore, in the rare case where a high-priority exception is actually associated with an untrusted exception handling routine, this can be handled by providing wrapper software in association with the exception handling routine being arranged to save the state of the second register subgroup and clear that state of the registers before transitioning to the untrusted body of the exception handling routine.

[0035] In one exemplary embodiment, the exception control circuitry is arranged to set a status flag to identify whether data from the second register subgroup has been saved. The status flag can be set in several ways. For example, in one embodiment, the status flag is provided as an extra bit within the link register to capture the exception return address on the exception entry. In some embodiments, portions of the address space are reserved and non-executable. Addresses branching into such portions of the address space can therefore be used to signal special conditions, such as an exception return requesting hardware execution to a background state. In one exemplary embodiment, on the exception entry, the exception return address captured in the link register can be set as a virtual return address, specifying an address within the reserved non-executable address space, where the actual return address is instead stored on the stack; the status flag can then be included in the link register along with the virtual return address.

[0036] Therefore, when an exception occurs, and the exception control circuitry thus categorizes the associated exception handling routines to determine whether to save the state of only the first register subgroup or both the first and second register subgroups, an indication can be added to the link register to identify whether the state of the second register subgroup has been saved. It should be noted that the position of this status flag can then move over time, for example, the information can be moved from the link register to the stack in memory, and possibly via other registers. However, regardless of when the status flag is saved, the exception control circuitry can refer to the value of this status flag as appropriate when taking steps to determine whether the contents of the second register subgroup need to be stacked or unstacked.

[0037] Furthermore, it should be noted that the status flag can identify whether data from the second register subgroup has been saved by the exception control circuitry in several ways. For example, the exception control circuitry can directly encode this information. However, in an alternative arrangement, the status flag value can be used to identify any deviation from some default status saving rules, so that the exception control circuitry can refer to this value again when determining whether data in the second register subgroup has undergone a previous status saving operation.

[0038] In many instances, it can be useful for exception control circuitry to reference state flags. For example, exception control circuitry can be configured to reference state flags upon exception return to determine whether the state of the second register subgroup needs to be restored (destacking). Thus, upon return to background processing, if the state flags indicate that the second register subgroup has undergone a state saving operation, the exception control circuitry can be configured to trigger the restoration of the state of not only the first register subgroup but also the second register subgroup.

[0039] When the data in a register is saved by the exception control circuitry as previously mentioned, there are many places where the current data content of the register can be saved. However, in one exemplary arrangement, when the state save operation is triggered, the exception control circuitry is arranged to cause the data to be saved to a stack data structure, such as a stack in memory. Typically, a stack pointer is maintained to identify specific locations within such a stack, such as the top of the stack, and can be used when new data is added to the stack or when data is retrieved from the stack. In other specific implementations, the stack can be a descending stack, where the top of the stack is located at a lower address in memory than the bottom of the stack.

[0040] In addition to handling exceptions that occur during background processing, the device is also configured to handle chained exceptions, which are exceptions that occur while the current exception handling routine is already executing. Chained exceptions have a lower priority than the current exception being handled by the current exception handling routine and are therefore not handled until the current exception handling routine has completed. However, instead of returning to background processing and then handling the chained exception, the device can alternatively be configured to jump directly from the completion of the current exception handling routine to handling another exception handling routine in order to handle the chained exception. Alternatively, both exceptions can occur simultaneously, and the exception handling circuitry can be configured to trigger the handling of the higher-priority exception before it chaines to the lower-priority exception when the higher-priority exception handler completes. Regardless of when the chained exception is pending, chaining can be viewed as entering the pending exception when the exception handler returns, rather than returning to the background processing code.

[0041] Therefore, in response to a trailing cascading exception corresponding to another exception handling routine that is to be executed after a given exception handling routine has been executed and before returning to background processing, the exception control circuitry can be arranged to determine, with reference to configuration information, whether the other exception handling routine belongs to a first category or a second category. Then, when the exception control circuitry determines that the other exception handling routine belongs to the second category and the data from the second register subgroup has not yet been saved, the exception control circuitry can be further arranged to trigger the saving of the data from the second register subgroup before triggering the processing circuitry to execute the other exception handling routine. The exception control circuitry can determine whether the data from the second register subgroup has been saved in various ways, for example, by referring to the previously mentioned status flags.

[0042] Similar to how exception control circuitry can be arranged when handling exceptions from background processing, exception control circuitry can be further arranged to trigger the clearing of registers whose data is saved before the triggering circuitry executes another exception handling routine for a cascading exception. In some implementations, register clearing may occur at the end of the chain, even if no registers have been saved when the exception transitions to a cascading exception. For example, if the entries of a previous exception or exception combination have already prompted the saving of both the first and second register subgroups, it may not be necessary to save the registers again. However, in such cases, it may still be necessary to clear the registers so that the values ​​left in the registers by one exception handler are not exposed to the next exception handler.

[0043] By maintaining the previously mentioned state flag, significant performance improvements can also be achieved when handling cascading exceptions by avoiding unnecessary resaving of the state when the state of the second register subgroup has already been saved. Specifically, the exception control circuitry can be further arranged to reference the state flag so that when the exception control circuitry determines that another exception handling routine for a cascading exception belongs to the second category, it is arranged to skip triggering the saving of data from the second register subgroup when the state flag indicates that data has been saved. Therefore, this approach yields a very efficient implementation.

[0044] Background processing can take various forms. For example, it may include executing program code instead of an exception handling routine, and in such cases, the previously mentioned given exception is the initial exception. However, alternatively or otherwise, background processing may include executing the current exception handling routine, and the given exception may be a preemptive exception with a higher priority than the exception corresponding to the current exception handling routine. In such scenarios, the processing of the current exception handling routine is interrupted to allow the handling of the higher-priority exception, and in this instance, the current exception handling routine itself is treated as background processing, and the previously discussed classification mechanism for pending exception handling routines (i.e., the mechanism associated with preemptive exceptions) is executed to determine whether a state saving operation is performed only on the first register subgroup or on both the first and second register subgroups to save the relevant state associated with the current exception handling routine.

[0045] In one exemplary embodiment, the processing circuitry is arranged to execute program code in one of a plurality of security domains, including at least a secure domain and a less secure domain. The exception control circuitry is then arranged to determine, with reference to configuration information, whether a given exception handling routine belongs to a first category or a second category, independent of whether any security domain change occurs when switching from background processing to execution of the given exception handling routine. Therefore, the way exception handling routines are classified does not depend on whether any security domain change occurs when switching from background processing to the exception handling routine. In one exemplary embodiment, different sets of configuration information versions may exist for each security domain, such that the domain in which the processing circuitry executes the exception handling routine when evaluating it may affect the configuration information. However, the classification is entirely independent of the security domain associated with the background processing, and therefore independent of whether any change occurs in the security domain due to an exception occurring from background processing.

[0046] As mentioned above, the configuration storage device is arranged to store configuration information for classifying the multiple exception handling routines associated with each security domain. While some exception handling routines may be able to execute in multiple security domains, others may only execute in a specific security domain, and therefore the configuration storage device only needs to maintain the configuration information associated with such exception handling routines for the security domain in which they will be executed. This may be useful in a specific implementation that provides separate configuration information for each exception handling routine, as this avoids the need to provide configuration bits for each exception handling routine in each security domain.

[0047] However, in alternative implementations as previously discussed, instead of providing configuration information for each exception handling routine, general information such as threshold priority is provided, and in such instances, the configuration storage device may provide a threshold priority for each security domain, such that the relevant threshold priority is referenced when considering the security domain in which a given exception handling routine will be executed.

[0048] In summary, however, in the presence of a system that supports multiple security domains, the configuration information is arranged in a configuration storage device, and the exception control circuitry can be arranged to determine whether a given exception handling routine belongs to a first category or a second category by referring to the configuration information provided for the security domain in which a given exception handling routine will be executed.

[0049] In cases where the processing circuitry can execute program code in multiple different security domains, within a given security domain, the processing circuitry can be configured to perform data processing in one of multiple states (including an unprivileged state and a privileged state). In some implementations, the processing circuitry can operate in multiple modes, including a processor mode for executing exception handlers and a thread mode. Execution in processor mode can always be in a privileged state, while execution in thread mode, whether in a privileged or unprivileged state, depends on configuration values.

[0050] In a specific implementation where the processing circuitry is arranged to execute program code in multiple different security domains, the exception control circuitry can also be arranged to perform additional checks when determining whether registers containing data need to be saved before triggering the execution of an exception handling routine. For example, to ensure the security of a security domain is not compromised, the exception control circuitry can take into account transitions within a security domain when determining whether data in a second register subgroup needs to be saved, independent of the previously mentioned checks that attempt to classify exception handling routines based on configuration information in the configuration storage device. Specifically, in response to identifying an exception as a first exception that causes a transition from a security domain to a less secure domain when background processing is executed by the processing circuitry in a security domain, the exception control circuitry can be further arranged to trigger the saving of data from the second register subgroup and clear the registers before triggering the execution of the exception handling routine corresponding to the identified exception. This approach ensures that data in a security domain is not unintentionally provided to exception handling routines operating in a less secure domain.

[0051] The identified exception can take various forms, and is the first exception that causes a transition from a safe domain to a less safe domain when background processing is executed by the processing circuitry in a safe domain. For example, the identified exception can be a given exception that causes a transition from background processing, as previously mentioned, or alternatively, a trailing exception. For example, a given exception that causes a transition from background processing may also be processed in a safe domain, and this given exception is a subsequent trailing exception that is then processed in an unsafe domain, and thus becomes the first exception that causes a transition from a safe domain to a less safe domain.

[0052] In a specific implementation where the exception control circuitry can perform additional checks to determine whether to save data from the second register subgroup, the exception control circuitry can be further arranged to refer to the previously mentioned status flags, such that in response to an identified exception, the exception control circuitry can be arranged to skip triggering the saving of that data when the status flag indicates that data from the second register subgroup has been saved. Therefore, during exception handling, the use of status flags again ensures improved efficiency when handling the saving and restoring of the states of the individual registers.

[0053] A specific example will now be described with reference to the accompanying drawings.

[0054] Figure 1 An example of a data processing system 2 is schematically shown, which includes processing circuitry 4 for performing data processing in response to instructions fetched from a memory system 26. The memory system 26 may include caches (e.g., one or more levels of data caches and / or instruction caches) and main memory. In some larger systems, the main memory may include a single memory type, such as DRAM, while in some smaller systems (e.g., microcontrollers), the main memory may include different memory types, such as flash memory for storing program code and constant values, and SRAM for storing a stack and other values ​​that change during execution. The processing circuitry 4 has a processing pipeline comprising multiple pipeline stages, including, for example: a fetch stage 12 for fetching instructions to be executed from the memory system 26; a decode stage 14 for decoding the fetched instructions to generate control signals for controlling the remaining pipeline stages to perform data processing; and an execution stage 16 for executing the decoded instructions to perform the data processing operation. Register 6 is provided for storing source data (source operands) for access by processing circuit 4 during instruction execution, and for storing result data (destination operands) generated by executing those instructions. Additionally, control register 18 is provided for storing control information for controlling the operation of processing circuit 4.

[0055] It should be understood that Figure 1The pipeline stages shown are simplified representations, and other types of pipeline stages are also available, such as: a rename stage for performing register renaming; a release stage for queuing instructions waiting to be executed and releasing those instructions for execution when their required source operands are available; and a write-back stage for processing instruction commitments and writing the results back to register 6. The pipeline can be an ordered pipeline or an unordered pipeline.

[0056] While the processing circuitry is executing program code, one or more exceptions may occur, prompting the execution of the corresponding exception handling routine. When an exception causes background processing to temporarily pause to allow the execution of the corresponding exception handling routine, it is typically necessary to save at least some of the data currently stored in register 6 associated with the background processing so that the data can be restored to the register later when the processing circuitry returns to executing the background processing. Such data can be saved for later use in various ways, but in one exemplary arrangement, such data is stored on stack 28 within memory system 26.

[0057] An exception control circuit 30 is provided to control the occurrence of exceptions. In response to a given exception, the exception control circuit is arranged to cause a state save operation to save data from register 6 before triggering the processing circuit 4 to execute a given exception handling routine corresponding to the given exception. As will be discussed in more detail herein, in response to the exception control circuit 30, exactly which registers save their state to stack 28 (such a save operation is also referred to herein as a stack operation) will depend on how the given exception handling routine is classified by the exception control circuit 30, and to assist the exception control circuit 30 in this classification process, the exception control circuit 30 accesses configuration storage 32, which stores configuration information for classifying exception handling routines. Figure 1 As shown, in some implementations, the exception control circuitry can directly access the register and memory hierarchy. However, in other implementations, the exception control circuitry can indirectly perform state saving by triggering a processing circuitry to perform the state saving on its behalf. In this way, the number of connections to the register and memory hierarchy can be minimized, thereby saving circuit area and power.

[0058] like Figure 1 As shown, register 6 can be considered to include a first register subgroup (referred to herein as caller register 8) and a second register subgroup that does not overlap with the first subgroup (referred to herein as callee register 10). By default, exception control circuitry 30 is responsible for directly or indirectly saving (the stack) the caller register when handling exceptions from background processing, while the saving (the stack) of the callee register is the responsibility of the given exception handling routine executed by the processing circuitry in response to a given exception.

[0059] However, as previously mentioned, the system described in this paper supports the execution of not only trusted exception handlers but also untrusted exception handlers. When executing an untrusted exception handler, the state of all registers (caller registers and callee registers) must be saved to stack 28, and the state of all registers must be cleared from the registers before executing the untrusted exception handler code to ensure that the untrusted exception handler code does not access data belonging to background processing. Trusted wrapper software can be used on the entries and exits of the untrusted exception handler code to perform any necessary steps to ensure that the untrusted body of the exception handler code does not access data it should not access, and thus can be used, for example, to save and clear callee registers associated with background processing. However, interrupt latency becomes a significant issue, and performing such steps using wrapper software can significantly increase the interrupt latency of such untrusted exception handler code.

[0060] As will be discussed in more detail herein, to mitigate this problem, exception control circuitry 30 is configured to refer to configuration information in configuration storage 32 to determine whether a given exception handling routine associated with a given exception is trusted or to be processed as untrusted. If a given exception handling routine is to be processed as untrusted, then exception control circuitry hardware 30 can be configured to save not only the caller register but also the callee register, and clear the contents of any saved registers before triggering the processing circuitry to execute the given exception handling routine. This significantly reduces interrupt latency for such untrusted exception handling routines by avoiding the need to save and clear registers to be executed by the trusted wrapper software. Furthermore, by using configuration information to attempt to distinguish between trusted exception handling routines and those to be processed as untrusted, this ensures that exception control circuitry 30 does not always need to save the state of all registers and can continue to save only the caller register for trusted exception handling routines, thus avoiding any performance impact on such trusted exception handling routines (which can often be time-critical processes).

[0061] The above-described techniques can be employed in various systems. For example, they can be employed in systems operating within a single security domain, where the processing circuitry can operate in both privileged and unprivileged states, and where configuration information enables the exception control circuitry to attempt to classify exceptions so as to treat those exception handling routines as untrusted, the main body of which will be executed by the processing circuitry in the unprivileged state. Alternatively, the above-described techniques can be employed in systems having security domains and less secure domains, with only a single processing state in each security domain, where configuration information enables the exception control circuitry to attempt to classify exceptions so as to treat those exception handling routines executed by the processing circuitry in the less secure domain as untrusted.

[0062] However, for the purposes of the examples discussed herein, a system will be considered in which processing circuitry is capable of operating in multiple security domains (including secure and less secure domains), and in each security domain, the processing circuitry is capable of operating in multiple processing states (including unprivileged and privileged states). Configuration information can then be specified for classifying a given exception handling routine within a security domain in which it will execute. Thus, the configuration information can vary between secure and less secure domains, but within any particular security domain, the configuration information can be used to attempt to distinguish between trusted exception handling routines and those to be processed as untrusted (e.g., in each of the previously given instances, any exception handling routine whose body is to be executed when the processing circuitry is in an unprivileged state can be considered untrusted).

[0063] In such a system 2, the system may further include a memory access check circuit 20 for checking whether access to the memory system 26 is permitted based on attribute data specified for each region of the memory address space. The memory access check circuit may include a Security Attribute Unit (SAU) 24 for storing security domain definition data that defines security domains associated with each corresponding region of the memory address space. Based on the security attribute data, the Security Attribute Unit 24 may check whether memory access is permitted depending on the current security domain of the operation of the processing circuitry and the security domain associated with the region containing the target address of the memory access. In other implementations, the SAU 24 may not directly store the security domain definition data, but may access security domain definition data stored elsewhere to perform the memory access check. In some systems, the security domain definition data may be stored in the memory system 26, or it may be stored in a configuration register elsewhere in the system 2.

[0064] Processing circuit 4 can operate within its current security domain, which generally corresponds to the security domain associated with the address of the instruction currently being executed (although some exceptions may exist, such as when transitioning between processing domains). This can trigger a transition in the current security domain of processing circuit 4 when an instruction branches from an address in a region within a domain, as specified by SAU 24, to an address in a region associated with a different domain. In other implementations, such a branch may not directly trigger a transition in the current security domain, but instead trigger additional security checks, such as the presence of a gateway instruction. In these implementations, the gateway instruction itself may trigger the change in the current security domain. For some other types of security domain transitions, specific branch instructions can be used to branch to an instruction executed at the address specified by that instruction, and in a different security state. Generally, while operating within a secure domain, processing circuitry can access data in memory regions associated with both the secure and less secure domains. Conversely, when operating within a less secure domain, processing circuitry can access data in regions associated with that less secure domain, but may not be permitted to access data in regions of the address space that are associated with the secure domain. The SAU24 designates that address space as associated with the secure domain. This allows for the protection of sensitive data from unauthorized access by code operating within the less secure domain.

[0065] Additionally, the memory access checking circuitry may include a memory protection unit (MPU) 22, which checks whether memory access to the memory system 26 meets access permissions. These access permissions may specify which privilege levels of the processing circuitry 4 are allowed to access a given region of memory, or may specify whether a memory region in the address space is accessible by both read and write operations, or is a read-only region where write access is prohibited. For example, the access permissions used by the MPU 22 may be specified by a higher-privileged process (such as a super administrator or operating system) to control which regions of memory are allowed to be accessed by lower-privileged processes (such as applications), and how these regions are accessed (read-only or read / write). The permissions provided by the MPU 22 may be orthogonal to the permissions provided by the SAU 24, such that for a given memory access to be permitted, it should pass a check based on the access permissions defined for both the MPU 22 and the SAU 24. Although the MPU 22 in Figure 1 The MPU 22 is shown as a single entity, but in some examples, separate secure and less secure MPUs may be provided, each associated with a secure domain within a secure domain, so that different memory access permissions can be specified for a given memory region depending on whether the current domain is secure or less secure (e.g., a region may be readable only in a less secure domain, but both readable and writable in a secure domain).

[0066] Therefore, as Figure 2As shown, processing circuit 4 can support data processing in one of a plurality of security domains, including at least a secure domain (S) and a less secure domain (LS). Although Figure 2 The system shown has only two security domains, but it can provide three or more domains associated with different security levels.

[0067] Furthermore, within a given security domain, such as Figure 2 As shown, the processing circuitry can perform data processing in one of several modes, including processor mode (H) and thread mode (T). Processor mode is typically used for exception handling, and thus, for example, a trusted exception handling routine can be executed in processor mode. Thread mode is typically used to run different threads, such as different application threads. However, the body of an untrusted exception handling routine can also be executed as a thread in thread mode; in one exemplary implementation, the associated wrapper code is executing in processor mode. When operating in processor mode H, it is assumed by default that processing circuitry 4 has a higher privileged operating mode, such that access to memory and control registers is controlled according to a privilege level different from the lower privilege level. In thread mode T, the processing circuitry can have one of several different privilege levels, depending on other architectural states stored in the control registers.

[0068] Therefore, as Figure 2 As shown, the combination of the security domain and the mode of the operation processing circuit 4 determines how the processing circuit 4 performs various aspects of the processing. Figure 2 Four different combinations of these patterns are shown, including:

[0069] • Thread-safe mode (an abbreviation for a combination of security domain and thread mode)

[0070] • Less safe threading mode (a combination of less safe domains and threading modes)

[0071] • Secure processor mode (a combination of security domain and processor mode) and

[0072] • Less secure processor mode (a combination of less secure domain and processor mode).

[0073] The configuration information provided in the configuration storage device 32 can take various forms. Figure 3AExamples are shown where separate configuration information is provided for each of at least one possible subgroup of exception handling routines. In one exemplary implementation, an entry may be provided for each exception handling routine, but in other implementations, it is possible that the category of one or more particular exception handling routines is predetermined and therefore does not need to be captured within an entry in the configuration storage device. For example, certain important exceptions may always be considered to belong to a first category, and therefore the exception control circuit 30 may make a determination based on the type of the exception itself without referring to the configuration information in the configuration storage device.

[0074] For each exception handling routine that provides corresponding configuration information in the configuration storage device 30, an entry is allocated within the configuration storage device 30. This entry has a first field 35 for identifying the exception handling routine and a second field 40 for identifying whether the exception handling routine belongs to a first category or a second category. In other embodiments, the second field 40 may be indexed by an exception number, and therefore a separate storage device for the first field 35 may not be necessary. The information provided in field 40 can take various forms, but in one example, the information is a single bit field set to identify when the exception handling routine belongs to the second category and cleared when the exception handling circuit belongs to the first category. Therefore, in such embodiments, setting field 40 instructs the exception control circuit 30 to save all register states, rather than just the caller register.

[0075] In implementations with multiple security domains, the configuration storage device can then be copied for each security domain. However, it should be understood that some exception handling routines may be specific to a particular security domain, and therefore only entries for such exception handling routines need to be generated in the table of exception handling routines maintained for the relevant security domain. In some implementations, there may be exceptions that can be configured to target either a security domain or a less secure domain. In such cases, copying the configuration storage device for these exceptions may be wasteful, as only one configuration storage device will be used to copy field 40 (which depends on the target security domain of the exception). In such implementations, each exception with a configurable target security domain may only provide a single field 40, and alternatively, if the exception is configured to target a security domain, access to field 40 for a given exception from a less secure domain may be prohibited.

[0076] In some instances, there may be a large number of different exception handling routines supported by the system, and in such instances, the size of the configuration storage device 32 required to capture the configuration information of each exception handling routine can be relatively large. However, in some specific implementations, a more efficient form of configuration storage device can be utilized. For example, in one exemplary embodiment, it may be common practice to assign lower priority to untrusted exception handling routines compared to trusted exception handling routines, and thus the priority level of associated exceptions can be used as an indicator of whether an exception handling routine should be handled as a trusted or untrusted proxy. In such cases, the configuration storage device 30 may be arranged to store threshold priority indicators, such as... Figure 3B As shown. In specific implementations with multiple security domains, different threshold priorities can be indicated for each security domain. Therefore, when considering the transition from background processing to a given exception handling routine indicated by an associated given exception, the priority of the given exception can then be compared with the threshold priority indication in configuration storage 32 to determine whether the associated exception handling routine should be considered in a first category or a second category. In cases where different threshold priorities are provided for different security domains, the security domain in which the given exception handling routine is executed can then be considered when determining whether to compare the appropriate threshold priority with the priority of the given exception.

[0077] According to the third exemplary embodiment, the threshold priority can be fixed, and the configuration storage device can be configured as follows: Figure 3C The configuration is shown to store configurable priorities for each exception. Therefore, each entry in the configuration storage 32 can be arranged to provide a first field 45 for identifying an exception handling routine and a second field 50 for identifying the priority of that exception. In other implementations, the second field 50 may be indexed by an exception number, and therefore a separate storage device for the first field 45 may not be necessary. (The above refers to...) Figure 3A The comments made regarding whether entries from different security domains need to be copied also apply. Figure 3C The specific implementation.

[0078] In one specific implementation, when the associated priority of a given exception is less than a threshold priority, the associated exception handling routine is determined to belong to the second category, meaning it will be processed as an untrusted exception handling routine. Therefore, this will trigger the exception control circuitry 30 to save and clear the state of both the caller register and the callee register before the triggering circuitry executes the given exception handling routine. However, if the priority is the same as or greater than the threshold priority, the exception handling routine will be considered to belong to the first category, and the exception control circuitry will only save (and optionally clear) the state of the caller register before the triggering circuitry executes the given exception handling routine. In other implementations, if the exception's priority is less than or equal to the threshold, the exception may be considered to belong to the second category (where both the caller register and the callee register need to be saved). In such systems, if the exception's priority is greater than the threshold, the exception may be considered to belong to the first category.

[0079] In other implementations, the priority of an incoming exception can be modified before it is compared with a threshold. The threshold priority can also undergo such modification before comparison. Modifying an exception's priority can take the form of restricting the priority to a range, or mapping the priority from one priority range to another. These priority modification classifications can be useful in systems with multiple security domains to ensure that even the highest priority exception for a less secure domain cannot preempt security-critical exceptions associated with that domain. However, when different comparisons and / or various priority modification and remapping schemes are used, it should be understood that these schemes do not prevent modified / remapped exception priorities from being used as a proxy for determining whether an associated exception handler should be processed as a trusted proxy.

[0080] Providing a priority configuration field for each exception is a common practice in modern systems, and therefore reusing this existing information to categorize exception handling routines does not add extra cost and provides a very efficient mechanism for performing the categorization described above.

[0081] Figure 4 This is a flowchart illustrating the handling of an exception from a background process. At step 100, it is determined whether an exception has occurred from a background process. For example, background processing may involve the execution of program code by processing circuitry rather than an exception handling routine, such as the execution of a specific application thread; in this case, the exception is the initial exception from that background process. However, sometimes it may be that the background process itself is executing a specific exception handling routine, and the exception detected at step 100 is a preemptive exception with a higher priority than the exception corresponding to the current exception handling routine. In this instance, the current exception handling routine must be interrupted (because the processing is background) in order to execute the exception handling routine required for the higher-priority exception detected at step 100.

[0082] If an exception is detected from background processing at step 100, then at step 105, the exception control circuitry 30 is configured to refer to the configuration storage device 32 to determine whether the required exception handling routine (i.e., the exception handling routine required to handle the exception detected at step 100) belongs to a first category or a second category. As previously discussed, the configuration information maintained in the configuration storage device 32 makes trusted exception handling routines generally considered to belong to the first category, and any exception handling routine belonging to the second category will be considered an untrusted exception handling routine. In specific implementations using threshold priority indication, then in some instances, it may be possible that a trusted exception handling routine actually has a sufficiently low priority, such that the exception handling routine is considered to belong to the second category and therefore is considered untrusted. This results in no incorrect behavior at the operating system level, but only a slight performance penalty by causing the callee register to be saved and cleared in addition to the caller register. Alternatively, if the system provides an untrusted exception handling routine with a particularly high priority, the determination made by referring to the configuration storage device can identify the exception handling routine as belonging to the first category and therefore trusted; in this case, the exception control circuitry will only save the caller register state. However, before handing over execution to the body of the untrusted exception handling routine, the previously mentioned wrapper software provided in handling mode can be used to save and clear the callee's registers.

[0083] At step 110, it is determined that the required exception handling routine belongs to a first category, and if so, the process proceeds to step 115. In some implementations, step 115 will not be required, but in other implementations, the exception control circuitry 30 may perform additional checks to determine whether the callee register needs to be saved. As a specific example, as discussed in common U.S. Patent 9,202,071 (the entire contents of which are incorporated herein by reference), the exception control circuitry may be arranged to detect situations where background processing is in a secure domain and the exception handling routine will be executed in a less secure domain, and in this instance, the exception control circuitry may be arranged to save the callee register in addition to the caller register. In implementations incorporating this functionality, the same exception control circuitry 30 can then be used to implement the techniques described herein based on the classification of individual exception handling routines within a specific security domain. As will be apparent from the preceding discussion, such classification occurs independently of the presence or absence of any transition caused by an exception occurring within the security domain.

[0084] If no other checks indicate that the callee register should be saved at step 115, the process proceeds to step 120, where only the caller register is saved to stack 28. In systems employing multiple security domains, a different stack may be provided for each security domain, and data from the caller register may be placed on the appropriate stack. Thus, if the background process is in a secure domain, data from the caller register is saved to the secure stack, while if the background process is in an unsecured domain, data from the caller register is saved to the unsecured stack. As indicated by step 120, the exception control circuitry may optionally clear the caller register if necessary. However, in other instances, if the required exception handling routine has been determined to belong to the first category (i.e., considered trustworthy), it may be deemed unnecessary to clear the caller register. At step 122, a status flag is cleared to identify that only the caller register has been saved to the stack.

[0085] If it is determined at step 110 that the required exception handling routine belongs to the second category (i.e., untrusted), the process proceeds to step 130, where exception control circuitry 30 is arranged to trigger the saving of data from the caller register and the callee register onto the stack, and to cause these registers to be cleared. Registers can be cleared after the saved state, and in one implementation, each register can be cleared as its data is saved onto the stack. Figure 4 As shown, step 130 can also be reached from the "yes" path of step 115, i.e., if the required exception handling routine belongs to the first category, but some other checks performed by the exception handling circuitry determine that saving the callee's registers is appropriate. Similarly, if the system supports execution in multiple security domains, the stack on which the register states are saved will be the stack associated with the security domain in which background processing is being performed.

[0086] Following step 130, and then at step 135, a status flag is set to indicate that the callee register has been saved to the stack. The status flag can be set in several ways. For example, the status flag can be provided as an extra bit within information stored in the link register to indicate the return address to which processing should return after the exception handling routine completes. In other implementations, the information stored in the link register is the exception return value. The exception return value is a reserved non-executable address that triggers the exception return procedure when a branch reaches that address. However, in both cases, the information initially stored in the link register can subsequently be migrated from the link register to other memory structures within the system, and thus may end up, for example, on a stack within the memory system or in another register.

[0087] After step 135, or after step 122, if the exception handling routine belongs to the first category, then at step 125, the exception control circuit 30 triggers the processing circuit to execute the required exception handling routine.

[0088] Figure 5 This shows the steps taken when configuring the storage device. Figure 3B The form shown is used to execute the threshold priority indication. Figure 4 The flowchart for step 105 is as follows. At step 150, the priority of the anomaly detected at step 100 is determined, and the corresponding anomaly handling routine is executed in the security domain.

[0089] At step 155, the exception control circuit then obtains a threshold priority applicable to a security domain from the configuration storage device, in which an exception handling routine will be executed. As previously mentioned, the configuration storage device 32 may store different threshold priorities for each security domain if needed, and thus determine an appropriate threshold priority at step 155.

[0090] At step 160, it is determined whether the priority of the exception is lower than the threshold priority. If not, the exception handling routine is determined to belong to the first type at step 165. However, if the priority of the exception is lower than the threshold priority, the exception handling routine is determined to belong to the second type at step 170.

[0091] Figure 6 This is a flowchart illustrating the exception return handling performed upon completion of an exception handling routine. At step 200, it is determined whether the exception return point has been reached, i.e., whether the processing of the current exception handling routine has been completed. In some implementations, this can be indicated by branching to a reserved non-executable exception return address, which may contain the previously mentioned status flag. In this case, the process proceeds to step 205, where the value of the previously mentioned status flag is determined. As previously mentioned, this can be available within a link register, but in some instances, the contents of that link register are simultaneously transferred elsewhere within the system, such as onto a stack, and therefore at this level, relevant information can be retrieved from the stack to determine the value of the status flag.

[0092] At step 210, it is determined whether the exception return will return to background processing. Assuming processing will return to background processing, at step 215, it is determined whether a status flag indicates that the callee register has been saved. In one exemplary implementation, the status flag information directly identifies whether the callee register has been saved. However, in an alternative implementation, the status flag information may encode whether a deviation from the default stack rules has occurred, and by knowing this information, it can be determined whether the callee register has been saved in any given situation.

[0093] If the callee register has not yet been saved, the process proceeds to step 220, where the exception control circuit 30 is configured to trigger the destack of the caller register, i.e., to retrieve the data previously saved from the caller register from the relevant stack and restore that data to the caller register. At this point, the subsequent trigger processing circuit resumes background processing.

[0094] If it is determined at step 215 that the callee register has been saved, the process proceeds to step 225, where the exception control circuitry 30 is configured to trigger a destack of both the caller and callee registers. This is achieved by reading previously saved data about the caller and callee registers from the relevant stack and restoring that data to the relevant registers. The triggering circuitry then returns to background processing.

[0095] However, it is not always the case that processing will return to background processing upon exception return. Specifically, another exception may be pending at that point; this is an exception with a lower priority than the exception handling routine that has just completed, and therefore does not preempt that exception handling routine. Therefore, if the pending exception has a higher priority than background processing, rather than simply returning to background processing for another immediately occurring exception, a trailing chain mechanism can be employed to begin execution of the pending exception that has been waiting for the current exception handling routine to complete. Thus, if it is determined at step 210 that processing will not return to background processing upon exception return, then at step 230, a status flag value is used to determine whether any further stack trace of the background register contents is needed before executing the exception handling routine associated with the trailing chain exception.

[0096] Figure 7 This is a flowchart illustrating how to handle trailing chained exceptions upon exception return, and thus shows how this can be implemented in an exemplary embodiment. Figure 6 The process of step 230. At step 250, the exception control circuit 30 refers to the configuration storage device 32 to determine whether the exception handling routine required for the terminal cascading exception belongs to the first category or the second category. At step 255, it is determined whether the terminal cascading exception belongs to the second category, and if so, the required exception handling routine is processed as untrusted and the process proceeds to step 260.

[0097] At step 260, it is determined whether a status flag indicates that the callee register has been saved. Specifically, since the required exception handling routine belongs to the second category and is therefore untrusted, the callee register state must be saved, but it is possible that this state has already been saved by the exception control circuitry in response to a previous action of a previous exception. If it is determined at step 260 that the status flag indicates that the callee register has not been saved, then at step 265, the callee register is saved to the stack by the exception control circuitry 30, and the callee register is cleared. Specifically, the contents of the callee register are saved to the stack associated with the security domain in which background processing is being performed. Additionally, at step 270, the contents of the call register are cleared. The process then proceeds to step 285, in which the processing circuitry is triggered to execute the exception handling routine required for the final chained exception. If it is determined at step 260 that the callee register has been saved based on the status flag, step 265 can be bypassed, and alternatively, the callee register can be cleared only at step 267. The process then proceeds to step 270.

[0098] At step 255, if it is determined that the exception handling routine required for the cascading exception belongs to the first category, then the known exception handling routine is reliable. Furthermore, since the required exception handling routine will execute in response to the cascading exception, the known exception control circuitry 30 has already saved the caller register state to the relevant stack associated with the previous exception. Therefore, no further action is required, different from the optional clearing of the caller register at step 280, and the process can proceed directly to step 285, in which the processing circuitry is triggered to execute the exception handling routine required for the cascading exception.

[0099] However, as previously combined Figure 4 As mentioned, in some specific implementations, the exception control circuit 30 may also perform additional checks to determine whether the state of the callee register needs to be saved, and thus at step 275, the exception control circuit may determine whether any other checks indicate that the callee register should be saved. If so, the process may proceed to step 260; otherwise, the process may proceed to step 280.

[0100] As an example of an implementation where the exception control circuitry can perform additional checks in a system employing multiple security domains, including secure and less secure domains, it is appropriate to execute the less secure exception handling routine in a case where background processing is occurring in a secure domain and the exception handling routine will be executed in a less secure domain, for the sake of the first saved callee register. The initial exception occurring from background processing may be related to an exception awaiting processing in a secure domain. Therefore, when handling a trailing chain exception, it may be appropriate to also check whether the exception handling routine required for the trailing chain exception is the first exception that, in the case of background processing in a secure domain, prompts a transition to a less secure domain, and in this instance, if the trailing chain exception has not yet been stacked, then the callee register is stacked; otherwise, it is stacked by the exception handling routine required for a trailing chain exception that is determined to belong to the second category.

[0101] Figure 8 This is a flowchart illustrating how preemption is handled according to an exemplary implementation. Preemption occurs when a newly arriving exception has a higher priority than the currently executing exception handling routine, and the exception occurs while the current exception handling routine is being executed. Such a higher-priority exception that occurs during the processing of the current exception handling routine is called a preemption exception. If a preemption exception is detected at step 300, the process proceeds to step 305, where the current exception handling routine is processed as background processing, and the preemption exception is processed as an exception from that background processing. Therefore, at step 310, execution... Figure 4 The previously discussed process is used to determine whether to save the register state to the stack before executing the exception handling routine to handle the preemptive exception. Therefore, there may actually be nested levels of background processing, where each time an exception occurs from such background processing, the process is implemented... Figure 4 The process. Examples will be provided later. Figure 9C Let's have a discussion.

[0102] Figures 9A to 9C This illustrates how exceptions are handled in various exemplary scenarios when the configuration information stored in the configuration storage device 32 provides threshold priorities. Figure 9AAn example of an exception occurring during background processing is shown, where the exception has a lower priority compared to a threshold priority. As previously discussed, the priority value used to infer priority can take various forms. For example, in one implementation, a lower priority value may indicate a lower priority, but in a particular exemplary implementation, a lower priority value actually indicates a higher priority. Similarly, as previously discussed, priorities may be modified and / or remapped before comparison. However, since priority values ​​are encoded and processed, it should be understood that, based on the known obtained priority associated with the exception and the known obtained threshold priority, it can be determined whether the obtained priority of the exception is lower than the obtained threshold priority.

[0103] exist Figure 9A In the example, during background processing, an interrupt is received at point 350, prompting exception control circuitry 30 to transition from background processing to execution of the required exception handling routine. During the transition between points 350 and 355, exception control circuitry 30 references configuration storage device 32 to obtain a threshold priority and evaluates whether the exception's priority is below the threshold priority. In this example, it is determined that the exception's priority is below the threshold priority, and therefore the exception control circuitry triggers the stacking of the caller register and callee register onto the corresponding stack 28 within memory system 26, and sets a status flag to identify that the callee register has been stacked.

[0104] exist Figure 9A In the example, it is assumed that the body of the exception handling routine will execute in an unprivileged state, and in one exemplary implementation, the wrapper software is associated with the body of the exception handling routine to handle transitions to and from the body of the exception handling routine. It should be noted that in the previously described threading mode, the background code may be executing in a privileged or unprivileged state, and in one exemplary implementation, regardless of whether the background code is in an unprivileged or privileged state, when the processing circuitry operates in processor mode in a privileged state, an exception handling routine entry appears at point 355, and therefore the wrapper software executes in a privileged state and may be referred to as a privileged wrapper.

[0105] Since the exception control circuit hardware 30 has already stacked the callee register and the caller register, the privileged wrapper software does not need to take any steps to stack the callee register, and instead only needs to take any other additional steps required before processing the unprivileged body executing the exception handling routine. Similarly, after the body executing the exception handling routine between points 360 and 365, the privileged wrapper is again used to take any necessary steps to manage the transition back to background processing before handing it over to the exception control circuit 30, and again, no steps regarding unstacking the callee register are required, as the exception control circuit hardware will handle this process. Therefore, the interrupt latency associated with executing the exception handling routine can be significantly reduced.

[0106] During the transition between points 370 and 375, the exception handling circuitry detects that a status flag has been set and unpacks both the caller's and callee's registers. It may subsequently clear the status flag. As previously discussed, the storage location of the status flag may change when the exception handling circuitry processes an exception return. For example, while the exception handling circuitry may have set the status flag to a bit in the link register on the exception entry, the contents of the link register may have moved during this time and may have ended, for example, on the stack itself. Therefore, when evaluating which registers need to be unpacked during the exception return, the exception handling circuitry will access the status flag from the relevant location. As previously discussed, in some implementations, the status flag is set in the exception return value, which is a reserved non-executable address, and the exception return process triggers an attempt to branch to the exception return value. In such cases, the action of branching to the exception return value also affects the passing of the status flag from an intermediate storage location (e.g., the stack) to the exception handling circuitry.

[0107] In some implementations, it may not be necessary to actually clear the status flag when an exception is returned, because in instances where the status flag forms a field within the exception return value, the exception return value is consumed when the exception is returned, and therefore no longer exists at that point.

[0108] Figure 9B A second exemplary scenario is illustrated where two interrupts are received simultaneously at point 400 during background processing. In this example, both an Unmasked Interrupt (NMI) and a Standard Interrupt (IRQ) are received, and the NMI is processed first because it has a higher priority. Between points 400 and 405, exception control circuitry 30 evaluates the priority of the NMI relative to a threshold priority and determines that the NMI has a higher priority than the threshold priority. Therefore, the exception control circuitry only stacks the caller register. As previously referenced... Figure 4The exception control circuitry discussed may perform additional checks to determine whether the callee register should be stacked, but for the purposes of this discussion, it will be assumed that any such further checks performed result in the determination that the callee register does not need to be stacked.

[0109] Between points 405 and 410, an NMI exception handling routine is executed to handle the NMI. In this example, it is assumed that the exception handling routine executes entirely in processor mode, where the processing circuitry operates in a privileged state.

[0110] At step 410, the exception handling routine for the NMI completes and determines that a cascading exception, i.e., the original IRQ interrupt, exists. It should be noted that although in Figure 9B In the example shown, the NMI interrupt and the IRQ interrupt are received at exactly the same time. However, if an IRQ exception occurs at any point during NMI processing, before point 410, an error will also occur. Figure 9B The processing is shown.

[0111] Between points 410 and 415, the exception control circuit 30 determines whether the priority of the IRQ interrupt is higher or lower than the threshold priority, and in this instance, it is determined to be lower than the threshold priority. Therefore, referring to the previously described... Figure 7 At step 255, it is determined that the exception handling routine to be executed to handle the IRQ interrupt belongs to the second category, and then at step 260, it is determined that the status flag does not indicate that the callee register has been saved. Specifically, it should be remembered that only the caller register is saved during the transition between points 400 and 405. Therefore, the exception control circuitry now triggers the stack of the callee register, the clearing of the register, and sets the status flag to indicate that the callee register has been saved.

[0112] Then, between points 415 and 430, the exception handling routine required to handle the IRQ interrupt is executed, and according to the previous... Figure 9A The discussion assumes that the body of the exception handling routine is executed in an unprivileged state by a thread in thread mode between points 420 and 425, and that transitions to and from the unprivileged thread are managed by privileged wrapper software that executes in processor mode.

[0113] At point 430, the execution of the exception handling routine is considered complete, and therefore the exception control circuit 30 determines at this point that there are no further trailing exceptions, and processing should return to background processing at point 435. During the transition to background processing, the exception control circuit detects that a status flag has been set and therefore triggers a destack of both the caller's register and the callee's register. The status flag can also be cleared at this point if necessary, but as mentioned above, this may not be necessary because the status flag may no longer exist after the exception returns.

[0114] Figure 9C An example of preemption is shown, where a higher-priority interrupt is received during the execution of an exception handling routine in response to an interrupt. Specifically, at point 450, a standard IRQ interrupt is received, and between points 450 and 455, the exception control circuitry 30 determines that the priority of this interrupt is lower than a threshold priority, and therefore triggers a stack check on both the caller's register and the callee's register used for background processing, and sets the status flag associated with the IRQ interrupt to indicate that both the caller's register and the callee's register have been saved. As previously discussed, the contents of these registers are then typically cleared before being handed over to the exception handling routine for execution to handle the IRQ interrupt. Figure 9C For the purpose of this explanation, it is irrelevant whether the exception handling routine for handling IRQ interrupts executes in a privileged or unprivileged state, and therefore whether any associated wrapper software exists. However, at some point during the exception handling routine, an NMI is received at point 460, which has a higher priority than the IRQ interrupt. Therefore, the NMI is treated as a preemptive exception, and the exception handling routine for IRQ interrupts is suspended while the NMI exception is being handled.

[0115] Specifically, such as Figure 9C As shown, between points 460 and 465, the exception control circuitry detects that the NMI has a higher priority than the threshold priority, and therefore the stack is updated to reflect the state of the caller register used by the exception handling routine that handles the IRQ interrupt. This also clears the status flag value associated with the NMI, and at that point, the IRQ exception handling routine is processed as a new background process.

[0116] Between points 465 and 470, an exception handling routine for handling NMI is executed. After this point, if an exception is detected, background processing is resumed (in this case, the background processing is the exception handling routine for handling IRQ). Between points 470 and 475, the exception control circuitry determines from the status flag for NMI that only the caller register has been stacked, and therefore only triggers destacking of the caller register for the exception handling routine for IRQ interrupt.

[0117] Between points 475 and 480, the exception handling routine for handling the IRQ interrupt completes, and then at step 480, a return to background processing (initial background processing) is detected. Therefore, the exception control circuitry determines that the status flag for the IRQ interrupt has been set, and thus de-stacks both the caller and callee registers of the background processing between points 480 and 485, after which background processing resumes.

[0118] Figure 10A specific implementation of a usable simulator is illustrated. While the previously described example implementations emulate the invention in terms of apparatus and methods for operating specific processing hardware supporting the technologies involved, it is also possible to provide an instruction execution environment implemented using a computer program according to the examples described herein. Such computer programs are generally referred to as simulators, in part because they provide a software-based implementation of a hardware architecture. Types of simulator computer programs include emulators, virtual machines, models, and binary converters, including dynamic binary converters. Typically, the simulator implementation can run on a host processor 515 supporting the simulator program 505, optionally running a host operating system 510. In some arrangements, multiple emulation 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 simulator implementations that execute at a reasonable speed, but this approach may be reasonable in certain situations, such as when it is desirable to run code native to another processor for compatibility or reuse reasons. For example, the simulator implementation may provide additional functionality to the instruction execution environment that is not supported by the host processor hardware, or provide an instruction execution environment that is typically associated with a different hardware architecture. An overview of the simulation is given in the following literature: “Some Efficient Architecture Simulation Techniques”, Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

[0119] As with the examples previously described with reference to specific hardware constructs or features, in a specific implementation of the simulation, equivalent functionality may be provided by suitable software constructs or features. For example, specific circuitry may be provided as computer program logic in a specific implementation of the simulation. Similarly, memory hardware (such as registers or caches) may be provided as software data structures in a specific implementation of the simulation. Furthermore, the physical address space for accessing memory 26 in hardware device 2 may be simulated as a simulated address space that is mapped by simulator 505 to the virtual address space used by host operating system 510. One or more of the hardware elements referenced in the previously described examples exist in an arrangement on host hardware (e.g., host processor 515), and where appropriate, some implementations of the simulation may utilize the host hardware.

[0120] 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 (instruction execution environment) to the target code 500 (which may include an application program, operating system, and management program), the virtual hardware interface being identical to the hardware interface of the hardware architecture modeled by the simulator program 505. Therefore, the simulator program 505 can be used to execute program instructions of the target code 500 from within the instruction execution environment, enabling the host computer 515, which does not actually possess the hardware features of the device 2 discussed above, to emulate these features. The simulator program may include processing program logic 520 for simulating the behavior of the processing pipeline 4, and for simulating... Figure 1 The exception control program logic 525 governs the behavior of the exception control circuit 30 of the hardware device 2. Data structure simulation program logic 530, maintained by simulator code 505, can also be used to simulate the architecture registers 6 of system 2, mapping the architecture registers of the target architecture to the memory space used by the host hardware 515. This data structure simulation program logic 530 can also be used to simulate the configuration storage device 32 of system 2 by providing suitable storage locations within the memory space used by the host hardware 515. Therefore, in Figure 10 In the example, the techniques described herein for stacking and unstacking caller and callee registers based on the classification of the exception handling routine to be executed can be executed in software via simulator program 505.

[0121] By using the techniques described herein, a system can be provided that supports the use of both trusted and untrusted exception handling routines, while allowing low interrupt latency to be maintained by selectively using exception control circuitry hardware to manage not only the stack and destack of the caller registers but also the stack and destack of the callee registers. By using appropriate configuration information, the exception control circuitry can attempt to distinguish between trusted and untrusted exception handling routines, and only the stack and the caller registers and callee registers associated with the exception handling routine that is determined to be untrusted are processed. This reduces the latency associated with processing untrusted exception handling routines without adversely affecting the execution speed of trusted exception handling routines.

[0122] In this application, the phrase "configured as..." is used to mean that the elements of the device have a configuration capable of performing the defined operations. 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 operations, or a processor or other processing device may be programmed to perform the function. "Configured as" does not mean that the elements of the device need to be changed in any way to provide the defined operations.

[0123] While illustrative examples of the invention have been described in detail herein with reference to the accompanying drawings, it should be understood that the invention is not limited to those precise examples, and various changes, additions, and modifications can be made therein by those skilled in the art without departing from the scope and spirit of the invention as defined by the appended claims. For example, features of the dependent claims may be combined with features of the independent claims in various ways without departing from the scope of the invention.

Claims

1. An apparatus for handling anomalies, the apparatus comprising: The processing circuitry is operable in at least one security domain to execute program code, the program code including a plurality of exception handling routines executed in response to a corresponding exception; Multiple registers for storing data for access by the processing circuit when executing the program code, the registers including a first register subgroup and a second register subgroup that does not overlap with the first register subgroup; An exception control circuit, in response to a given exception occurring from background processing, is configured to trigger a state saving operation to save data from the plurality of registers before triggering the processing circuit to execute a given exception handling routine corresponding to the given exception; as well as A configuration storage device is configured to store configuration information for classifying exception handling routines within the plurality of exception handling routines; The exception control circuitry is configured to: determine, with reference to the configuration information, whether the given exception handling routine belongs to a first category or a second category within the security domain in which the given exception handling routine will be executed, and when the state saving operation is triggered, to: trigger the saving of the data from the first register subgroup when the given exception handling routine belongs to the first category, and trigger the saving of the data from both the first register subgroup and the second register subgroup when the given exception handling routine belongs to the second category.

2. The apparatus according to claim 1, wherein: At least when the given exception handling routine belongs to the second category, the exception control circuit is further arranged to: trigger the clearing of the registers whose data was saved during the state saving operation before triggering the processing circuit to execute the given exception handling routine.

3. The apparatus of claim 1 or claim 2, wherein the first category indicates a trusted exception handling routine, and the second category indicates an exception handling routine to be processed as untrusted.

4. The apparatus of claim 3, wherein the processing circuitry is operable in both a non-privileged state and a privileged state, and the processing circuitry is operable to execute at least the body of the untrusted exception handling routine when in the non-privileged state.

5. The apparatus according to claim 1 or claim 2, wherein the configuration storage device is arranged to store corresponding configuration information items for one or more exception handling routines.

6. The apparatus of claim 5, wherein the configuration information item is set to a first value to indicate that the corresponding exception handling routine is trustworthy, and is set to a second value to indicate that the corresponding exception handling routine is handled as untrustworthy.

7. The apparatus according to claim 1 or claim 2, wherein: The configuration storage device is configured to identify threshold priorities; Each exception has an associated priority; and The exception control circuit is configured to determine whether a given exception handling routine belongs to the first category or the second category based on a comparison between a value derived from the associated priority of the given exception and a value derived from the threshold priority.

8. The apparatus of claim 7, wherein the exception control circuitry is arranged to determine that the given exception handling routine belongs to the second category when the associated priority of the exception is less than the threshold priority.

9. The apparatus of claim 1 or claim 2, wherein the anomaly control circuit is arranged to set a status flag to identify whether the data from the second register subgroup has been saved.

10. The apparatus according to claim 9, wherein: Upon an error return, the error control circuit is configured to refer to the status flag to determine whether data in the second register subgroup needs to be recovered.

11. The apparatus of claim 1 or claim 2, wherein when the state saving operation is triggered, the exception control circuit is arranged to cause the data to be saved to a stack data structure.

12. The apparatus according to claim 1 or claim 2, wherein: In response to a trailing cascading exception corresponding to another exception handling routine that is to be executed after the given exception handling routine has been executed and before returning to the background processing, the exception control circuitry is configured to determine, with reference to the configuration information, whether the other exception handling routine belongs to the first category or the second category; and When the exception control circuit determines that the additional exception handling routine belongs to the second category and the data from the second register subgroup has not yet been saved, the exception control circuit is arranged to trigger the saving of the data from the second register subgroup before triggering the processing circuit to execute the additional exception handling routine.

13. The apparatus of claim 12, wherein the exception control circuit is further arranged to: trigger the clearing of the registers whose data is stored before the processing circuit is triggered to execute the additional exception handling routine for the final chain exception.

14. The apparatus of claim 12, wherein the anomaly control circuit is arranged to set a status flag to identify whether the data from the second register subgroup has been saved, and The exception control circuit is further arranged to refer to the status flag such that when the exception control circuit determines that the additional exception handling routine for the final chain exception belongs to the second category, the exception control circuit is arranged to skip triggering the saving of the data from the second register subgroup when the status flag indicates that the data has been saved.

15. The apparatus of claim 1 or claim 2, wherein the background processing includes executing program code other than an exception handling routine, and the given exception is an initial exception.

16. The apparatus of claim 1 or claim 2, wherein the background processing includes executing a current exception handling routine, and the given exception is a preemptive exception with a higher priority than the exception corresponding to the current exception handling routine.

17. The apparatus according to claim 1 or claim 2, wherein: The processing circuitry is arranged to execute the program code in one of a plurality of security domains, which includes at least a security domain and a less secure domain; The exception control circuitry is configured to determine, with reference to the configuration information, whether the given exception handling routine belongs to the first category or the second category, independently of whether any security domain change will occur when switching from background processing to execution of the given exception handling routine.

18. The apparatus according to claim 17, wherein: The configuration storage device is arranged to store configuration information for classifying the plurality of exception handling routines associated with each security domain; and The exception control circuitry is configured to determine whether the given exception handling routine belongs to the first category or the second category by referring to the configuration information provided for the security domain in which the given exception handling routine will be executed.

19. The apparatus of claim 17, wherein, within a given security domain, the processing circuitry is arranged to perform data processing in one of a plurality of states including an unprivileged state and a privileged state.

20. The apparatus according to claim 17, wherein: In response to identifying an exception as a first exception to cause a transition from the secure domain to the less secure domain in the case where the background processing is executed by the processing circuitry in the secure domain, the exception control circuitry is further arranged to trigger the saving of the data from the second register subgroup before triggering the processing circuitry to execute an exception handling routine corresponding to the identified exception.

21. The apparatus of claim 20, wherein the anomaly control circuit is arranged to set a status flag to identify whether the data from the second register subgroup has been saved, and The exception control circuit is further arranged to reference the status flag such that, in response to the identified exception, the exception control circuit is arranged to skip triggering the saving of the data from the second register subgroup when the status flag indicates that the data has been saved.

22. A method for handling an anomaly within a device, the method comprising: Execute program code on a processing circuit capable of operating in at least one security domain, the program code including a plurality of exception handling routines executed in response to a corresponding exception; Data is stored in multiple registers for access by the processing circuit when executing the program code, the registers including a first register subgroup and a second register subgroup that does not overlap with the first register subgroup; In response to a given exception occurring from background processing, an exception control circuit is employed to trigger a state saving operation to save data from the plurality of registers before the processing circuit is triggered to execute a given exception handling routine corresponding to the given exception. Store configuration information for classifying exception handling routines within the plurality of exception handling routines; The configuration information is used to determine whether the given exception handling routine belongs to a first category or a second category within the security domain in which the given exception handling routine will be executed. as well as When the state save operation is triggered, the exception control circuit causes the data from the first register subgroup to be saved when the given exception handling routine belongs to the first category, and the data from both the first register subgroup and the second register subgroup to be saved when the given exception handling routine belongs to the second category.

23. A computer program product comprising a computer program for controlling a host data processing device to provide an instruction execution environment, the computer program comprising: The process logic is operable in at least one security domain to execute program code, the program code including a plurality of exception handling routines that are executed in response to a corresponding exception; The data structure simulation program logic is used to maintain multiple register data structures to store data for access by the processing program logic when executing the program code. The register data structures include a first data structure subgroup and a second data structure subgroup that does not overlap with the first data structure subgroup. as well as An exception control program logic, in response to the occurrence of a given exception from background processing, is configured to trigger a state saving operation to save data from the plurality of register data structures before the processing program logic is triggered to execute a given exception handling routine corresponding to the given exception. The data structure simulation program logic is further arranged to maintain a configuration data structure to store configuration information for classifying exception handling routines within the plurality of exception handling routines. and The exception control program logic is configured to refer to the configuration information to determine whether the given exception handling routine belongs to a first category or a second category within the security domain in which the given exception handling routine will be executed, and is configured to trigger the state saving operation as follows: if the given exception handling routine belongs to the first category, a saving of the data from the first data structure subgroup is triggered, and if the given exception handling routine belongs to the second category, a saving of the data from both the first data structure subgroup and the second data structure subgroup is triggered.

24. A computer-readable medium storing a computer program for controlling a host data processing apparatus to provide an instruction execution environment, the computer program comprising: The process logic is operable in at least one security domain to execute program code, the program code including a plurality of exception handling routines that are executed in response to a corresponding exception; The data structure simulation program logic is used to maintain multiple register data structures to store data for access by the processing program logic when executing the program code. The register data structures include a first data structure subgroup and a second data structure subgroup that does not overlap with the first data structure subgroup. as well as An exception control program logic, in response to the occurrence of a given exception from background processing, is configured to trigger a state saving operation to save data from the plurality of register data structures before the processing program logic is triggered to execute a given exception handling routine corresponding to the given exception. The data structure simulation program logic is further arranged to maintain a configuration data structure to store configuration information for classifying exception handling routines within the plurality of exception handling routines. and The exception control program logic is configured to refer to the configuration information to determine whether the given exception handling routine belongs to a first category or a second category within the security domain in which the given exception handling routine will be executed, and is configured to trigger the state saving operation as follows: if the given exception handling routine belongs to the first category, a saving of the data from the first data structure subgroup is triggered, and if the given exception handling routine belongs to the second category, a saving of the data from both the first data structure subgroup and the second data structure subgroup is triggered.

Images