Intermodal Call Branch Instruction

Abstract

The processing circuit (4) has a handler mode and a thread mode. In response to an exception condition, a switch to the handler mode is made. When the processing circuit (4) is in the handler mode, in response to an intermodal call branch instruction specifying a branch target address, the instruction decoder (10) controls the processing circuit (4) to save a function return address to a function return address storage location, switch the current mode of the processing circuit (4) to the thread mode, and branch to the instruction identified by the branch target address. This can be useful for deprivileging exceptions.

Description

[Technical Field]

[0001] The present technology relates to the field of data processing.

[0002] The processing circuit may have several operating modes in which the processing circuit can process instructions. For example, the modes may include at least a handler mode and a thread mode. An exception condition may cause the processing circuit to switch to processing an exception handler in the handler mode. By providing hardware separation between the handler mode and the thread mode, this may make it easier to manage the separation between the operation of exception handlers associated with an operating system and threads managed by the operating system.

[0003] At least some examples provide an apparatus including: a processing circuit for performing data processing in one of a plurality of modes including at least a handler mode and a thread mode; an exception control circuit that, in response to an exception condition, controls the processing circuit to switch to processing of an exception handler in the handler mode; and an instruction decoder that controls the processing circuit to decode instructions for performing the data processing, wherein, at least when the processing circuit is in the handler mode, in response to an intermodal call branch instruction specifying a branch target address, the instruction decoder is configured to control the processing circuit to save a function return address in a function return address memory location, switch a current mode of the processing circuit to the thread mode, and branch to the instruction identified by the branch target address.

[0004] At least some examples provide a data processing method for an apparatus comprising a processing circuit that performs data processing in one of a plurality of modes including at least a handler mode and a thread mode, and an exception control circuit that controls the processing circuit to switch to processing of an exception handler in the handler mode in response to an exception condition, the method including: decoding an intermodal call branch instruction that specifies a branch target address; and, in response to the intermodal call branch instruction, at least when the processing circuit is in the handler mode, saving a function return address to a function return address memory location; switching the current mode of the processing circuit to the thread mode; and branching to the instruction identified by the branch target address.

[0005] At least some embodiments provide a computer program for controlling a host data processing apparatus to provide an instruction execution environment for executing instructions from target program code, the computer program including: processing program logic for performing data processing in one of a plurality of modes including at least a handler mode and a thread mode; exception control program logic for controlling the processing program logic in response to an exception condition to switch to processing of an exception handler in the handler mode; and instruction decode program logic for decoding instructions of the target program code to control the processing program logic to perform the data processing, wherein at least when the processing program logic is in the handler mode, in response to an intermodal call branch instruction specifying a branch target address, the instruction decode program logic is configured to control the processing program logic to save a function return address in a function return address memory location, switch the current mode of the processing program logic to the thread mode, and branch to the instruction of the target program code identified by the branch target address.

[0006] The computer-readable storage medium can store the above-mentioned computer program. The storage medium may be a non-transitory storage medium. [Brief explanation of the drawings]

[0007] Further aspects, features, and advantages of the present technology will become apparent from the following description of examples, read in conjunction with the accompanying drawings. [Figure 1] 1 illustrates a schematic diagram of an example data processing system having processing circuitry that supports different modes of operation. [Figure 2] 1 illustrates examples of different domains and modes of operation of a processing circuit. [Figure 3] 1 shows an example of a register of a processing circuit. [Figure 4] Indicates the provision of reserved address ranges that cannot be used for executable instructions. [Figure 5] A dummy function return address and a dummy exception return address are shown. [Figure 6] 1 illustrates the different stack frames that may be saved on the stack in response to a function call or an exception. [Figure 7] For comparison, an example of exception deprivilege when intermodal call branch instructions are not supported is shown. [Figure 8] 10 illustrates an example of exception deprivilege using an intermodal call branch instruction. [Figure 9] Examples of prohibited domain / mode switching combinations are: [Figure 10] Examples of allowed combined domain / mode switching are shown below. [Figure 11A] Figure 10 shows an example of a tail call where combined domain / mode switching may be useful. [Figure 11B] Figure 10 shows an example of a tail call where combined domain / mode switching may be useful. [Figure 11C] Figure 10 shows an example of a tail call where combined domain / mode switching may be useful. [Figure 12] FIG. 2 is a flow diagram showing the steps performed when a function is called. [Figure 13]FIG. 10 is a flow diagram showing the steps performed in an exception entry. [Figure 14] FIG. 1 is a flow diagram showing steps performed in response to a branch instruction other than a function call. [Figure 15] FIG. 10 is a flow diagram illustrating steps performed in response to a branch to a dummy function return address. [Figure 16A] FIG. 16 illustrates potential attacks that can be detected using the integrity cross-check shown in FIG. 15. [Figure 16B] FIG. 16 illustrates potential attacks that can be detected using the integrity cross-check shown in FIG. 15. [Figure 16C] FIG. 16 illustrates potential attacks that can be detected using the integrity cross-check shown in FIG. 15. [Figure 16D] FIG. 16 illustrates potential attacks that can be detected using the integrity cross-check shown in FIG. 15. [Figure 17] FIG. 10 is a flow diagram illustrating disabling domain transitions in thread mode. [Figure 18] Here is an example of using the domain transition disable configuration parameter: [Figure 19] Here is an example of using the domain transition disable configuration parameter: [Figure 20] Here is an example of using the domain transition disable configuration parameter: [Figure 21] FIG. 10 is a flow diagram illustrating checking of domain transition disable configuration parameters when fetching an instruction having an address within a secure address region. [Figure 22] An example of a simulator that can be used is shown.

[0008] Intermodal Call Branch Instruction In systems in which a processing circuit supports a handler mode and a thread mode, it is generally expected that the handler mode will be used to handle exception handlers (e.g., associated with an operating system or other monitoring software) and that the thread mode will be used to handle background code in threads managed by the operating system or monitoring software. However, there may be types of exceptions that are directed to potentially untrusted devices, such as a USB controller or a wireless network interface. Interrupts directed to such devices may be handled by exception handler code provided by a third party other than the party providing the operating system that manages the general operation of the processing system. The operating system provider may not trust the code provided by the other party and may therefore prefer that untrusted exception handler code for controlling such untrusted devices not have the full privileges associated with the handler mode. Therefore, it may be desirable to be able to "deprivilege" exceptions so that the exception handler does not have the ability to access all registers or memory that code in handler mode can normally access. Also, if all software running on a device is from the same vendor, it may be desirable to reduce the complexity of the privileged software and, therefore, the likelihood of security vulnerabilities in the privileged software. So, as part of a defense in depth strategy, there may still be a desire to "deprivilege" exceptions even if all software is from a single vendor.

[0009] However, in a typical system with a handler mode and a thread mode, the mechanism for switching modes may be to use an exception to switch from thread mode to handler mode and then switch back to thread mode upon exception return. Simply triggering an exception to return to thread mode may not be appropriate because this typically lowers the priority level associated with the original exception, making it difficult to properly prioritize different interrupts or exceptions. Therefore, in many cases, it may be necessary to generate a "fake" second exception simply to set up exception return control information that causes the original exception to be handled in thread mode rather than handler mode upon return from the second exception. This mechanism can be slow because invoking the second exception may incur the cost of additional state save and restore operations, as well as the performance cost of the operations to set up the false exception return behavior. Additional state save and restore operations are typically performed on exception entry and return to preserve architectural state associated with the process running before the exception. Therefore, if an exception entry and return mechanism is used to deprivilege an exception handler, this can increase overall interrupt / exception processing latency, which may be unacceptable in some systems, particularly those intended for real-time applications. This approach is also difficult to code for a compiler and prone to errors.

[0010] In the example described below, an intermodal call branch instruction specifying a branch target address is provided. In response to the intermodal call branch instruction, at least when the processing circuit is in handler mode, the instruction decoder controls the processing circuit to save a function return address in a function return address storage location, switch the current mode of the processing circuit to thread mode, and branch to an instruction identified by the branch target address specified by the branch instruction. Thus, a function call mechanism is provided that allows instructions to branch directly to the branch target address of an instruction processed in thread mode rather than handler mode. This provides a much faster and simpler mechanism for deprivileging exceptions and eliminates the need for a spurious second exception as described above.

[0011] In addition to the handler mode and the thread mode, the processing circuit may also support data processing in one of multiple security domains, including at least a secure domain and a less secure domain. A memory access checking circuit may be provided for checking whether memory access is permitted depending on the current security domain of the processing circuit. For example, the memory access checking circuit may maintain a table providing security attributes that define each address region as either a secure region associated with the secure domain or a less secure region associated with the less secure domain. When operating in the secure domain, the processing circuit may access both the secure and less secure regions of memory; in the less secure domain, the processing circuit may access the less secure region but may not be permitted to access the secure region.

[0012] The instruction decoder and processing circuitry may support an inter-domain call branch instruction that specifies a branch target address. In response to the inter-domain call branch instruction, the instruction decoder may control the processing circuitry to save a function return address to a function return address location, branch to an instruction identified by the branch target address, and switch the current security domain of the processing circuitry. Thus, changing security domains may also be made faster by allowing direct branching from one domain to another. In some systems, inter-domain call branch instructions may be supported in both directions: from a secure domain to a less secure domain and from a less secure domain to a secure domain. However, in other implementations, it may not be necessary to provide inter-domain call branch instructions for both directions of switching domains. For example, in some implementations, the inter-domain call branch instruction may be a secure-to-less-secure call branch instruction that triggers a switch from the secure domain to the less secure domain, or other mechanisms may be provided for transitioning from the less secure domain to the secure domain (e.g., alternatively, a secure gateway instruction may switch domains from the less secure domain to the secure domain, such that the valid locations from which the secure domain can be entered may be restricted by requiring that the secure gateway instruction be at the first address fetched from the secure region of memory after executing an instruction from the less secure region of memory). Some implementations may use a similar scheme to prevent code running in a less privileged state from accessing regions of memory marked as privileged only.

[0013] Thus, several call branch instructions may be supported that cause the processing circuit to perform a function call operation that preserves a function return address and branches to an instruction at a branch target address. These may include call branch instructions that remain within the same mode and domain, as well as intermodal call branch instructions that trigger a switch to threaded mode and inter-domain call branch instructions that trigger a change of security domain. However, combined switching of both mode and domain in response to the same call branch instruction may be prohibited. Thus, in response to an intermodal call branch instruction, the instruction decoder may control the processing circuit to switch the current mode to threaded mode without changing the current security domain of the processing circuit. This may improve security by reducing the number of valid transitions of security domains that are allowed, making it easier to verify that a change of security domain is safe.

[0014] In response to the intermodal function return instruction, the processing circuit may change the current mode of the processing circuit back to the handler mode and branch to the instruction identified by the function return address previously saved by the intermodal call branch instruction. Thus, once the non-privileged portion of the exception handler is completed, the intermodal function return instruction may be used to trigger a switch back to the handler mode that the processing circuit was originally executing in when the corresponding exception was taken.

[0015] In some examples, an intermodal function return instruction may be a dedicated function return instruction having an encoding that is identified by an instruction decoder as requiring a function return operation.

[0016] However, this is not required, and in some cases, whether an instruction causes an intermodal function return may depend on information stored in a register or memory at execution time. For example, an intermodal function return may be triggered by an attempt to branch to a reserved, non-executable address (hereinafter referred to as a dummy function return address, e.g., FNC_RETURN address 140 shown in FIG. 5 , which will be described in more detail later). Because an intermodal function return instruction may be part of untrusted code within the unprivileged section of an exception handler, it may be useful if the intermodal function return instruction has the same instruction encoding as a non-intermodal function return instruction that is not intended to trigger a switch back from thread mode to handler mode. This is because the unprivileged section of an exception handler may be provided by a third party who is unaware that the exception handler is unprivileged.

[0017] In some examples, in response to an intermodal call branch instruction, the instruction decoder may control the processing circuit to save a dummy function return address in a link register. The dummy function return address may be an address in a reserved address range that is not a valid executable address. The dummy function return address may include an intermodal call indication value indicating that the dummy function return address was saved in response to an intermodal call branch instruction. When an instruction attempts to branch to the dummy function return address, if the dummy function return address includes the intermodal call indication value, the processing circuit may treat the instruction as an intermodal function return instruction, switch to handler mode, and branch to the real function return address retrieved from the stack. Thus, by storing the intermodal call indication value in the dummy function return address, it can distinguish intermodal function returns from non-intermodal returns, and as a result, the same instruction encoding can be used for both types of function returns. This means that no modification of third-party unprivileged exception handler code is required to support the above-described intermodal branch technique. Also, by using a non-executable dummy function return address in the link register to signal that the real function return address should be accessed from the stack on function return, this can hide the real function return address from non-privileged code running in thread mode following an intermodal call branch instruction.

[0018] The intermodal function return instruction may be one of several types of instructions that can cause a branch to a dummy function return address, such as a branch instruction or a non-branch instruction (such as a register move instruction, load instruction, or stack pop instruction) that causes the program counter to be set to the dummy function return address. Thus, in some implementations, it may be the processing circuitry (rather than the instruction decoder) that identifies that an intermodal function return should be executed and therefore should also trigger a switch to handler mode. In some examples, all types of branches may cause a function return if they specify the dummy function return address as the branch target address. In other examples, there may be types of branches that specify the dummy function return address as the branch target address but do not cause a function return (e.g., a branch that uses an immediate value to specify a target address may not cause a function return because the immediately specified branch target address could not be saved in response to the function call instruction, making a function return unnecessary).

[0019] Unlike intermodal call branch instructions, for intermodal function return instructions, it may be desirable to allow a combined domain and mode switch. Thus, in response to an intermodal function return instruction, the processing circuitry may be able to perform a combined domain / mode switch from processing in a first security domain and thread mode to processing in a second security domain and handler mode. This may be useful to support tail calls, a performance optimization used by some compilers in scenarios where a second function is called as the last action in code executed for a first function. Because the second function can be processed in a different security domain than the first function, intermodal function return instructions may be useful to support combined domain / mode switches, so that legacy code previously compiled with tail calls still functions correctly.

[0020] However, in some cases, combined domain / mode switching on an intermodal function return may be allowed if the first security domain is a secure domain and the second security domain is a less secure domain, but may be prohibited if the first security domain is a less secure domain and the second security domain is a secure domain. By prohibiting combined domain / mode switching on a function return when this would cause a transition to the secure domain, security can be improved by reducing the number of available means for valid entry into the secure domain.

[0021] As described further below, a domain transition disable configuration value may be provided to indicate whether transitions between the secure domain and the less secure domain while in thread mode are disabled or enabled. This may be useful for supporting delayed allocation of resources associated with one of the secure domain or the less secure domain. Setting the domain transition disable configuration value in response to the intermodal call branch instruction may be useful because an exception handler or other process executing the intermodal call branch instruction can often know whether it has already configured the resources necessary to operate in both domains. This improves performance by avoiding the need to execute a separate instruction to set the domain transition disable configuration value. One or more variations of the intermodal call branch instruction: In response to a first variation of the intermodal call branch instruction, the instruction decoder may control the processing circuit to set the domain transition disable configuration value indicating that transitions between the secure domain and the less secure domain while in thread mode are disabled. In response to a second variation of the intermodal call branch instruction, the instruction decoder may control the processing circuit to set the domain transition disable configuration value indicating that transitions between the secure domain and the less secure domain while in thread mode are enabled. Some systems may support both variants of the intermodal call branch instruction, while other systems may support only one of the first or second variants of the intermodal call branch instruction.

[0022] In response to an intermodal call branch instruction, the instruction decoder can trigger a fault signaling if the current mode of the processing circuit is thread mode. Because the intermodal call branch instruction is intended to cause a transition of handler mode to thread mode, executing it from thread mode can be an indication of an error. In this case, a fault prevents misuse. For example, because execution of an intermodal call branch instruction can trigger a state save indicating that a transition from thread mode to handler mode should occur on the corresponding function return, an attacker running a process in thread mode could attempt to use the intermodal call branch instruction in an attempt to gain privileges on the corresponding function return. Preventing successful execution of an intermodal call branch instruction in thread mode and signaling a fault if this is attempted improves security by preventing this type of attack from succeeding.

[0023] In general, a function return instruction may be any instruction that causes a branch to an instruction identified by a function return address previously set in response to a call branch instruction. An intermodal function return instruction is a specific type of function return instruction that also triggers a switch from thread mode to handler mode in the current mode (e.g., an intermodal function return can be distinguished from a non-intermodal function return by information stored in a register or memory, or by the branch target being a reserved dummy function return address). If an intermodal function return instruction is encountered when the current mode is handler mode, a fault may be signaled. This can improve security. In an intermodal function call, some information may be saved in a stack frame on a stack data structure in memory. If an intermodal function return is attempted when the current mode is handler mode, this may be a sign that the function return transition is not the intended transition expected to use that stack frame, potentially compromising security if the information on the stack frame is misused. Intermodal function return only when in handler mode function Return Life By enforcing that commands can be successfully executed, this reduces vulnerability to such attacks.

[0024] The processor architecture may provide a link register designated to store a function return address in response to a call branch instruction. The link register may also be available for use as a general-purpose register, but in a function call, it is used to store the function return address to which processing branches upon completion of the function. For at least one call branch instruction other than an intermodal call branch instruction, the link register may be used as the function return address storage location. However, for an intermodal call branch instruction, the function return address storage location may be a location on a stack data structure stored in memory. The region of memory containing the stack data structure may be inaccessible to thread mode (e.g., because memory protection data defining access permissions for the corresponding address region indicates that it is inaccessible to code having a privilege level associated with thread mode and / or because the stack pointer for pointing to the stack data structure is in a register that is inaccessible in thread mode). Storing the function return address on the stack rather than in the link register prevents the function return address from being visible to unprivileged code executing in thread mode after the intermodal function call, improving security by reducing the opportunity for an attacker to view or modify information about the operation of more privileged code executing in handler mode.

[0025] As described above, in response to an intermodal call branch instruction, a dummy function return address may be saved in the link register. However, it should be noted that by the time the corresponding function return instruction attempts to branch to the dummy function return address, this dummy function return address may no longer be stored in the link register. Some compilers may generate code such that the dummy function return address is kept in the link register. If another function is nested within a previously called function, the compiled code may save the dummy function return address on a stack in memory and restore the dummy function return address to the link register when the nested function completes, so that upon return from the first function, the dummy function return address is again present in the link register. However, this is not required. Other compilers may compile code that does not restore the dummy function return address to the link register upon return from a nested function call, but instead improves performance by loading the dummy function return address directly from the stack to the program counter register when the corresponding function return is required, effectively causing a branch to the dummy function return address, which may be detected when the real function return address needs to be obtained from the stack. Thus, upon function return, it is not necessary that the dummy function return address still be stored in the link register. Note that if the dummy function return address is saved on a stack to allow for nested function calls, the stack used to store the dummy function return address may be a different stack data structure than the stack data structure used to store the real function return address when an intermodal call branch instruction is executed. For example, the stack used to store the real function return address in response to an intermodal call branch instruction may be the main stack associated with Handler mode, but if there is nested function calls within unprivileged code executing in Thread mode, the dummy function return address previously in the link register may be saved in the process stack data structure associated with Thread mode.

[0026] The dummy function return address may include various information for controlling operation when a corresponding function return is attempted. For example, the dummy function return address may indicate at least one of whether a switch from thread mode to handler mode is requested in response to an instruction attempting to branch to the dummy function return address, whether a switch in the processing circuit's current security domain is requested in response to an instruction attempting to branch to the dummy function return address, and which of a plurality of stack data structures should be used as the stack data structure from which the function return address is obtained in response to the instruction attempting to branch to the dummy function return address. Thus, upon a function return, the processing circuit may use the information in the dummy function return address to determine whether to switch modes, whether to switch domains, and / or which stack data structure to use to obtain the function return address. In some examples, the dummy function return address may indicate these three pieces of information using two bits, where the first bit indicates whether the dummy function return address was set in response to an intermodal call branch instruction, and the second bit indicates the security domain from which the intermodal function call was made. Which stack data structure to use can be inferred from these two bits and may not require an explicit indication. However, it will be appreciated that this is just one way of encoding information in the dummy function return address, and other approaches may take different choices. Also, some implementations may not indicate all three types of information described above.

[0027] A predetermined portion of the dummy function return address may indicate whether a switch within the current security domain of the processing circuit is required in response to an instruction that attempts to branch to the dummy function return address. For example, the predetermined portion may be the least significant bits of the dummy function return address. In response to a secure gateway instruction when the current security domain is a less secure domain, the processing circuit may set a portion of the return address (e.g., an address in a link register) to a value indicative of a less secure state, the portion being at the same relative location in the return address value as the portion of the dummy function return address that indicates the domain switch. This technique helps improve security by reducing attacks based on less secure code passing a false return address to secure code when calling a secure function from a less secure domain in an attempt to cause a corresponding return branch in the secure code to jump to any location within the secure domain rather than returning to an address in the less secure domain. A secure gateway instruction may be an instruction that, when executed from a less secure domain, triggers a switch from the less secure domain to the secure domain, and the processing circuitry may trigger fault signaling if the first instruction fetched from the secure domain after executing an instruction in the less secure domain is not a secure gateway instruction. Therefore, because a secure gateway instruction may be expected to be a valid entry point into the secure domain, a return address set by less secure code upon entering the secure domain may be sanitized to indicate that the return address cannot be trusted to cause a branch to any address within the secure domain. When a certain type of branch instruction is executed within the secure domain, specifying as the branch target address an address having a portion set to a value indicative of a less secure state, this causes the processing circuitry to return to the less secure domain, regardless of whether the target address corresponds to a secure region or a less secure region in memory.Thus, secure code can be written to include a predetermined type of branch instruction in branches that are expected to use branch target addresses controlled by a less secure domain, which provides protection against the types of attacks described above. Because intermodal function return branches may be at risk of similar attacks, encoding a dummy function return address, the portion used to signal whether a security domain switch is required, in the same relative position as the portion of the return address that is set to a value indicating a less secure state in response to a secure gateway instruction also protects intermodal function return branches from attack.

[0028] The link register may be a register accessible to code executing in thread mode. Therefore, it is convenient to use a dummy function return address stored in the link register to provide information indicating whether a corresponding function return should be treated as an intermodal call; however, the information located at the dummy function return address may be vulnerable to modification by low-privilege code executing in thread mode. To protect against attacks based on malicious modification of the dummy function return address, in response to an intermodal call branch instruction, the instruction decoder may control the processing circuit to store a cross-check value in at least a portion of a first relative position in a stack frame stored in a stack data structure. The stack data structure in which the cross-check value is stored may be a stack inaccessible to code executing in thread mode. In response to at least one type of instruction attempting to branch to a dummy function at an address, the processing circuit may compare a portion of the dummy function return address for encoding the intermodal call indication value with the value of at least a portion of the first relative position in the stack frame obtained from the stack data structure, and determine whether to trigger fault signaling based on the comparison. Thus, the dummy function return address can signal whether a stack frame on the stack data structure needs to be accessed, but the cross-check value in the stack frame can provide a double check that any information indicating a change in the mode of the function return can be trusted for added security. A similar check can be made for the security domain indication in the dummy function return address.

[0029] In response to at least one type of call branch instruction other than an intermodal call branch instruction, the instruction decoder may control the processing circuit to save a value other than the crosscheck value at at least a portion of the first relative position in the stack frame saved in the stack data structure. Thus, the crosscheck may also protect against attacks that attempt to use an intermodal function return as a mechanism for returning from code entered via a non-intermodal call branch instruction. This type of mismatched function call and function return may result in a vulnerability based on mismatched stack frames in memory. Thus, if an attempt is made to modify a dummy function return address to indicate an intermodal function return, but the corresponding stack data structure in memory was actually saved in memory by the non-intermodal call branch instruction, the crosscheck may fail, thereby triggering a fault.

[0030] In response to an intermodal call branch instruction, the instruction decoder can control the processing circuit to store a value indicating a handler mode in at least a portion of a second relative location in a stack frame saved in the stack data structure. The second relative location can be the same address as the first relative location (in which case cross-check information for the intermodal call indication value and the value indicating the handler mode can be in different bits in the same data word on the stack), or it can be a different relative offset in the stack frame corresponding to a different address relative to the first relative location. In response to at least one type of instruction attempting to branch to a dummy function return address when the dummy function return address includes the intermodal call indication value, the processing circuit can trigger fault signaling if the value in the associated portion of the second relative location in the stack frame does not indicate handler mode. Thus, a fault can be triggered if the dummy function return address indicates a threading mode to handler mode function return, but the stack frame in memory indicates that the corresponding function call was not originally from handler mode. Again, this protects against several forms of attack.

[0031] Some implementations may provide both a cross-check value at a first relative location and a handler mode indicating a value at a second relative location on the stack, while other implementations may omit one of these types of cross-checks and provide only either a cross-check value or a value indicating a handler mode.

[0032] In response to at least one type of instruction attempting to branch to a dummy function return address when the dummy function return address includes an intermodal call indication value, the processing circuit may perform a check of the function return address obtained from the stack data structure. Before switching the current mode of the processing circuit to the handler mode, the processing circuit may check whether the function return address obtained from the stack data structure is within a predetermined range of reserved addresses in which instruction execution is prohibited. If the function return address is within the predetermined range of reserved addresses, a fault due to program code executing in a thread mode may be triggered. This type of check may be useful because, when the intermodal call branch instruction is executed, the function return address may be saved at a third relative location in a stack frame saved in the stack data structure, and for at least one type of exception transition triggered by an exception condition, the exception control circuit may save a stack frame including one of the predetermined range of reserved addresses saved at the third relative location in the stack frame. Thus, by checking for intermodal function returns, whether the function return address is one of a predetermined range of reserved addresses, this protects against attacks based on attempting to perform a function return based on the actual saved stack frame in response to an exception entry transition rather than a function call transition, which could otherwise lead to unpredictable results that compromise security. Checking the function return address can also help prevent other types of attacks. For example, if the top of the stack is sealed with another reserved value at a third relative position in the stack frame (out of the predetermined range of reserved addresses), an attempt to underflow the stack (i.e., use the stack frame when the stack is empty) will also be detected and signal a fault.

[0033] Checking whether the function return address is within the reserved address range as part of the check for an intermodal function return instruction may seem redundant, since a fault caused by an attempt to execute an instruction from a predetermined range of reserved addresses would be expected to be triggered at the time of attempting to fetch the instruction from one of the reserved addresses. However, the inventors recognized that for an intermodal function return, if the intermodal function return is allowed to complete normally, resulting in a mode switch to handler mode, and then a fault is triggered when attempting to fetch the next instruction from the function return address, the fault may be due to code executing in handler mode rather than program code executing in thread mode before switching to handler mode. This can be problematic because the handler code may be associated with the operating system, and therefore the fault may lead to operating system operation being suspected to be faulty, potentially requiring relatively intrusive action, such as a full system reset. Thus, in this approach, this can provide a way for an attacker to perform a denial-of-service attack aimed at disrupting the correct functioning of a processing system (by repeatedly triggering function returns based on exception stack frames).

[0034] In contrast, in the approach described herein, where an early check is made whether the function return address is within a reserved address range when processing an intermodal function return instruction (before triggering any mode switch from Thread mode to Handler mode), faults can originate in Thread mode code, and therefore fault handling actions can have a much lower impact on system functionality (e.g., only killing and restarting a single thread), reducing the opportunity for denial of service attacks and therefore improving security.

[0035] For reliability and safety purposes, some implementations may have error detection / correction circuitry to detect transient or permanent errors caused by hardware failures or transient defects. For example, the error detection / correction circuitry may include circuitry that uses error detection / correction codes to detect errors in data stored in registers or memory, which may be caused, for example, by a particle strike or a storage element stuck at a 0 or 1. The error detection / correction circuitry may also include redundant processing logic that can perform the same operations more than once so that errors can be detected from a comparison of the redundant results of those operations. The specific form of the error detection / correction circuitry may vary significantly from system to system, depending on the needs of that system. For reasons similar to the denial-of-service attack scenario described above, it may be useful to be able to attribute any detected error to a particular data processing context, so that resolution of the error can be more efficient (e.g., by avoiding the need to kill the operating system and perform an intrusive system reset if the error actually occurred within data processing associated with a particular thread).

[0036] To enable error isolation, in response to an intermodal call branch instruction, the instruction decoder can control the processing circuitry to perform an error synchronization barrier operation to separate the detection of errors associated with data processing performed before the error synchronization barrier operation from the detection of errors associated with data processing performed after the error synchronization barrier operation. Similarly, in the case of an intermodal function return instruction, this can also trigger an error synchronization barrier operation. For example, the error synchronization barrier operation can include pausing processing until outstanding operations are completed and the results of error checks on any operations performed before the error synchronization barrier operation are available to determine whether the results of the previous operations were correct. This can therefore better identify occurring errors to the specific code in which the error occurred. In some systems, intermodal call branch instructions and intermodal function return instructions can always trigger an error synchronization barrier operation. Other systems (e.g., systems without any reliability / safety error checking circuitry) may not support the error synchronization barrier operation. In other examples, some configuration state data may be provided that controls whether intermodal call branch instructions and intermodal function return instructions trigger an error synchronization barrier operation. By allowing the presence of error synchronization barrier operation to be configurable by software, a single chip can better address the needs of different markets where, for example, performance is more important than error isolation, or vice versa.

[0037] Some implementations may provide two or more stack pointer registers, including a process stack pointer register per security domain and a main pointer register per security domain (in systems with only one security domain, there may be only a single process stack pointer register and a single main stack pointer register, and in systems supporting multiple security domains, the stack pointer registers may be banked per security domain). The selection circuitry may select, for each security domain, which stack pointer register to use to provide a stack pointer for accessing the stack data structure in memory. In handler mode, the selection circuitry may select the main stack pointer register of the current security domain. In thread mode, the selection circuitry may select between the main stack pointer register and the process stack pointer register of the current domain based on the stack pointer selection value of the current domain. Providing separate main and process stacks for handler mode and thread mode, respectively, may simplify development of exception handler code, as it means that any data that an exception handler may leave on the main stack data structure may generally be inaccessible to threads executing in thread mode after an exception return. In some implementations, using separate stacks for thread and handler mode can also help protect against certain types of attacks based on the spoofing of false exception return stack frames. However, in some scenarios (e.g., when available memory is limited), it may be desirable to allow thread mode code to share a main stack, identified by a main stack pointer, with handler mode, instead of thread mode using a separate process stack. Thus, a stack pointer selection value may be provided (controlled by more privileged code) to define which stack should be used in thread mode.

[0038] In response to an intermodal call branch instruction, the instruction decoder can control the processing circuitry to set the stack pointer select value of the current security domain to indicate that the process stack pointer register should be selected when in thread mode, thereby improving security by preventing unprivileged sections of exception handlers from executing after an intermodal function call that accesses information that may remain in the main stack structure for more privileged code.

[0039] A simulator computer program can be provided for controlling a host data processing apparatus to provide an instruction execution environment for executing instructions from target program code. The computer program can have processing program logic, exception control program logic, and instruction decoding program logic that emulates the functionality of the processing circuitry, exception control circuitry, and instruction decoder described above. This includes support for intermodal call branch instructions, as described above. Thus, such a simulator computer program can present to target code running on the simulator computer program an instruction environment similar to that provided by an actual hardware device, even though the host computer running the simulator computer program does not have actual hardware that provides these functions. This can be useful for executing code written for one instruction set architecture on a host platform that does not actually support that architecture. Simulators can also be useful during the development of software for a new version of an instruction set architecture, when software development is performed in parallel with the development of hardware devices that support the new version of the instruction set architecture, allowing software under development to be tested in simulation, allowing software development to begin before hardware devices supporting the new version of the instruction set architecture are ready.

[0040] Domain Transition Disabled Configuration Parameter As mentioned above, the processing circuit may have several security domains, including at least a secure domain and a less secure domain, and a memory access check circuit may be provided to check whether memory access is permitted according to the current security domain of the processing circuit. For example, this memory access check may be based on attribute data defining whether a memory region is considered secure or insecure, and when operating within a less secure domain, access to the secure region may be prohibited.

[0041] A control memory location may be provided for storing a domain transition disable configuration parameter that specifies whether domain transitions between the secure domain and the less secure domain are enabled or disabled in at least one mode in the processing circuit. If, in at least one mode, the domain transition disable configuration parameter specifies that domain transitions are disabled, the processing circuit may trigger signaling of a disable domain transition fault in response to an attempted transition from the secure domain to the less secure domain, and may trigger signaling of a disable domain transition fault in response to an attempted transition from the less secure domain to the secure domain. This approach may be counterintuitive because one may expect that being able to prevent transitions from the less secure domain to the secure domain is useful for security reasons, but may wonder why being able to selectively disable transitions from the secure domain to the less secure domain is useful. However, the inventors have recognized that this provides a way to contain a particular processing thread in a single one of the secure and less secure domains, which may be advantageous for performance because it can suppress some of the performance-intensive operations that may be required if the thread were to span both domains if an attempt to switch domains is known to trigger a disable domain transition fault. This allows these performance-intensive operations to be performed lazily, only as needed when there is an attempt to switch domains, to avoid the performance cost of speculatively performing these operations for all threads, regardless of whether they span domains. Therefore, it may be beneficial for performance to provide a domain transition disable configuration parameter that disables transitions in both directions between the secure and less secure domains when the processing circuit is in at least one mode.

[0042] This technique may be particularly useful when, in the secure domain, a processing circuit controls access to memory using information stored in at least one secure configuration register, and when, in the less secure domain, a processing circuit controls access to memory using information stored in at least one less secure configuration register. For example, the secure / less secure configuration registers may include a stack pointer register that stores a stack pointer for accessing a respective secure or less secure stack data structure in memory, a register in a memory protection unit (MPU) that defines memory protection attributes for defining access permissions to a region of memory, and / or an MPU pointer register that provides a pointer to a table in memory that provides memory protection region attributes. To ensure separation between the secure and less secure domains, it may be desirable to define separate sets of MPU attributes or stack data structures for use in the secure and less secure domains, respectively. However, the operations for configuring stack pointers, allocating space in memory address space for stack data structures, and / or configuring MPU region attributes for the secure and less secure domains may be relatively performance-intensive, and therefore it may be desirable to avoid performing these operations for one of the secure and less secure domains for threads that only need to operate in the other domain. This can be particularly important when time-critical operations such as interrupt handling need to be performed. Thus, by providing a domain transition disable configuration parameter, this provides a fault that can be used to detect when a thread that has not had these configuration operations performed attempts to switch to another domain, so that these configuration operations can be performed lazily on demand. In one example, the configured resources can include stack pointer registers that store stack pointers for pointing to stack data structures, including at least one stack pointer register associated with the secure domain and at least one stack pointer register associated with the less secure domain.

[0043] In response to an attempt to perform at least one type of transition from a less secure domain to a secure domain in at least one mode, the processing circuit may perform a disable domain transition check using a domain transition disable configuration parameter to determine whether to trigger signaling of a disable domain transition fault. This disable domain transition check may be performed before performing at least one other security check to determine whether the attempted transition from the less secure domain to the secure domain is permitted. At least a portion of the at least one other security check may depend on information or resources that have not yet been configured for a thread that was not expected to switch domains, such as an MPU configuration or a stack data structure referenced by a stack pointer register. Thus, if the other security check is performed before the disable domain transition check, this may lead to the security check failing not because some other security risk has been identified, but simply because the relevant data to be checked has not yet been configured. Because security checks may be associated with fault handlers that trigger more drastic actions than fault handlers associated with invalidating domain transition faults (which may simply trigger delayed configuration of resources), it may be desirable to perform invalidating domain transition checks first so that, if resources are not available, they can be configured before continuing to perform other types of security checks. For example, some implementations may perform security checks that cause a secure fault if the check fails. To ensure the integrity of the secure state, an exception handler associated with a secure fault may terminate execution of the entire less secure state. Such faults may be intentionally triggered by software operating in a less secure and less privileged state as a means of performing a denial-of-service attack against an operating system operating in the less secure state.

[0044] In the case of an attempted transition from a secure domain to a less secure domain, a disable domain transition check may also be performed using the domain transition disable configuration parameter. However, because this transition is from a secure domain to a less secure domain, no other security checks may need to be performed, so the order between the disable domain transition check and the other security checks may not be relevant. Alternatively, some systems may still perform security checks when returning from a secure domain to a less secure domain, in which case the order between the disable domain transition check and the other security checks may depend on whether any information configured in response to a disable domain transition failure is expected to be used in the other security checks.

[0045] The disable domain transition check may be triggered by an attempt to perform at least one type of transition from a less secure domain to a secure domain or from a secure domain to a less secure domain. In some cases, the disable domain transition check may be triggered by an event or instruction that may not necessarily actually cause a transition between a secure domain and a less secure domain. For example, in some cases, the disable domain transition check may be performed when an event or instruction that could potentially cause a transition between security domains is encountered, but before it is identified whether the event or instruction actually triggers a domain change. Thus, while the domain transition disable configuration parameter is at least checked in response to an actual attempt to change domains, this does not exclude that it may also be checked for events that do not actually cause a domain change if the disable domain transition check passes and determines that the domain transition is enabled.

[0046] The domain transition disable configuration parameter may be modifiable in both the secure domain and the less secure domain. In some implementations, other conditions may be imposed on whether particular program code is allowed to change the domain transition disable configuration parameter. For example, in a system with privileged and less privileged states, the domain transition disable configuration parameter may only be modifiable in the privileged state. Nevertheless, a processing circuit may be allowed to change the domain transition disable configuration parameter even if the current security domain is the less secure domain. This may seem counterintuitive because normal configuration parameters that restrict security domain changes are expected to be configured from the secure domain. However, because triggering a disable domain transition fault may be used as a mechanism to improve performance rather than security, it may be acceptable for the domain transition disable configuration parameter to be changed from the less secure domain. This takes advantage of the fact that there may be little thread benefit to allowing security domain changes if the appropriate secure resources are not established; in that case, if an attempt is made to switch to the secure domain, the process will fail because such resources are not established.

[0047] As described above, the processing circuit may have a thread mode and a handler mode. These modes may be orthogonal to the security domain in that in the secure domain, the processing circuit may operate in either the thread mode or the handler mode, and similarly in the less secure domain, the processing circuit may operate in either the thread mode or the handler mode. At least one mode of the processing circuit described above may be a thread mode. Thus, when in the thread mode, a domain transition disable configuration parameter may selectively disable security domain transitions. However, at least one mode may exclude the handler mode, such that in the handler mode, the processing circuit can determine whether a domain transition is allowed independent of the domain transition disable configuration parameter. Thus, even if the domain transition disable configuration parameter indicates that transitions between the secure domain and the less secure domain are disabled in the thread mode, such secure / less secure domain transitions may still be allowed in the handler mode. In a system having a secure domain and a less secure domain, there is little value in disabling secure / less secure domain transitions in the handler mode because handler code (e.g., which may be associated with an operating system) executing in the handler mode may include both secure and less secure processing and require resources from both domains. Also, the handler code running in handler mode may be the code that steps in and gracefully configures the resources of the other domain if the thread mode code triggers a disable domain transition fault, so it may be useful to allow the handler mode to continue operating in both domains even if the thread mode disables the domain transition.

[0048] As described above, the instruction decoder may support an intermodal call branch instruction that, in addition to preserving a function return address and branching to a branch target address, switches the current mode of the processing circuit from handler mode to thread mode. It may also be useful to set a domain transition disable configuration parameter in response to such an instruction to specify whether the domain transition is enabled or disabled. At least one of first and second variants of the intermodal call branch instruction may be defined, where the first variant causes the domain transition disable configuration parameter to be set to specify that the domain transition is disabled in at least one mode, and the second variant causes the parameter to be set to specify that the domain transition is enabled in at least one mode. A system supporting both variants may be particularly useful because it allows the handler code to signal whether it has already configured resources for the unprivileged section to operate in both domains in the same intermodal call branch instruction that calls the unprivileged section of the exception handler code.

[0049] Similarly, in the case of an intermodal function return instruction, as described above, this can also trigger the domain transition disable configuration parameter to be set. In the case of a function return, it can be particularly useful for the domain transition disable configuration parameter to be set to a value specifying that domain transitions are enabled in at least one mode. This is useful because, as described above, one use case for intermodal function call branches and intermodal function returns can be to allow an exception handler to call a function that is unprivileged in thread mode, and this code can be provided by a third-party provider. More privileged code in handler mode can execute "wrapper" code that runs before and after the unprivileged section of code. By setting the domain transition disable configuration parameter to a default value in response to an intermodal function return instruction, this means that the wrapper code at the end of the unprivileged section always executes in a consistent and known state, regardless of whether the unprivileged section actually used both the secure and less secure domains. Also, by using an "enabled" indication as the default value set following an intermodal function return rather than a "disabled" indication, this means that subsequent legacy code written for systems that do not support the domain transition disable configuration parameter (which expects thread mode domain transitions to be allowed) can still function without triggering additional failures.

[0050] Also, in response to the intermodal function return instruction, and updating the domain transition disable configuration parameter to indicate that domain transition was enabled in at least one mode, the processing circuitry may record an indication of the domain transition disable configuration parameter that specified whether domain transition was enabled or disabled in at least one mode before executing the intermodal function return instruction. This indication of the previous state of the domain transition disable configuration parameter helps enable subsequent handler code to determine whether information in configuration registers belonging to other security states (such as the MPU state or stack pointer) may have been modified by code executed between the intermodal call and the intermodal function return, so that if configuration registers for other security states have not been modified, any operations to restore the previous configuration may be omitted to improve performance.

[0051] If, following checking the domain transition disable configuration parameter, a disable domain transition fault is signaled when attempting a transition from a first security domain to a second security domain, the exception control circuitry can control the processing circuitry to process an exception handler in the first security domain. Thus, if the fault was triggered by an attempt to switch from a less secure domain to a secure domain, the fault is processed in the less secure domain, and if the attempt was to transition from a secure domain to a less secure domain, the fault is processed in the secure domain. This is useful because typically, the domain in which the corresponding thread was operating before the domain switch is the domain in which the thread was originally initialized and is therefore the domain associated with the managing process that manages the thread. For example, a secure thread created in a secure domain may be managed by a secure operating system, and a less secure thread created in a less secure domain may be managed by a less secure operating system; therefore, it may be desirable for the disable domain transition fault to be directed to the managing process associated with the thread that attempted the disable domain transition. Although the fault may be processed in the first security domain, the configuration of resources performed by the exception handler in response to the fault may be the configuration of resources associated with the second security domain. Since the domain of the invalid domain transition fault target is different from the state where resources need to be lazily configured, a close coordination between the program code operating in the less secure state and the secure state may be required in the handler mode. Therefore, it may be advantageous to exclude the handler mode from at least one mode in which the invalid domain transition check is performed.

[0052] Upon the occurrence of an exceptional condition, the exception control circuitry can update the domain transition disable configuration parameter to specify that secure / less secure domain transitions are enabled in at least one mode. Again, this provides a safe, known default state for the exception handler, so that the exception handler can function in a consistent manner regardless of the value of the domain transition disable configuration parameter associated with the background code being processed at the time the exception is taken. Also, by defaulting to enable transitions in response to exceptional conditions, this improves compatibility with legacy code in the exception handler that may have been written for systems that did not support the domain transition disable feature.

[0053] When an exception condition occurs, the exception control circuitry may trigger some state saving to preserve architectural state associated with operations performed before the exception condition occurred. It is not necessary for the exception control circuitry hardware to preserve all architectural state associated with previous operations; in some cases, the hardware may preserve only a subset of the architectural state. If registers in which other state resides are overwritten by the exception handler, it may be the responsibility of subsequent exception handlers to preserve other architectural state not saved in hardware.

[0054] When performing such a state save in response to an exception, the architectural state saved in the state save may include a domain transition disable configuration parameter. Thus, the domain transition disable configuration parameter may be automatically saved by hardware when an exception occurs, so that when exception handling is complete and processing returns to the previous processing that was being performed before the exception occurred, the domain transition disable configuration parameter may be restored to a control storage location, so that subsequent processing of the background code can function as if the exception had not occurred.

[0055] In some implementations, the domain transition disable configuration parameter may be saved as part of a stack frame that is saved to a stack data structure in response to an exception condition, the stack frame also including other architectural state, such as general-purpose register contents or the exception return address. However, in some implementations, there may be little spare space in the stack frame for encoding the domain transition disable configuration parameter, and it may be preferable to preserve any spare encoding space for other purposes.

[0056] Thus, in some examples, during a state save, the exception control circuitry may save a first stack frame, including the exception return address and the first subset of the architectural state, to a stack data structure, but the value indicative of the domain transition disable configuration parameter may be saved in a predetermined register (e.g., the predetermined register may be the link register) instead of being included in the first stack frame. This avoids the need to consume extra bits in the stack frame. Note that the saved value indicative of the domain transition disable configuration parameter need not have the same encoding as the domain transition disable configuration parameter itself; any value may be saved on the stack that enables determining what value the domain transition disable configuration parameter had when the exception occurred.

[0057] However, certain registers may be accessible to exception handlers that are executed in response to an exception condition. At least for exceptions that cause a transition from a secure domain to a less secure domain, it may be undesirable to allow less secure code executing after the exception to modify the value that indicates whether security domain transitions were disabled in processing executing before the exception.

[0058] To protect against this scenario, in response to an exception condition that triggers a transition from at least the secure domain to the less secure domain, the exception control circuitry may save in the stack data structure not only the first stack frame described above, but also a second stack frame that includes a second subset of the architectural state and cross-check information for checking a value indicative of the domain transition disable configuration parameter. At at least the exception return transition from the less secure domain to the secure domain, the exception control circuitry may compare the value indicative of the domain transition disable configuration parameter with the cross-check information in the second stack frame and may trigger fault signaling if a mismatch is detected. Note that while the value indicative of the domain transition disable configuration parameter may have been saved in a predetermined register in response to the initial exception, at the time of executing the exception return transition, the domain transition disable configuration parameter may no longer be in the predetermined register, but may be in a value loaded from the stack data structure in memory or in a field in a dummy non-executable address branched to to trigger the exception return. Providing cross-check information in the second stack frame can enable attempts by a less-secure exception handler to modify the saved value of a domain transition disable configuration parameter initially placed in a predetermined register to be detected to prevent security violations. While this approach may appear more complex, the second stack frame can record additional state saved in memory to hide from the less-secure exception handler and can have more room for the additional information than the first stack frame, which provides a subset of the saved state for all exception entries.Thus, recording the cross-check information in the second stack frame means that for exceptions where only the first stack frame is needed, there is no need to incur the memory cost and interrupt latency of storing the additional stack state to keep in the domain transition disable configuration parameter (since it is safe to trust the predetermined registers in this case), but for secure to less secure exception transitions where a second stack frame needs to be saved, the cross-check can be saved on the stack for increased security.

[0059] There may be several ways in which the processing circuitry allows domain transitions between secure and less secure domains to be performed, and the checking of the domain transition disable configuration parameter may be performed in slightly different ways depending on which route is used to transition between security domains.

[0060] As described above, one way to switch domains is to use an inter-domain call branch instruction to request a transition from the secure domain to the less secure domain, in response to which the instruction decoder can control the processing circuit to perform an inter-domain call branch operation, the inter-domain call branch operation including saving a function return address in a function return address location (e.g., a stack data structure in memory), saving a dummy function return address in a predetermined register (e.g., a link register), switching the processing circuit to the less secure domain, and branching to an instruction identified by the branch target address specified by the inter-domain call branch instruction. Allowing direct function calls from the secure domain to the less secure domain eliminates the need to invoke exception handler or monitor code to manage domain transitions, improving performance.

[0061] For an inter-domain call branch instruction, a domain transition disable configuration parameter may be checked, and if the domain transition disable configuration parameter specifies that inter-domain transitions are enabled in at least one mode, an inter-domain call branch operation may be performed. Also, regardless of the value of the domain transition disable configuration parameter, if the processing circuit is currently in a mode other than at least one mode (e.g., if the current mode is the handler mode), an inter-domain call branch operation may be performed. Conversely, if, in at least one mode (e.g., the thread mode), the domain transition disable configuration parameter specifies that domain transitions are disabled in that at least one mode, signaling of a disabled domain transition fault may be triggered.

[0062] Another way to transition between domains may be to attempt to execute an inter-domain return branch instruction that requests a transition from a secure domain to a less secure domain and branches to an instruction identified by a branch target address specified by the inter-domain return branch instruction. The attempt to execute the instruction may trigger a domain transition disable configuration parameter to be checked, and if the domain transition disable configuration parameter specifies that inter-domain transitions are enabled in at least one mode, an inter-domain return branch operation may be executed. Also, regardless of the value of the domain transition disable configuration parameter, the inter-domain return branch operation may be executed if the processing circuit is currently in a mode other than at least one mode (e.g., if the current mode is handler mode). Conversely, if, in at least one mode (e.g., thread mode), the domain transition disable configuration parameter specifies that domain transitions are disabled in that at least one mode, signaling of a disabled domain transition fault may be triggered.

[0063] Another way to transition between domains may be to attempt to branch to a dummy function return address set up by a previous function call branch instruction, as described above. When an inter-domain call branch instruction requesting a transition from a secure domain to a less secure domain is executed, the function return address for the function call may be saved in a stack data structure to protect it from visibility to the less secure code, and the dummy function return address may be saved in a link register visible to the less secure code. The dummy function return address may include information indicating that a domain transition should be performed to return to the secure domain at the corresponding function return. Thus, when there is a later attempt to branch to the dummy function return address and the dummy function return address indicates an inter-domain function return, if the processing circuit is currently in at least one mode and the domain transition disable configuration parameter specifies that domain transitions should be disabled in that at least one mode, the processing circuit may trigger signaling of a disable domain transition fault.

[0064] Another way to transition from the low domain to the secure domain may be when an instruction is fetched from a low secure address region. Security attribute data maintained by the memory access check circuitry can define an address region as either a low secure address region or a secure address region. Instructions stored in a secure address region of memory can only be executed from the secure domain. Currently in the low secure domain, an attempt to fetch an instruction having an address within the secure address region may require performing several security checks to check whether transition to the secure domain can be permitted. For example, the checks may include checking whether the instruction at the address within the secure address region is a specific type of secure gateway instruction that marks a valid entry point into the secure domain. In some cases, if the instruction at the address within the secure address region is a secure gateway instruction, decoding the secure gateway instruction can trigger a security domain change from the low secure domain to the secure domain. In other cases, a transition from the low secure domain to the secure domain may be permitted only if the attempt to fetch an instruction targets a specific type of secure memory, which may be a low secure callable secure memory. Some implementations can perform both secure gateway instruction checks and low secure callable secure memory checks.

[0065] However, as mentioned above, for transitions from a less secure domain to a secure domain, security checks may rely on resources that may not be configured for threads expected to remain within a single security domain (e.g., checks may rely on memory protection unit attributes of the secure domain being set so that instructions fetched from the secure domain can be fetched and decoded). Thus, if a thread expected to reside only in the less secure domain attempts to switch state, the security checks themselves may fail. To prevent these security checks from failing, it may be desirable to perform checks of domain transition disable configuration parameters as early as possible.

[0066] Thus, this check may be performed in response to an attempt to fetch an instruction having an address within the secure address region, rather than waiting until that instruction is fetched and decoded. Performing the check for the domain transition disable configuration parameter early in the pipeline reduces the likelihood of a security check failing due to a lack of configured resources. At the time this check is performed, it may not yet be known whether the instruction being fetched is one that would have actually triggered a transition to the secure domain (e.g., if the fetched instruction was not a secure gateway instruction, it may not have triggered entry into the secure domain). Thus, the check for the domain transition disable configuration parameter may be conservative in that it may be checked regardless of the type of fetched instruction when an instruction is fetched from an address within the secure address region and the current domain is a less secure domain. In some implementations, the location of the various checks within the pipeline may vary, but it will be appreciated that the same effect of performing the domain transition disable check first can be achieved by performing this check later in the pipeline but prioritizing the signaling of a resulting domain transition disable fault over the signaling of other faults.

[0067] With respect to the intermodal call branch instruction discussed above, the domain transition disable configuration parameter may be used in a simulation environment in which a simulation computer program executing on a host data processing apparatus simulates an instruction execution environment equivalent to that expected when the target program code is executed on an actual hardware device having the characteristics of a control memory location that stores the domain transition disable configuration parameter and associated logic for setting and using the parameter, as described above. Thus, the computer program may have processing program logic, memory access checking program logic, and configuration parameter setting program logic that emulates the functionality of the processing circuitry, memory access checking circuitry, and circuitry for maintaining the domain transition disable configuration parameter in the control memory location, as described above.

[0068] Specific example explanation FIG. 1 schematically illustrates an example of a data processing system 2 including processing circuitry 4 for performing data processing in response to instructions fetched from a memory system 6. Memory system 6 may include caches (e.g., one or more levels of data cache and / or instruction cache) in addition to main memory. Processing circuitry 4 includes a processing pipeline including several pipeline stages, including, for example, a fetch stage 8 for fetching instructions to be executed from memory system 6, a decode stage 10 for decoding the fetched instructions to generate control signals for controlling the remaining pipeline stages to perform the data processing, and an execution stage 12 for executing the decoded instructions to perform the data processing operations. Registers 14 are provided for storing input operands of instructions processed by pipeline 4. Registers 14 include several types of registers, including general-purpose (integer) registers 16 for storing integer values ​​and control registers 20 for storing control parameters for controlling instruction execution by processing circuitry 4 and other operations such as exception handling, security checks, etc. Other types of registers may also be provided, such as floating-point registers for storing floating-point values, or vector registers for storing vector operands containing multiple independent data values.

[0069] 1 is a simplified representation, and it will be understood that other types of pipeline stages may also be provided, such as a rename stage for performing register renaming, an issue stage for queuing instructions awaiting execution and issuing them for execution when their required operands are available, and a writeback stage for processing instruction commitments and writing results back to registers 14. The pipeline may be an in-order pipeline or an out-of-order pipeline.

[0070] Reliability, Availability, and Serviceability (RAS) error detection / correction circuitry 29 is provided to perform error detection or correction operations to detect or correct hardware faults that occur randomly during the operation of the processing system. For example, a hardware fault can occur due to a particle strike that flips the state of a stored bit or a signal on a processing logic path between 0 and 1. Hardware faults can also occur due to physical degradation of electronic circuits over time; for example, electromigration can eventually cause a storage element to become stuck at 0 or 1, regardless of the bit value written to the storage element. To detect such faults, the RAS can include another error detection / correction mechanism. For example, one mechanism could provide redundant processing logic for redundantly performing the same operations as processing circuitry 4 and comparison logic for comparing the results of the primary and redundant processing to detect faults. Another mechanism could manage the setting and checking of error detection or error correction codes stored in association with data written to memory; upon reading data from memory, the corresponding error detection / correction code can be recalculated and compared with the stored error detection / correction code to detect (and possibly correct) errors. If a RAS error is detected, the error is corrected if possible and processing continues forward (for example, this may be possible with triple-core lockstep techniques or the use of error correction codes). Alternatively, if the error is not correctable, a fault may be signaled that may cause the processing thread to terminate and restart. It will be appreciated that any known techniques for error detection / correction and recovery may be used.

[0071] System 2 also includes a memory access check circuit 22 for checking whether access to memory system 6 is permitted based on attribute data specified for various regions of the memory address space. The memory access check circuit includes a security attribute unit (SAU) 24 for storing security domain definition data defining a security domain associated with each respective region of the memory address space. Based on the security attribute data, security attribute unit 24 can check whether memory access is permitted depending on the current security domain of the operation of the processing circuit and the security domain associated with the region containing the target address of the memory access. In other embodiments, the SAU does not directly store the security domain definition data but instead can 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 memory system 6 or in a configuration register elsewhere in system 2. Processing circuit 4 can operate in a current security domain of the operation, which can generally correspond to the security domain associated with the address of the currently executed instruction (although there may be some exceptions, such as when handling transitions between domains). When an instruction branches from an address in a region designated by SAU 24 as being in one domain to an address in a region associated with a different domain, this may trigger a transition of the current security domain in which processing circuit 4 is operating. In other embodiments, such a branch may not directly trigger a transition of the current security domain, but may instead trigger additional security checks such as whether a gateway instruction is present; in these embodiments, it may be the gateway instruction itself that triggers the change of current security domain.In general, while operating in the secure domain, the processing circuitry can access data in memory regions associated with both the secure domain and the less secure domain, and when operating in the less secure domain, the processing circuitry can access data in regions associated with the less secure domain, but may not be permitted to access data in regions of the address space that SAU 24 designates as associated with the secure domain. This allows for protection of sensitive data against unauthorized access from code operating in the less secure domain.

[0072] The memory access checking circuitry may also include a memory protection unit (MPU) 26 that checks whether memory accesses to the memory system 6 satisfy access permissions. The access permissions may, for example, specify which privilege levels of the processing circuitry 4 are permitted to access a given region of memory, or may specify whether a memory region of an address space is accessible by both read and write operations or is a read-only region where writing is prohibited. The access permissions used by the MPU 26 may, for example, be specified by a more privileged process (such as a hypervisor or operating system) to control which regions of memory a less privileged process (such as an application) is permitted to access and in what manner (read-only or read / write, and whether the memory is executable). In some implementations, the MPU 26 may also apply checks on which memory regions a privileged process is permitted to access and in what manner (read-only or read / write, and whether the memory is executable). The MPU 26 may allow different permissions to be specified for less privileged access and for privileged access. The permissions provided by MPU 26 may be orthogonal to the permissions provided by SAU 24, such that for a given memory access to be permitted, it must pass checks based on the access permissions defined for both MPU 26 and SAU 24. MPU 26 may include separate secure MPU 26-S and less secure MPU 26-NS, each associated with one of the security domains, such that different memory access permissions can be specified for a given region of memory depending on whether the current domain is the secure domain or the less secure domain (e.g., a region may be read-only in the less secure domain, but both readable and writable in the secure domain).

[0073] Thus, as shown in Figure 2, processing circuitry 4 may support performing data processing in one of multiple security domains, including at least a secure domain (S) and a less secure domain (also referred to as a non-secure domain, NS). Although Figure 2 shows a system with only two security domains, it is possible to provide more than two domains associated with different levels of security, in which case the illustrated S domain and NS domain may be any two of the three or more provided domains.

[0074] Also, as shown in FIG. 2, within a given security domain, the processing circuitry may perform data processing in one of several modes, including a handler mode (H) for exception handling and a thread mode (T) for background processing. As shown in FIG. 1, exception control circuitry 28 may be provided to control exception handling operations, including exception entry and return transitions and the saving / restoring of architectural state during such transitions. Isolating exception handling into a dedicated handler mode H may be useful to simplify management of which registers are permitted to be accessed by the processing circuitry (e.g., some registers used for exception handling may be accessible in handler mode H but inaccessible in thread mode T). In general, when operating in handler mode H, the processing circuitry 4 may by default assume a more privileged mode of operation, such that access to memory and registers is controlled according to a particular privilege level other than the minimum privilege level, and in thread mode T, the processing circuitry may have one of several different privilege levels, depending on other architectural state stored in control registers 20.

[0075] Thus, as shown in Figure 2, the combination of the security domain and the mode in which processing circuitry 4 is operating can determine how processing is performed by processing circuitry 4. Figure 2 shows four different combinations of these modes, including: Secure thread mode (shorthand for the combination of secure domain and thread mode), Low-secure thread mode (combination of low-secure domain and thread mode), Secure handler mode (combination of secure domain and handler mode), - Low secure handler mode (combination of low secure domain and handler mode).

[0076] As described below, the actions taken in response to exception conditions and exception return conditions may depend on the particular transitions made between these respective combinations of security domains and modes. Attributes in the Secure Attribute Unit (SAU) 24 monitor the boundary between the secure and less secure domains. Attributes in the Secure MPU 26-S may be used to monitor the boundary between different threads operating in the secure threading mode and between these threads and the secure operating system. Attributes in the Less Secure MPU 26-NS may be used to monitor the boundary between different threads operating in the less secure threading mode and between these threads and the less secure operating system.

[0077] FIG. 3 illustrates some of the registers 14 of the processing system. It will be understood that this representation does not represent all of the possible registers that may be provided, and that many other registers may also be provided. As shown in FIG. 3, the registers 14 include general-purpose registers 16 and several control registers 20 (only some of the control registers are shown in FIG. 3; others may be provided). In this example, 16 general-purpose registers are provided, labeled R0 through R15. In some embodiments, the general-purpose registers 16 may also include a program status register (XPSR), which may hold condition flag values ​​and other information relevant to the current context.

[0078] Of the general purpose registers R0-R15, registers R0-R12 are used to store general purpose operands, such as input operands for arithmetic or logic instructions, or operands used to derive addresses for load / store instructions to access memory system 6. While it may be possible to use general purpose registers R13-R15 for such general purpose operands, they also perform other control functions.

[0079] Register R15 is used as a program counter (PC) register that stores a program counter that provides an indication of the current point in the program reached by processing circuitry 4. The program counter register may be used by fetch stage 8 to determine which instructions to fetch from the memory system.

[0080] Register R14 is used as a link register (LR) that is used to store a function return address when a function is called so that the address in the link register can be used to transfer program flow to the next instruction after the function call instruction when processing associated with the function is completed. The link register can also be used when an exception occurs to store an exception return value that provides information for controlling the unstacking of architectural state when a corresponding exception return condition is encountered. Similarly, the link register may also be used to store a dummy function return address when an intermodal or inter-domain function call is performed, as described in more detail below.

[0081] Register R13 is used as a stack pointer register that provides a stack pointer that points to the address of a stack data structure in memory. The stack data structure can be used to save architectural state when an exception condition occurs and to restore architectural state when an exception return condition occurs. As shown in Figure 3, register R13 is banked such that the hardware is provided with several different physical registers, each accessible using the register specifier R13; how a particular banked register is selected when R13 is specified may depend on several factors, including the current security domain and mode of the processing circuit and the values ​​of configuration registers.

[0082] For example, the banked stack pointer registers may include a secure main stack pointer register (MSP_S), a secure process stack pointer register (PSP_S), a less secure main stack pointer register (MSP_NS), and a less secure process stack pointer register (PSP_NS). Generally, the secure stack pointer registers MSP_S and PSP_S are accessible to processing circuitry 4 when in secure domain S but are not accessible when in less secure domain NS. The less secure stack pointer registers MSP_NS and PSP_NS are accessible in the less secure domain. Some implementations may provide additional ways to access the banked stack pointers, which may give the secure domain access to the stack pointers (MSP_NS and PSP_NS) associated with the less secure domain. Generally, the process stack pointer PSP_S or PSP_NS is expected to be used in thread mode T, and the main stack pointer MSP_S or MSP_NS is expected to be used in handler mode H. Providing separate main and process stacks for Handler mode and Thread mode, respectively, can make development of exception handler code easier, because it means that any data an exception handler leaves on the main stack may generally be inaccessible to a thread executing in Thread mode after an exception return. This simplifies development of exception handler code, because the exception handler does not need to include instructions to clear all of its data from the main stack data structure. However, a process in Thread mode T can use a main stack pointer, with a stack pointer selection value 30 stored in control register 32 that controls whether the main stack pointer or the process stack pointer should be used when in Thread mode T. Thus, which stack pointer should be used can be determined based not only on the combination of the current mode (thread or handler) and the current domain (secure or less secure), but also on the stack pointer selection value 30.3, the stack pointer selection value 30 may be banked between security states so that the secure and less secure domains can independently control whether the secure and less secure thread modes use the main stack pointer or the process stack pointer, respectively, using separate secure and less secure versions 30-S and 30-NS of the stack pointer selection value 30. The current security domain controls which banked version 30-S, 30-NS is read / written.

[0083] In general, within the body of an exception handler operating in handler mode H or a thread operating in thread mode T, the selection of a secure or non-secure stack pointer may depend on the current security domain in which processing circuitry 4 is executing code. In the case of exception entry and return, stacking and unstacking of state is performed from the stack identified by the stack pointer associated with the security domain of the background code that was executing before the exception occurred.

[0084] The control register 32 may also include a privilege control value (nPRIV) 31 that controls whether code executing in the thread mode is privileged or non-privileged. The privilege control value may be set differently for the secure domain and the less secure domain (e.g., the secure thread mode may be non-privileged while the less secure thread mode may be privileged, or vice versa). Alternatively, both the secure thread mode and the less secure thread mode may operate at the same level of privilege. It will be appreciated that the privilege control value 31 is merely an example, and there may be other ways of using the architectural state stored in the control register to control the level of privilege assigned to code in the secure / less secure thread mode. In the example of FIG. 3, the privilege control value 31 is banked such that separate secure privilege control values ​​31-S and less secure privilege control values ​​31_NS are provided to control the privilege levels used by the thread mode in the secure and less secure domains, respectively. However, another approach may be to provide a single control bit that toggles on domain transitions.

[0085] 3, the control register 32 also includes a thread mode interstating disable (TMID) parameter 34, also referred to as a domain transition disable configuration parameter, for controlling whether transitions between the secure and less secure domains in thread mode are enabled or disabled, as described in more detail below. Unlike the stack pointer selection value 30 and the privilege value 31, the TMID 34 value is shared between security states. The TMID parameter 34 can be used to disable transitions between the secure and less secure domains in thread mode, which can be useful for enabling delayed configuration of resources for one of the secure / less secure domains, as described further below, because disabling domain transitions (which triggers a fault if an attempt is made to execute a disabled domain transition) means that a thread can be confined to a single domain.

[0086] As shown in FIG. 3, the control registers 20 also include a register that provides an exception number 36. The exception number 36 may not be the only value stored in this control register; other states may be stored in the same register. The exception number identifies the exception associated with the currently executing exception handler when the system is in handler mode. When the system is in thread mode, the exception number 36 is set to a specific default value (e.g., 0) indicating that no exception is currently being handled. Thus, the exception number 36 is effectively an indication of whether the system is currently in thread mode or handler mode; if the registered exception number register 36 specifies a specific value (e.g., 0), the system is in thread mode; if any other value is specified, the system is in handler mode; and a specific non-zero value identifies the current exception being handled. Thus, a separate register indicating the current mode in which the system is operating may not be necessary. Although not shown in FIG. 3, there may be a control register that indicates whether the current domain is the secure domain or the less secure domain. Alternatively, such a register may be unnecessary because the address of the instruction being processed may be implicit from the determination by the SAU 24 of whether it is in the secure or less secure region of memory.

[0087] FIG. 4 illustrates an example of a memory address space used to address memory system 6. Memory address space 100 may include one or more less secure regions 102 accessible by both the secure and less secure domains, and one or more secure regions 104 accessible by the secure domain but not by the less secure domain. For ease of illustration, FIG. 4 illustrates only one less secure region 102 and one secure region 104; however, there may be multiple regions of each type, and these regions may be interspersed with one another; thus, not all of the secure regions need be in contiguous blocks, and not all of the less secure regions need be in contiguous blocks. A less secure region may include less secure program code 110, a stack data structure 112 (accessed using less secure stack pointers MSP_NS and PSP_NS), and less secure data 114. Similarly, secure region 104 may include secure program code 122, a stack data structure 124 (accessed using secure stack pointers MSP_S and PSP_S), and secure data 126. Again, the program code, stack, and data within the secure region 104 or the less secure region 102 need not be organized into contiguous blocks as shown in Figure 4, and in fact the stack and program code may be distributed over several non-contiguous blocks interspersed with other data. The particular allocation of memory within the executable address range may be selected by software running on the processing system and is not fixed by hardware.

[0088] 4, memory address space 100 includes a reserved region 130, which in this example includes addresses equal to or greater than 0xF0000000 (represented in hexadecimal; it will be understood that a different address range may be selected for reserved region 130 in other examples). Reserved region 130 represents a range of addresses that are not permitted to provide executable instructions. Some of these reserved addresses may be assigned for special purposes, such as to indicate a function return or an exception return, as described further below. An attempt to fetch an instruction from one of reserved addresses 130 may cause instruction fetch stage 8 to signal a fault. These reserved addresses may provide an opportunity for future versions of the architecture to assign additional addresses for special purposes, such that an attempt to fetch an instruction from one of these addresses may be interpreted as signaling that a given event is being processed.

[0089] As shown in FIG. 5 , a portion of the reserved address range is allocated to represent special dummy function return addresses 140 and dummy exception return addresses 142 used to indicate function returns for specific domain / mode transitions and exception return operations. The dummy function return addresses 140 are any of a group of addresses within the reserved range 130 with the most significant portion of bits 144 set to a specific function return prefix value 144. In this example, the function prefix has a value of 0xF0 or greater, such that the dummy function return address is within the reserved range 130. The dummy function return addresses are used to signal that a function return operation should be performed if an attempt is made to fetch or execute an instruction from the dummy function return address. In some implementations, an attempt to set the program counter (PC) to a dummy reserved address (either by a branch or some other instruction, such as a load that targets the PC) may trigger a function return operation instead of an instruction fetch. To simplify the hardware, only a subset of instructions that can set the PC (those typically used to perform a function return) may actually be able to trigger a function return operation. This provides a mechanism to avoid having to expose the actual function return address for intermodal or cross-domain function calls in the link register R14 so that it cannot be accessed by less secure or less privileged code.

[0090] Dummy function return address 140 includes some state information that can be set when performing an intermodal or inter-domain function call to indicate properties of the function call and / or information about how the corresponding function return should be handled. In this example, dummy function return address 140 includes an intermodal call flag (M) 146 that indicates whether the dummy function return address was set in response to an intermodal function call from handler mode to thread mode or a non-intermodal call that remained in the same mode (remained in handler mode or remained in thread mode). In this example, intermodal call flag 146 is encoded to indicate an intermodal call when it has a value of 0 and to indicate that the mode remained unchanged during the corresponding function call when flag 146 is 1. Intermodal call flag 146 can be used upon function return to determine whether the current mode should be changed back from thread mode to handler mode or should remain unchanged.

[0091] The dummy function return address 140 also includes a security domain indicator (S) 148 that indicates whether the corresponding function call was made from a less secure domain or a secure domain. In this example, the security domain indicator is encoded such that it is set to 1 if the call was made from the secure domain and set to 0 if the call was made from the less secure domain. It will be understood that the particular encoding of the flags 146, 148 shown in the dummy function return address 140 is merely an example, and other approaches may use different encodings. The dummy function return address may also include additional status flags not shown in FIG. 5 . In some implementations, a secure gateway instruction is issued at the start of a secure function that can be called from a less secure domain. This secure gateway instruction causes the processing circuit to perform a transition from the less secure domain to the secure domain. Thus, a subsequent function return can determine whether the function was called from the secure domain or the less secure domain and, therefore, which domain execution to return to; if the secure gateway instruction performed the transition from the less secure domain to the secure domain, the secure gateway instruction may clear the least significant bit of the return address in the link register. As described below, placing S148 in the least significant bit of a dummy function return address and encoding the S148 indicator such that a 0 indicates a less secure domain can provide additional security protection when used in combination with the secure gateway instruction operations described above. In the implementation described above, a value of 0 for S148 indicates a less secure state and the secure gateway instruction clears the least significant bit of the return address, but it will be appreciated that other encodings of the S148 field can achieve the desired operation. For example, if a value of 1 for S148 indicates a less secure state, then the secure gateway instruction sets the least significant bit of the return address to 1.

[0092] The dummy exception return address 142 is saved in the link register in response to a particular exception entry transition and, similar to the dummy function return address 140, provides a mechanism for allowing the actual exception return address to be saved to (and subsequently restored from) the stack, hiding it from less-secure processes that execute after the exception. The dummy exception return address 142 includes an exception return prefix 150 in the most significant bit portion of the dummy exception return address 142, which also has a value of 0xF0 or greater to ensure that the exception return address is within the reserved range 130. The exception return prefix 150 is different from the function prefix 144 so that the dummy function / exception return addresses 140, 142 can be distinguished from one another.

[0093] The dummy exception return address 142 includes a mode flag 152 indicating the mode in which the exception was taken (thread or handler) and a security domain flag (S) 156 indicating the security domain in which the exception was taken (secure or less secure). In some implementations, there may also be an exception security domain flag (ES) 157 indicating the security domain in which the exception was initially taken (secure or less secure). The exception return value also includes a thread mode interstating enabled (TMIE) value 158, which indicates whether, prior to taking the exception, the TMID flag 34 indicated that domain transition was disabled or enabled in thread mode in the context in which the exception was taken. For backward compatibility reasons (such that legacy code that is expected to set the bit corresponding to 158 to 1 represents the TMIE flag 158 as enabling domain transition in thread mode), the TMIE flag 158 in the dummy exception return address has the opposite encoding to the TMID flag 34 in the control register 32, resulting in the value of the TMID flag for the current security domain being inverted when setting the TMIE flag 158 in the dummy exception return address 142. While the TMIE flag 158 itself is not required to control exception return behavior, saving the TMIE flag 158 at the dummy exception return address effectively provides a context save / restore function so that upon return from the exception, the value of the TMID flag 34 in control registers 32 for the process being returned to can be restored to the state it was in before the exception was taken. Upon return from the exception, the value of the TMIE flag 158 is again inverted and written to the TMID flag 34 in control registers 32. While Figure 5 shows a particular encoding of the TMIE flag 158, this encoding is not required and other ways of representing the value restored to TMID 34 can be used.

[0094] Note that the status information 146, 148, 152, 156, 157, 158 recorded in the dummy function return address 140 and the dummy exception return address 142 can take on different values, meaning that there are multiple different addresses within the reserved range 130 that each act as a dummy function return address 140 and multiple different addresses that each act as a dummy exception return address 142. Thus, the particular dummy address stored in the link register R14 upon a function call or exception entry is selected based on the information encoded in the status flags.

[0095] Figure 6 shows examples of different stack frames that may be saved in a stack data structure in memory when making an intermodal or cross-domain function call or when entering an exception. The particular stack data structure in which the stack frame is saved depends on the current mode and security domain at the time of the function call or exception; if currently in thread mode, the stack selected also depends on the stack pointer selection value 30 associated with the current domain, as described above.

[0096] As shown in portion 170 of Figure 6, for function calls other than inter-domain / intermodal function calls (which do not trigger a mode or domain transition), the stack frame does not need to be stored on the stack, and for function calls within the same mode and domain, the actual function return address can simply be saved in the link register R14, and there is no need to hide the function return address from code executing after the function call.

[0097] For inter-domain or intermodal function calls from a secure domain to a less secure domain, the function return stack frame 172 is saved on the stack. For inter-domain function calls from a secure domain to a less secure domain, the stack frame 172 is saved on the secure stack pointed to by one of the secure stack pointers. If the inter-domain function call is made from Handler mode, this will be the secure main stack pointer MSP_S; if the inter-domain call is made from Thread mode, the stack frame is saved on one of the secure main stack (MSP_S) and the secure process stack (PSP_S), whose pointer is pointed to by the secure domain's stack pointer selection value 30-S. For intermodal function calls, these are made from Handler mode by default, so the main stack pointer associated with the current security domain is used.

[0098] As shown in FIG. 6 , function return stack frame 172 includes return address 174, which represents the actual function return address to which processing should return when returning from the called function. The actual function return address can be set to the address of the next instruction following the address of the function call branch instruction. The function return stack frame also includes a state data word 176 (FRETPSR) that provides information for determining how to handle the corresponding function return. In this example, it includes a thread mode unprivileged handler (HDT) flag 178, which indicates whether the function return stack frame 172 was saved in response to an intermodal function call from handler mode to thread mode. For example, the HDT flag can have a value of 0 if the function call was not an intermodal function call and therefore the handler mode was not unprivileged to thread mode, or a value of 1 if the function call was an intermodal function call. State data word 176 also includes exception number value 179, which corresponds to the value of exception number register 36 at the time the function was called. This serves as a "handler mode indicator" indicating whether the function return stack frame was saved in response to a function called from handler mode or thread mode. It will be appreciated that other information may also be stored in the function return status word 176 or in other portions of the function return stack frame 172.

[0099] Examples of exception stack frames 180, 182 are shown at the top of Figure 6. In response to an exception, one or both of a first (calling) stack frame 180 and a second (callee) stack frame 182 are saved to the stack. For performance reasons, it may be useful to divide the registers that may need to be saved in response to an exception entry event into two groups called "caller" registers and "callee" registers. Caller registers are registers that the hardware-implemented exception control circuitry 28 is responsible for saving to the stack. Therefore, the exception handler software does not need to include instructions for saving the caller registers to a stack data structure.

[0100] As shown in Figure 6, the caller registers (included in the caller stack frame 180) may include a subset of the general-purpose registers. In this example, the caller state includes general-purpose registers R0, R1, R2, R3, and R12, a link register LR (R14), an indication of the return address 181 to which processing will return after handling the exception (which may be set to a value derived from the program counter register R15 at the time the exception is taken), and an exception return program state value (ERETPSR) that is set based on a value in a program status register XPSR that may provide condition codes for controlling the outcome of conditional instructions and other state information about the current processing state. ERETPSR may also specify the exception number 36 of the processing that was executing before the exception was taken, which may have a default value of 0 if the processing circuitry was operating in thread mode before the exception was taken. It will be understood that this is just one specific example of which register state may be included in the caller register state. Some examples may also include floating point register state in the caller stack frame, and whether the floating point register state should be included may be configurable (e.g., depending on whether the executing thread has floating point state enabled).

[0101] For exceptions where only the caller stack frame 180 is saved to the stack, after the caller stack frame 180 is saved to the stack by the exception control circuitry 28 in response to the exception event, execution of the exception handling code begins. The exception handler software can then save state from additional callee registers to the stack if it knows it will overwrite this state during execution. However, this state saving by the exception handler is performed by controlling the load / save unit of the processing circuitry 4 to save relevant data to memory in response to load / store instructions provided in the exception handler code, which may be slower than if the exception control circuitry 28 controlled the stack in hardware. However, it may be beneficial to allow a distinction between the caller register state and the callee register state so that software executing after entering the exception can influence which registers need to be saved. If the exception handler never accesses a particular callee register (e.g., general-purpose register R7), the exception handler does not need to save the corresponding architectural state, and the energy and time associated with performing this state saving in the exception control circuitry 28 and hardware are also avoided. Writers of code for exception handlers, or compilers of such code, may be encouraged to use caller registers first before using additional callee registers, to reduce the likelihood that additional state saving in the software will be required.

[0102] However, if the exception entry causes a transition from the secure domain to the less secure domain and the original background processing is executed in the secure domain before the exception, and only the caller registers are saved to memory by the exception control circuitry 28, this may leave the callee registers accessible in the register bank 14 to a less secure exception handler to be executed after the most recent exception. This may be undesirable because the callee registers may contain information derived from the secure region of the memory address space that the SAU 24 would normally prevent the less secure exception handler from accessing.

[0103] Thus, for some transitions from the secure domain to the less secure domain where background processing was previously performed in the secure domain, the exception control circuitry 28 may also save the callee registers in the relevant stack data structures, in addition to saving the caller registers, and may clear the contents of the saved registers (including the caller and callee registers). Thus, by performing an additional state save in hardware, this means that less secure software that would normally save the callee registers cannot in this case gain access to potentially secure information that was stored in these registers before the exception occurred.

[0104] Thus, for some exception entry transitions, in addition to storing the caller stack frame 180, a second (callee) stack frame 182 may also be saved (under hardware control by the exception control circuitry 28, i.e., without requiring explicit load / store instructions to be executed by the processing circuitry 4). Note that while the callee stack frame is referenced in FIG. 6 as a separate stack frame from the caller stack frame, others may view the callee stack frame as an extension of the caller stack frame, with the combination of 180, 182 viewed as a single stack frame. Both approaches may be considered equivalent.

[0105] Callee stack frame 182 includes additional callee state, including registers R4-R11, that were not saved in caller stack frame 180. Optionally, floating point context may also be included in callee stack frame 182. The additional state saved by the hardware may also include a predetermined integrity signature 190. Integrity signature 190 is included in callee stack frame 182 when both caller and callee states are saved by exception control hardware 28, but is missing from caller exception stack frame 180. Integrity signature 190 has a value that corresponds to one of the reserved ranges of non-executable addresses 130, such that any attempt to fetch an instruction from it will signal a failure. Integrity signature 190 may have a value that cannot match any valid dummy function return address 140 or dummy exception return address 142. Integrity signature 190 can be used to detect several forms of attacks that can be launched on a processing circuit to attempt to circumvent the security protections afforded by hardware enforcing the distinction between a secure domain and a less secure domain. One possible means of attack may be for an attacker to attempt to perform an exception entry transition to enter the processing of an exception, but then later forge a different type of return transition to one expected to return from the exception entry, such as performing a function return transition. Signature 190 is placed in the same relative location on the stack frame as the relative location used in function return stack frame 172 to store function return address 174. Thus, if return address 174 is detected in the function return to match integrity signature 190 (or correspond to one of non-executable reserved addresses 130), a fault may be triggered because it means that the stack frame used to perform the function return was actually saved to the stack in response to the exception entry event, which may be an indicator that an attack is being carried out.Also, the absence of a signature may indicate that an exception return event is being executed based on a stack frame saved in memory in response to a function call, which again poses a security risk, so when returning from an exception where additional architectural state associated with the callee registers is present on the stack, part of the security check may be to check that the value at the associated offset in the stack corresponding to the integrity signature 190 has the expected value.

[0106] 6, as part of predefined signature value 190, TMIE cross-check value 192 may be stored within one of the bits of predefined signature 190 (thus, effectively, there may be two or more valid values ​​of predefined signature 190, each within reserved range of addresses 130, but separate from the addresses used for dummy function return values ​​and dummy exception return values). If callee stack frame 182 takes a saved exception, TMIE cross-check value 192 is set to a value indicating the state of TMIE flag 158 written to dummy exception return address 142 in the link register (e.g., cross-check value 192 may be equal to TMIE flag 158, may be inverted relative to TMIE flag 158, or another encoding may be used to represent the state of the TMIE flag). If the callee stack frame 182 is saved on the stack, this indicates that the exception is being taken from the secure domain to the less secure domain if the original background processing that ran before the exception was in the secure domain, and therefore there may be a risk that less secure code that runs after the exception may modify the TMIE value in the dummy exception return address 142 in an attempt to prevent the secure code from functioning correctly after the exception return. The TMIE crosscheck value 192 provides a crosscheck to detect tampering with the TMIE value 158.

[0107] In some system implementations, it may be desirable for certain types of exception handlers to run in an unprivileged state. This may be useful, for example, for certain types of exceptions associated with devices controlled by library code provided by an untrusted third party, where it may be undesirable to allow an exception handler provided by an untrusted third party to have the full privileges available to the handler mode because it cannot prevent the handler from modifying certain state information. However, as shown in Figure 2, handler mode operates in a privileged state by default, so a switch back to thread mode is required for the exception handler to operate in an unprivileged state. However, in typical implementations, the mechanism for switching from handler mode to thread mode is via an exception return. It is generally undesirable for the original exception to trigger an exception return because it reduces the execution priority of the original exception (after modifying the return address, the return proceeds to unprivileged library code rather than the previous background processing). This reduction in execution priority can prevent exception handling routines from being correctly prioritized. Therefore, it is preferable if the handler code handling the original exception can switch to thread mode without triggering an exception return.

[0108] In a typical system, the only mechanism for switching from a handler to Thread mode is via an exception return, so as shown in Figure 7, this requires that the exception handler generate a further exception (e.g., a Supervisor Invoke Exception, SVC) so that it can become unprivileged to handle the original exception, and as a result, an exception return stack frame may be set up in memory; this exception return stack frame does not represent the actual processing context running before the exception, but is faked to ensure that processing switches to Thread mode when the SVC exception returns, and the body of the previously raised exception can be handled in unprivileged Thread mode.

[0109] For example, as shown in Figure 7, when processing some background code in thread T1 in thread mode, an interrupt IRQ that is passed to a non-privileged library occurs. In step 1 of Figure 7, the interrupt triggers the exception control circuit 28 to stack register states onto the process stack to maintain the register states of thread T1. Because exceptions are initially taken by default in handler mode, the interrupt causes a transition from thread mode to handler mode. Although the main body 200 of the exception handler for handling the IRQ exception is executed by an untrusted library, the exception handler for handling the IRQ exception is provided with wrapper code 202 that executes before and after the main exception handler body 200. The wrapper code executes in handler mode and controls the operation for generating an SVC exception to ensure that the main body can be handled in thread mode.

[0110] 7, the wrapper code in handler mode generates an SVC exception, which does not actually handle the original IRQ interrupt, but is generated simply to allow the IRQ handler to switch to thread mode. The SVC exception causes the exception control circuit 28 to stack register state onto the main stack pointed to by the main stack pointer MSP associated with the current domain (the main stack is used because the current mode is handler mode). The SVC exception handler executed in response to the SVC exception switches the process stack pointer to point to a different stack structure PSPIRQ associated with the thread TIRQ, which will execute the main exception handler body 200 to handle the original IRQ exception. In its exception return state information (ERETPSR), the SVC exception handler fakes a stack frame on the process stack indicating exception number 0 to indicate that the corresponding exception return should return to thread mode. Note that this value is false because the processing executed before the SVC exception was actually in handler mode.

[0111] When the SVC exception handler completes, it causes a branch to a fake dummy exception return address, which triggers an exception return using the fake exception return stack frame created on the stack pointed to by PSPIRQ rather than the exception stack frame created on the main stack in step 2. The exception return is then executed by exception control circuitry 28, which unstacks the hardware from the PSPIRQ stack in step 3 of FIG. 7. The hardware detects that the M bit 152 in the fake dummy exception return address 142 indicates that the return should be in threaded mode, so in step 4 the subsequent body of exception handler 200 for handling the IRQ exception can be executed in threaded mode by an unprivileged library. Note that this is done without returning from the original IRQ exception, and therefore the priority of the exception handler for handling the IRQ exception is not reduced.

[0112] Upon completion of the main exception handler body 200, another SVC exception call is made in step 5 (SVC is a type of exception that can be triggered spontaneously by software, as opposed to a type of exception that is triggered by an unexpected or faulty event), which again causes further hardware stacking onto the process stack pointed to by PSPIRQ; the called SVC handler then destroys the stack frame just created on the process stack pointed to by PSPIRQ and then updates the process stack pointer of the current security domain to restore the previous stack pointer PSP1 associated with background thread T1. In step 6 of Figure 7, the SVC exception generates an exception return, which then triggers further hardware unstacking from the main stack using MSP (i.e., unstacking the stack frame created during step 2), and then, after executing the remaining wrapper function 202 in handler mode, in step 7, a further exception return is generated, which causes hardware unstacking of the register state associated with thread T1 from the process stack pointed to by PSP1 (i.e., unstacking the stack frame created during step 1). Processing then continues in the background code of thread T1 running in thread mode.

[0113] The process shown in Figure 7 allows certain types of exceptions to be deprivileged so that the exception handler operates in threaded mode. However, it has several drawbacks. First, generating software code to control this process is difficult due to the required spoofing of exception stack frames, and is therefore prone to programmer errors, potentially providing vulnerabilities that an attacker could exploit or that could stop the system from functioning correctly, or potentially providing a way for an attacker to extract secret values ​​such as cryptographic keys.

[0114] Another drawback is that for this approach to work, the exception priority of the SVC exception (which runs at the beginning and end of the main exception handler body 200 to create a fake stack frame and clean up before returning from the original exception) must be higher than the priority of all interrupting IRQs that need to be non-privileged. This can make the design of real-time systems much more complicated because the SVC exception is always taken to the same priority, so the worst-case interrupt latency of other IRQ exceptions is increased by the duration of the longest SVC call, which may be undesirable.

[0115] Additionally, the approach shown in Figure 7 is very slow, which is a major blocker to the use of unprivileged libraries with significant interrupt latency. This poor performance is due to several factors, including the manual creation of the exception stack frame when handling the SVC exception between steps 2 and 3 of Figure 7, and the need for two different SVC exceptions that trigger four additional register state stack and unstacking events in steps 2, 3, 5, and 6 of Figure 7, which represent memory access latency that would not be required if the exception handler for handling the IRQ simply ran in handler mode. Thus, the performance cost may mean that some system designers may find it impossible to simply use devices such as wireless network interfaces or USB controllers associated with untrusted library code, potentially limiting system design flexibility. In this example, the entire unprivileged process runs in the less-secure domain, as shown at the bottom of Figure 7, although it will be understood that the process may also run within the secure domain.

[0116] Figure 8 shows an alternative approach to improving exception deprivilege performance using an intermodal call branch instruction as described in this application. By providing an intermodal call branch instruction that can branch to an instruction at a target address specified by the instruction and set the function return address to indicate the address to which processing should return after the function completes, as well as triggering a switch from handler mode to thread mode, this means that interrupts can be deprivileged much faster, reducing the performance hit, complexity, and other issues mentioned above associated with the approach shown in Figure 7. This approach allows for a much simpler response to IRQ exceptions that should be handled in an unprivileged state.

[0117] Step 1 of Figure 8 is the same as Figure 7. In step 2, some wrapper code 203 is executed to prepare for execution of the main interrupt handler body 201, which has as its last instruction before the main interrupt handler body 201 an intermodal call branch instruction that specifies as a branch target address the address of the first instruction to be executed within the main exception handler body 201. In some operating systems, wrapper 203 may be identical to wrapper 202, except that it executes an intermodal branch instruction instead of triggering an SVC exception. In some implementations, the intermodal call branch instruction may have a dedicated instruction encoding that differs from the instruction encoding of a non-intermodal call branch instruction that does not transition from the handler to thread mode. Thus, in step 3 of Figure 8, execution of the intermodal call branch instruction triggers a switch from handler mode to thread mode, and then the main exception handler body 201 continues executing in thread mode at step 4 of Figure 8. No SVC exception needs to be raised.

[0118] When an intermodal function call is made, information can be stored in dummy function return address 140 to indicate that the function call was an intermodal call (using intermodal call indicator 146). As a result, when the corresponding function return is triggered in step 5 of FIG. 8, processing circuitry 4 can detect indicator 146 and, in addition to branching to function return address 174 associated with the previous function call (stored in function return stack frame 178), can detect that the current mode should also be changed back from thread mode to handler mode. Any remaining wrapper code 203 then executes in handler mode in step 6 of FIG. 8, followed by step 7, where an exception return is executed to return from the handler to the background thread T1 that was executing before the IRQ exception occurred. In some systems, main interrupt handler body 201 (FIG. 8) may be identical to main interrupt handler body 200 (FIG. 7) in that, instead of triggering an SVC exception to return from the unprivileged main interrupt handler body, a return can be requested simply by branching to dummy function return address 140 placed in the link register in step 3 of FIG. 8. Therefore, the main interrupt handler body 201 (FIG. 8) can be a standard C function and requires no special handling.

[0119] Thus, with this approach, the only hardware stacking and unstacking operations required are those to save and restore register state associated with background code T1, and no additional hardware stacking and unstacking operations associated with the two SVC exceptions are required. This approach is also much easier to code for a compiler or programmer, reduces the likelihood of errors, and does not require the SVC exception to have a higher priority than all exceptions that are non-privileged.

[0120] To improve security by limiting the number of opportunities to switch security domains, intermodal function calls cannot change security domains, only between modes. Thus, when executing an intermodal function call branch instruction, processing circuitry 4 can keep the current security domain the same as it was before the execution of the intermodal function call branch instruction. As shown in FIG. 9, to maintain security, combined domain / mode function return transitions from the less secure thread mode to the secure handler mode can be prohibited. This can be implemented by an explicit check whether a return to the secure domain is requested in the intermodal function return, and a fault can be triggered if this is detected, as described below with reference to FIG. 15.

[0121] However, for intermodal function returns, it may be desirable to allow combined mode / domain transitions, at least when the intermodal function return is from a secure thread mode to a less secure handler mode, as shown in Figure 10. This allows compilers to use a technique known as tail calls, as shown in Figures 11A-11C. In some implementations, for security reasons, tail calls may be prohibited for secure to less secure function calls. Thus, it may be necessary to support the secure thread to less secure handler intermodal return transition shown in Figure 10, but it may not be necessary to support the less secure thread to secure handler intermodal return transition shown in Figure 9.

[0122] As shown in FIG. 11A, some high-level code (compiled into assembly code supported by the instruction decoder 10 of the processing system) may contain nested function calls where a second function fn2 is called inside a first function fn1, and the location of the call to function fn2 is such that there are no further instructions of fn1 between the end of fn2 and the end of fn1.

[0123] In this scenario, as shown in FIG. 11B, one option for a compiler generating assembly code could be to generate, for each call to fn1 and fn2, a call branch instruction (BL, also known as a branch and link instruction) that triggers the saving of the function return address in the link register (LR) (R14) and a branch to a target address representing the start of the function code for that function, followed by a function return instruction (an indirect branch instruction BX specifying the link register as its address operand) indicating that processing should return to the return address previously saved in the link register. Because the call branch instruction for calling fn1 would be part of the code that called fn1, it is not shown in FIG. 11B, which shows only the function code for fn1 and fn2. Thus, for fn1, the compiler generates a BL instruction 283 (to call fn2) and a BX instruction 286 (to return from fn1 to the code that called fn1). For fn2, the compiler generates a BX instruction 284 for the return from fn2 to fn1. To ensure that the return address of fn1 is preserved when calling fn2, the fn1 code also includes a push instruction 282 that pushes the contents of the link register onto the stack before calling fn2, and a pop instruction 285 to restore the link register from the stack before returning from fn1. In fact, because fn2 is the last activity executed within fn1, this pushing and popping of function 1's link register to and from the stack introduces some unnecessary memory and performance overhead.

[0124] 11C, an alternative approach to compiling the function may be to call the code associated with fn2 using a no-call branch instruction 287 that does not update the link register, effectively passing the return address saved in the link register to fn1 through fn2. This means that when final return branch 288 is executed, processing returns to the background code that was processing before fn1. This approach is known as a tail call, and can improve performance by avoiding the need for the push 282, pop 285, and BX 286 instructions.

[0125] However, in a scenario where function 1 is in the less secure threading mode and is called by an intermodal function call, and function 2 is in the secure threading mode and is called by an inter-domain function call (a call from the less secure domain NS to the secure domain S), as shown in the example of FIG. 10, this means that to support tail calls, a subsequent return branch instruction 288 must trigger a direct return from the secure threading mode to the less secure handler mode. If combined domain / mode transitions were not supported, tail calls would not be possible, which could require a lot of existing legacy code to be recompiled; therefore, it may be more efficient to support combined domain / mode transitions when in the secure threading mode to the less secure handler mode. Nevertheless, by prohibiting intermodal function returns from the less secure domain to the secure domain, this improves security because it limits the means by which the secure domain can be entered. As explained earlier, this combined transition may not be necessary because tail calls from the secure domain to the less secure domain may already be prohibited in legacy code.

[0126] FIG. 12 is a flow diagram illustrating steps performed in response to a function call branch instruction (BLX). These steps are performed by processing circuitry 4 under control of instruction decoder 10 in response to decoding an instruction identified as a function call branch instruction. In step 300, it is determined whether the function call branch instruction is an intermodal call branch instruction, which is a specific type of function call branch instruction distinguished by a different instruction encoding from other types of function call branch instructions. For example, an intermodal call branch instruction may have a different opcode than a non-intermodal call branch instruction, or it may have the same opcode but a separate parameter specified in the instruction encoding that distinguishes it from an intermodal call branch instruction. In the exemplary embodiment shown in FIG. 12, there are two variants of the intermodal call branch instruction, BLXT and BLXTI, which both trigger an intermodal function call but differ in how they set the TMID parameter 34 in control register 32. It will be appreciated that some system implementations may not support both variants of the intermodal call branch instruction and may have only one of the BLXT and BLXTI variants. Also, some implementations may have further variations of the intermodal call branch instruction.

[0127] If the function call branch instruction is not an intermodal call branch instruction, then in step 302, processing circuitry 4 (under control of instruction decoder 10) determines whether the function call is an inter-domain function call from a secure domain to a less secure domain. In some implementations, such a secure-to-less secure domain call may be signaled by yet another variant of the function call branch instruction, BLXNS, which has a dedicated instruction encoding that distinguishes it from other types of function call branches. Also, in some implementations, whether a BLXNS instruction triggers an inter-domain call may also depend on the branch target address specified by the instruction, particularly whether the least significant bit of the branch target address is 0. In some examples, for a valid function call or branch from less secure code to a secure domain, in response to a secure gateway instruction executed as the first instruction in secure code after the function call, the least significant bit of the function return address may be sanitized to 0 to ensure that a subsequent function return returns to the less secure domain, thereby preventing less secure code from illegally branching to secure code anywhere within the secure address space defined by SAU 24 by providing a function return address that is within the secure domain. Since sanitizing the least significant bit of a branch target address can be used to ensure the security of a secure to less secure domain function return (using the BXNS instruction), it may be convenient to use a similar scheme to ensure the security of a secure to less secure domain function call (using the BLXNS instruction). Thus, upon detecting an inter-domain call instruction BLXNS with the least significant bit of the branch target address set to 0, this may be treated as a secure to less secure domain call. In some implementations, the secure to less secure domain call instruction (BLXNS) may only be available in the instruction set (and therefore detectable by decoder stage 10) when processing circuitry 4 is operating in the secure domain.In such an embodiment, an attempt to execute a BLXNS instruction from a less secure state may result in decode stage 10 not recognizing the instruction as a valid instruction for the current state, and therefore processing never reaches step 300.

[0128] If the function call is not a secure to less secure domain call, then in step 304, the function call can be processed without any particular security impact, and in step 304, the link register (R14) is set to the function return address. The function return address has a value of the address of the instruction after the function call instruction in address space 100 (i.e., the address of the function call instruction plus the length of the function call instruction opcode). In step 306, the program counter register R15 is updated based on the branch target address specified by the function call branch instruction, so that processing branches to the instruction at the branch target address. This represents the normal case of branch processing for a function call that does not trigger a domain change or mode change.

[0129] If, in step 302, it is determined that the function call branch is a secure-to-less secure inter-domain call, then in step 307, the processing circuit 4 determines whether the current mode is Thread mode (based on whether the exception number 36 is a special Thread mode value of 0) and whether the Thread mode transition disable (TMID) parameter 34 indicates that domain transitions are disabled in Thread mode. If the current mode is Thread mode and inter-domain transitions are disabled in Thread mode, then in step 308, the processing circuit signals a fault. The particular type of fault signaled may be a dedicated fault type used only for exceptions triggered by attempts to switch security domains in Thread mode when the TMID flag 34 indicates this is disabled. Alternatively, the fault may be directed to an exception handler used to handle various fault conditions; in such cases, a syndrome flag associated with the inter-domain transition disable check may be set, allowing the exception handling routine to easily identify the cause of the fault and any subsequent actions that need to be taken. In Figure 12, this is shown as an INVTMI (Invalid Thread Mode Transition) UsageFault, although the exact naming convention for this type of fault may of course vary. For secure to less secure domain calls, the INVTMI fault is handled in the secure domain (the current domain before the call was attempted), which is useful because the process for managing the thread that requested the secure to less secure transition is the secure operating system that manages the secure thread, which may be better placed to handle the INVTMI fault so that it can configure the resources needed for that thread to operate in the less secure domain.

[0130] If step 307 determines that the current mode is handler mode (e.g., if exception number 36 is non-zero) or that TMID parameter 34 is 0 to indicate that domain transitions are enabled in thread mode, then in step 310 the processing circuit sets link register R14 to one of the valid dummy function return address values ​​140, as shown in FIG. 5. In the dummy function return address 140, intermodal flag (M) 146 is set to 1 to indicate that this was not an intermodal function call, and security domain flag (S) 148 is set to 1 to indicate that the call was made from the secure domain. In step 312, the function return stack frame 172 is saved to a stack data structure pointed to by either secure main stack pointer MSP_S or secure process stack pointer PSP_S (depending on whether the current mode is handler mode or thread mode, and if in thread mode, depending on stack pointer selection value 30 of secure domain 13_S). The saved function return stack frame 172 specifies that HDT flag 178 is equal to 0 to indicate that this is not an intermodal function call. Also, an exception number field 179 in the function return stack frame 172 is set equal to the current value of exception number 36 in control register 20 to indicate whether the call was made from handler mode or thread mode. This exception number field 179 functions as a handler mode, indicating whether the current mode is handler mode. The function return stack frame also includes a function return address 174, set in the same manner as in step 304, but this time saved in the stack instead of the link register, so that less-secure code executing after the inter-domain call cannot know which instructions were executing in the secure code before the function call. In step 314, the processing circuitry then switches the current domain to the less-secure domain, and the method then proceeds to step 306, where a branch to the branch target address specified by the function call branch instruction is executed in the same manner as described above.

[0131] Referring again to step 300, if the function call branch instruction is an intermodal call branch instruction, then in step 320 the processing circuit determines whether the current operating mode is thread mode. If the current mode is thread mode, then in step 322 a usage fault is signaled. This may be a different type of usage fault than an INVTMI UsageFault. The intermodal call branch instruction is intended to trigger a switch from handler mode to thread mode to support interrupt deprivilege, and an attempt to execute it from thread mode is an error. Suppressing instruction execution of an intermodal call branch when in thread mode avoids potentially unpredictable results caused by setting an incorrect stack frame in response to a call branch, which could lead to a security vulnerability. Therefore, an intermodal call branch instruction can only be executed from handler mode.

[0132] If in step 320 it is determined that the current mode is handler mode, the method proceeds to step 324 where the link register is set to one of the special dummy function return address values ​​140, but unlike in step 310, the intermodal flag (M) 146 is set to 0 in step 324 to indicate that the corresponding function return should be treated as an intermodal function return. Also, a security domain flag (S) 148 in the function return value 140 indicates the current domain of operation at the time the intermodal call branch instruction was executed (intermodal calls can be made from either the secure domain or the less secure domain).

[0133] In step 326, the processing circuitry saves a function return stack frame 172 to a stack selected based on the domain and operating mode before executing the intermodal call instruction and stack pointer select value 30. The function return stack value again includes a function return address 174 (set in the same manner as in steps 304 or 312) and a handler mode indicating a value corresponding to the current value of exception number 36. If the intermodal call is made from handler mode, exception number field 179 is expected to be non-zero. For an intermodal call, HDT flag 178 in the function return stack frame is set to 1 to indicate that this function return stack frame was saved in response to an intermodal call, and a dummy function return address 140 can be used with the corresponding function return to provide cross-check information to check whether intermodal flag 146 is correct or has been tampered with by untrusted code. Note that following the saving of the function return stack frame in either step 312 or 326, if more stack information is needed before the currently saved stack frame is unstacked, the corresponding stack pointer is also updated to point to the location where more stack information should be saved to the stack.

[0134] In step 328, optionally, the processing circuitry triggers an error synchronization barrier operation to be performed in response to the intermodal call branch instruction. For example, the error synchronization barrier operation may include processing circuitry 4 halting further execution of instructions until the results of at least some types of error detection or correction operations to check the validity of any previously executed instructions are completed, confirming that those operations were either error-free, contained correctable errors, or contained errors correctly attributable to execution of instructions prior to the change from the handler to thread mode. The error synchronization barrier operation is an operation to ensure that at least some types of errors detected by reliability, availability, and serviceability (RAS) error detection / correction circuitry 29 are attributable to code executing before the mode change caused by the intermodal call branch instruction and can be distinguished from errors that occur when processing code executed after the mode change caused by the intermodal call branch instruction. In the case of an intermodal call branch, it may be useful to be able to accurately identify whether a detected RAS error affected more privileged code executed before the mode change caused by the intermodal function call or less privileged code executed after the mode change. This is because resolving errors associated with less privileged code can often have a much lower impact on system availability than resolving errors associated with more privileged code. For example, the more privileged code may be the operating system, so handling an error caused by the operating system may require a complete system reset, whereas an error caused by less privileged code associated with an individual thread can be handled simply by killing the thread but leaving other threads and the operating system unaffected.Thus, by performing an error synchronization barrier operation in response to an intermodal call, this can improve system availability by limiting the impact of handling detected errors when they may safely be attributed to low-privilege code that executes after a mode change caused by the intermodal function call. It will be appreciated that there may be some types of errors that may be outside the scope of an error synchronization barrier and therefore may not be contained by the use of such a barrier. These uncontained errors may still require a full system reset. However, the use of an error synchronization barrier can increase the likelihood of errors being attributed to a single thread and therefore reduce the likelihood that a full system reset is required.

[0135] It is not mandatory that an error synchronization barrier operation be triggered in all scenarios. Some systems may prefer improved performance of regular program execution by not artificially suppressing execution of subsequent instructions executed after an intermodal function call. For example, for certain real-time-critical interrupts, interrupt processing latency may need to be as short as possible, so it may be preferable not to trigger an error synchronization barrier operation when a RAS error is detected, at the expense of a greater performance cost. However, for other types of interrupts with low real-time criticality requirements or other types of interrupts associated with safety-critical operations, it may be preferable to trigger an error synchronization barrier operation. As a result, normal interrupt latency may be slightly slowed to hold off instruction execution after the intermodal call until error detection / correction results are available, but if an error is detected, the error can be located and the full effects of a system reset can be avoided to the greatest extent possible. Thus, in some implementations, control register 20 may store a configuration parameter specifying whether an error synchronization barrier operation should be triggered in response to an intermodal call instruction. In some systems, the configuration parameter specifying whether an error synchronization barrier operation should be performed is banked between security domains, allowing the less secure domain and the secure domain to independently select whether the barrier operation should be performed.

[0136] Regardless of whether an error synchronization barrier operation is performed, in step 330, in response to the intermodal call branch instruction, the processing circuitry also sets the stack pointer selection value 30-S or 30-NS of the current security domain to indicate that the process stack pointer should be selected for subsequent operations executed in Thread mode after the intermodal function call. This ensures that the less privileged portion of the exception handler executing after the intermodal call cannot access or corrupt the main stack pointer used by the more privileged section of wrapper code that executed in handler mode before the intermodal call instruction, even if Thread mode code executing before the exception is handled by the exception handler accesses the main stack pointer.

[0137] In step 332, processing circuit 4 determines whether the intermodal call branch instruction being executed is the BLXTI variant of the instruction. If so, in step 334, TMID parameter 34 is set to 0 to indicate that domain transitions between the secure and less secure domains are enabled in thread mode. This corresponds to the second variant of the intermodal call branch instruction, as described above. If the intermodal call branch instruction is the BLXT variant (first variant), in step 336, TMID parameter 34 is set to 1 to indicate that domain transitions in thread mode are disabled. The programmer can choose whether to use the BLXT or BLXTI variant depending on whether resources in both the secure and less secure domains have already been established for the thread that will be executed following the intermodal function call. The BLXTI variant can be selected when resources in both domains have already been established so that it is safe to switch between the secure and less secure domains as needed, while the BLXT variant can be selected when resources in only one of the S / NS domains have been configured. These resources may include an MPU configuration within the associated one of the secure MPU 26-S and the less secure MPU 26-NS (the MPU configuration may include one or both of several memory region attributes defining access permissions to the respective memory regions and / or a pointer to a table within the memory system 6 that provided those memory attributes). The resources may also include a stack pointer in a secure or less secure stack pointer register (a banked version of R13 shown in FIG. 3), and may also include an allocation of a corresponding stack structure stored in memory if an appropriate stack structure in memory is not already available.By providing the ability to disable domain transitions in thread mode, this allows a thread to configure its resources for only one domain, and then only needs to lazily allocate resources in the other domain if there is an attempt to switch domains, otherwise a fault is triggered as shown in step 308 above, or as previously described for other types of inter-domain transitions. By also setting the transition disable parameter 34 in the thread using the BLXTI or BLXT instruction, this avoids the need for a separate instruction to set the flag separately.

[0138] Regardless of which variation of the intermodal call branch instruction is executed, in step 338 the processing circuitry updates exception number 36 to indicate a non-exception handling value (e.g., 0), thereby switching the processor to thread mode. Again, the method then proceeds to step 306, branching to the branch target address specified by the function call branch instruction. Program execution then continues from the instruction stored at the branch target address. It will be appreciated that the branch target address can be specified by the function call branch instruction in several ways. For indirect branches, the branch target address can be defined using an operand to select a register containing the target address. Direct branches can specify the target address using an immediate value directly encoded in the instruction encoding. Program counter relative branches (which can be indirect or direct) can specify an offset to be added to the current program counter value to obtain the branch target address.

[0139] 13 shows the steps performed when entering an exception. In step 350, the exception is taken. The exception can be a software-triggered exception, such as a supervisor call (SVC), or an exception caused by the occurrence of a fault caused directly by software, such as an attempt to execute an undefined instruction, an attempt to fetch an instruction from the reserved address range 130, or an access to memory that triggers an address fault due to a failed memory permission check in the memory access check circuitry 22. The exception can also be a hardware-triggered interrupt caused by the receipt of a signal or message from an external device or peripheral.

[0140] Regardless of the cause of the exception, once the exception is taken, in step 352, the processing circuit 4 is controlled by the exception control circuit 28 to set the link register R14 to the aforementioned special dummy exception return value 142. More specifically, one of several dummy exception return values ​​is selected, and the values ​​of the current mode and current domain flags 152, 156 are selected based on the current mode and operating domain at the time the exception occurred. Additionally, the thread mode transition enable (TMIE) flag 158 is set to the inverse of the current value of the TMID flag 34 in the control register 32. This allows the information in the TMID flag to be preserved during exception handling and restored upon exception return. It will be appreciated that an implementation that inverts the TMID flag to set the TMIE flag is just one possible implementation; other examples may simply encode the TMIE value with the same encoding as the TMID value and copy it directly, or may use an entirely different encoding that need not be represented as a single-bit flag but may use a multi-bit value.

[0141] In step 354, exception control circuitry 28 triggers a hardware-triggered state save of register state from register 1 to a stack data structure in memory identified by one of the stack pointers in the banked stack pointer registers. The particular stack pointer selected depends on the current domain and mode in use before the exception occurred and the stack pointer selection value 30. The state save may include storing only the caller stack frame 180 shown in FIG. 6, or storing both the caller stack frame 180 and the callee stack frame 182. The decision to save only the caller stack frame or both the caller and callee stack frames depends on the current operating domain at the time the exception was taken and the domain in which the exception is handled, and may possibly be based on state data stored in control registers 20.

[0142] If an exception is taken from background code that is not itself handling the exception, a previously raised exception has already been handled, and the background code is handled in a less secure domain, only the caller stack frame 180 needs to be preserved, and there is no need to preserve the callee stack frame 182. Also, if the background code was handled in a secure domain, but the exception should be taken in the secure domain, there is no need to preserve the callee stack frame 182.

[0143] If an exception is taken from background code that was handled in the secure domain, but the exception ends up being handled in the less secure domain, there is a risk that the less secure exception handler can access register state placed in registers 14 by secure code running before the exception. Thus, in this case, both the caller and callee stack frames 180, 182 can be saved on a secure stack identified by one of the secure main stack pointer and the secure process stack pointer, and general purpose registers 16 can be cleared to hide secure data from being accessed by the less secure handler.

[0144] The previous paragraphs describe the general principles of determining whether to preserve additional callee stack frames when taking an exception from background code. However, if a further exception preempts a previous exception that has not yet completed its exception handler, or if a tail chain of exceptions executes, completing one exception before another is taken before returning to the background code, a more complex determination of whether to preserve the caller and / or callee stack frames can occur. Examples of decision processes for determining whether to preserve caller and callee state in response to an exception are described in published PCT applications WO 2013 / 117899 and WO 2014 / 053804, the contents of which are incorporated by reference and can be used to determine which registers can be stacked in step 354 of Figure 13 of the present application. See, in particular, Figure 12 of WO 2013 / 117899 and the associated discussion.

[0145] If it is decided in step 354 to save the callee stack frame 182 to the stack, then in the predefined signature 190, TMIE cross-check information 192 is specified, which is set to the same value as the TMIE flag 158 in the dummy exception return address set in step 352 (or, in an alternative embodiment, to another value that can be used to check whether the TMIE flag 158 is set correctly). This provides protection against the risk that less secure code running after the occurrence of the exception may tamper with the TMIE flag 158 in the dummy exception return address, such that if the TMIE flag 158 is used to restore the TMID flag 34 to the control register 32, there is a risk that secure code will process after receiving an incorrect value for the transition disable flag TMID 34 after returning from the exception. This protects against denial of service attacks caused by spurious faults generated based on a TMID 34 that was set based on a tampered TMIE flag 34.

[0146] One might wonder why the TMIE cross-check value 190 is specified in the callee stack frame 182 rather than the caller stack frame 180, because one might think that if a value holding the TMID flag 34 for background code were saved in the caller stack frame 180, it could be kept secure without being accessible to the exception handler in the link register, as is the case with the TMIE flag 158 in the exception return value 142. In reality, however, the caller stack frame 180 may not have much spare capacity for additional information because the status field ERETPSR may already have much information to encode and therefore may not have space for the cross-check information 192. In some implementations, there is enough space in the ERETPSR value to add a TMIE flag, but the remaining space in the ERETPSR value is still limited, and it may be preferable to reserve that space for future additions to the architecture. The callee stack frame 182 cannot be relied upon to store a primary copy of the TMIE value 158 that indicates the value to be restored to the TMID flag 34 upon exception return, because it is not saved for all types of exceptions. Thus, the approach shown in Figures 5 and 6, where the TMIE flag 158 is placed in the link register as part of the dummy exception return address, but the cross-check information 190 is included in the callee stack frame 182, allows all types of exceptions to retain the value of the TMID flag 34 despite there being no space in the caller stack frame 180; however, in scenarios where there is a risk of the TMIE flag 158 being tampered with, these are also the same scenarios where the register state is protected by saving an additional callee stack frame 182; therefore, the cross-check information 192 saved in the callee stack frame 182 protects the TMIE flag 158 from tampering.

[0147] In step 356, as part of the exception entry transition, exception control circuitry 28 triggers handling circuitry 4 to set TMID flag 34 in control register 32 to 0, indicating that domain transitions are enabled in Thread mode. This ensures that all exception handlers have a consistent view of whether domain transitions are enabled in Thread mode, regardless of whether domain transitions were disabled for code executing before the exception. Enabling domain transitions in Thread mode in this manner may be required for backward compatibility with software written before TMID flag 34 was created.

[0148] In step 358, the exception control circuit 28 controls the processing circuit 4 to branch to the exception handling routine. The address of the instruction to be executed at the start of the exception handling routine can be determined based on an exception vector table that maps different types of exceptions to their respective exception handling routine addresses. Because the exception handling routine is processed in handler mode, if the processing circuit 4 was currently in thread mode, the current mode is switched to handler mode in response to the exception being taken. If the current mode was already handler mode when the exception was taken, no change to the current mode is made. Thus, it is possible to execute an intermodal function call as described above to switch to thread mode after processing some code in handler mode, but it is not possible to first take the exception in thread mode.

[0149] Also, upon exception entry, the exception control circuit 28 can optionally trigger the processing circuit 4 to switch security domains, if necessary. Different exceptions may be associated with different security domains. Some exceptions may always need to be taken in a particular domain, such as a secure domain or a less secure domain. At the time an exception occurs, other exceptions can be taken in the current domain. Thus, in addition to branching to an exception handling routine, the exception control circuit 28 can also trigger a change of security domain if the exception is to be handled in a domain different from the current domain.

[0150] FIG. 14 is a flow diagram illustrating steps performed in response to a branch instruction that is not a function call branch instruction of the type shown in FIG. 12. In step 400, the processing circuitry checks whether the target address is within the reserved address range 130. If not, this is a normal branch instruction to the address of an executable instruction. In step 402, it is detected whether the branch requests a transition from a secure domain to a less secure domain. This can be identified by checking the current operating domain of the processing circuitry 4 and checking the least significant bit of the branch target address. If the least significant bit of the branch target address is 0, this indicates a branch back to a less secure domain. Alternatively, in some implementations, a branch requesting a transition from a secure domain to a less secure domain can be indicated by the use of a dedicated domain transition branch instruction (which may be referred to as BXNS). The dedicated domain transition branch instruction may be detectable by a different opcode value than other types of branch instructions, or may have the same opcode as other types of branch instructions but a parameter value indicating that a transition from a secure domain to a less secure domain is requested. Some implementations may combine the two approaches so that a transition request from a secure to a less secure domain requires both the least significant bit of the branch target address to be 0 and the use of a dedicated domain transition instruction.

[0151] If the branch does not require a secure-to-less secure branch, then in step 404, the branch may be processed normally, the program counter register R15 is updated based on the branch target address specified by the branch instruction, and program flow continues executing instructions at the branch target address (in the same domain as before the branch was executed). It will be appreciated that in some implementations, not all types of non-function call branches may be used for function returns. For example, a branch that determines its target address based on an immediate value encoded in the instruction opcode may always branch to the same location and therefore may not be suitable for a function return branch where program flow must branch back to various different functions that called the function from which it returned. To simplify design, some implementations may choose to only perform the steps described in FIG. 14 for a subset of non-function call branches that can be used to perform a function return. As noted above, there may be many types of instructions that can have the effect of executing a branch, even if the instruction is not a dedicated branch instruction (e.g., even a load instruction that writes a value loaded into the program counter). The steps described in FIG. 14 may also be applied to at least a subset of such non-branch instructions that have the effect of executing a branch.

[0152] If, in step 402, it is determined that the branch is a secure to less secure branch, then in step 406 the processing circuitry checks whether the current mode is Thread mode and whether the domain transition disable configuration parameter (TMID) is 1, indicating that inter-domain transitions are disabled in Thread mode. If the current mode is Thread mode and the TMID indicates that domain transitions are disabled in Thread mode, then in step 408 an INVTMI UsageFault is triggered which is handled in the secure domain. This allows the secure operating system managing the secure thread to configure any MPU or stack resources as necessary to allow the secure thread to also run in the less secure domain.

[0153] Alternatively, if step 406 determines that the current mode is handler mode or the TMID value 34 in control register 32 is 0 to indicate that domain interstating is enabled, then in step 410 the security domain is switched to the less secure domain (NS), and then in step 404 a branch to the target address is executed as described above.

[0154] If, in step 400, it is determined that the target address is within the reserved range, this indicates that the branch may be intended to represent either a function return or an exception return. In step 412, execution stage 12 of processing circuit 4 determines whether the target address of the branch is one of valid dummy function return addresses 140, as indicated in its most significant bit portion by a function return prefix 144. If the target address is one of valid dummy function return addresses 140, then in step 414, function return branch processing is performed, which is described in more detail with reference to Figure 15 below.

[0155] Alternatively, if the target address of the branch is not one of the valid dummy function return addresses, then in step 416, it is determined whether the target address is one of the valid dummy exception return addresses 142, as shown in Figure 5. If not, the address represents a non-executable instruction address and is not a dummy address used to signal an exception function return, so the attempt to branch to the target address is an error and a fault may be triggered in step 418. Alternatively, instead of directly triggering a fault in response to detecting that the branch is to a non-executable address, the branch may be executed normally, setting the program counter register to the branch target address (so that Figure 14 transitions from step 416 to step 404 for a "N" determination in step 416), and then when the instruction fetch circuitry 8 attempts to fetch an instruction from the non-executable address, this may signal a fault. Thus, the generation of a fault may be indirectly caused by the branch but may not be directly signaled in response to the branch instruction itself. Either approach may be effective.

[0156] If, in step 416, it is determined that the target address is one of the valid dummy exception return addresses 142, then in step 420, a cross-check comparison is made between the TMIE flags 158 in the dummy exception return address 142 and the TMIE cross-check information 190 saved as part of the call stack frame 182, at least if the exception return involves a transition from a less secure domain to a secure domain (which can be determined from the security domain flags 156 in the dummy exception return address). If a mismatch is detected, in step 422, a fault is triggered, as this may indicate that an attempt has been made to tamper with the TMIE flags 158 in the link register, or alternatively, that an inadvertent error has occurred. If the TMIE flags 158 match the cross-check information 192, or the exception return transition is one that does not require this cross-check, the method proceeds to step 424, where the exception return is processed.

[0157] The exception return processing in steps 420 and 424 may also include other operations as described in the above-referenced PCT Publications WO 2013 / 117899 and WO 2014 / 053804. Prior to checking the TMIE value in step 420, the exception return processing in step 424 may include unstacking the register state from the stack to registers 14. The determination of whether the unstacking should include unstacking only the caller stack frame 180 or both the caller and callee stack frames 180, 182 can be made based on status flags that may be stored as part of the exception return value 142 when the exception is taken. See Figure 13 of WO 2013 / 117899 or Figure 13 of WO 2014 / 053804 for details on determining which registers need to be unstacked.

[0158] Exception return processing may also include checking whether a predetermined signature 190 is expected to be present on the stack as part of the callee stack frame 182. This may be determined according to FIG. 14 of WO 2014 / 053804. If the predetermined signature 190 is expected to be present but the contents of the location on the stack compared to the predetermined signature do not match, a fault may be triggered, as this may detect an instance where an exception return mechanism was attempted based on a stack frame saved in response to a function call. The occurrence of the fault is illustrated in FIG. 7 of WO 2014 / 053804.

[0159] The exception return handling operations may also include other operations such as updating the restored exception number value 36 based on the ERETPSR value in the loaded stack frame and changing the exception priority level based on the priority of the process being returned to.

[0160] Additionally, in step 424, the TMID value 34 in the control register 32 may be restored based on the TMIE flag 158 contained in the branched dummy exception return address. The restored value of the TMIE flag 34 may correspond to the inverse of the value of the TMIE flag 158 to indicate whether domain transitions in thread mode should be enabled or disabled to match the value that the TMID 34 had before the corresponding exception was taken. It will be appreciated that many other operations may be performed in handling the exception return that are not described here.

[0161] 15 shows in more detail the operations performed for a branch to a function return address in step 414 of FIG. 14. In step 440, the processing circuit determines whether the dummy function return address 140 detected as the branch target address of the branch indicates an intermodal function return. For example, this may be a check whether the intermodal indicator 146 is 0 to specify that the corresponding function return value was set in an intermodal call from a handler to a thread mode. If the attempted function return is not an intermodal function return, it is an inter-domain function return (because if the corresponding function call was neither an intermodal nor an inter-domain call, the link register would simply be set to the function return address and there would have been no need to use a dummy function return address).

[0162] In step 442 for an inter-domain function return, a check is performed on the thread mode transition disable flag TMID 34. If the current mode is thread mode and TMID flag 34 is 1 to indicate that domain transitions are disabled in thread mode, then in step 444, INVTMI UsageFault is triggered again, similar to step 308 of Figure 12 or step 408 of Figure 14. However, in step 444, the INVTMI fault is handled regardless of which domain was current at the time the fork was attempted (i.e., the source domain where the inter-domain function return is being attempted, rather than the secure domain as in steps 308 and 408). This ensures that the process responsible for managing the thread that requested the fork can handle the fault and configure the necessary resources in the destination domain, if necessary.

[0163] If, in step 442, it is determined that the current mode is Handler mode or the TMID flag 34 is zero, indicating that the transition is enabled, then in step 446 the branch can be allowed to proceed. The function return address 174 to which the branch is taken is read from the associated stack, which is determined based on the current operating mode, the transitioned security domain, and, if in Thread mode, the stack pointer selection value 30. Necessary integrity checks are performed to verify whether the inter-domain transition is allowed. These integrity checks can include, for example, checking whether the exception number 179 in the function return stack frame 172 indicates that the stack frame was created in the same mode as the current operating mode (i.e., exception number 179 is zero if the current operating mode is Thread mode and non-zero if the current operating mode is Handler mode), as well as whether the HDT flag 178 is zero, as expected for an inter-domain function return. Any other requirements that limit the domain transitions that are allowed can also be checked. If the integrity checks pass, the branch to function return address 174 is allowed and succeeds, after which subsequent processing continues from the instruction fetched from function return address 174 (this is the real function return address loaded from function return stack frame 172, not the dummy function return address 140 that was actually specified as the target address of the attempted branch encountered in step 400 of FIG. 14). The stack pointer that points to function return stack frame 172 can be adjusted to account for the unstacking and removal of the function return stack frame from the stack data structure. If any of the required integrity checks fail, a fault is signaled (this can be a security fault that can be handled in the secure domain).

[0164] If, in step 440, it is determined that the attempted function return is an intermodal function return, then, in step 450, the processing circuit determines whether the current domain is a less secure domain and the security domain indicator 148 in the dummy function return address 140 indicates that a return to a secure domain is requested. If this is the case, then, in step 452, an INVPC usage fault is triggered that should be handled in the current domain (the less secure domain). This fault is triggered to prevent a prohibited combined domain / mode transition from a less secure thread mode to a secure handler mode, as shown in Figure 9 above, which could otherwise cause a security vulnerability.

[0165] If the attempted intermodal function return is not from a less secure domain to a secure domain (either remaining within the same domain or from a secure domain to a less secure domain), the method proceeds to step 454, where an error synchronization barrier operation is triggered, if configured, similar to step 328 of Figure 12. Again, by triggering an error synchronization barrier on the intermodal function return, this can help identify errors to reduce the need for an intrusive system reset operation if the error may be due to less privileged processing running before the intermodal function return.

[0166] In step 456, in response to the intermodal function return instruction, the processing circuit loads the function return stack frame 172 from the main stack associated with the destination security domain to which the return is being made. In step 458, the processing circuit performs an integrity cross-check operation and determines whether the result of the integrity cross-check is successful. This integrity cross-check may check several items on the function return stack frame. For example, the processing circuit may check whether the function return address 174 is one of the reserved address ranges 130. If the function return address is one of the reserved address ranges, this may be an indication that the function return is attempted based on a stack frame that is actually an exception stack frame that includes a predetermined signature 190 at the same relative location on the stack as the function return address 174 in the function return stack frame 172; this mismatch between the exception and function entry and return may be an avenue for attack. Thus, if the function return address 174 on the stack frame is a reserved address 130, the integrity cross-check fails.

[0167] Also, as part of the integrity cross-check, the processing circuitry checks whether the current mode is thread mode based on the exception number value 36 in control register 20. If the current mode is handler mode, the integrity cross-check fails.

[0168] The integrity cross-check also includes checking the exception number field 179 in the function return stack frame, and if it is zero, triggers the integrity cross-check to fail because an intermodal function return is expected from thread mode back to handler mode.

[0169] The integrity cross-check also uses HDT flag 178 to detect whether the function return stack frame was saved in response to an intermodal call branch instruction. If the HDT flag is 0, this indicates that the function return stack frame was set up in response to an inter-domain function call rather than an intermodal function call (see step 312 of FIG. 12 ), and therefore the integrity cross-check fails. Again, this prevents mismatched function call and return sequences, limiting the opportunity for attacks based on stack frame mismatches, and also protects against potential modification of the intermodal flag 146 in the dummy function return address 140 while it is saved in the publicly accessible link register; the HDT flag 178 serves as a cross-check value to check that the intermodal flag is correct.

[0170] If any of the integrity cross-checks fail, then in step 460 a security check failure occurs and an INVPC usage fault is triggered indicating that this type of fault should be handled in the destination security domain associated with the code attempting the branch.

[0171] Alternatively, if all integrity cross-checks pass, an intermodal function return can be effected in step 462. When the intermodal function return is executed, several actions are performed in step 462. The security state is updated to the security state indicated by the security domain indicator 148 in the dummy function return address 140. This ensures that the security domain is restored to the domain that was executing before the corresponding intermodal function call was made.

[0172] Also, in step 462, before the intermodal function return, an indication is saved to record whether the TMID flag 34 was 0 or 1. This indication is separate from the TMIE flag 158 that is saved in the exception entry. The location where the indication of the previous value of the TMID is stored may vary from embodiment to embodiment. For example, the indication may be saved in a general purpose register 16 or in a control register 20, such as a condition flag in the flags register, that can be directly tested by a subsequent conditional instruction.

[0173] Also, in step 462, the TMID value 34 in control register 32 may be set to 0 to indicate that thread mode domain transitions are re-enabled. This ensures that the domain transition disable configuration value 34 can be in a consistent state upon return to the more privileged wrapper code, regardless of whether any unprivileged sections of exception handler code executed before the intermodal function return attempted to switch security domains.

[0174] Also, in intermodal function return step 462, the destination stack pointer into which the function return stack frame was loaded may be adjusted to account for the unstacked data removed from the stack. Also, the destination domain's stack pointer selection value 30 is updated to indicate that the main stack pointer should be selected, and the current operating mode is switched to handler mode by restoring exception number register 36 from exception number field 179 in function return stack frame 172 (the previous integrity check in step 458 may have checked that exception number field 179 was non-zero, so that restoring exception number register 36 would switch the current mode to handler mode). In step 464, a branch is executed to the real function return address 174 obtained from function return stack frame 172, so that the next instruction processed is the instruction at the function return address.

[0175] Thus, by using a dummy function return address 140 that is saved when calling a function (the body of ISR 201) to signal whether a subsequent function return should be an intermodal function return, this means that the instruction that triggers the function return itself does not need to be aware of whether it is switching modes, which means that legacy exception handler code that was written without any awareness of support for intermodal function calls and returns can still be used. This is particularly useful for the disabled interrupts scenarios described with respect to Figures 7 and 8 above. That is, the function return branch instruction can have the same encoding whether it is an intermodal branch or not.

[0176] 14 and 15, it should be noted that the instruction that triggers a branch to a given target address can be any of a variety of instructions that modify the program counter register R15 to the branch target address. In some cases, this may be a dedicated branch instruction, but it may also be a register move instruction that moves the branch target address to the program counter register, or a stack pop instruction that pops information from a stack data structure and loads it into the program counter register. In particular, if the branch is to one of a dummy function return address 140 or a dummy exception return address 142, which may end up being saved on the stack if an additional function call is made before the corresponding function / exception return, it may be more efficient for the compiler to generate code that pops the return address directly from the stack frame to the program counter register rather than first loading the return address into the link register and then executing a return branch specifying the link register. Thus, it will be appreciated that while the real function return address, dummy function return, or dummy exception return address may initially be saved in the link register when calling a function or taking an exception, by the time the corresponding return is executed, it may no longer be in the link register, and the instruction that triggers the branch operation in FIGS. 14 and 15 need not actually be a dedicated branch instruction.

[0177] 16A-16D show examples of possible attacks that can be prevented using the checks described above. These attacks can be based on mismatched sequences of exceptions or function calls and returns, and can attempt to take advantage of mismatched stack frames set up by the call and expected on return.

[0178] In the example of FIG. 16A , an exception occurs in step 1 during processing in secure handler mode, and because the exception is taken in the less secure domain, both the caller and callee stack frames 180, 182 are saved on the stack. In step 2 of FIG. 16A , a series of exception returns and / or function calls are made, ultimately resulting in processing in secure thread mode. Once in secure thread mode, in step 3, an attempt is made to perform an intermodal function return based on the exception stack frames 180, 182 established in step 1. For example, this can be done by branching to one of the dummy function return values ​​140. This type of attack can be detected because the integrity cross-check check of step 458 of FIG. 15 on the function return detects that the function return address 174 is one of the reserved address ranges of addresses 130 (because the predetermined signature 190 is at the bottom of the exception stack frame loaded in step 3, not the expected function return stack frame 172).

[0179] Figure 16B shows a second example in which, in step 1, an inter-domain function call is made from a secure domain to a less secure domain and a function return stack frame 172 is saved on the secure main stack. Again, in step 2, a series of other transitions are performed, and then in step 3, an intermodal function return is attempted based on the inter-domain stack frame established in step 1. This intermodal function return should not be allowed to succeed because the corresponding call was an inter-domain call, not an intermodal call. This is detected because the HDT value 178 in the function return stack frame was set to 0 for the inter-domain function call in step 1 and should be 1 for the intermodal function return in step 3; therefore, the integrity cross-check in step 458 of Figure 15 fails.

[0180] FIG. 16C illustrates another potential attack in which an intermodal function call is first made in step 1, which deprivileges from handler mode to thread mode, then a series of other transitions are made in step 2, followed by an attempt to perform a cross-domain function return in step 3, which transitions from a secure domain to a less secure domain based on the intermodal function return stack frame established in step 1. In step 446 of FIG. 15, an integrity check is performed to see if the HDT value 178 in the function return stack frame 172 is equal to 0, and if the HDT value is equal to 1, a fault may be triggered. Thus, in the scenario of FIG. 16C in which an intermodal function call is made and a cross-domain function return is attempted, the HDT check will detect a mismatch, ensuring that the intermodal stack frame created in step 1 cannot be considered a cross-domain stack frame in step 3. Note that the HDT checks in steps 446 and 458 can be thought of as equivalent to a comparison between the intermodal flag M 146 in the dummy function return address and the HDT flag 178 in the function return stack frame, and any mismatch identified in this comparison will trigger a fault in either the case of an intermodal return (FIG. 16B) or an inter-domain return (FIG. 16C).

[0181] Continuing with reference to FIG. 16C, instead of performing an inter-domain return (with intermodal flag M=0) in step 3, an attacker could attempt an intermodal function return (with intermodal flag M=1). Although the corresponding function call was in fact an intermodal call, it would not match the attempted intermodal function return because the current mode before step 3 was Handler mode, not Thread mode. In this case, the intermodal call value 146 may match the HDT value 178 in the function return stack frame that was set for the intermodal call in step 1, but an intermodal function return is not allowed when the current state is Handler mode, and this would be caught by the integrity check of step 458 of FIG. 15, which checks whether the current mode is Thread mode, thus preventing the attack.

[0182] 16D shows another example in which an inter-domain branch instruction from a secure domain to a less secure domain causes an inter-domain stack frame to be set up in step 1, followed by a series of transitions in step 2 back to the secure domain, and then an attempt in step 3 to perform an intermodal function return using the stack frame set up by the inter-domain branch in step 1. This type of attack cannot succeed because the exception number field 179 in the function return stack frame 172 indicates that the stack frame set up in step 1 was set to Thread mode rather than Handler mode, which the intermodal function return requires entry into. Alternatively, if a transition of the domain and mode combination from non-secure Thread mode to secure Handler mode were attempted, as shown in step 2', this would again fail because step 450 prevents the disallowed combination of transitions.

[0183] It will be appreciated that some checks may overlap, and that the same type of attack may trigger the failure of more than one type of check. In some architecture implementations, if some of these checks are deemed redundant, they may be excluded from the architecture requirements; thus, it is not necessarily required to implement all of the different types of attack prevention mechanisms, depending on what is deemed important to protect against. However, any one or more of these checks may be provided. It will be appreciated that the attack shown in FIG. 16 is just a small subset of a vast number of different combinations of similar mismatch-type attacks, in which an attacker attempts to corrupt the state of a system by attempting a return behavior (either a function or exception return) that does not match the original transition, and therefore the type of stack frame, that was created.

[0184] Steps 307, 406, and 442 in Figures 12, 14, and 15 illustrate specific examples of checking the domain transition disable configuration parameter (TMID) 34 for function call branches, non-function call branches, and function returns, respectively. However, in some architectures, there may be other valid means by which a transition between domains can be triggered, and Figure 17 illustrates a more general approach for handling the checking of TMID values. In step 500, a possible attempt to perform either a secure-to-less-secure domain transition within the current mode, or a less-secure-to-secure domain transition within the current mode, is detected. This attempt may be an actual attempt to perform a domain transition, or it may be an operation that may trigger such a domain transition if other security or integrity checks pass, but that does not always trigger a domain transition if the TMID check is performed early enough that it cannot yet detect whether the domain transition is actually allowed or whether another check will fail and cause a fault.

[0185] In step 502, if an attempt to trigger a domain transition is detected, it is determined whether the current mode is threaded mode. If the current mode is threaded mode, in step 504, the processing circuit determines whether the TMID value 34 indicates that domain transitions are disabled in threaded mode. If the current mode is threaded mode and domain transitions are disabled in threaded mode, an disable domain transition fault (e.g., the INVTMI UsageFault described above) is signaled in step 506. Faults are handled in the current security domain before the attempted domain transition is acted upon, so that if the attempted domain transition is from secure to less secure, the fault is handled in the secure domain, and if the attempted transition is from less secure to secure, the fault is handled in the less secure domain. Additionally, in some cases, some syndrome information can be stored in a control register that indicates information about the attempted transition that caused the fault. In some implementations, setting the syndrome information can include setting an INVTMI bit in a UsageFault Status Register (UFSR).

[0186] If step 502 determines that the current mode is Handler mode, or if step 504 detects that TMID value 34 indicates that a domain transition is possible in Thread mode, the method proceeds to step 508, where, at least if the attempted transition is from a less secure domain to a secure domain, it checks whether any other required security checks have passed, and if so, the transition is allowed in step 510. If no security checks are required (e.g., checks may not be required for some types of secure domain to less secure domain transitions because secure code can be trusted not to attack less secure code), the transition may be allowed in step 510 without performing a security check (i.e., step 508 may be omitted for such transitions). Alternatively, if the security check fails, a fault may be triggered in step 512, which may be handled in the secure domain because it relates to an unauthorized entry or exit from a secure state. The type of fault triggered in step 512 and any syndromes set may depend on the type of security check that failed.

[0187] Although FIG. 17 shows steps 502 and 504 being performed sequentially, in some instances they may be performed in the reverse order or in parallel.

[0188] 18-20 show several example use cases involving TMID value 34. FIG. 18 essentially corresponds to the example of FIG. 8, which includes an intermodal call, such that the exception handler is deprivileged to include body 201, which is processed in thread mode. In this example, the exception is a non-secure (also known as less secure) exception, so the exception handler processing, including wrapper 203 and body 201, is entirely within the less secure domain. Any thread that crosses the secure / less secure domain boundary may need to establish both secure and less secure resources (such as the MPU configuration and stack pointers for associated stack structures allocated in memory). For threads such as T2 shown in FIG. 18 that operate only in one domain, it may be desirable to avoid allocating resources in the other domain to avoid wasting memory and increasing context switch time. Therefore, preferably, the system can avoid the cost of allocating additional resources to all threads, regardless of whether the additional resources are used. This ability to not configure both secure and less secure resources for all threads can also help improve interrupt latency for interrupts that need to be de-privileged to return to thread mode as shown in FIG. 18, which means that the wrapper code 203 takes less time to execute since it can avoid configuring either a secure or non-secure MPU and either a secure or non-secure stack pointer.

[0189] One approach to handling this might be to allocate a thread the stack and MPU configuration for a single security state (e.g., the less secure domain in the example of Thread 2 in FIG. 18 ) and then allocate resources from the other domain only if the thread attempts to switch to that other security domain. However, without the TMID parameter 34, the only way to accomplish this and generate the fault necessary to trigger the delayed allocation is to reconfigure the MPU 26, which would result in an address fault being generated if the process attempts to access an address that it does not have permission to access or whose region permission data is not defined for the MPU 26. This is a disadvantage because the MPU configuration must be handled per thread rather than per process, and because it involves the MPUs 26-S and 26-NS of both security domains, significantly more secure / non-secure interaction is required, negating the benefit of being able to skip the MPU configuration operation for one of the security domains. For example, before executing a secure thread, the less secure operating system might need to reconfigure the less secure MPU 26-NS so that any attempt to branch to a less secure state would result in a fault. Thus, using the MPU 26 to generate a fault can be difficult and performance intensive, and difficult to code for different parties providing secure and less secure operating system code. Alternatively, if it is known in advance which threads will use only one security domain and which will use both, this information can be used to avoid delayed allocation, but this cannot be relied upon as the software may crash and attempt to access the other state, or an attacker may attempt to exploit this, so it may still be desirable to provide a mechanism for generating a fault on detection of a transition to the other domain when the resource is configured only for one domain.

[0190] Instead, by providing a TMID parameter 34 that selectively disables domain transitions in thread mode, this means that a thread that is expected to be only in the less secure domain (as in the case of T2 in Figure 18) can initially have its TMID parameter 34 set to disable domain transitions, and then only if it attempts to switch domains can it generate a fault so that the appropriate resources can be configured.

[0191] 18 thus illustrates an example in which thread mode transition is disabled upon entry into the non-privileged exception handler body 201 (because the BLXT variant of the intermodal call branch instruction is used to invoke the exception handler body 201). In this case, the exception handler body 201 remains in the less secure domain and does not attempt to switch to the secure domain; as a result, by the time the body 201 later returns function to the wrapper code 203, no processing resources or memory allocations have been wasted in configuring the secure domain's MPU or stack resources for thread T2. This therefore improves performance. Once processing of the body 201 is complete, a branch is executed in step 604 to the intermodal dummy function return address 140. This triggers a return to handler mode, which, in some implementations, may cause the indication of the TMID flag 34 in the control register 32 to be saved (e.g., in a general-purpose register) before being cleared as described in step 462 of FIG. 15. Program flow then returns to wrapper 203, where the wrapper checks the saved indication of TMID flag 34 and determines that TMID flag 34 was 1 prior to the intermodal function return in step 604. Thus, wrapper 203 determines that resources associated with the secure state are still configured for background thread T2, and that these resources do not need to be reconfigured before performing the exception return, returning to background processing of T2.

[0192] Figure 19 shows a similar scenario, but in this case, after invoking the non-privileged exception handler body 201 using the BLXT instruction, thus disabling inter-domain transitions while in thread mode, the body now attempts to switch to the secure domain, which triggers a usage fault as described above. This fault causes an exception to be handled by handler code 608 in handler mode, which may then request allocation or configuration of resources for thread T2 in secure MPU 26-S and a secure stack pointer register, before returning to exception handler body 201 and retrying the less-secure to secure domain transition at point 600 in Figure 19. (The gap between the point at which processing returns to non-secure T2 and inter-domain transition 600 is exaggerated in Figure 19 for clarity; it will be understood that inter-domain transition 600 may actually occur at the first instruction after returning to T2.) After finishing the section of processing that requires being in the secure domain, an inter-domain return may be performed at point 602, and subsequent processing is the same as in Figure 18.

[0193] FIG. 19 illustrates a scenario in which the execution of the intermodal return at portion 604 of FIG. 19 stores an indication of whether the TMID value 34 of the thread mode non-secure processing executed for thread T2 was 0 or 1 prior to the intermodal return for the transition from non-privileged exception handler body 201 back to wrapper code 203. This is done before clearing the TMID flag of the intermodal return to re-enable the domain transition of wrapper code 203. As discussed above in step 462 of FIG. 15, this indication of whether TMID 34 was zero or was prior to step 604 of FIG. 19 can be saved in any convenient location, such as a control register, a general-purpose register, or one of the condition codes. This is useful because it allows subsequent code at 610 to distinguish the situation shown in FIG. 18 from the situation shown in FIG. 19 once processing is returned to non-secure wrapper code 203 to be processed in handler mode. As in the scenario shown in Figure 18, because there was no processing in the secure domain, the secure stack pointer and MPU configuration may remain as previously set at point 606 during previous processing of background code in the secure domain. In contrast, in Figure 19, the attempted entry of thread T2 into the secure domain at step 601 (which subsequently succeeded when retried at step 600) means that the configuration of thread T2's MPU / stack resources at point 608 in Figure 19 has modified the associated MPU contents and stack pointer registers for the thread mode. Thus, the remaining wrapper code 203 executed at portion 610 in Figures 18 and 19 may need to determine whether it needs to update the secure stack pointer and secure MPU configuration to restore the information that was present in portion 606 before returning processing to the secure portion of thread T1. To make this determination, an indication of whether TMID is 0 or 1 prior to step 604 in the intermodal function return can be used.

[0194] In other implementations, an indication of whether the domain transition was disabled or enabled in Thread mode before the intermodal return to be preserved is not required, in which case in step 610 of Figures 18 and 19, wrapper code 203 can simply always perform the operations to restore the secure resources that were present in step 606. However, the example shown in Figure 19, which preserves an indication of whether the thread mode transition was disabled, can improve performance by avoiding redundant stack pointer update operations when not necessary.

[0195] For comparison, Figure 20 shows another scenario where, once the IRQ exception handler is deprivileged, it is now expected that the exception handler will use both the secure and less secure domains, so during wrapper code 203 executed at point 620, appropriate actions are taken to configure secure and less secure resources for both domains, and the body of the exception handler 201, which runs unprivileged in Thread mode, is called with the BLXTI variant of the intermodal function call branch instead of BLXT as in Figures 18 and 19. Thus, upon execution of the intermodal function call from Handler mode to Thread mode, TMID value 34 is set to 0 to indicate that domain transitions are enabled in Thread mode, so that in step 622 when the interrupt handler body attempts to transition to the secure domain, this is allowed and no fault is required as in the example of Figure 19. Again, saving an indication that the TMID was 0 before the intermodal return in intermodal function return 64 can be used by wrapper code 203 executed in 626 to determine that the secure side stack pointer or MPU configuration associated with thread T1 needs to be restored to the state it was in at point 628 before the interrupt occurred. In some implementations of the wrapper code, wrapper code 203 may not check the indication of the TMID flag saved during the intermodal function return in the example of FIG. 20 because the wrapper performed configuration of both domains before executing body 201 and therefore knows in advance that it needs to restore resources for both domains before returning to background thread T1. This may be a simpler approach than redundantly checking the indication of the TMID saved during intermodal function return, but may mean that sharing code between different wrappers for different exception handlers is more difficult. Thus, both approaches may be useful.

[0196] FIG. 21 shows another example of a more specific scenario in which checking the TMID value 34 in an attempt to switch domains may be useful. This is another specific example within the general approach of FIG. 17. Another way in which a domain transition may occur is when a less secure domain attempts to fetch an instruction from an address in one of the secure address regions defined by the SAU 24. In step 700, the instruction fetch circuit 8 determines whether the current domain is the less secure domain and whether there was an attempt to fetch an instruction having an address in one of the secure regions defined by the SAU 24. If not, instruction fetching continues normally. If the current domain is the less secure domain and an instruction is being fetched from a secure address region, in step 702, it is checked whether the current mode is thread mode, and the transition disable flag (TMID 34) indicates that domain transitions in thread mode are disabled. If so, in step 704, an INVTMI UsageFault is triggered to prevent the domain transition from occurring. This fault is handled in the current domain, i.e., the less secure domain. Note that a fault is generated conservatively, assuming that an instruction fetched from a secure address region may not actually have triggered a domain transition, but that the transition may nevertheless occur if subsequent security checks pass. By generating the fault in fetch stage 8, this ensures that a UsageFault triggered by an invalidated domain transition is evaluated relatively early compared to other types of security checks that may need to be performed, so that those other security checks do not fail simply because the secure resource has not yet been configured.

[0197] On the other hand, if in step 702 fetch stage 8 determines that the current mode is handler mode, or if TMID 34 indicates that thread mode domain transitions are enabled, instruction fetching is allowed to continue in step 706. If an instruction fetched from a secure address space is identified in decode stage 10 as an instruction that triggers a domain change (e.g., a secure gateway instruction that marks a valid entry point into the secure domain), additional security checks are performed when the instruction reaches execution stage 12, and if these checks are passed, a transition to the secure domain is allowed.

[0198] Thus, FIG. 21 is an example in which the checking of TMID value 34 is not necessarily performed in execution stage 12, but may be performed on instruction fetch.

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

[0200] While embodiments have been described above with reference to particular hardware configurations or functions, equivalent functionality may be provided in simulated embodiments through appropriate software configurations or functions. For example, particular circuits may be implemented as computer program logic in simulated embodiments. Similarly, memory hardware such as registers or caches may be implemented as software data structures in simulated embodiments. In arrangements where one or more of the hardware elements referenced in the foregoing embodiments reside in host hardware (e.g., host processor 830), some simulated embodiments may use the host hardware where appropriate.

[0201] Simulator program 810 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (an instruction execution environment) to target code 800 (which may include an application, an operating system, and a hypervisor), which program interface is the same as the application program interface of the hardware architecture being modeled by simulator program 810. Thus, program instructions of target code 800, including the intermodal call branch instruction described above, may be executed from within an instruction execution environment using simulator program 810, allowing host computer 830, which does not actually have the hardware functions of device 2 described above, to emulate these functions.

[0202] 22, the simulator program 810 includes instruction decode program logic 811, processing program logic 812, exception control program logic 813, and memory access check program logic 814, which perform functions equivalent to the instruction decoder 10, execution stage 12, exception control circuitry 28, and memory access check circuitry 22 described above. The instruction decode program logic 811 decodes instructions in the target code 800 and, depending on the encoded instruction type, selects one of several program code sequences in the processing program logic 812 that controls the host hardware 830 to perform operations equivalent to those defined in the simulated instruction set architecture for the decoded instructions in the target code 800. When a simulated exception occurs, the exception control program logic 813 controls exception handling in a manner similar to the exception control circuitry 28 described above. The simulator program 810 also includes register emulation program logic 815 that maps register references required by instructions in the target code 800 to equivalent memory accesses in the host memory address space used by the host device, so that a data structure can be maintained in the host memory address space corresponding to the contents of registers 14 of the target data processing device being simulated by the simulator program. Similarly, memory access program logic 817 maps memory accesses and instruction fetches required by target code 800, which are defined using addresses from simulated address space 816, into the host memory address space used by host data processing hardware 830. For example, memory access program logic 817 may control accesses to a stack data structure 818 that is actually stored in the host memory address space, but from the perspective of target code 800, appears to be stored in simulated address space 816.

[0203] Thus, the control registers emulated by the register emulation program logic 815 may include the above-described TMID flag 34, and the processing program logic 812 may simulate whether an inter-domain transition in thread mode is allowed based on the TMID flag 34. The register emulation program logic 815 may include configuration parameter setting program logic 819 that sets the TMID flag 34 in response to an event such as the execution of an intermodal function call and return, an exception entry or return, or other instruction to write to the TMID flag 34. Also, the instruction decode program logic 811 may switch the current mode of the simulated processor represented by the processing program logic 812 from handler mode to thread mode in response to an intermodal call branch instruction, as described above.

[0204] In this application, the term "configured to..." is used to mean that elements of an apparatus have a configuration that allows them to perform a defined operation. In this context, "configuration" refers to a way of arranging or interconnecting hardware or software. For example, an apparatus may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to" does not imply that an apparatus element must be modified in some way to provide the defined operation.

[0205] Although exemplary embodiments of the present 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 embodiments, and that various changes and modifications can be made by those skilled in the art without departing from the scope and spirit of the invention as defined by the appended claims.

Claims

1. 1. An apparatus comprising: processing circuitry for performing data processing in one of a plurality of modes including at least a handler mode and a thread mode; an exception control circuit that controls the processing circuit to switch to processing of an exception handler in the handler mode in response to an exception condition; an instruction decoder for controlling said processing circuitry to decode instructions for performing said data processing; Equipped with and in response to an intermodal call branch instruction specifying a branch target address, at least when the processing circuitry is in the handler mode, the instruction decoder controls the processing circuitry to: saving the function return address in a function return address location; switching the current mode of the processing circuitry to the threaded mode; Branch to the instruction identified by said branch target address The apparatus is configured to:

2. the processing circuitry is configured to perform the data processing in one of a plurality of security domains, the security domain including at least a secure domain and a less secure domain; the apparatus comprises a memory access check circuit for checking whether a memory access is permitted according to a current security domain of the processing circuit; 2. The apparatus of claim 1, wherein in response to a cross-domain call branch instruction specifying a branch target address, the instruction decoder is configured to control the processing circuit to save the function return address to the function return address location, branch to an instruction identified by the branch target address, and switch a current security domain of the processing circuit.

3. 3. The apparatus of claim 2, wherein in response to the intermodal call branch instruction, the instruction decoder is configured to control the processing circuit to switch the current mode of the processing circuit to the threaded mode without changing the current security domain of the processing circuit.

4. in response to an intermodal function return instruction, the processing circuitry is configured to switch the current mode of the processing circuitry to the handler mode and branch to an instruction identified by the function return address; 4. The apparatus of claim 2 or 3, wherein in response to the intermodal function return instruction, the processing circuitry is capable of performing a combined domain / mode switch from processing in a first security domain and in the thread mode to processing in a second security domain and in the handler mode.

5. In response to the intermodal function return instruction, the processing circuitry: permitting the combined domain / mode switch if the first security domain is the secure domain and the second security domain is the less secure domain; prohibiting the combined domain / mode switch when the first security domain is the less secure domain and the second security domain is the secure domain; 5. The apparatus of claim 4, wherein the apparatus is configured to:

6. 6. The apparatus of claim 1, wherein in response to the intermodal call branch instruction, the instruction decoder is configured to trigger fault signaling if the current mode of the processing circuitry is the threaded mode.

7. In response to a function return instruction, the processing circuitry: branching to an instruction identified by said function return address; Also, if the function return instruction is an intermodal function return instruction, the current mode of the processing circuit is switched to the handler mode.

7. The device according to claim 1, wherein the device is configured to:

8. 8. The apparatus of claim 7, wherein in response to the intermodal function return instruction, the processing circuitry is configured to trigger fault signaling if the current mode of the processing circuitry is the handler mode.

9. for at least one call branch instruction other than said intermodal call branch instruction, said function return address location comprises a link register; The apparatus of claim 1 , wherein for the intermodal call branch instruction, the function return address location comprises a location on a stack data structure.

10. in response to the intermodal call branch instruction, the instruction decoder is configured to control the processing circuitry to cause a dummy function return address to be stored in the link register, the dummy function return address including an intermodal call indication value indicating that the dummy function return address was stored in response to the intermodal call branch instruction; 10. The apparatus of claim 9, wherein in response to at least one type of instruction attempting to branch to the dummy function return address when the dummy function return address includes the intermodal call indication value, the processing circuitry is configured to branch to an instruction identified by the function return address obtained from the location on the stack data structure and switch the current mode of the processing circuitry to the handler mode.

11. The dummy function return address is whether a switch from a thread mode to a handler mode is requested in response to the at least one type of instruction attempting to branch to the dummy function return address; whether a switch in the current security domain of the processing circuitry is requested in response to the at least one type of instruction attempting to branch to the dummy function return address; which of a plurality of stack data structures should be used as the stack data structure from which the function return address is obtained in response to the at least one type of instruction attempting to branch to the dummy function return address; 11. The apparatus of claim 10, wherein the apparatus exhibits at least one of:

12. the dummy function return address portion indicates whether a switch within the current security domain of the processing circuit is required in response to the at least one type of instruction attempting to branch to the dummy function return address; and in response to a secure gateway instruction when the current security domain is the secure domain, the instruction decoder is configured to set a portion of a return address to a value indicative of a less secure state; 11. The apparatus of claim 10, wherein the portion of the return address and the portion of the dummy function return address are at the same relative position within their respective return address values.

13. 13. The apparatus of claim 12, wherein the portion of the dummy function return address is the least significant bits.

14. in response to the intermodal call branch instruction, the instruction decoder is configured to control the processing circuitry to store a cross-check value at least in part at a first relative position within a stack frame stored in the stack data structure; 14. The apparatus of claim 10, wherein in response to the at least one type of instruction attempting to branch to the dummy function return address, the processing circuitry is configured to perform a comparison between a portion of the dummy function return address for encoding the intermodal call indication value and a value of the at least a portion of the first relative position in the stack frame obtained from the stack data structure, and determine whether to trigger fault signaling based on the comparison.

15. 15. The apparatus of claim 14, wherein in response to at least one type of call branch instruction other than the intermodal call branch instruction, the instruction decoder is configured to control the processing circuitry to preserve a value other than the crosscheck value in the at least some of the first relative positions in the stack frame saved in the stack data structure.

16. in response to the intermodal call branch instruction, the instruction decoder is configured to control the processing circuitry to store a value indicative of the handler mode at at least a portion of a second relative position within a stack frame stored in the stack data structure; 16. The apparatus of claim 10, wherein in response to the at least one type of instruction attempting to branch to the dummy function return address when the dummy function return address includes the intermodal call indication value, the processing circuitry is configured to trigger signaling of a fault if values ​​in the at least some of the second relative locations in the stack frame do not indicate the handler mode.

17. In response to the at least one type of instruction attempting to branch to the dummy function return address when the dummy function return address includes the intermodal call indication value, the processing circuitry: Before switching the current mode of the processing circuit to the handler mode, check whether the function return address obtained from the stack data structure is within a predetermined range of reserved addresses where instruction execution is prohibited, and trigger signaling of a fault caused by program code executing in the thread mode if the function return address is within the predetermined range of reserved addresses.

17. The device according to any one of claims 10 to 16, configured to:

18. for the intermodal call branch instruction, the function return address location comprises a location at a third relative position within a stack frame stored in a stack data structure; 18. The apparatus of claim 17, wherein for at least one type of exception transition triggered by an exception condition, the exception control circuitry is configured to store in the stack data structure the stack frame that includes one of the predetermined ranges of the reserved addresses stored at the third relative location within a stack frame.

19. 19. The apparatus of claim 1, wherein in response to the intermodal call branch instruction, the instruction decoder is configured to control the processing circuitry to perform the error synchronization barrier operation to isolate detection of errors associated with data processing performed before the error synchronization barrier operation from detection of errors associated with data processing performed after the error synchronization barrier operation.

20. 9. The apparatus of claim 7 or 8, wherein in response to the intermodal function return instruction, the processing circuitry is configured to perform an error synchronization barrier operation to separate detection of errors associated with data processing performed before the error synchronization barrier operation from detection of errors associated with data processing performed after the error synchronization barrier operation.

21. the processing circuitry is configured to perform the data processing in at least one security domain; The device comprises: a plurality of stack pointer registers including at least a process stack pointer register per security domain and a main stack pointer register per security domain; a selection circuit for selecting, for each security domain, which of the stack pointer registers to use to provide a stack pointer for accessing a stack data structure in memory; at least one stack pointer selection value storage location for storing a stack pointer selection value for each security domain; Equipped with In the handler mode, the selection circuitry is configured to select the main stack pointer register; in the thread mode, the selection circuitry is configured to select between the process stack pointer register and the main stack pointer register based on the stack pointer selection value; 21. The apparatus of claim 1, wherein, in response to the intermodal call branch instruction executed in a current security domain of the at least one security domain, the instruction decoder is configured to control the processing circuitry to cause the stack pointer select value of the current security domain to be set to indicate that the process stack pointer register should be selected when in the thread mode.

22. 1. A data processing method for an apparatus comprising: a processing circuit that executes data processing in one mode of a plurality of modes including at least a handler mode and a thread mode; and an exception control circuit that controls the processing circuit to switch to processing of an exception handler in the handler mode in response to an exception condition, the method comprising: The method comprises: decoding an intermodal call branch instruction that specifies a branch target address; in response to said intermodal call branch instruction, at least when said processing circuitry is in said handler mode; saving the function return address in a function return address location; switching the current mode of the processing circuit to the threaded mode; branching to an instruction identified by said branch target address; data processing methods, including

23. 1. A computer program for causing a host data processing apparatus to operate to provide an instruction execution environment for executing instructions from a target program code, comprising: The computer program comprises: processing program logic for performing data processing in one of a plurality of modes including at least a handler mode and a thread mode; exception control program logic that, in response to an exception condition, controls the processing program logic to switch to processing an exception handler in the handler mode; instruction decoding program logic for decoding instructions of said target program code to control said processing program logic to perform said data processing; Equipped with In response to an intermodal call branch instruction specifying a branch target address, at least when the processing program logic is in the handler mode, the instruction decode program logic controls the processing program logic to: saving the function return address in a function return address location; Switching the current mode of the processing program logic to the thread mode; branching to an instruction of the target program code identified by the branch target address A computer program configured to:

24. 24. A computer-readable storage medium storing the computer program of claim 23.

Images