intermodal call branch instruction

Abstract

A processing circuit (4) is provided having a handler mode and a thread mode. In response to an exception condition, a switch to the handler mode is made. In response to an inter-mode call branch instruction specifying a branch target address when the processing circuit (4) is in the handler mode, an instruction decoder (10) controls the processing circuit to save a function return address to a function return address storage location; to switch the current mode of the processing circuit (4) to the thread mode; and to branch to the instruction identified by the branch target address. This can be useful for exception privilege reduction.

Description

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

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

[0003] At least some examples provide 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; exception control circuitry, in response to an exception condition, for controlling the processing circuitry to switch to the handler mode to process an exception handler; and an instruction decoder for decoding instructions to control the processing circuitry to perform data processing; wherein: at least when the processing circuitry is in handler mode, in response to an inter-module call branch instruction specifying a branch target address, the instruction decoder is configured to control the processing circuitry to: save a function return address to a function return address storage location; switch the current mode of the processing circuitry to the thread mode; and branch to an instruction identified at the branch target address.

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

[0005] At least some examples provide a computer program for controlling a host data processing device to provide an instruction execution environment for executing instructions from target program code; the computer program includes: process logic for performing data processing in one of a plurality of modes including at least a process mode and a thread mode; exception control logic for controlling the process logic to switch to the process mode to handle exception handlers in response to an exception condition; and instruction decoding logic for decoding instructions of the target program code to control the process logic to perform data processing; wherein: at least when the process logic is in process mode, in response to an inter-module call branch instruction specifying a branch target address, the instruction decoding logic is configured to control the process logic to: save a function return address to a function return address storage location; switch the current mode of the process logic to the thread mode; and branch to instructions of the target program code identified at the branch target address.

[0006] A computer-readable storage medium may store the aforementioned computer program. This storage medium may be a non-transitory storage medium.

[0007] Further aspects, features, and advantages of this technology will become apparent from the following description, which is taken in conjunction with the accompanying drawings, in which:

[0008] Figure 1 An example of a data processing system with processing circuitry that supports different operating modes is shown schematically;

[0009] Figure 2 Examples of different domains and operating modes of the processing circuit are shown;

[0010] Figure 3 An example of a register in the processing circuit is shown;

[0011] Figure 4 This indicates the provision of reserved address ranges that cannot be used for executable instructions;

[0012] Figure 5 Show the return addresses of virtual functions and virtual exceptions;

[0013] Figure 6 This shows the different stack frames that can be saved to the stack in response to function calls or exceptions;

[0014] Figure 7 An example of abnormal privilege removal in cases where inter-module call branch instructions are not supported is shown for comparison;

[0015] Figure 8This example demonstrates the use of inter-module call branch instructions to remove abnormal privileges;

[0016] Figure 9 This shows an example of a prohibited combination of domain / mode switching;

[0017] Figure 10 Examples of allowed combined domain / mode switching are shown;

[0018] Figures 11A to 11C Show Figure 10 Examples of tail calls that might be useful for combining domain / mode switching;

[0019] Figure 12 This is a flowchart illustrating the steps executed when a function is called;

[0020] Figure 13 This is a flowchart illustrating the steps executed when an exception occurs;

[0021] Figure 14 It is a flowchart illustrating the steps executed in response to branch instructions other than function calls;

[0022] Figure 15 This is a flowchart illustrating the steps executed in response to a branch leading to the return address of a virtual function;

[0023] Figures 16A to 16D Showing the usable Figure 15 The integrity cross-check shown is used to detect potential attacks;

[0024] Figure 17 This is a flowchart illustrating the disabling of domain translation in threaded mode;

[0025] Figures 18 to 20 This shows an example of disabling configuration parameters using domain translation;

[0026] Figure 21 This is a flowchart illustrating the process of checking domain translation disabled configuration parameters when retrieving instructions whose addresses are in the secure address region; and

[0027] Figure 22 Examples of available simulators are shown.

[0028] Inter-module branch instruction

[0029] In systems where the processing circuitry supports both handler mode and thread mode, it is generally desirable to use handler mode for handling exception handlers (e.g., associated with the operating system or other monitoring software) and thread mode for handling background code of threads managed by the operating system or monitoring software. However, sometimes there may be types of exceptions that point to potentially untrusted devices, such as USB controllers or wireless network interfaces. Interrupts to such devices can be handled by exception handler code provided by a third party, different from the party providing the operating system, which manages the general operation of the system. The operating system provider may not trust the code provided by another party and may therefore want untrusted exception handler code used to control such untrusted devices not to have all the privileges associated with handler mode. Therefore, it may be desirable to be able to "deprivilege" exceptions, preventing exception handlers from accessing all registers or memory that code in handler mode would normally have access to. Furthermore, in cases where all software running on a device comes from the same vendor, it may be desirable to reduce the complexity of the privileged software and thus reduce the likelihood of security vulnerabilities in it. Therefore, even when all software comes from a single vendor, "deprivilege" of exceptions may still be desirable as part of a defense-in-depth strategy.

[0030] However, in typical systems with handler and thread modes, the mechanism for switching between modes could be to use an exception to switch from thread mode to handler mode and an exception return to switch back to thread mode. Simply triggering an exception return to thread mode might be inappropriate, as this typically lowers the priority level associated with the original exception, making it difficult to properly determine the priorities of different interrupts or exceptions. Therefore, it might be necessary to generate a "fake" second exception, used only to establish exception return control information, which, upon returning from the second exception, causes the original exception to be handled in thread mode rather than handler mode. This mechanism can be slow because calling the second exception may incur not only the performance cost of the operation used to establish the fake exception return but also the cost of additional state saving and restoration operations, which are typically performed upon exception entry and return to preserve the architectural state associated with the process executing before the exception. Therefore, using an exception entry and return mechanism to deprivilege exception handlers could increase overall interrupt / exception handling latency, which might be unacceptable in some systems, especially those designed for real-time applications. Furthermore, this approach could be difficult to code for the compiler, leading to potential errors.

[0031] In the example described below, an inter-module call branch instruction is provided that specifies a branch target address. In response to the inter-module call branch instruction, at least when the processing circuitry is in handler mode, the instruction decoder controls the processing circuitry to save the function return address to the function return address storage location, switch the current mode of the processing circuitry to thread mode, and branch to the instruction recognized by the branch target address specified by the branch instruction. Thus, a function call mechanism is provided where an instruction can directly branch to the branch target address of the instruction, and then the instruction is processed in thread mode instead of handler mode. This provides a faster and simpler mechanism for deprivileging exceptions, eliminating the need for the pseudo-second exception described above.

[0032] In addition to process mode and thread mode, the processing circuitry can also support data processing within one of multiple security domains, including at least a security domain and a lower security domain. Memory access checking circuitry can be provided to check whether memory access is permitted based on the current security domain of the processing circuitry. For example, the memory access checking circuitry can maintain a table providing security attributes that define corresponding address regions as either secure regions associated with a security domain or lower security regions associated with a lower security domain. When operating within a security domain, the processing circuitry can access both the secure and lower security regions of the memory; while within a lower security domain, the processing circuitry can access the lower security region but is not permitted to access the secure region.

[0033] The instruction decoder and processing circuitry can support inter-domain call branch instructions that specify a branch target address. In response to an inter-domain call branch instruction, the instruction decoder can control the processing circuitry to save the function return address to the function return address storage location, branch to the instruction recognized at the branch target address, and switch the current security domain of the processing circuitry. Therefore, by allowing direct branching from one domain to another, security domain changes can be performed more quickly. In some systems, inter-domain call branch instructions can be supported in both directions, from a security domain to a lower security domain and from a lower security domain to a security domain. However, in other implementations, it may not be necessary to provide inter-domain call branch instructions for both directions of domain switching. For example, in some implementations, the inter-domain call branch instruction may be a safe-to-lower security call branch instruction that triggers a switch from a security domain to a lower security domain, and other mechanisms may be provided for switching from a lower security domain to a security domain (e.g., alternatively, a security gateway instruction can cause a domain to switch from a lower security domain to a security domain, allowing access to the security domain to be restricted by requiring the presence of a security gateway instruction at a first address fetched from the security region of memory after the execution of an instruction from the lower security region of memory). Some specific implementations may use similar schemes to prevent code running in a lower privilege state from accessing only privileged regions of memory.

[0034] Therefore, multiple call branch instructions can be supported, causing the processing circuitry to execute function call operations that save the function return address and branch to the branch target address. These instructions can include call branch instructions that remain within the same mode and domain, as well as inter-modal call branch instructions that trigger a switch to thread mode and inter-domain call branch instructions that trigger a change in security domain. However, combined mode and domain switching in response to the same call branch instruction can be prohibited. Therefore, in response to an inter-modal call branch instruction, the instruction decoder can control the processing circuitry to switch the current mode to thread mode without changing the current security domain of the processing circuitry. This increases security by reducing the number of valid security domain transitions allowed, making it easier to verify whether a security domain change is safe.

[0035] In response to an inter-module function return instruction, the processing circuit can switch its current mode back to handler mode and branch to the instruction identified by the function return address previously saved by the inter-module call branch instruction. Therefore, when the privilege deprivation portion of the exception handler completes, the inter-module function return instruction can be used to trigger a switch back to handler mode, in which the processing circuit executes first when the corresponding exception occurs.

[0036] In some examples, intermodal function return instructions can be dedicated function return instructions, which have encodings that the instruction decoder recognizes as requiring a function return operation.

[0037] However, this is not necessary, and in some cases, whether an instruction causes an inter-module function to return can depend on information stored in registers or memory at execution time. For example, this can be achieved by attempting to branch to a reserved non-executable address (hereinafter referred to as the virtual function return address, e.g.) Figure 5 The FNC_RETURN address 140 shown (which will be described in more detail later) is used to trigger an inter-module function return. Since an inter-module function return instruction can be part of untrusted code within the privileged deprivileging section of an exception handler, it can be useful if the inter-module function return instruction has the same instruction encoding as a non-inter-module function return instruction that is not intended to trigger a switch from thread mode back to handler mode, because the privileged deprivileging section of the exception handler may be provided by a third party unaware that its exception handler has undergone privileged deprivileging.

[0038] In some examples, in response to an inter-module call branch instruction, the instruction decoder can control the processing circuitry to save the virtual function return address to the link register. The virtual function return address can be an address within a reserved address range that is not a valid executable address. The virtual function return address may include an inter-module call indicator value to indicate that the virtual function return address should be saved in response to the inter-module call branch instruction. If an instruction attempts to branch to the virtual function return address, which includes the inter-module call indicator value, the processing circuitry can treat the instruction as an inter-module function return instruction and switch to handler mode, branching to the real function return address obtained from the stack. Therefore, by storing the inter-module call indicator value within the virtual function return address, this distinguishes between inter-module and non-inter-module returns, allowing the same instruction encoding to be used for both types of function returns. This means that no modification to third-party privilege-removal exception handler code is required to support the inter-module branching techniques discussed above. Furthermore, by using a non-executable virtual function return address in the link register to signal that the real function return address should be accessed from the stack upon function return, the real function return address can be hidden from privilege-removal code for execution in thread mode after the inter-module call branch instruction.

[0039] Intermodal function return instructions can be one of several types of instructions that could lead to a branch to the virtual function return address, such as branch instructions or non-branch instructions (like register move instructions, load instructions, or stack pop instructions), which cause the program counter to be set to the virtual function return address. Therefore, in some implementations, this instruction can be processing circuitry (rather than an instruction decoder) that recognizes an intermodal function return should be performed, and thus should also trigger a switch to handler mode. In some examples, if all types of branches specify the virtual function return address as the branch target address, they can cause function return processing. In other examples, there may be certain types of branches that do not cause function return processing, even if they do specify the virtual function return address as the branch target address (e.g., branches specifying the target address using an immediate value may not cause function return processing because they do not need to perform function return, since the immediately specified branch target address cannot be saved in response to a function call instruction).

[0040] Unlike inter-module call branch instructions, inter-module function return instructions may require allowing combined switching of both domains and modes. Therefore, in response to an inter-module function return instruction, 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 is useful for supporting tail calls, a performance optimization used by some compilers in scenarios where a second function is called as the last action within code executed against the first function. Since the second function can be processed in a different security domain than the first function, this can be useful for supporting combined domain / mode switching in inter-module function return instructions, allowing legacy code previously compiled using tail calls to still function correctly.

[0041] However, in some cases, if the first security domain is a safe domain and the second security domain is a lower security domain, then a combination domain / mode switch is permitted upon function return from an intermodal function; but when the first security domain is a lower security domain and the second security domain is a safe domain, a combination domain / mode switch is prohibited. If this would result in a transition to a safe domain, then by prohibiting a combination domain / mode switch upon function return, security is improved by reducing the number of valid pathways to a safe domain.

[0042] As further described below, a domain translation disable configuration value can be provided to indicate whether translation between a security domain and a lower security domain is disabled or enabled when in thread mode. This can be useful for supporting the delayed allocation of resources associated with either the security domain or the lower security domain. Since exception handlers or other processes executing intermodal call branch instructions may typically know whether they have configured the resources required to operate in both domains, setting the domain translation disable configuration value in response to intermodal call branch instructions can be useful. This improves performance by avoiding the need to execute separate instructions to set the domain translation disable configuration value. There are 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 can control the processing circuitry to set the domain translation disable configuration value to indicate that translation between a security domain and a lower security domain is disabled when in thread mode. In response to a second variation of the intermodal call branch instruction, the instruction decoder can control the processing circuitry to set the domain translation disable configuration value to indicate that translation between a security domain and a lower security domain is enabled when in thread mode. Some systems may support both variations of the intermodal call branch instruction. Other systems may only support one of the first or second variants of the inter-module call branch instruction.

[0043] In response to an intermodal call branch instruction, the instruction decoder can trigger a fault signaling when the current mode of the processing circuit is thread mode. Since intermodal call branch instructions are designed to cause a transition from handler mode to thread mode, executing such an instruction from thread mode could be a erroneous indication. Proposing a fault in this situation prevents misuse. For example, because the execution of an intermodal call branch instruction might trigger a state saving, indicating that a transition from thread mode to handler mode should occur upon the return of the corresponding function, an attacker running a process in thread mode might be tempted to use intermodal call branch instructions to attempt to gain privileges upon the return of the corresponding function. Security is improved by preventing successful execution of intermodal call branch instructions in thread mode and signaling a fault if such an attempt is made.

[0044] Generally, a function return instruction can be any instruction that causes a branch to an instruction identified by the function return address previously set in response to a call branch instruction. Intermodal function return instructions are a specific type of function return instruction that also triggers a switch from thread mode to handler mode in the current mode (e.g., distinguished from non-intermodal function returns by information stored in registers or memory, or by a branch target as a reserved virtual function return address). Encountering an intermodal function return instruction while the current mode is handler mode can signal a failure. This improves security. During an intermodal function call, some information may be stored in a stack frame on a stack data structure in memory. If an intermodal function return is attempted while the current mode is handler mode, it may indicate that the function return transition is not the intended transition using that stack frame, which could compromise security if the information on that stack frame is misused. Enforcing that intermodal return branch instructions can only be successfully executed when in handler mode reduces vulnerabilities for such attacks.

[0045] The processor architecture may provide a link register, which is designated to store the function return address in response to a call-branch instruction. The link register can also be used as a general-purpose register, but it is used to store the function return address during a function call, to which processing branches when the function completes. For at least one call-branch instruction other than inter-module call-branch instructions, the link register can be used as the function return address storage location. However, for inter-module call-branch instructions, the function return address storage location may be a location on a stack data structure stored in memory. The memory region including the stack data structure may be a region inaccessible in thread mode (e.g., because memory protection data defining access permissions for the corresponding address region indicates that code with a privilege level associated with the thread mode cannot access that address region, and / or because the stack pointer to the stack data structure is located in a register inaccessible in thread mode). By saving the function return address to the stack instead of to the link register, this prevents the function return address from being visible to deprivileged code executing in thread mode after an inter-module function call, thereby improving security by reducing the opportunity for an attacker to view or modify information related to the operations of higher-privileged code executing in handler mode.

[0046] As mentioned above, in response to inter-module call branch instructions, the virtual function return address can be saved to the link register. However, it should be noted that when the corresponding function return instruction attempts to branch to the virtual function return address, that virtual function return address may no longer be stored in the link register. Some compilers can generate code such that the virtual function return address remains in the link register, and if another function is nested within a previously called function, the compiled code can save the virtual function return address to the stack in memory, and then restore the virtual function return address to the link register once the nested function completes, so that the virtual function return address is again in the link register when returning from the first function. However, this is not necessary. Other compilers can compile code that does not restore the virtual function return address to the link register when returning from a nested function call, but instead, improves performance by loading the virtual function return address directly from the stack to the program counter register when the corresponding function return is needed, thus effectively causing a branch to the virtual function return address, which can then be detected as needing to obtain the real function return address from the stack. Therefore, whether the virtual function return address is still stored in the link register when the function returns is not important. It is important to note that when virtual function return addresses are saved to the stack to enable nested function calls, the stack used to store the virtual function return address can be a different stack data structure than the one used to store the real function return address when executing inter-module call branch instructions. For example, the stack used to store the real function return address in response to inter-module call branch instructions could be the main stack associated with the handler mode, while if nested function calls exist within the privilege-deprivileged code executing in thread mode, the virtual function return address previously stored in the link register could be saved to the process stack data structure associated with the thread mode.

[0047] The virtual function return address can include various information for controlling operations when attempting to return the corresponding function. For example, the virtual function return address may indicate at least one of the following: whether a switch from thread mode to handler mode is requested in response to an instruction attempting to branch to the virtual function return address; whether a switch of the current security domain of the processing circuitry is requested in response to an instruction attempting to branch to the virtual 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 virtual function return address. Therefore, upon function return, the processing circuitry can use the information in the virtual function return address to determine whether to switch modes, switch domains, and / or determine which stack data structure to use to obtain the function return address. In some examples, the virtual function return address may use two bits to indicate these three pieces of information: the first bit indicates whether the virtual function return address was set in response to an inter-module call branch instruction, and the second bit indicates the security domain for the inter-module function call. Which stack data structure should be used can be inferred from these two bits, so explicit indication may not be necessary. However, it should be understood that this is merely one way to encode information within the virtual function return address, and other methods may employ different options. Furthermore, some specific implementations may not indicate all of the three types of information mentioned above.

[0048] A predetermined portion of the virtual function return address can indicate whether a switch of the current security domain of the processing circuitry is requested in response to an instruction attempting to branch to the virtual function return address. For example, this predetermined portion could be the least significant bit of the virtual function return address. In response to a security gateway instruction when the current security domain is a lower security domain, the processing circuitry can set a portion of the return address (e.g., an address in a link register) to a value indicating a lower security state, where this portion is in the same relative position within the return address value as the portion in the virtual function return address indicating a domain switch. Security is improved by mitigating attacks based on the lower security code passing a fake return address to the security code when a security function is called from a lower security domain, attempting to make the corresponding return branch in the security code jump to any location in the security domain instead of returning to an address in the lower security domain. A security gateway instruction can be an instruction that triggers a switch from a lower security domain to a security domain when executed from a lower security domain, and the processing circuitry can trigger fault signaling if the first instruction fetched from the security domain after an instruction is executed in the lower security domain is not a security gateway instruction. Therefore, it might be desirable for a security gateway instruction to exist at a valid entry point into a security domain, thereby cleaning up return addresses set by lower security codes upon entry into the security domain to indicate that the return address is untrusted, leading to branching to arbitrary addresses within the security domain. When a predetermined type of branch instruction is executed in a security domain, which specifies an address with a portion set to indicate a lower security state as the branch target address, this causes the processing circuitry to switch back to the lower security domain, regardless of whether the target address corresponds to a secure region or a lower security region in memory. Therefore, secure code can be written to include predetermined type of branch instructions at those branches where the branch target address controlled by the lower security domain is expected, thus providing protection against the aforementioned attack types. Intermodal function return branches may be vulnerable to similar attacks; therefore, by encoding the virtual function return address such that the portion signaling whether a security domain switch is requested is in the same relative position as the portion of the return address set to indicate a lower security state in response to a security gateway instruction, intermodal function return branches are also protected from attacks.

[0049] Link registers can be registers accessible to code executing in thread mode. Therefore, while it is convenient to use the virtual function return address stored in the link register to provide information indicating whether the corresponding function return should be considered an intermodal call, the information placed in the virtual function return address may be easily modified by lower-privileged code executing in thread mode. To prevent attacks based on malicious modifications to the virtual function return address, in response to an intermodal call branch instruction, the instruction decoder can control the processing circuitry 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 storing the cross-check value can be a stack inaccessible to code executing in thread mode. In response to at least one type of instruction attempting to branch to a virtual function at an address, the processing circuitry can compare a portion of the virtual function return address used to encode the intermodal call indication value with a value in at least a portion of the first relative position in a stack frame obtained from the stack data structure to determine whether a fault signaling should be triggered based on the comparison. Therefore, while the virtual function return address can signal whether access to a stack frame on a stack data structure is necessary, the cross-check value in the stack frame provides double checking, meaning any information indicating a mode change upon function return is trustworthy, thereby improving security. A similar check can be performed on the security field indication in the return address of a virtual function.

[0050] In response to at least one type of call branch instruction other than intermodal call branch instructions, the instruction decoder can control the processing circuitry to store values ​​other than the cross-check value in at least a portion of a first relative position within the stack frame stored in the stack data structure. Therefore, cross-checking also prevents attacks attempting to use intermodal function returns as a mechanism for returning from code entered via non-intermodal call branch instructions. This type of mismatched function call and function return can lead to vulnerabilities based on mismatched stack frames in memory. Therefore, if an attempt is made to modify the virtual function return address to indicate an intermodal function return, but the corresponding stack data structure in memory is actually stored by a non-intermodal call branch instruction, the cross-check may fail, potentially triggering a failure.

[0051] In response to an inter-module call branch instruction, the instruction decoder can control the processing circuitry to store the value indicating the handler mode in at least a portion of a second relative location within a stack frame stored in the stack data structure. The second relative location can be the same address as the first relative location (in which case, cross-checking information between the inter-module call indicator value and the value indicating the handler mode may reside in different bit portions within the same data word on the stack), or it can be a different relative offset corresponding to an address within the stack frame that is different from the first relative location. In response to at least one type of instruction attempting to branch to the virtual function return address when the virtual function return address includes the inter-module call indicator value, the processing circuitry can trigger a fault signaling if the value in the relevant portion of the second relative location in the stack frame does not indicate a handler mode. Therefore, a fault can be triggered if the virtual function return address indicates a function return from thread mode to handler mode, but the stack frame in memory indicates that the corresponding function call did not initially originate from handler mode. Similarly, this prevents certain forms of attacks.

[0052] Some implementations may provide a cross-check value at a first relative position on the stack and a handler mode indication value at a second relative position. Other implementations may omit one of these types of cross-checks and may provide only the cross-check value or the handler mode indication value.

[0053] In response to at least one type of instruction that attempts to branch to the virtual function return address when the virtual function return address includes an intermodal call indicator value, the processing circuitry may perform a check on the function return address obtained from a stack data structure. Before switching the processing circuitry's current mode to handler mode, the processing circuitry may check whether the function return address obtained from the stack data structure is within a predetermined reserved address range from which execution is prohibited by its instruction. When the function return address is within the predetermined reserved address range, a fault attributable to the program code execution thread mode may be triggered. This type of check can be useful because when an intermodal call branch instruction is executed, the function return address can be saved to a third relative position within the stack frame saved to the stack data structure, and for at least one type of exception transition triggered by an exceptional condition, the exception control circuitry can store a stack frame including an address from the predetermined reserved address range stored at the third relative position within the stack frame. Therefore, by checking whether the function return address is within the predetermined reserved address range when returning from an intermodal function, attacks based on attempts to execute a function return based on a stack frame actually saved in response to an exception entry transition rather than a function call transition can be prevented, potentially leading to unpredictable and security-critical results. Checking the function return address may also help prevent other types of attacks. For example, if the beginning of the stack is sealed with another reserved value (from a predetermined reserved address range) at the third relative position within the stack frame, an attempt to underflow the stack (i.e., using the stack frame when the stack is empty) will also be detected, and a fault will be signaled.

[0054] As part of the inspection of inter-module function return instructions, checking whether the function return address is within the reserved address range seems redundant, as a failure caused by attempting to execute an instruction from a predetermined reserved address range should, as expected, be triggered when attempting to fetch an instruction from one of the reserved addresses. However, the inventors recognized that, for inter-module function returns, if allowing the inter-module function return to complete successfully, causing the mode to switch to handler mode, and then triggering a failure when attempting to fetch the next instruction from the function return address, could be attributed to code executing in handler mode, rather than program code executing in thread mode before switching to handler mode. This could be problematic because handler code might be associated with the operating system, and therefore the failure could lead to the operating system being suspected of malfunction, potentially requiring relatively intrusive actions such as a complete system reset. Therefore, using this method, this could provide an attacker with a way to execute a denial-of-service attack aimed at disrupting the normal operation of the processing system (by repeatedly triggering function returns based on abnormal stack frames).

[0055] In contrast, using the method described in this paper, where the function return address is checked in advance to ensure it is within the reserved address range when processing inter-mode function return instructions (before any mode switch from thread mode to handler mode is triggered), the fault can be attributed to thread mode code. Therefore, the impact of fault handling actions on system functionality can be much smaller (e.g., simply killing and restarting a single thread), reducing the chance of denial-of-service attacks and thus improving security.

[0056] For reliability and security purposes, some implementations may include error detection / correction circuitry to detect transient or permanent errors caused by hardware malfunctions or minor glitches. For example, error detection / correction circuitry may include circuitry that uses error detection / correction codes to detect errors in data stored in registers or memory, such as those caused by particle impacts or storage elements stuck at, for example, 0 or 1. Error detection / correction circuitry may also include redundant processing logic that performs the same operation two or more times, allowing errors to be detected by comparing the redundant results of these operations. The specific form of error detection / correction circuitry can vary significantly between systems depending on the system's needs. For reasons similar to the denial-of-service attack scenarios described above, it is useful to be able to attribute any detected errors to a specific data processing context, allowing for more efficient error resolution (e.g., if the error actually occurred within data processing associated with a specific thread, there is no need to terminate the operating system and perform an intrusive system reset).

[0057] To isolate errors, in response to inter-module call branch instructions, the instruction decoder can control the processing circuitry to perform an error synchronization barrier operation. This isolates 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, this can also trigger an error synchronization barrier operation for inter-module function return instructions. For example, an error synchronization barrier operation may include pausing processing until any incomplete operations have been completed, and the results of any error checks on any operations performed before the error synchronization barrier operation are available, and it is known whether the results of the prior processing were correct. Therefore, this allows any errors that occur to be more precisely pinpointed to the specific code where the error occurred. In some systems, inter-module call branch instructions and inter-module function return instructions may always trigger an error synchronization barrier operation. Other systems (e.g., systems without any reliability / safety error checking circuitry) may not support error synchronization barrier operations. In other examples, some configuration state data may be provided that controls whether inter-module call branch instructions and inter-module function return instructions trigger an error synchronization barrier operation. By allowing the existence of error synchronization barrier operations that can be configured by software, a single chip can better meet the needs of different markets, such as markets where performance is more important than error isolation, and vice versa.

[0058] Some implementations may provide two or more stack pointer registers, including a process stack pointer register for each security domain and a master pointer register for each security domain (in a system with only one security domain, there may be only a single process stack pointer register and a single master stack pointer register; in systems supporting multiple security domains, the stack pointer registers may be grouped per security domain). Selection circuitry can select for each security domain which stack pointer register should be used to provide the stack pointer for accessing stack data structures in memory. In handler mode, the selection circuitry can select the master stack pointer register for the current security domain. In thread mode, the selection circuitry can select between the master stack pointer register and the process stack pointer register for the current domain based on the stack pointer selection value for the current domain. Providing separate master and process stacks for handler and thread modes respectively simplifies the development of exception handler code because it means that after an exception returns, thread access running in thread mode may often be unable to access any data that the exception handler might have left on the master stack data structures. In some implementations, using separate stacks for thread and handler modes may also help prevent certain types of attacks based on forgery of fake exception return stack frames. However, in certain scenarios (e.g., where available memory is limited), it may be desirable to allow thread-mode code to share the main stack identified by the main stack pointer with the handler-mode code, rather than using a separate process stack as in thread-mode. Therefore, a stack pointer selection value (controlled by higher-privileged code) can be provided to define which stack should be used in thread-mode.

[0059] In response to inter-module call branch instructions, the instruction decoder can control the processing circuitry to set the stack pointer selection value for the current security domain, indicating that the process stack pointer register should be selected when in thread mode. This improves security by preventing the execution of the privilege-removing portion of the exception handler after an inter-module function call accesses information that higher-privileged code might leave on the main stack structure.

[0060] A simulator computer program can be provided for controlling a host data processing device to provide an instruction execution environment for executing instructions from target program code. This computer program may have processing logic, exception control logic, and instruction decoding logic that emulate the functionality of the aforementioned processing circuitry, exception control circuitry, and instruction decoder. This includes support for inter-module call branch instructions as described above. Therefore, such a simulator computer program can present an instruction environment similar to that provided by an actual hardware device for target code executed on the simulator computer program, even if the host computer executing the simulator computer program may not have any actual hardware providing these features. This can be useful for executing code written for an instruction set architecture on a host platform that does not actually support the architecture. Furthermore, when software development is carried out in parallel with the development of hardware devices that support a new version of the instruction set architecture, the simulator is useful during the development of software for a new version of the instruction set architecture, allowing the software under development to be tested during simulation, and enabling software development to begin before the hardware devices supporting the new version of the instruction set architecture are ready.

[0061] Domain transition disabled configuration parameters

[0062] As described above, the processing circuit may have multiple security domains, including at least a secure domain and a lower security domain, and may provide memory access checking circuitry to check whether memory access is permitted based on the current security domain of the processing circuit. For example, the memory access check may be based on attribute data defining whether a memory region is considered secure or less secure, and access to the secure region may be prohibited when operating in the lower security domain.

[0063] A control storage unit can be provided to store domain translation disable configuration parameters that specify whether domain translation between a secure domain and a lower secure domain is enabled or disabled when the processing circuitry is in at least one mode. In this at least one mode, when the domain translation disable configuration parameter specifies that domain translation is disabled, the processing circuitry can trigger a signaling to disable domain translation fault in response to an attempt to translate from a secure domain to a lower secure domain, and can also trigger a signaling to disable domain translation fault in response to an attempt to translate from a lower secure domain to a secure domain. This approach may be counterintuitive, as while it may be useful to prevent translations from a lower secure domain to a secure domain for security reasons, it may be questionable why it is useful to be able to selectively disable translations from a secure domain to a lower secure domain. However, the inventors recognize that this provides a method for including specific processing threads within a single secure domain and a lower secure domain, which can be beneficial for performance because some performance-intensive operations that may be required when a thread traverses two domains can be suppressed if it is known that an attempt to switch domains will trigger a domain translation disable fault. This then allows performance-intensive operations to be delayed, performed only when needed when attempting to switch domains, thus avoiding the performance cost of speculatively performing these operations for all threads, regardless of whether those threads will cross domains. Therefore, providing a domain switching disabling configuration parameter that disables switching in both directions between the safer and lower safer domains can benefit performance when the processing circuitry is in at least one mode.

[0064] This technique is particularly useful when processing circuitry uses information stored in at least one security configuration register to control memory access in a secure domain, and information stored in at least one lower security configuration register to control memory access in an insecure domain. For example, the secure / lower security configuration registers may include: a stack pointer register that stores a stack pointer for accessing the corresponding secure or lower security stack data structure in memory; a register within a memory protection unit (MPU) that defines memory protection attributes for defining access permissions to memory regions; and / or an MPU pointer register that provides a pointer to a table in memory that provides memory protection region attributes. To ensure isolation between secure and lower security domains, it may be desirable to define separate sets of MPU attributes or stack data structures for use by the secure and lower security domains respectively. However, operations for configuring stack pointers, allocating space in the memory address space for stack data structures, and / or configuring MPU region attributes for the secure and lower security domains can be relatively performance-intensive, and therefore, for threads that only need to operate in one domain, it may be desirable to avoid performing these operations on either the secure or lower security domain. This can be particularly important when time-critical operations such as interrupt handling are required. Therefore, by providing a domain switching disable configuration parameter, this provides a fault that can be used to detect when a thread that has not yet performed these configuration operations attempts to switch to another domain, allowing these configuration operations to be delayed as needed. In one example, the configured resources may include stack pointer registers storing stack pointers to stack data structures, including at least one stack pointer register associated with a security domain and at least one stack pointer register associated with a lower security domain.

[0065] In response to an attempt to perform at least one type of transition from a lower security domain to a secure domain in at least one mode, the processing circuitry may use a domain transition disable configuration parameter to perform a domain transition disable check to determine whether signaling for a domain transition disable failure is triggered. This domain transition disable check may be performed before at least one other security check is performed to determine whether the attempt to transition from the lower security domain to the secure domain is permitted. It is possible that at least a portion of the at least one other security check may depend on information or resources, such as MPU configuration or stack data structures referenced by stack pointer registers, that have not yet been configured for threads that do not expect domain switching. Therefore, if another security check is performed before the domain transition disable check, this could cause the security check to fail simply because the relevant data to be checked has not been configured, rather than because some other security risk has been identified. Since security checks may be associated with fault handlers that trigger more drastic operations than those associated with a domain transition disable failure (which might only trigger a delayed configuration of resources), it may be desirable to perform the domain transition disable check first so that if resources are unavailable, they can be configured before proceeding with other types of security checks. For example, some implementations can perform security checks, and if these checks fail, a security failure occurs. To ensure the integrity of the security state, exception handlers associated with the security failure can terminate the execution of the entire lower security state. This failure can be intentionally triggered by software running in a lower security and lower privilege state as a means of launching a denial-of-service attack against the operating system running in the lower security state.

[0066] For attempts to transition from a secure domain to a lower secure domain, the domain transition disable configuration parameter can also be used to disable domain transition checks. However, since the transition is from a secure domain to a lower secure domain, additional security checks may not be required, and therefore the order of disabling domain transition checks with other security checks may be irrelevant. Alternatively, some systems may still perform security checks when returning from a secure domain to a lower secure domain. In this case, the order of disabling domain transition checks with other security checks may depend on whether any information configured in response to a domain transition disable failure is intended for that other security check.

[0067] A domain translation disabling check can be triggered by attempting at least one type of transition from a lower security domain to a higher security domain or from a higher security domain to a lower security domain. Sometimes, a domain translation disabling check can be triggered by an event or instruction that does not necessarily result in a transition between a security domain and a lower security domain. For example, in some cases, a domain translation disabling check may be performed upon encountering an event or instruction that could potentially lead to a transition between security domains, but before identifying whether that event or instruction actually triggers a domain change. Therefore, while the domain translation disabling configuration parameter is checked at least in response to an actual attempt to change the domain, this does not preclude the possibility of checking for events that do not actually result in a domain change if the disabling check passes and determines that the domain translation will be enabled.

[0068] Domain translation disable configuration parameters can be modified in both the security domain and the lower security domain. In some implementations, additional conditions may be imposed on whether a specific code segment is allowed to modify the domain translation disable configuration parameter. For example, in a system with a privileged state and a lower privileged state, the domain translation disable configuration parameter can only be modified in the privileged state. However, even if the current security domain is the lower security domain, processing circuits may be allowed to modify the domain translation disable configuration parameter. This may seem counterintuitive, as configuration parameters that typically restrict security domain changes are expected to be configured from the security domain. However, since triggering a domain translation disable failure can be used as a mechanism to improve performance rather than security, modifying the domain translation disable configuration parameter from the lower security domain is acceptable. This leverages the fact that enabling security domain changes for a thread may offer little benefit if the thread has not established appropriate security resources for it; in such a case, if the thread attempts to switch to a security domain, processing will fail because no such resources will be established.

[0069] As discussed above, processing circuitry can have thread mode and handler mode. These modes can be orthogonal to security domains because in a security domain, processing circuitry can operate in either thread mode or handler mode, and similarly, in a lower security domain, processing circuitry can operate in either thread mode or handler mode. At least one of the aforementioned processing circuitry modes can be thread mode. Therefore, when in thread mode, the domain transition disable configuration parameter can selectively disable transitions in the security domain. However, at least one mode can exclude handler mode, such that in handler mode, processing circuitry can determine whether to allow domain transitions independently of the domain transition disable configuration parameter. Therefore, even if the domain transition disable configuration parameter indicates that transitions between the security domain and the lower security domain are disabled in thread mode, such security / lower security domain transitions can still be allowed in handler mode. More likely, in a system with security domains and lower security domains, the handler code executing in handler mode (e.g., which may be associated with the operating system) may involve both security processing and lower security processing, and therefore requires resources from both domains, thus the value of disabling security / lower security domain transitions in handler mode is smaller. Furthermore, the handler code executed in handler mode can be code that intervenes and delays the configuration of resources for other domains if the thread mode code has triggered a failure to disable domain translation. Therefore, it may be useful to allow handler mode to continue operating in both domains even if the thread mode has disabled domain translation.

[0070] As previously mentioned, the instruction decoder can support intermodal call branch instructions. Besides saving the function return address and the branch target address, this instruction also switches the current mode of the processing circuit from handler mode to thread mode. It may also be useful to set a domain translation disable configuration parameter in response to such instructions to specify whether domain translation is enabled or disabled. At least one of a first and a second variant of the intermodal call branch instruction can be defined, where the first variant causes the domain translation disable configuration parameter to be set to specify that domain translation is disabled in at least one mode, and the second variant causes the parameter to be set to specify that domain translation is enabled in at least one mode. Systems supporting both variants may be particularly useful because this allows the handler code to signal in the same intermodal call branch instruction that calls the privileged deprivation section of the exception handler code whether resources have been configured for the privileged deprivation section to operate in both domains.

[0071] Similarly, for inter-module function return instructions as described above, this can also trigger the setting of the domain translation disable configuration parameter. Setting the domain translation disable configuration parameter to a value that specifies enabling domain translation in at least one mode can be particularly useful for function returns. This is useful because, as mentioned above, one use case for inter-module function call branches and inter-module function returns could be allowing exception handlers to call functions that require deprivileging in thread mode, and this code could be provided by a third-party vendor. Higher-privileged code in handler mode can execute “wrapper” code to execute before and after the deprivileged portion of the code. By setting the domain translation disable configuration parameter to its default value in response to the inter-module function return instruction, this means that the wrapper code at the end of the deprivileged portion always executes with a consistent, known state, regardless of whether the deprivileged portion actually uses both the security domain and the lower security domain. Furthermore, by using an “enabled” indicator as the default value set after the inter-module function return instead of a “disabled” indicator, this means that subsequent legacy code written for systems that do not support the domain translation disable configuration parameter (which is expected to allow thread mode domain translation) will still run without triggering additional failures.

[0072] Furthermore, in response to an inter-module function return instruction and an update of the domain translation disable configuration parameter to indicate that domain translation is enabled in at least one mode, the processing circuitry can also record whether the domain translation disable configuration parameter specifies an indication of enabling or disabling domain translation in at least one mode before the execution of the inter-module function return instruction. This indication of the previous state of the domain translation disable configuration parameter can be useful for allowing subsequent processing code to determine whether information in the configuration register belonging to other security states (such as MPU state or stack pointer) has been changed by code executed between the inter-module call and the inter-module function return, so that if the configuration registers of other security states have not been changed, any operation to restore the previous configuration can be omitted to improve performance.

[0073] If, after checking the domain transition disable configuration parameters, a domain transition disable failure is signaled when attempting to transition from the first security domain to the second security domain, the exception control circuitry can control the processing circuitry to handle the exception handler in the first security domain. Therefore, if a failure is triggered by attempting to switch from a lower security domain to a security domain, the failure will be handled in the lower security domain, and if an attempt is made to transition from a security domain to a lower security domain, the failure will be handled in the security domain. This is useful because typically, the domain that the corresponding thread is operating on before the domain switch will be the domain in which the thread was first initialized, and therefore the domain associated with the management process that manages that thread. For example, a security thread created in a security domain might be managed by a security operating system, while a lower security thread created in a lower security domain might be managed by a lower security operating system; therefore, it might be desirable to direct any domain transition disable failures to the management process associated with the thread attempting to disable domain transition. Although failures can be handled in the first security domain, the resource configuration executed by the exception handler in response to the failure can be a resource associated with the second security domain. Because the domain targeted by the disabled domain translation failure differs from the state requiring delayed resource configuration, close coordination between program code operating in a lower security state and the security state may be required in handler mode. Therefore, it may be advantageous to exclude handler mode from at least one mode that performs disabled domain translation checks.

[0074] In the event of an exceptional condition, the exception control circuitry can update the domain translation disable configuration parameter to specify that safe / lower security domain translation is enabled in at least one mode. Similarly, this provides a safe, known default state for the exception handler, allowing it to operate consistently regardless of the value of the domain translation disable configuration parameter associated with the background code being processed when the exception occurs. Furthermore, by enabling translation by default in response to exceptional conditions, this improves compatibility with legacy code in the exception handler that may have been written for systems that do not support domain translation disable functionality.

[0075] When an exceptional condition occurs, the exception control circuitry can trigger some state saving to preserve the architectural state associated with the processes executed prior to the exceptional condition. The hardware of the exception control circuitry does not need to save all architectural states associated with previous processes, and in some cases, the hardware may save only a subset of the architectural states. If registers containing other states are to be overwritten by the exception handler, a subsequent exception handler may be responsible for saving other architectural states not already saved in the hardware.

[0076] When such state saving is performed in response to an exception, the architectural state saved in the state save may include domain translation disable configuration parameters. Therefore, when an exception occurs, the domain translation disable configuration parameters can be automatically saved by the hardware so that once the exception handling is complete and processing returns to the previous processing executed before the exception occurred, the domain translation disable configuration parameters can be restored to the control store location, allowing subsequent processing in the background code to function in the same way as if no exception had ever occurred.

[0077] In some implementations, the domain translation disable configuration parameter may be saved as part of a stack frame in response to an exceptional condition. This stack frame is saved to a stack data structure that also includes other architectural states, such as general-purpose register contents or exception return addresses. However, in some implementations, there may be very little spare space within the stack frame for encoding the domain translation disable configuration parameter, and it may be preferable to reserve any spare encoding space for other purposes.

[0078] Therefore, in some examples, during state saving, the exception control circuitry can save a first stack frame, including the exception return address and a first subset of the architecture state, to a stack data structure. However, the value of the domain translation disable configuration parameter can be saved to a predetermined register instead of being included in the first stack frame (e.g., the predetermined register could be a link register). This avoids consuming additional bits in the stack frame. It should be noted that the saved value of the domain translation disable configuration parameter does not need to have the same encoding as the domain translation disable configuration parameter itself; any value can be saved to the stack, and the value of the domain translation disable configuration parameter at the time of the exception can be determined.

[0079] However, exception handlers executed in response to exceptional conditions can access predetermined registers. At least for exceptions that cause a transition from a security domain to a lower security domain, it may be undesirable to allow lower-security code executed after the exception to modify the value indicating whether security domain transitions were disabled in the processing executed before the exception.

[0080] To prevent this scenario, at least in response to an exceptional condition that triggers a transition from a security domain to a lower security domain, the exception control circuitry can save not only the first stack frame described above to the stack data structure, but also a second stack frame, including a second subset of the architecture state and cross-checking information for checking the value of the domain transition disable configuration parameter, to the stack data structure. At least during an exceptional return transition from a lower security domain to a security domain, the exception control circuitry can compare the value of the domain transition disable configuration parameter with the cross-checking information in the second stack frame, and if a mismatch is detected in the comparison, trigger a fault signaling. It should be noted that although the value of the domain transition disable configuration parameter may have been saved to a predetermined register in response to the initial exception, during the exceptional return transition, the domain transition disable configuration parameter may no longer be in the predetermined register, but may be in a value loaded from a stack data structure in memory, or in a field within a virtual non-executable address where the branch triggers the exception return. By providing cross-checking information in the second stack frame, this allows the lower security exception handler to attempt to modify the saved value of the domain transition disable configuration parameter initially placed in the predetermined register to be checked, to prevent security violations. While this approach may seem more complex, the second stack frame can record additional state saved to memory to hide its relatively low-safety exception handler and may have more spare capacity than the first stack frame for additional information, thus providing a saved subset of state for all exceptions entering the stack. Therefore, recording cross-check information in the second stack frame means that for those exceptions that only require the first stack frame, there is no need to incur the memory cost and interrupt latency of saving any additional stack state to preserve the domain transition disable configuration parameters (because relying on predefined registers is safe in this case), but for those safe-to-lower-safe exception transitions that require saving the second stack frame, cross-checking can be saved to the stack to improve safety.

[0081] The processing circuitry can allow domain translation to be performed between a security domain and a lower security domain in several ways, and can perform domain translation in slightly different ways depending on the route used for the translation between security domains, disabling the checking of configuration parameters.

[0082] As previously mentioned, one way to switch domains is by using inter-domain call branch instructions, which request a transition from a secure domain to a lower secure domain. In response, the instruction decoder controls the processing circuitry to perform the inter-domain call branch operation, which includes: saving the function return address to a function return address storage location (e.g., a stack data structure in memory); saving the virtual function return address to a predetermined register (e.g., a link register); switching the processing circuitry to the lower secure domain; and branching to an instruction recognized by the branch target address specified by the inter-domain call branch instruction. By allowing direct function calls from a secure domain to a lower secure domain, this avoids the need to call exception handlers or watcher code to monitor domain transitions, thereby improving performance.

[0083] For inter-domain call branch instructions, the domain translation disable configuration parameter can be checked, and the inter-domain call branch operation can be performed if the domain translation disable configuration parameter specifies that inter-domain translation is enabled in at least one mode. Furthermore, regardless of the value of the domain translation disable configuration parameter, the inter-domain call branch operation can be performed if the processing circuit is currently in a mode other than at least one mode (e.g., when the current mode is processor mode). Conversely, when in at least one mode (e.g., thread mode) and the domain translation disable configuration parameter specifies that domain translation is disabled in at least one mode, a signaling for a domain translation disable failure can be triggered.

[0084] Another approach to inter-domain translation is to attempt to execute an inter-domain return branch instruction that requests a translation from a security domain to a lower security domain and branches to an instruction identified by the branch target address specified by the inter-domain return branch instruction. Attempts to execute this instruction may trigger a check of the inter-domain translation disable configuration parameter, and if the inter-domain translation disable configuration parameter specifies that inter-domain translation is enabled in at least one mode, then the inter-domain return branch operation can be executed. Furthermore, regardless of the value of the inter-domain translation disable configuration parameter, if the processing circuitry is currently in a mode other than at least one mode (e.g., when the current mode is process mode), then the inter-domain return branch operation can be executed. Conversely, when in at least one mode (e.g., thread mode) and the inter-domain translation disable configuration parameter specifies that inter-domain translation is disabled in at least one mode, then a signaling for a disabled inter-domain translation fault can be triggered.

[0085] Another way to perform inter-domain transitions is to attempt to branch to a virtual function return address, established by the earlier function call branch instructions discussed earlier. When an inter-domain call branch instruction is executed, requesting a transition from a safe domain to a lower safe domain, the function return address of the function call can be saved to a stack data structure to prevent it from being visible in the lower safe code, and the virtual function return address can be saved to a link register visible to the lower safe code. The virtual function return address may include information indicating that a domain transition should be performed to return to the safe domain when the corresponding function returns. Therefore, when a branch to a virtual function return address is later attempted and the virtual function return address indicates an inter-domain function return, if the processing circuitry is currently in at least one mode and the domain transition disable configuration parameter specifies that domain transitions should be disabled in at least one mode, the processing circuitry can trigger a signaling to disable domain transitions.

[0086] Another way to transition from a lower security domain to a secure domain is by retrieving instructions from a secure address region. Security attribute data maintained by memory access checking circuitry can define an address region as either a lower security address region or a secure address region. Instructions stored in a secure address region of memory can only be executed from the secure domain. When currently in a lower security domain, attempting to retrieve instructions from an address in a secure address region may require performing security checks to determine if a transition to the secure domain is permitted. For example, this check might include checking if the instruction at the address in the secure address region is a specific type of security gateway instruction that marks a valid entry point into the secure domain. In some cases, if the instruction at the address in the secure address region is a security gateway instruction, decoding the security gateway instruction can trigger a change of security domain from a lower security domain to a secure domain. In other cases, a transition from a lower security domain to a secure domain is permitted only if the attempt to retrieve the instruction targets a specific type of secure memory, such as a lower security callable secure memory. Some implementations perform both security gateway instruction checks and lower security callable secure memory checks.

[0087] However, as mentioned earlier, for transitions from a lower security domain to a higher security domain, security checks may depend on resources that may not yet be configured for threads expected to remain within a single security domain (e.g., checks may depend on memory protection cell attributes of the security region being set, making it possible to extract and decode instructions extracted from the security region). Therefore, if a thread expected to reside only in the lower security domain attempts to switch states, the security checks themselves may fail. To prevent these security checks from failing, it may be desirable to perform checks on domain transition disabling configuration parameters as soon as possible.

[0088] Therefore, this check can be performed in response to an attempt to extract an address from a secure address zone, rather than waiting for the instruction to be extracted and decoded. By performing the domain translation disabling configuration parameter check early in the pipeline, this reduces the likelihood of security checks failing due to a lack of configuration resources. At the time the check is completed, it may not be known whether the instruction being extracted is actually the one that will trigger a translation to a secure domain (e.g., if the extracted instruction is not a secure gateway instruction, entry into the secure domain may not be triggered). Therefore, the domain translation disabling configuration parameter check can be conservative, as it can be checked regardless of the type of instruction extracted if the instruction is extracted from an address in a secure address zone and the current domain is a lower security domain. It should be understood that in some implementations, the location of various checks within the pipeline may vary, but the same effect of performing the domain translation disabling check first can be achieved by performing this check later in the pipeline, but with signaling for any resulting domain translation disabling failures taking precedence over other failures.

[0089] For the inter-module call branch instructions described above, the domain translation disable configuration parameter can be used in a simulated environment. If the target program code executes on a real hardware device, the simulated computer program executing on the host data processing device simulates an instruction execution environment equivalent to the expected one. This hardware device has a control storage location for storing the domain translation disable configuration parameter and features related logic for setting and using the parameter as described above. Therefore, the computer program can have processing program logic, memory access checking program logic, and configuration parameter setting program logic. These logics simulate the functions of the processing circuitry, memory access checking circuitry, and circuitry for maintaining the domain translation disable configuration parameter in the control storage location as described above.

[0090] Description of specific examples

[0091] Figure 1An example of a data processing system 2 is schematically shown, including processing circuitry 4 for performing data processing in response to instructions fetched from a memory system 6. The memory system 6 may include caches (e.g., one or more levels of data caches and / or instruction caches) and main memory. Processing circuitry 4 includes a processing pipeline comprising multiple pipeline stages, including, for example: a fetch stage 8 for fetching instructions to be executed from the memory system 6; a decode stage 10 for decoding the fetched instructions to generate control signals for controlling the remaining pipeline stages to perform data processing; and an execution stage 12 for executing the decoded instructions to perform the data processing operation. A register 14 is provided for storing input operands of the instructions processed by pipeline 4. Register 14 includes several types of registers, including: a general-purpose (integer) register 16 for storing integer values; and a control register 20 for storing control parameters used by the processing circuit 4 to control instruction execution and other operations such as exception handling and security checks. 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.

[0092] It should be understood that Figure 1 The pipeline stages shown are simplified representations, and other types of pipeline stages may also be provided, such as: a rename stage for performing register renaming; a release stage for queuing instructions awaiting execution and releasing them for execution when their required operands are available; and a write-back stage for handling instruction submissions and writing the results back to register 14. The pipeline can be an ordered pipeline or an unordered pipeline.

[0093] A Reliability, Availability, and Serviceability (RAS) error detection / correction circuit 29 is provided to perform error detection or correction operations to detect or correct hardware failures that occur randomly during the operation of the processing system. For example, a hardware failure may occur due to a particle impact causing a stored state bit or a signal on a processing logic path to toggle between 0 and 1. Furthermore, hardware failures may be caused by physical degradation of electronic circuitry over time; for example, electromigration may eventually cause a memory element to get stuck at 0 or 1, regardless of the bit value written to that memory element. To detect such failures, the RAS may include one or more error detection / correction mechanisms. For example, one mechanism could be providing redundant processing logic to redundantly perform the same operations as processing circuit 4, and providing comparison logic to compare the results of the main processing and the redundant processing to detect any failures. Another mechanism could be managing the setting and checking of error detection codes or error correction codes stored in association with data written to memory, such that when data is read back from memory, the corresponding error detection code / error correction code can be recalculated and compared with the stored error detection code / error correction code to detect (and, if possible, correct) errors. If a RAS error is detected, it is corrected where possible, and processing continues (e.g., this can be achieved using a three-core lockstep technique or by using error correction codes). Alternatively, if the error is uncorrectable, a fault can be signaled, which may cause the processing thread to terminate and restart. It should be understood that any known techniques for error detection / correction and recovery can be used.

[0094] System 2 also includes a memory access check circuit 22, which checks whether access to memory system 6 is permitted based on attribute data specified for each region of the memory address space. The memory access check circuit includes a Security Attribute Unit (SAU) 24, which stores security domain definition data that defines a security domain associated with each corresponding region of the memory address space. Based on the security attribute data, the Security Attribute Unit 24 can check whether memory access is permitted according to the current operating security domain 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 may not directly store the security domain definition data, but may access security domain definition data stored elsewhere to perform the memory access check. In some systems, the security domain definition data may be stored in memory system 6, or it may be a configuration register elsewhere in system 2. The processing circuit 4 can operate in the current operating security domain, which typically corresponds to the security domain associated with the address of the currently executing instruction (although some anomalies may exist, such as when transitioning between processing domains). When an instruction branches from an address in a region designated by SAU24 as being within a domain to an address in a region associated with a different domain, this can trigger a transition of the current security domain in which processing circuitry 4 is operating. In other embodiments, such a branch may not directly trigger a transition of the current security domain, but rather trigger additional security checks, such as the presence of a gateway instruction, which in these embodiments may be the gateway instruction itself that triggers the change of the current security domain. Generally, when operating in a secure domain, processing circuitry can access data in memory regions associated with both the secure domain and the lower security domain. When operating in a lower security domain, processing circuitry can access data in regions associated with the lower security domain, but may not be permitted to access data in regions of the address space designated by SAU24 as being associated with the secure domain. This allows for the protection of sensitive data from unauthorized access from code operating in the lower security domain.

[0095] Furthermore, the memory access checking circuitry may include a memory protection unit (MPU) 26 that checks whether memory access to the memory system 6 meets access permissions. These access permissions may specify, for example, which privilege levels of the processing circuitry 4 are allowed to access a given region of memory, or may specify whether a memory region in the address space is accessible via both read and write operations, or is a read-only region where writing is prohibited. For example, the access permissions used by the MPU 26 may be specified by a higher-privileged process (such as a super administrator or operating system) to control which regions of memory are allowed to be accessed by lower-privileged processes (such as applications), and how these regions are accessed (read-only or read / write, and whether the memory is executable). In some implementations, the MPU 26 may also check which regions of memory are allowed to be accessed by privileged processes, and how these regions are accessed (read-only or read / write, and whether the memory is executable). The MPU 26 may allow different permissions to be specified for lower-privileged and privileged accesses. The permissions provided by the MPU 26 may be orthogonal to those provided by the SAU 24, such that for a given memory access to be allowed, it should pass the check based on the access permissions defined by both the MPU 26 and the SAU 24. MPU 26 may include separate secure MPU 26-S and lower-security MPU 26-NS, each associated with a security domain within a security domain, allowing different memory access permissions to be specified for a given memory region depending on whether the current domain is a secure domain or a lower-security domain (e.g., a region may be read-only in a lower-security domain, but both readable and writable in a secure domain).

[0096] Therefore, as Figure 2 As shown, processing circuit 4 can support data processing in one of a plurality of security domains, including at least a security domain (S) and a lower security domain (also referred to as the lower security domain, NS). Although Figure 2 A system with only two security domains is shown, but three or more domains associated with different security levels can be provided. In this case, the S domain and NS domain shown can be any two of the three or more domains provided.

[0097] Furthermore, within a given security domain, such as Figure 2 As shown, the processing circuit can perform data processing in one of several modes, including a handler mode (H) for exception handling and a thread mode (T) for background processing. Figure 1As shown, exception control circuitry 28 can be provided to control exception handling operations, including exception entry transitions and exception return transitions, and any saving / restoration of architectural state during such transitions. Separating exception handling into a dedicated handler mode H helps simplify the management of which registers the processing circuitry is allowed to access (e.g., some registers used for exception handling are accessible in handler mode H but inaccessible in thread mode T). Generally, when operating in handler mode H, it can be assumed by default that the processing circuitry 4 has a higher privileged operating mode, such that access to memory and registers is controlled according to a specific privilege level other than the least privilege level, while in thread mode T, the processing circuitry can have one of several different privilege levels depending on other architectural states stored in control register 20.

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

[0099] ● Thread-safe mode (short for the combination of security domain and thread mode)

[0100] ●Lower-safe threading mode (a combination of lower-safety domain and threading mode)

[0101] ●Security handler mode (a combination of security domain and handler mode) and

[0102] ● Lower security handler mode (a combination of lower security domain and handler mode).

[0103] As described below, the actions performed in response to exceptional conditions and exceptional return conditions may depend on specific transitions between these corresponding combinations of security domains and modes. Attributes in the Security Attribute Unit (SAU) 24 manage the boundaries between security domains and lower security domains. Attributes in the Security MPU 26-S can be used to manage the boundaries between different threads operating in secure thread mode and between these threads and the secure operating system. Attributes in the Lower Security MPU 26-NS can be used to manage the boundaries between different threads operating in lower security thread mode and between these threads and the lower security operating system.

[0104] Figure 3 Some registers in register 14 of the processing system are shown. It should be understood that this representation does not show all possible registers available, and many other registers may be provided. Figure 3 As shown, register 14 includes general-purpose register 16 and multiple control registers 20. Figure 3This example only shows some of the control registers (other control registers may also be provided). In this example, 16 general-purpose registers are provided, labeled R0 through R15. In some implementations, general-purpose register 16 may also include a program status register (XPSR), which stores condition flag values ​​and other information related to the current context.

[0105] In general-purpose registers R0 through R15, registers R0 through R12 are used to store general-purpose operands, such as input operands for arithmetic or logic instructions or operands used to derive addresses for accessing load / store instructions in memory system 6. General-purpose registers R13 through R15 can be used for such general-purpose operands, but they also serve other control functions.

[0106] Register R15 serves as the program counter (PC) register, which stores the program counter and provides an indication of the current point of the program reached by processing circuitry 4. The program counter register can be used by fetch stage 8 to determine which instructions to fetch from the memory system.

[0107] Register R14 serves as the link register (LR), which stores the function return address when a function is called. This allows the address in the link register to be used to redirect program flow to the next instruction after the function call instruction once the associated processing has completed. Furthermore, in the event of an exception, the link register can be used to store the exception return value, which provides information for unstacking the control architecture state when the corresponding exception return condition is encountered. Similarly, the link register can be used to store the return address of virtual functions when performing inter-module or inter-domain function calls. These will be discussed in more detail below.

[0108] Register R13 serves as the stack pointer register, providing a stack pointer that indicates the address of the stack data structure in memory. The stack data structure can be used to save the schema state when an exceptional condition occurs and to restore the schema state when an exceptional return condition occurs. Figure 3 As shown, register R13 is grouped, allowing multiple different physical registers to be provided in the hardware. Each register can be accessed using the register specifier R13. How a particular block of registers is selected when R13 is specified can depend on several factors, including the current security domain and the mode of the processing circuitry, as well as the value of the configuration register.

[0109] For example, the grouped stack pointer registers may include a secure main stack pointer register (MSP_S), a secure process stack pointer register (PSP_S), a lower-security main stack pointer register (MSP_NS), and a lower-security process stack pointer register (PSP_NS). Generally, the secure stack pointer registers MSP_S and PSP_S are accessible to the processing circuitry 4 in the security domain S, but inaccessible in the lower-security domain NS. The lower-security stack pointer registers MSP_NS and PSP_NS are accessible in the lower-security domain. Some implementations may provide additional ways to access the grouped stack pointers, granting the security domain access to the stack pointers associated with the lower-security domains (MSP_NS and PSP_NS). 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 stack and process stack for handler mode and thread mode respectively simplifies the development of exception handler code because it means that any data that the exception handler might leave on the main stack is generally inaccessible to the thread running in thread mode after the exception returns. This simplifies exception handler code development because the exception handler does not need to include instructions for clearing all data from the main stack data structures. However, a process in thread mode T may use the main stack pointer, where the stack pointer selection value 30 stored in control register 32 controls whether the main stack pointer or the process stack pointer should be used when in thread mode T. Therefore, which stack pointer should be used can be determined not only based on the combination of the current mode (thread or handler) and the current domain (safe or less safe), but also based on the stack pointer selection value 30. Figure 3 As shown, stack pointer selection value 30 can group security states, allowing the security domain and the lower security domain to independently control whether they use the main stack pointer or the process stack pointer, respectively, using separate security versions 30-S and lower security versions 30-NS of stack pointer selection value 30. The current security domain controls which grouped versions 30-S and 30-NS are read / written.

[0110] Generally, within an exception handler operating in handler mode H or the body of a thread operating in thread mode T, the choice of a safe or less safe stack pointer depends on the current safety domain in which the processing circuit 4 is executing code. For exception entry and return, the stack and destack execution states are identified from the stack pointer associated with the safety domain of the background code running before the exception occurred.

[0111] Control register 32 may also include a privilege control value (nPRIV) 31, which controls whether code executing in thread mode is privileged or unprivileged. The privilege control value can be set differently for safe and lower security domains (e.g., safe thread mode can be unprivileged, while lower safe thread mode can be privileged, and vice versa). Alternatively, both safe and lower safe thread modes can operate at the same privilege level. It should be understood that privilege control value 31 is merely an example, and other ways of using architectural state stored in the control register to control the privilege level assigned to code in safe / lower safe thread modes may exist. Figure 3 In the example, privilege control value 31 is grouped so that separate security privilege control values ​​31_S and lower security privilege control values ​​31_NS are provided to control the privilege levels used by the thread mode in the security domain and lower security domain, respectively. However, an alternative approach could be to provide a single control bit that toggles during domain transitions.

[0112] like Figure 3 As shown, control register 32 also includes the Thread Mode Intermediate State Disable (TMID) parameter 34, also known as the Domain Translation Disable configuration parameter, which controls whether translation between a security domain and a lower security domain is enabled or disabled in thread mode. This will be discussed 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 translation between a security domain and a lower security domain in thread mode, as further described below. This can be useful for enabling deferred configuration of resources for one of the security domains / lower security domains, because disabling domain translation (which triggers a failure if an attempt is made to disable domain translation) means that a thread can be restricted to a single domain.

[0113] like Figure 3 As shown, control register 20 also includes a register providing exception number 36. Exception number 36 may not be the only value stored in this control register; other states may be stored in the same register. When the system is in handler mode, the exception number identifies the exception associated with the currently executing exception handler. When the system is in thread mode, exception number 36 is set to a default value (e.g., 0), indicating that no exception is currently being handled. Therefore, exception number 36 is also effectively an indicator of whether the system is currently in thread mode or handler mode, because if the registered exception number 36 specifies a special value (e.g., 0), the system is in thread mode, while if any other value is specified, the system is in handler mode, and a specific non-zero value identifies the currently handled exception. Therefore, a separate register to indicate the current mode in which the system is running may not be necessary. Although Figure 3It is not shown, but there may be a control register indicating whether the current domain is a secure domain or a lower secure domain. Alternatively, such a register may not be necessary, as it may be implicit in determining whether the address of the instruction being processed is in a secure region or a lower secure region of memory defined by SAU 24.

[0114] Figure 4 An example of a memory address space for addressing memory system 6 is shown. Memory address space 100 may include one or more lower-security regions 102 accessible in both the security domain and the lower-security domain, and one or more security regions 104 accessible in the security domain but inaccessible in the lower-security domain. Although for ease of explanation... Figure 4 Only one lower-security region 102 and one security region 104 are shown, but multiple regions of each type can exist, and these regions can be scattered among each other. Therefore, it is not necessary for all security regions to be in contiguous blocks, nor is it necessary for all lower-security regions to be in contiguous blocks. A lower-security region may include lower-security program code 110, stack data structure 112 (accessed using lower-security stack pointers MSP_NS and PSP_NS), and lower-security data 114. Similarly, security region 104 may include secure program code 122, stack data structure 124 (accessed using secure stack pointers MSP_S and PSP_S), and secure data 126. Furthermore, the program code, stack, and data within security region 104 or lower-security region 102 need not be organized as follows: Figure 4 The diagram shows contiguous blocks, but in practice, the stack and program code can be distributed across multiple non-contiguous blocks scattered with other data. Specific allocations of memory within the executable address range can be chosen by the software executing on the processing system, rather than being fixed by the hardware.

[0115] like Figure 4 As shown, memory address space 100 includes reserved regions 130, which in this example include addresses greater than or equal to 0xF0000000 (in hexadecimal representation; it should be understood that other examples may choose different address ranges as reserved regions 130). Reserved regions 130 represent address ranges where executable instructions are not permitted. Some of these reserved addresses may be allocated for special purposes, such as indicating function returns or exception returns, as described further below. If an attempt is made to fetch an instruction from one of the reserved addresses 130, instruction fetch level 8 may signal a failure. These reserved addresses provide the opportunity for future versions of the architecture to allocate additional addresses for special purposes, such that an attempt to fetch an instruction from one of these addresses can be interpreted as signaling the need to process a given event.

[0116] like Figure 5As shown, certain reserved address ranges are allocated to represent the specific virtual function return address 140 and virtual exception return address 142, which are used to indicate function returns for certain domain / mode transitions and exception return operations. Virtual function return address 140 is any address within a set of addresses within reserved range 130, where the most significant portion of bit 144 is set to a function return prefix value 144. In this example, the function prefix value is greater than or equal to 0xF0, making the virtual function return address within reserved range 130. The virtual function return address is used to signal that if an instruction is attempted to be fetched or executed from that virtual function return address, a function return operation should be performed. In some implementations, setting the program counter (PC) to the virtual reserved address (via a branch or some other instruction, such as a load targeting the PC) might trigger a function return operation instead of instruction fetching. To simplify hardware, it's possible that only a subset of instructions capable of setting the PC (typically instructions used to execute function returns) can actually trigger a function return operation. This provides a mechanism to avoid exposing the real function return address in the link register R14 for inter-module or inter-domain function calls, making it inaccessible to lower-security or lower-privilege code.

[0117] The virtual function return address 140 includes multiple status messages that can be set during inter-module or inter-domain function calls to indicate the attributes of the function call and / or information about how to handle the corresponding function return. In this example, the virtual function return address 140 includes an inter-module call flag (M) 146 that indicates whether the virtual function return address is set in response to an inter-module function call from handler mode to thread mode, or in response to a non-inter-module call that remains within the same mode (either in handler mode or in thread mode). In this example, the inter-module call flag 146 is encoded such that if its value is 0, it indicates an inter-module call, and if flag 146 is 1, it indicates that the mode remains unchanged during the corresponding function call. The inter-module call flag 146 can be used upon function return to determine whether the current mode should switch back from thread mode to handler mode or remain unchanged.

[0118] Furthermore, the virtual function return address 140 includes a security domain indicator (S) 148, which indicates whether the corresponding function call is made from a lower security domain or from a higher security domain. In this example, the security domain indicator is encoded such that if the call is made from a higher security domain, the security domain indicator is set to 1, and if the call is made from a lower security domain, the security domain indicator is set to 0. It should be understood that the specific encoding of the markers 146 and 148 shown in the virtual function return address 140 is only an example, and other methods may use different encodings. Additionally, the virtual function return address may include... Figure 5Additional status flags are not shown. In some implementations, the security gateway instruction is placed at the beginning of a security function that can be called from a lower security domain. This security gateway instruction causes the processing circuitry to perform a transition from a lower security domain to a security domain. Therefore, subsequent function returns can determine whether the function was called from a security domain or a lower security domain, and thus, which domain to return to for execution. If the security gateway instruction performs a transition from a lower security domain to a security domain, it can clear the least significant bit of the return address in the link register. As will be discussed later, placing S148 in the least significant bit of the virtual function return address and encoding the S148 indicator such that 0 indicates a lower security domain provides additional security protection when used in conjunction with the aforementioned security gateway instruction behavior. It should be understood that although in the above implementation, a value of 0 for S148 indicates a lower security state, and the security gateway instruction clears the least significant bit of the return address, other encodings of the S148 field can also be used to achieve the desired behavior. For example, if a value of 1 for S148 indicates a lower security state, the security gateway instruction sets the least significant bit of the return address to 1.

[0119] Virtual exception return address 142 is saved to the link register in response to certain exception entry transitions and provides a mechanism, similar to virtual function return address 140, for allowing the actual exception return address to be saved to (and subsequently restored from) the stack, thus hiding the actual exception return address relative to the lower-security process executing after the exception. Virtual exception return address 142 includes an exception return prefix 150 located in the most significant bit portion of virtual exception return address 142, which again has a value greater than or equal to 0xF0 to ensure the exception return address is within the reserved range 130. Exception return prefix 150 differs from function prefix 144, allowing virtual function / exception return addresses 140 and 142 to be distinguished from each other.

[0120] The virtual exception return address 142 includes a mode flag 152 and a security domain flag (S) 156. The mode flag indicates the mode from which the exception occurred (thread or handler), and the security domain flag indicates the security domain from which the exception occurred (safe or lower security). In some implementations, an exception security domain flag (ES) 157 may also be present, indicating which security domain (safe or lower security) the exception was initially taken to. Furthermore, the exception return value includes a Thread Mode Intermediate State Enable (TMIE) value 158, which indicates whether, prior to the exception, the TMID flag 34 indicated that domain translation was disabled or enabled in thread mode within the context of the exception occurrence. For backward compatibility reasons (so that legacy code that would expect to set the bit corresponding to 158 to 1 would represent TMIE flag 158 as domain translation enabled in thread mode), the TMIE flag 158 in the virtual exception return address has the opposite encoding to the TMID flag 34 in control register 32, such that when the TMIE flag 158 is set in the virtual exception return address 142, the value of the TMID flag for the current security domain is inverted. While the TMIE flag 158 itself is not required to control the exception return operation, saving the TMIE flag 158 to the virtual exception return address effectively provides context saving / restoration functionality. This allows the value of the TMID flag 34 in control register 32 (used by the returning process) to be restored to its state before the exception occurred upon return from an exception. Upon return from an exception, the value of the TMIE flag 158 is inverted again, and the inverted value is written to the TMID flag 34 in control register 32. Although Figure 5 The specific encoding for TMIE tag 158 is shown, but this encoding is not required and other ways of indicating that you want to restore the value to TMID 34 can be used.

[0121] It should be noted that since the status information 146, 148, 152, 156, 157, and 158 recorded in the virtual function return address 140 and the virtual exception return address 142 can take different values, this means that within the reserved range 130, there exist multiple different addresses that each represent the virtual function return address 140, and multiple different addresses that each represent the virtual exception return address 142. Therefore, the specific virtual address saved to the link register R14 when a function is called or an exception is entered is selected based on the information to be encoded in the status flags.

[0122] Figure 6 Examples of different stack frames that can be saved to memory during inter-modal or inter-domain function calls or upon entering an exception are shown. The specific stack data structure to which a stack frame is saved depends on the current mode and security domain at the time of the function call or exception, and if the current mode is threaded, the stack selected also depends on the stack pointer selection value 30 associated with the current domain described above.

[0123] like Figure 6 As shown in section 170, for function calls other than inter-domain / inter-modal function calls (which do not trigger any mode or domain transitions), there is no need to store the stack frame on the stack because for function calls within the same mode and the same domain, the actual function return address can be simply saved to the link register R14 without hiding the function return address from the code being executed after the function call.

[0124] For inter-domain function calls or inter-module function calls from a safe domain to a lower safe domain, the function return stack frame 172 is saved to the stack. For inter-domain function calls from a safe domain to a lower safe domain, stack frame 172 is saved to the safe stack indicated by one of the safe stack pointers. If the inter-domain function call is made from handler mode, this will be the safe main stack pointer MSP_S; if the inter-domain call is made from thread mode, the stack frame is saved to either the safe main stack (MSP_S) or the safe process stack (PSP_S), the pointers of which are indicated by the stack pointer selection value 30-S of the safe domain. For inter-module function calls, by default, these calls are made from handler mode, therefore the main stack pointer associated with the current safe domain is used.

[0125] like Figure 6 As shown, the function return stack frame 172 includes a return address 174, which represents the actual function return address to which processing will return when returning from the called function. The actual function return address can be set to the address of the next instruction sequentially following the address of the function call branch instruction. Furthermore, the function return stack frame includes a status data word 176 (FRETPSR), which provides information for determining how to handle the corresponding function return. In this example, this includes a handler privilege deprivation to thread mode (HDT) flag 178, which indicates whether the function return stack frame 172 is saved in response to a call from handler mode to thread mode. For example, if the function call is not an inter-modal function call, the HDT flag may have a value of 0, thus not causing a deprivation from handler mode to thread mode; if the function call is an inter-modal function call, the HDT flag may have a value of 1. Additionally, the status data word 176 includes an exception number value 179, which corresponds to the value of the exception number register 36 when the function is called. This acts as a "handler mode indicator value," indicating whether the function return stack frame is saved in response to a function called from handler mode or thread mode. It should be understood that other information may also be stored within the function return status word 176, or in other parts of the function return stack frame 172.

[0126] Examples of exception stack frames 180 and 182 are in Figure 6The upper half is shown. In response to an exception, one or both of the first (caller) stack frame 180 and the second (callee) stack frame 182 are saved onto 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 the "caller" register and the "callee" register). The caller register is the register that the exception control circuitry 28 implemented in hardware is responsible for saving onto the stack. Therefore, the software of the exception handler does not need to include instructions for saving the caller register onto the stack data structure.

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

[0128] For exceptions where only the caller stack frame 180 is saved to the stack, after exception control circuitry 28 saves the caller stack frame 180 to the stack in response to the exception event, execution of the exception handling code can begin. The exception handler software can then save the state from the additional callee registers onto the stack, if the exception handler software knows it will overwrite this state during execution. However, performing this state saving by controlling the load / store unit of processing circuitry 4 to save relevant data to memory in response to load / store instructions provided in the exception handler code can be slower than the case where exception control circuitry 28 controls the stack in the hardware. However, allowing partitioning between the caller and callee register states can be beneficial, allowing software execution after entering an exception to 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, thus avoiding the energy and time associated with such state saving in exception control circuitry 28 and the hardware. It can encourage exception handler code writers or compilers of such code to use the caller register first and then the additional callee register, in order to reduce the need for additional state saving in the software.

[0129] However, if an exception entry results in a transition from a secure domain to a lower secure domain, and the original background processing was performed in the secure domain prior to the exception, then if the exception control circuitry 28 only saves the caller register to memory, this could allow the callee register within register set 14 to be accessed by the lower-secure exception handler to execute after the latest exception. This could be undesirable because the callee register could include information derived from a secure region of the memory address space, which SAU 24 would otherwise prevent the lower-secure exception handler from accessing.

[0130] Therefore, for certain transitions from a security domain to a lower security domain where background processing was previously performed, in addition to saving the caller register, exception control circuitry 28 can also save the callee register to the relevant stack data structure and clear the contents of the saved registers (including both the caller and callee registers). Thus, by performing this additional state saving in hardware, it means that lower-security software, which would typically save the callee register in this situation, cannot access the potentially secure information stored in those registers before an exception occurs.

[0131] Therefore, for certain exception entry transitions, in addition to storing the caller's stack frame 180, the second (callee's) stack frame 182 can also be saved to the stack (under the hardware control of the exception control circuit 28, i.e., without the need for the processing circuit 4 to execute explicit load / store instructions). It should be noted that although in Figure 6In this context, the callee's stack frame is referred to as a separate stack frame from the caller's stack frame. However, others might consider the callee's stack frame as an extension of the caller's stack frame, thus the combination of 180 and 182 is considered a single stack frame. Both methods can be considered equivalent.

[0132] The callee stack frame 182 includes additional callee state, which includes registers R4-R11 not saved in the caller stack frame 180. Optionally, the floating-point context may also be included in the callee stack frame 182. The additional state saved by hardware may also include a predetermined integrity signature 190. Integrity signature 190 is included in the callee stack frame 182 when both the caller state and the callee state are saved by exception control hardware 28 but are lost from the caller exception stack frame 180. The value of integrity signature 190 corresponds to an address within the reserved range of non-executable address 130, such that a fault is signaled if an attempt is made to fetch instructions from it. The value of integrity signature 190 may not match any valid virtual function return address 140 or virtual exception return address 142. Integrity signature 190 can be used to detect certain forms of attacks that can be installed on processing circuitry to attempt to circumvent hardware-provided security protections that enforce partitioning between security domains and lower security domains. One possible attack path is for an attacker to attempt to enter exception handling by performing an exception entry transition, but then forge a different type of return transition as the expected return transition from an exception entry, such as executing a function return transition. Signature 190 is located on the stack frame at the same relative position as the position in the function return stack frame 172 used to store the function return address 174. Therefore, if a return address 174 is detected to match integrity signature 190 upon function return (which corresponds to any non-executable reserved address 130), a fault can be triggered because this means that the stack frame used to execute the function return was actually saved to the stack in response to the exception entry event, which could be an indicator of an attack. Similarly, in the case of an exception return from the stack with additional architectural state associated with the callee's registers, part of the security check could be to check whether the value at the relevant offset in the stack corresponding to integrity signature 190 has the expected value, as the absence of a signature might indicate that the exception return event was executed based on a stack frame saved to memory in response to a function call, which could again pose a security risk.

[0133] like Figure 6As shown, as part of the predefined signature value 190, the TMIE cross-check value 192 may be stored within a bit of the predefined signature 190 (therefore, effectively, the predefined signature 190 may have two or more valid values, each within the reserved address range 130, but separate from the addresses used for virtual function return values ​​and virtual exception return values). When an exception occurs that saves the callee stack frame 182, the TMIE cross-check value 192 is set to a value indicating the state of the TMIE flag 158 written to the virtual exception return address 142 in the link register (e.g., the cross-check value 192 may be equal to the TMIE flag 158, or may be inverted relative to the TMIE flag 158, or may use another encoding to represent the state of the TMIE flag). In the case where the callee stack frame 182 is saved to the stack, this indicates that if the original background processing executed before the exception was in a safe domain, the exception is being moved from a safe domain to a lower safe domain, thus potentially posing a risk that lower-safe code executing after the exception might modify the TMIE value in the virtual exception return address 142 in an attempt to prevent safe code from functioning correctly after the exception returns. The TMIE cross-check value 192 provides cross-checking to detect tampering with the TMIE value 158.

[0134] In some system implementations, it may be desirable for certain types of exceptions to allow their exception handlers to execute in an unprivileged state. This can be useful because, for certain types of exceptions associated with devices controlled by library code provided by an untrusted third party, it may not be desirable to allow exception handlers provided by the untrusted third party to have all the privileges available for the handler mode, since they are not trusted to modify certain state information. However, as... Figure 2 As shown, by default, exception handler mode operates in privileged mode. Therefore, to enable exception handlers to operate in unprivileged mode, a switch back to thread mode is required. However, in typical implementations, the mechanism for switching from exception handler mode to thread mode is via exception return. It is generally undesirable for the original exception to trigger an exception return (after modifying the return address, thus returning to unprivileged library code instead of the previous background processing) because this would lower the execution priority of the original exception. Lowering execution priority in this way prevents exception handling routines from being correctly prioritized. Therefore, it is preferable if the handler code processing the original exception can switch to thread mode without triggering an exception return.

[0135] In a typical system, since the only mechanism for switching from handler mode to thread mode is via exception return, therefore... Figure 7As shown, in order to deprivilege the exception handler to process the original exception, it would be necessary to generate a further exception (e.g., a hypervisor invocation exception, SVC) so that an exception return stack frame can be built in memory. This exception return stack frame does not represent the actual processing context executed before the exception, but is forged to ensure that when the SVC exception returns from it, processing will switch to thread mode, so that the body of the previously occurring exception can be processed in thread mode in an unprivileged state.

[0136] For example, such as Figure 7 As shown, when processing some background code in thread T1 in thread mode, an interrupt IRQ occurs, and the type of this interrupt IRQ is to be passed to the unprivileged library. Figure 7 At step 1, the interrupt causes exception control circuitry 28 to trigger the register state onto the process stack to maintain the register state of thread T1. The interrupt causes a transition from thread mode to handler mode because the exception initially occurred in handler mode by default. Although the body 200 of the exception handler for handling IRQ exceptions will be executed by an untrusted library, the exception handler for handling IRQ exceptions is provided with wrapper code 202 to execute before and after the main exception handler body 200. The wrapper code executes in handler mode and controls the operations used to generate the SVC exception to ensure that the body can be handled in thread mode.

[0137] Therefore, in Figure 7 In step 2, the wrapper code in handler mode generates an SVC exception. This exception does not actually handle the original IRQ interrupt; it is generated solely to allow the IRQ handler to switch to thread mode. The SVC exception causes exception control circuitry 28 to execute register states onto the main stack pointed to by the main stack pointer MSP associated with the current domain (since the current mode is handler mode, the main stack is used). The SVC exception handler, executed in response to the SVC exception, switches the process stack pointer to point to the thread T. IRQ Related different stack structures PSP IRQ The thread will execute the main exception handler body 200 to handle the original IRQ exception. The SVC exception handler forges a stack frame on the process stack that indicates an exception number of zero in its exception return status information (ERETPSR) to indicate that the corresponding exception return should return to thread mode. Note that this value is false because the processing performed before the SVC exception is actually in handler mode.

[0138] When the SVC exception handler completes, it branches to the return address of a dummy exception, which is used by the PSP. IRQThe spurious exception return stack frame created on the stack pointed to is used to trigger the exception return, instead of the exception stack frame created on the main stack in step 2. Then, the exception return is executed by the exception control circuit 28, which... Figure 7 Step 3 causes the hardware to exit the PSP IRQ De-stack. The hardware detects that bit 152 in the spurious virtual exception return address 142 indicates a return to thread mode, and therefore, at step 4, the subsequent body of the exception handler 200 for handling the IRQ exception can be executed by the unprivileged library in thread mode. Note that this is done without returning from the original IRQ exception, therefore the priority of the exception handler for handling the IRQ exception is not reduced.

[0139] Once the main exception handler 200 completes, another SVC exception call is made at step 5 (SVC is an exception type that can be voluntarily triggered by the software, rather than an exception type triggered by an unexpected or erroneous event), which again causes an exception to be called by the PSP. IRQ The pointer points to the further hardware stack of the process stack, and the invoked SVC handler subsequently corrupts the process just executed by the PSP. IRQ The stack frame created on the process stack is pointed to, and the process stack pointer of the current security domain is subsequently updated to restore the previous stack pointer PSP1 associated with the background thread T1. Figure 7 At step 6, the SVC exception generates an exception return, which then triggers further hardware destacking from the main stack using the MSP (i.e., destacking the stack frame created during step 2). After any remaining wrapper function 202 is executed in handler mode, a further exception return is generated at step 7, which causes the register state associated with thread T1 to be destacking from the process stack pointed to by PSP1 (i.e., destacking the stack frame created during step 1). Processing then continues in the background code of thread T1, which is executing in thread mode.

[0140] Figure 7 The process illustrated allows certain types of exceptions to be deprived of privileges, enabling their exception handlers to operate in thread mode. However, it has several drawbacks. First, due to the forgery of the required exception stack frames, it is difficult to generate the software code to control this process, making the programmer prone to errors. This could provide attackers with vulnerabilities that could be exploited or prevent the system from functioning properly, or provide attackers with a way to extract secret values ​​such as encryption keys.

[0141] Another drawback is that, for this approach, the exception priority of the SVC exception (executed at the beginning and end of the main exception handler body 200 to create dummy stack frames and clear them before returning from the original exception) must be higher than the priority of each interrupt IRQ requiring privilege deprivation. This can complicate the design of real-time systems because the SVC exception always has the same priority, and therefore the worst-case interrupt latency of other IRQ exceptions can extend the duration of the longest SVC call. This is potentially undesirable.

[0142] also, Figure 7 The method shown is very slow, which is a major obstacle to using unprivileged libraries with critical interrupt latency. This poor performance is caused by several factors, including... Figure 7 Manually creating exception stack frames when handling SVC exceptions between steps 2 and 3, and the fact that two different SVC exceptions are required, will... Figure 7 Steps 2, 3, 5, and 6 trigger four additional register status stack and destack events, indicating memory access latency that is unnecessary if the exception handler for handling IRQs executes only in handler mode. Therefore, performance costs may mean that some system designers may feel they cannot use devices associated with untrusted library code, such as wireless network interfaces or USB controllers, which could limit the flexibility of system design. Figure 7 As shown in the bottom section, in this example, the entire privilege removal process is performed in a lower security domain, but it should be understood that the process can also be performed within a security domain.

[0143] Figure 8 An alternative method for improving the performance of exception privilege removal is illustrated using intermodal call branch instructions as described in this application. By providing intermodal call branch instructions that can branch to a target address specified by the instruction and set the function return address to indicate the address to which processing should return once the function has completed, and by triggering a switch from handler mode to thread mode, this means that privilege removal of interrupts can be performed faster, and performance impact, complexity, and [other benefits] can be reduced. Figure 7 The method shown relates to the other issues mentioned above. Using this method, responding to IRQ exceptions that would be handled in an unprivileged state can be much simpler.

[0144] Figure 8 Step 1 and Figure 7The steps are the same. In step 2, a wrapper code 203 is executed to prepare for the execution of the main interrupt handler body 201, which has an inter-module call branch instruction as its last instruction before the main interrupt handler body 201. This inter-module call branch instruction specifies the address of the first instruction to be executed in the main exception handler body 201 as the branch target address. In some operating systems, wrapper 203 may be the same as wrapper 202, except that it executes the inter-module call branch instruction instead of triggering an SVC exception. In some implementations, the inter-module call branch instruction may be a special instruction code, different from the instruction code used for non-inter-module call branch instructions that do not transition from handler to thread mode. Therefore, in Figure 8 At step 3, the execution of the inter-module call branch instruction triggers a switch from handler mode to thread mode, and then the main exception handler body 201 continues in... Figure 8 Step 4 is executed in thread mode. There is no need to call an SVC exception.

[0145] When performing intermodal function calls, information can be stored in the virtual function return address 140 to indicate (using intermodal call indicator 146) that the function call is an intermodal call, so that when in Figure 8 When the corresponding function return is triggered at step 5, processing circuit 4 can detect indicator 146, and in addition to branching to the function return address 174 associated with the previous function call (stored in function return stack frame 178), it also detects that the current mode should switch back from thread mode to handler mode. Then, in Figure 8 At step 6, some remaining wrapper code 203 executes in handler mode, followed by step 7, where an exception return is performed to return from the handler to the background thread T1 that was executing before the IRQ exception occurred. In some systems, the main interrupt handler body 201 ( Figure 8 (in Chinese) can be connected with the main interrupt handler body 200 ( Figure 7 The difference is that, instead of triggering an SVC exception to return from the unprivileged main interrupt handler body, it can be done by simply branching to... Figure 8 Step 3 involves requesting a return by processing the virtual function return address 140 in the link register. Therefore, the main interrupt handler body 201 ( Figure 8 (The function in the middle) can be a standard C function and does not require any special processing.

[0146] Therefore, using this method, the only hardware stack and destack operations required are those for saving and restoring the register state associated with the background code T1, and no additional hardware stack and destack operations are needed for the two SVC exceptions. Furthermore, this method is easier for the compiler or programmer to code, reduces the chance of errors, and does not require the SVC exceptions to have a higher priority than all exceptions requiring privilege deprivation.

[0147] To improve security by limiting the number of opportunities to switch security domains, it may be necessary to prevent inter-modal function calls from changing security domains, instead allowing changes only between modes. Therefore, when executing an inter-modal function call branch instruction, processing circuit 4 can maintain the current security domain as it was before the branch instruction was executed. Figure 9 As shown, a combination of domain / pattern function return transitions from lower-safety thread mode to safe handler mode can be disabled to maintain safety. This can be enforced by explicitly checking whether a return to a safe domain is requested upon function return from a lower-safety thread mode, and by triggering a fault if a fault is detected, as referenced below. Figure 15 As stated above.

[0148] However, for intermodal function returns, such as Figure 10 As shown, at least for cases where the inter-module function return value is from a thread-safe mode to a lower-safe handler mode, it may be desirable to allow combined mode / domain conversions. This allows the compiler to use methods such as... Figures 11A to 11C The technique shown is called tail calling. In some implementations, tail calling may be prohibited for security reasons, for function calls that are safe to a minimum of security. Therefore, although support may be required... Figure 10 The example shows a safe thread to lower-safety handler mode return conversion, but support may not be required. Figure 9 The example shows the transition from a lower-security thread to a security handler module.

[0149] like Figure 11A As shown, some high-level code (which will be compiled into assembly code supported by the instruction decoder 10 of the processing system) may include nested function calls, in which a second function fn2 is called within a first function fn1, and the call to function fn2 is positioned such that there are no further instructions of fn1 between the end of fn2 and the end of fn1.

[0150] In this scenario, such as Figure 11BAs shown, one option for the compiler to generate assembly code is to generate a call branch instruction (BL, also known as a branch and link instruction) for each call to fn1 and fn2. This call branch instruction triggers the saving of the function return address to the link register LR (R14) and a branch to the target address representing the beginning of the function code. Then, a function return instruction (indirect branch instruction BX, which specifies the link register as its address operand) is generated, indicating that processing should return to the return address previously saved to the link register. Figure 11B The call branch instruction used to call fn1 is not shown because it will be part of the code that calls fn1, and Figure 11B Only the function code for fn1 and fn2 is shown. Therefore, for fn1, the compiler generates BL instruction 283 (calling fn2) and BX instruction 286 (returning from fn1 to the code that called fn1). For fn2, the compiler generates BX instruction 284 for returning from fn2 to fn1. To ensure that the return address of fn1 is preserved when fn2 is called, the fn1 code also includes push instruction 282 to push the contents of the link register onto the stack before calling fn2, and pop instruction 285 to restore the link register from the stack before returning from fn1. In practice, since fn2 is the last activity to be executed within fn1, pushing and popping the link register of function 1 onto and from the stack incurs some unnecessary memory performance overhead.

[0151] Therefore, as Figure 11C As shown, an alternative method for compiling the function could be to use a non-call branch instruction 287 that does not update the link register to call the code associated with fn2, thereby effectively passing the return address stored in the link register to fn1 through fn2. This means that when the final return branch 288 is executed, the background code being processed before returning to fn1 is handled. This method is called tail calling and can improve performance by avoiding the need for PUSH 282, POP 285, and BX 286 instructions.

[0152] However, when function 1 is in a lower thread-safe mode and passes through Figure 10In the example shown, where function 2 is called via an inter-module function call and is in thread-safe mode via an inter-domain function call (a call from lower security domain NS to security domain S), this means that to support tail calls, the subsequent return branch instruction 288 would need to trigger a direct return from thread-safe mode to lower security handler mode. If combined domain / mode transitions are not supported, tail calls cannot be made, which could require recompiling much existing legacy code. Therefore, supporting combined domain / mode transitions may be more efficient when the combined domain / mode transition is from thread-safe mode to lower security handler mode. However, by disallowing inter-module function returns from lower security domains to security domains, this improves security because it restricts the pathways to security domains. As mentioned earlier, such combination of transitions may not be necessary because tail calls from security domains to lower security domains may already be disabled in legacy code.

[0153] Figure 12 This is a flowchart illustrating the steps executed in response to a function call branch instruction (BLX). These steps are executed by processing circuitry 4 under the control of instruction decoder 10 in response to the decoding of an instruction identified as a function call branch instruction. At 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 different instruction encodings compared to 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 with a separate parameter specified in the instruction encoding that identifies whether it is an intermodal call branch instruction. Figure 12 In the exemplary implementation shown, there are two variants of the inter-module call branch instruction, BLXT and BLXTI, both of which trigger inter-module function calls, but they differ in how they set the TMID parameter 34 in control register 32. It should be understood that some system implementations may not support both variants of the inter-module call branch instruction and may only have one of the BLXT and BLXTI variants. Furthermore, some implementations may have further variants of the inter-module call branch instruction.

[0154] If the function call branch instruction is not an inter-module call branch instruction, then at step 302, the processing circuit 4 (under the control of the instruction decoder 10) determines whether the function call is an inter-domain function call from a security domain to a lower security domain. In some implementations, such a security-to-lower-security-domain call can be signaled by another variant of the function call branch instruction, BLXNS, which has a dedicated instruction code to distinguish it from other types of function call branches. Furthermore, in some implementations, whether the BLXNS instruction triggers an inter-domain call may also depend on the branch target address specified by the instruction, specifically whether the least significant bit of the branch target address is 0. In some examples, during a valid function call or when branching from a lower security code into a security domain, in response to a security gateway instruction executed as the first instruction in the security code after the function call, the least significant bit of the function return address can be cleared to 0 to ensure that subsequent function returns and then returns to the lower security domain, preventing the lower security code from spoofing the security code to branch to any location within the security address region defined by SAU 24 by providing a function return address in the security region. Since the safety of function returns from a safe-to-lower-security domain can be ensured by clearing the least significant bit of the branch target address (using the BXNS instruction), it may be convenient to use a similar scheme to ensure the safety of function calls from a safe-to-lower-security domain (using the BLXNS instruction). Therefore, when the presence of an inter-domain call instruction BLXNS is detected and the least significant bit of the branch target address is set to 0, this can be considered a safe-to-lower-security domain call. In some implementations, the safe-to-lower-security domain call instruction (BLXNS) may only be available in the instruction set when processing circuitry 4 is operating in a security domain (and therefore can be detected by decoding stage 10). In such an implementation, an attempt to execute the BLXNS instruction from a lower-security state may cause decoding stage 10 to fail to recognize the instruction as a valid instruction for the current state, and therefore processing will not reach step 300.

[0155] If the function call is a lower-security-to-lower-security domain call, then at step 304, the function call can be processed without any specific security risks, and at step 304, the link register (R14) is set to the function return address. The function return address has the value of the address of the instruction following 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). At step 306, the program counter register R15 is updated based on the branch target address specified by the function call branch instruction, such that processing proceeds with the instruction at the branch target address. This represents the normal state of branch processing for function calls, where these function calls do not trigger any domain changes or mode changes.

[0156] If it is determined at step 302 that the function call branch is a safe-to-lower security domain call, then at step 307, processing circuit 4 determines (based on whether exception number 36 is a special thread mode value 0) whether the current mode is thread mode, and also determines whether the Thread Mode Intermediate State Disabled (TMID) parameter 34 indicates that domain switching is disabled in thread mode. If the current mode is thread mode and inter-domain switching is disabled in thread mode, then at step 308, the processing circuit signals a fault. The specific type of fault signaled can be a dedicated fault type, used only for exceptions triggered by attempts to switch security domains in thread mode when TMID flag 34 indicates disabling. Alternatively, the fault can point to an exception handler for handling various fault conditions, and in such cases, a corrective flag associated with the inter-domain switching disabled check can be set so that the exception handling routine can easily identify the cause of the fault and the subsequent actions to be performed. Figure 12 In this context, this is referred to as INVTMI (Invalid Thread Mode Intermediate State) UsageFault, although the exact naming convention for this type of fault may certainly vary. For calls between safe and lower security domains, handling INVTMI faults within the safe domain (the current domain before the attempted call) is useful because the process used to manage the thread requesting the safe-to-lower security transition will be a safe thread managed by the safe operating system, which may be better suited to handle INVTMI faults, allowing the configuration of any resources required for the thread to operate in the lower security domain.

[0157] If at step 307 it is determined that the current mode is handler mode (e.g., when exception number 36 is non-zero) or TMID parameter 34 is 0, indicating that domain translation is enabled in thread mode, then at step 310, the processing circuitry sets the link register R14 to one of the return address values ​​in the valid virtual function return address values ​​140, such as... Figure 5As shown. In the virtual function return address 140, the inter-module flag (M) 146 is set to 1 to indicate that it is not an inter-module function call, and the security domain flag (S) 148 is also set to 1 to indicate that the call was made from the security domain. At step 312, the function return stack frame 172 is saved to the stack data structure pointed to by the security main stack pointer MSP_S or the security process stack pointer PSP_S (depending on whether the current mode is handler mode or thread mode, and if it is thread mode, it depends on the stack pointer selection value 30 of security domain 13_S). The saved function return stack frame 172 specifies the HDT flag 178 to be equal to 0 to indicate that it is not an inter-module function call. In addition, the exception number field 179 in the function return stack frame 172 is set to be equal to the current value of the exception number 36 in the control register 20 to indicate whether the call was made from handler mode or thread mode. This exception number field 179 is used as a handler mode indicator value to indicate whether the current mode is handler mode. The function return stack frame also includes the function return address 174, which is set in the same way as in step 304, but this time it is saved to the stack instead of the link register. This prevents the lower-security code to be executed after the inter-domain call from knowing what instructions were being executed in the security code before the function call. At step 314, the processing circuit then switches the current domain to the lower-security domain, and the method proceeds to step 306, where the branch to the branch target address specified by the function call branch instruction is executed in the same manner as described above.

[0158] Referring again to step 300, if the function call branch instruction is an inter-module call branch instruction, then at step 320, the processing circuitry determines whether the current operating mode is thread mode, and if the current mode is thread mode, then at step 322, a usage fault is signaled. This may be a different type of usage fault than INVTMI UsageFault. Since inter-module call branch instructions are designed to trigger a switch from handler mode to thread mode to support interrupt privilege deactivation, an attempt to execute it from thread mode is erroneous. Suppressing the execution of inter-module call branch instructions while in thread mode avoids potentially unpredictable results due to incorrect stack frame setup in response to the call branch, which could lead to security vulnerabilities. Therefore, inter-module call branch instructions can only be executed from handler mode.

[0159] If the current mode is determined to be the process mode at step 320, the method proceeds to step 324, where the link register is set to one of the return address values ​​in the special virtual function return address value 140. However, unlike step 310, at step 324, the inter-module flag (M) 146 is set to 0 to indicate that the corresponding function return should be considered an inter-module function return. Furthermore, the security domain flag (S) 148 in the function return value 140 indicates the current operating domain when executing the inter-module call branch instruction (inter-module calls can be made from a security domain or a lower security domain).

[0160] At step 326, before executing the inter-module call instruction and stack pointer selection value 30, the processing circuit saves the function return stack frame 172 to the stack selected based on the domain and mode of the operation. The function return stack value again includes the function return address 174 (set in the same manner as in steps 304 or 312), and a handler mode indicator value corresponding to the current value of exception number 36. When an inter-module call is made from processor mode, the exception number field 179 can be expected to be non-zero. For inter-module calls, the 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 inter-module call that provides cross-checking information to check whether the inter-module flag 146 is correct or has been tampered with by untrusted code when the corresponding function return is made using virtual function return address 140. It should be noted that after saving the function return stack frame in step 312 or 326, if further stack information is needed before the currently saved stack frame is unstacked, the corresponding stack pointer will also be updated to point to the location where further stack information should be saved to the stack.

[0161] At step 328, optionally, the processing circuitry triggers an error synchronization barrier operation to be performed in response to an inter-modal call branch instruction. For example, the error synchronization barrier operation may involve the processing circuitry 4 suspending further execution of the instruction until the results of at least some types of error detection or correction operations used to check the validity of any previously executed instructions have been completed and confirmed to be error-free, involving correctable errors, or errors that can be properly attributed to the execution of instructions before the change from handler mode to thread mode. The error synchronization barrier operation is an operation that ensures that at least some types of errors detected by the reliability, availability, and serviceability (RAS) error detection / correction circuitry 29 are attributable to code executing before the mode change caused by the inter-modal call branch instruction, and distinguishes them from errors that occur when processing code executing after the mode change caused by the inter-modal call branch instruction. For inter-modal call branches, it may be useful to accurately determine whether a detected RAS error affects higher-privileged code executing before the mode change caused by the inter-modal function call or lower-privileged code executing after the mode change. This is because resolving errors associated with lower-privileged code typically has a much lower impact on system availability than resolving errors associated with higher-privileged code. For example, higher-privileged code might be the operating system, so handling errors attributed to the operating system might require a full system reset, while errors attributed to lower-privileged code associated with a single thread could be handled simply by killing that thread without affecting other threads and the operating system. Therefore, by implementing error synchronization barriers in response to inter-module function calls, the availability of the system can be improved by limiting the impact of handling any detected errors, in which case the error can be safely attributed to lower-privileged code executed after a mode change caused by an inter-module function call. It should be understood that there may be certain types of errors that are beyond the scope of error synchronization barriers and therefore may not be controllable by using such barriers. These uncontrollable errors may still require a full system reset. However, the use of error synchronization barriers may increase the likelihood that the error is attributed to a single thread and thus reduce the likelihood of needing a full system reset.

[0162] Not all scenarios require triggering an error synchronization barrier operation. Some systems may prefer to improve the performance of regular program execution by not artificially preventing the execution of subsequent instructions following an inter-module function call. For example, for certain real-time critical interrupts, interrupt handling latency may need to be as short as possible, and therefore it may be preferable not to trigger an error synchronization barrier operation if a RAS error is detected, at the cost of higher performance. However, for other types of interrupts with lower real-time requirements or those related to safety-critical behavior, it may be preferable to trigger an error synchronization barrier operation, so that although the regular interrupt latency may be slightly slower because instruction execution is delayed after the inter-module call until error detection / correction results are available, if an error is detected, its location can be identified, and the full impact of a system reset can be avoided if possible. Therefore, in some implementations, control register 20 may store configuration parameters specifying whether an error synchronization barrier operation should be triggered in response to an inter-module call instruction. In some systems, the configuration parameters specifying whether an error synchronization barrier operation should be performed are grouped across security domains, allowing lower security domains and security domains to independently choose whether to perform the barrier operation.

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

[0164] At step 332, processing circuit 4 determines whether the inter-module call branch instruction being executed is a BLXTI variant of the instruction. If so, at step 334, TMID parameter 34 is set to 0 to indicate that domain translation between the security domain and the lower security domain is enabled in thread mode. This corresponds to the second variant of the inter-module call branch instruction as described above. If the inter-module call branch instruction is a BLXT variant (first variant), at step 336, TMID parameter 34 is set to 1 to indicate that domain translation is disabled in thread mode. The programmer can choose to use either the BLXT or BLXTI variant depending on whether resources for the security domain and the lower security domain have been established for the thread to be executed after the inter-module function call. If resources for both domains have been established, the BLXTI variant can be selected, making it safe to switch between the security domain and the lower security domain when necessary; while the BLXT variant can be selected if only one S / NS domain has resources configured in the S / NS domain. These resources may include the MPU configuration within one of the secure MPU 26-S and the lower-security MPU 26-NS (wherein the MPU configuration may include one or both of certain memory region attributes defining access permissions to the corresponding memory regions and / or pointers to tables in memory system 6 that provide these memory attributes). Additionally, resources may include a secure stack pointer register or a lower-security stack pointer register (such as...). Figure 3 The resources include the stack pointer in the R13 grouped version shown, and if no suitable stack structure is available in memory, the resources may also include the allocation of the corresponding stack structure stored in memory. By providing the ability to disable domain transitions in thread mode, this allows a thread to configure its resources for use only in one domain, and then only needs to delay the allocation of resources for other domains when attempting to switch domains, otherwise triggering a failure, as shown in step 308 above, or as described earlier for other types of inter-domain transitions. The thread maximum intermediate state disable parameter 34 is additionally set using the BLXTI or BLXT instructions, which avoids the need for separate instructions to set the flag separately.

[0165] Regardless of which variant of the inter-module call branch instruction is executed, at step 338, the processing circuitry updates exception number 36 to indicate a non-exception handling value (e.g., 0), thus switching the processor to thread mode. Again, the method then proceeds to step 306 to branch to the branch target address specified by the function call branch instruction. Subsequent program execution then continues from the instruction stored at the branch target address. It should be understood that the branch target address can be specified by the function call branch instruction in several ways. For indirect branches, operands can be used to define the branch target address to select the register containing the target address. Direct branches can specify the target address using an immediate value directly encoded in the instruction encoding. Program counter-related 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.

[0166] Figure 13 The steps performed upon entering an exception are shown. At step 350, an exception occurs. The exception can be a software-triggered exception (such as a hypervisor call (SVC)) or an exception caused by a fault directly caused by software (such as an attempt to execute an undefined instruction, an attempt to fetch an instruction from reserved address range 130, or an access to memory), which triggers an address fault due to a failure of the memory access check at memory access check circuit 22. Alternatively, the exception can be a hardware-triggered interrupt caused by receiving a signal or message from an external device or peripheral device.

[0167] Regardless of the cause of the exception, when an exception occurs, at step 352, the processing circuit 4, controlled by the exception control circuit 28, sets the link register R14 to the previously described special virtual exception return value 142. More specifically, one of several virtual exception return values ​​is selected, where the values ​​of the current mode and current domain flags 152, 156 are selected based on the current operating mode and domain at the time the exception occurred. Furthermore, the Thread Mode Intermediate State Enable (TMIE) flag 158 is set to the reciprocal of the current value of the TMID flag 34 in the control register 32. This retains information in the TMID flag during exception handling, allowing that information to be recovered upon exception return. It should be understood that the specific implementation of reversing the TMID flag to set the TMIE flag is merely one possible implementation, and other examples may use the same encoding as the TMID value to encode the TMIE value and simply copy it directly, or may use a completely different encoding that does not require a single-bit flag but can use a multi-bit value.

[0168] At step 354, the exception control circuit 28 triggers a hardware-triggered state save from register 1 to a stack data structure in memory, which is identified by a stack pointer in the grouped stack pointer register. The specific stack pointer to be selected depends on the current domain and mode, as well as the stack pointer selection value 30 used before the exception occurred. The state save may involve storing only... Figure 6 The caller stack frame 180 shown may be either a caller stack frame 180 or both a callee stack frame 182. The decision of whether to save only the caller stack frame or both the caller and callee stack frames may depend on the current operating domain at the time of the exception and the domain to handle the exception, and in some cases may be based on the state data stored in the control register 20.

[0169] If an exception occurs from background code that does not handle exceptions itself, and any previously occurring exceptions have been handled, and the background code was handled in a lower security domain, then only the caller stack frame 180 needs to be saved, and the callee stack frame 182 does not need to be saved. Furthermore, if the background code was handled in a security domain, but an exception will occur in that security domain, then again, the callee stack frame 182 does not need to be saved.

[0170] In cases where an exception occurs from background code processed in a secure domain but is to be handled in a lower secure domain, there is a risk that the lower-secure exception handler could access the register state placed in register 14 by the secure code that operated prior to the exception. Therefore, in such cases, both caller stack frame 180 and callee stack frame 182 will be saved to the secure stack identified by either the secure main stack pointer or the secure process stack pointer, and general-purpose register 16 can be cleared to hide secure data from access by the lower-secure handler.

[0171] The preceding section described the general principle of determining whether to save the attached callee stack frame when an exception occurs from the background code. However, more complex decisions may arise regarding whether to save the caller's stack frame and / or the callee's stack frame when a further exception preempts an earlier exception before its exception handler has completed, or when tail-linking of exceptions occurs, where another exception occurs while one is completing before returning to the background code. Examples of a decision process for determining which of the caller's and callee's states to save in response to an exception are described in published PCT applications WO2013 / 117899 A1 and WO2014 / 053804 A1, the contents of which are incorporated herein by reference and may be used to determine the validity of this application. Figure 13 Which registers can be used for stack operations at step 354? See WO 2013 / 117899 A1 for details. Figure 12 And related explanations.

[0172] At step 354, if it is decided to save the callee stack frame 182 to the stack, TMIE cross-check information 192 is specified within the predefined signature 190. This information is set to the same value as the TMIE flag 158 set in the virtual exception return address at step 352 (or, in an alternative implementation, to a different value that can be used to check whether the TMIE flag 158 has been correctly set). This provides protection against the risk that lower-security code operating after an exception might tamper with the TMIE flag 158 in the virtual exception return address, in a manner that could allow security code to be processed after receiving an erroneous value for the intermediate state disabled flag TMID 34 following the exception return. This prevents denial-of-service attacks caused by spurious faults generated based on the tampered TMIE flag 34.

[0173] It can be questioned why the TMIE cross-check value 190 is specified in the callee stack frame 182 rather than the caller stack frame 180, because it could be assumed that if the value of TMID flag 34, reserved for the backend code, is saved in the caller stack frame 180, it remains safe from access by the exception handler in the link register, just like TMIE flag 158 in the exception return value 142. However, in practice, the caller stack frame 180 may not have much free capacity for additional information, as the status field ERETPSR may already have a lot of information to encode, and therefore there may not be space for cross-check information 192. In some specific implementations, there may be enough space in the ERETPSR value to add the TMIE flag, but the remaining space in the ERETPSR value is still limited, and it is preferable to reserve this space for future additions to the architecture. The callee stack frame 182 is not saved for all types of exceptions, so it cannot be relied upon to store a master copy of the TMIE value 158, which indicates the value to be restored to when the exception returns. Therefore, in Figure 5 and Figure 6 In the method shown, the TMIE flag 158 is placed in the link register as part of the virtual exception return address, but the cross-check information 190 is included in the callee stack frame 182, enabling all types of exceptions to retain the value of the TMID flag 34. Although there is a lack of space in the caller stack frame 180, for those scenarios where there is a risk of TMIE flag 158 being tampered with, which are also the same scenarios where the register state is protected by saving the attached callee stack frame 182, the cross-check information 192 saved to the callee stack frame 182 protects the TMIE flag 158 from tampering.

[0174] At step 356, as part of the exception entry transition, exception control circuitry 28 triggers processing circuitry 4 to set the TMID flag 34 in control register 32 to 0, indicating that domain translation is enabled in thread mode. This ensures that all exception handlers see a consistent view of whether domain translation is enabled in thread mode, regardless of whether domain translation is disabled for code executed before the exception. Enabling domain translation in thread mode in this manner may be necessary for backward compatibility with software written before the creation of the TMID flag 34.

[0175] At step 358, exception control circuit 28 controls processing circuit 4 to branch to an 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 the addresses of the corresponding exception handling routines. The exception handling routine is processed in handler mode, so if processing circuit 4 is currently in thread mode, the current mode is switched to handler mode in response to an exception. If the current mode is already handler mode when an exception occurs, the current mode is not changed. Therefore, it is initially impossible to perform exception handling in thread mode, although after processing some code in handler mode, an inter-modal function call, as previously described, can be executed to switch to thread mode.

[0176] Furthermore, upon an exception's entry, the exception control circuit 28 may 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 occur in a specific domain, such as the current security domain or a lower security domain. When an exception occurs, other exceptions may occur in the current domain. Therefore, if an exception needs to be handled in a domain different from the current domain, the exception control circuit 28 may trigger a change in security domain in addition to branching to the exception handling routine.

[0177] Figure 14 It shows a response to not Figure 12The flowchart illustrates the steps of a branch instruction executed for a function call branch instruction of the type shown. At step 400, the processing circuit checks if the target address is within the reserved address range 130. If not, this is a regular branch instruction to the address of an executable instruction. At step 402, it is detected whether the branch is requesting a transition from a secure domain to a lower secure domain. This can be identified by checking the current operating domain of processing circuit 4 and the least significant bit of the branch target address. If the least significant bit of the branch target address is 0, it indicates that the branch should return to the lower secure domain. Alternatively, in some implementations, a branch requesting a transition from a secure domain to a lower secure domain can be indicated by using a dedicated domain transition branch instruction (which may be called BXNS). A dedicated domain transition branch instruction can be detected by an opcode value different from other types of branch instructions, or it may have the same opcode as other types of branch instructions but with a parameter value indicating a request for a secure transition to a lower secure domain. Some implementations may combine these two methods such that a secure transition to a lower secure domain request requires both the least significant bit of the branch target address to be 0 and the use of a dedicated domain transition instruction.

[0178] If the branch does not request a safer path to a lower-safety branch, then at step 404, the branch can be processed normally, and the program counter register R15 is updated based on the branch target address specified by the branch instruction. Program flow then continues executing instructions at the branch target address (in the same domain as before the branch execution). It should be understood that in some implementations, not all types of non-function call branches will be used for function returns. For example, branches that determine the target address based on the immediate value encoded within the instruction opcode may always branch to the same location, and therefore may not be suitable for function return branches, where program flow may need to branch back to various different functions from which the caller is returning. To simplify the design, some implementations may selectively execute only a subset of non-function call branches that are available for executing function returns. Figure 14 The steps described herein. As mentioned above, there may be many types of instructions that can have the effect of branching, even if the instructions may not be dedicated branch instructions (for example, they may be load instructions that write loaded values ​​to the program counter). Figure 14 The steps described herein can also be applied to at least one subset of such non-branching instructions that have the effect of branching.

[0179] If it is determined at step 402 that the branch is safe to a lower security branch, then at step 406, the processing circuitry checks whether the current mode is thread mode and whether the Domain Translation Disable Configuration Parameter (TMID) is 1, which indicates that inter-domain translation is disabled in thread mode. If the current mode is thread mode and the TMID indicates that domain translation is disabled in thread mode, then at step 408, an INVTMI UsageFault processed in the security domain is triggered. This allows the security operating system managing the security thread to configure any MPU or stack resources as needed to allow the security thread to also operate in the lower security domain.

[0180] Alternatively, if at step 406 it is determined that the current mode is process mode or the TMID value 34 in control register 32 is 0 to indicate that domain switching (intermediate state) is enabled, then at step 410, the security domain is switched to the lower security domain (NS), and then at step 404, the branch to the target address is executed as previously described.

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

[0182] Alternatively, if the target address of the branch is not an address among the valid virtual function return addresses, then in step 416, it is determined whether the target address is an address among the valid virtual exception return addresses 142. Figure 5 As shown. If not, the attempt to branch to the target address is incorrect because that address represents the address of a non-executable instruction and is not the virtual address used to signal the return of an exception function, thus potentially triggering a fault at step 418. Alternatively, instead of directly triggering a fault in response to detecting a branch to a non-executable address, the branch can be executed normally to set the program counter register to the branch target address (therefore, if "N" is determined in step 416, Figure 14 (From step 416 to step 404), this may result in a signaling fault when the instruction fetch circuit 8 attempts to fetch an instruction from a non-executable address. Therefore, the fault may be caused indirectly by a branch, but may not be directly signaled in response to the branch instruction itself. Either approach may be effective.

[0183] If the target address is determined at step 416 to be one of the valid virtual exception return addresses 142, then at step 420, at least if the exception return involves a lower security to a security domain translation (which can be determined based on the security domain flag 156 in the virtual exception return address), a cross-check comparison is performed between the TMIE flag 158 in the virtual exception return address 142 and the TMIE cross-check information 190 stored as part of the call stack frame 182. If a mismatch is detected, a fault is triggered at step 422, as this may indicate that an attempt has been made to tamper with the TMIE flag 158 in the link register, or alternatively, an unexpected error has occurred. If the TMIE flag 158 matches the cross-check information 192, or alternatively, the exception return is translated to a translation that does not require this cross-check, then the method proceeds to step 424, where the exception return is processed.

[0184] The exception return handling at steps 420 and 424 may also include other operations as described in previously cited PCT publications WO 2013 / 117899A1 and WO 2014 / 053804 A1. Before checking the TMIE value at step 420, the exception return handling at step 424 may include unstacking the register state from the stack to register 14. The determination of whether unstacking should involve only the unstacking of caller stack frame 180 or both caller stack frame 180 and callee stack frame 182 may be based on a status flag that may be stored as part of the exception return value 142 when an exception occurs. For further details on determining which registers need to be unstacked, see WO 2013 / 117899 A1. Figure 13 Or WO 2014 / 053804 A1 Figure 13 .

[0185] Furthermore, exception return handling may include checking whether the pre-defined signature 190 is expected to exist on the stack as part of the callee's stack frame 182. This is in accordance with WO 2014 / 053804 A1. Figure 14 This is to determine the nature of the problem. If a pre-defined signature 190 is expected, but the contents at the location on the stack do not match the pre-defined signature, a fault can be triggered because this detects cases where the stack frame saved in response to a function call has attempted an exception return mechanism. The fault occurs in WO 2014 / 053804 A1. Figure 7 As shown in the image.

[0186] The exception return handling operation may also include other operations, such as updating the recovered exception number value 36 based on the ERETPSR value in the loaded stack frame, and changing the exception priority level based on the returned handling priority.

[0187] Furthermore, at step 424, the TMID value 34 in the control register 32 can be restored based on the TMIE flag 158 included in the virtual exception return address to which the branch is located. The restored value of the TMIE flag 34 can correspond to the reciprocal of the value of the TMIE flag 158 to indicate whether domain translation should be enabled or disabled in thread mode to match the value that TMID 34 had before the corresponding exception occurred. It should be understood that many other operations can also be performed when handling exception returns not discussed here.

[0188] Figure 15 More details are shown in Figure 14 Step 414 involves the operation performed on the branch leading to the function return address. At step 440, the processing circuitry determines whether the virtual function return address 140 of the branch target address detected as a branch indicates an inter-module function return. For example, this could check if the inter-module indicator 146 is 0 to specify that the corresponding function return value was set during the inter-module call from the handler to the thread mode. If the attempted function return is not an inter-module function return, it is an inter-domain function return (because if the corresponding function call is neither an inter-module call nor an inter-domain call, the link register would simply be set to the function return address, and a virtual function return address would not be needed).

[0189] At step 442, for inter-domain function returns, a check is performed on the thread-mode intermediate state disable flag TMID 34. If the current mode is thread-mode and TMID flag 34 is 1 to indicate that domain translation is disabled in thread-mode, then at step 444, the INVTMI UsageFault is triggered again. Figure 12 Step 308 or Figure 14 Step 408. However, at step 444, the INVTMI fault is handled in any domain within the current domain when attempting a branch (that is, the source domain returned by the inter-domain function being attempted, not the same security domain as in steps 308 and 408). This ensures that the process responsible for managing the thread requesting the branch can handle the fault and then configure the necessary resources for the target domain as needed.

[0190] If, at step 442, the current mode is determined to be handler mode, or the TMID flag 34 is determined to be 0, indicating that an intermediate state is enabled, then at step 446, the branch can be allowed to continue. The function return address 174 to which the branch will occur is read from the relevant stack determined based on the current operating mode to which the security domain is being transitioned, and, if in thread mode, based on the stack pointer selection value 30. Any integrity checks required to verify whether inter-domain transitions are allowed are performed. For example, these integrity checks may include 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), and checking whether the HDT flag 178 is 0, as expected for inter-domain function returns. Additionally, any other requirements restricting allowed domain transitions may be checked. If the integrity check passes, the branch to function return address 174 is allowed to succeed, and subsequent processing continues from the instructions fetched from function return address 174 (this is the actual function return address loaded from function return stack frame 172, not the one actually specified at function return address 174). Figure 14 The virtual function return address 140 is the target address of the attempted branch encountered at step 400. The stack pointer pointing to the function return stack frame 172 can be adjusted to resolve the unstacking and removal of the function return stack frame from the stack data structure. If any required integrity checks fail, a fault is signaled (this may be a security fault that can be handled in the security domain).

[0191] If, at step 440, the attempted function return is determined to be an inter-mode function return, then at step 450, the processing circuitry determines whether the current domain is a lower security domain, and the security domain indicator 148 in the virtual function return address 140 indicates a request to return to a security domain. If this is the case, then at step 452, an INVPC usage fault that would be processed in the current domain (lower security domain) is triggered. This fault is triggered to prevent a prohibited combination of domains / modes from transitioning from a lower security thread mode to a secure handler mode, as described above. Figure 9 As shown, otherwise it may cause security vulnerabilities.

[0192] If the attempted intermodal function returns a value that is not from a lower security domain to a security domain (or remains within the same domain, or moves from a security domain to a lower security domain), the method proceeds to step 454, where, if configured, an error synchronization barrier operation is triggered, similar to... Figure 12 The operation at step 328. Furthermore, by triggering an error synchronization barrier upon the return of the inter-module function, this helps to identify errors, thus reducing the need for intrusive system reset operations if the error can be attributed to lower-privilege processing performed prior to the inter-module function's return.

[0193] At step 456, in response to an inter-module function return instruction, the processing circuit loads function return stack frame 172 from the main stack associated with the target security domain being returned to. At 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 can check multiple items on the function return stack frame. For example, the processing circuit can check whether the function return address 174 is an address in the reserved address range 130. If the function return address is an address in the reserved address range, this may indicate an attempt to return the function based on a stack frame that is actually an exception stack frame containing a predefined signature 190 located on the stack at the same relative position as the function return address 174 within the function return stack frame 172, and this mismatch between the exception and the function entry and return could be a pathway for an attack. Therefore, if the function return address 174 on the stack frame is a reserved address 130, the integrity cross-check fails.

[0194] Furthermore, 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 process mode, the integrity cross-check fails.

[0195] In addition, the integrity cross-check includes checking the exception number field 179 in the function return stack frame. If this field is 0, the integrity cross-check will fail because the inter-module function return is expected to return from thread mode to handler mode.

[0196] In addition, integrity cross-checking uses the HDT flag 178 to detect whether the function return stack frame was saved in response to an inter-domain function call branch instruction. If the HDT flag is 0, this indicates that the function return stack frame was created in response to an inter-domain function call rather than an inter-module function call (see [link to documentation]). Figure 12 Step 312), therefore the integrity cross-check fails. This again prevents mismatched sequences of function calls and function returns to limit attack opportunities based on mismatched stack frames, and also prevents potential modification when the inter-module flag 146 within the virtual function return address 140 is stored in a normally accessible link register, where the HDT flag 178 acts as a cross-check value to check that the inter-module flag is the correct one.

[0197] If any integrity cross-check fails, an INVPC use failure is triggered at step 460, which indicates that a security check has failed and this type of failure will be handled in the target security domain associated with the code to which the branch was attempted.

[0198] Alternatively, if all integrity cross-checks pass, action can be taken on the inter-module function return at step 462. When the inter-module function return is executed, several actions are performed at step 462. The security state is updated to the security state indicated by the security domain indicator 148 in the virtual function return address 140. This ensures that the security domain is restored to the domain that was being executed before the corresponding inter-module function call was made.

[0199] Furthermore, at step 462, an indication is saved to record whether the TMID flag 34 was 0 or 1 before the inter-module function returns. This indication is separate from the TMIE flag 158 saved upon exception entry. The location of the indication storing the previous value of the TMID can vary depending on the implementation. For example, the indication can be saved to general-purpose register 16, or it can be saved to control register 20, such as a condition flag in the flag register, which can be directly tested by subsequent condition instructions.

[0200] Furthermore, at step 462, the TMID value 34 in control register 32 can be set to 0 to indicate that thread mode domain translation is now enabled again. This ensures that the domain translation disabled configuration value 34 remains consistent when returning to the higher privilege wrapper code, regardless of whether the privilege-removing portion of the exception handler code executed before the inter-mode function returns has attempted to switch security domains.

[0201] Furthermore, at step 462, upon returning from the inter-module function, the target stack pointer from which the function return stack frame is loaded can be adjusted to account for destack data that has been removed from the stack. Additionally, the stack pointer selection value 30 of the target field is updated to indicate that the main stack pointer should be selected, and the exception number register 36 is restored from the exception number field 179 in the function return stack frame 172, switching the current operation mode to handler mode (the previous integrity check at step 458 may have checked that the exception number field 179 was non-zero, therefore restoring the exception number register 36 switches the current mode to handler mode). At step 464, the branch obtained from the function return stack frame 172 to the actual function return address 174 is executed, such that the next instruction to be processed is the instruction at the function return address.

[0202] Therefore, by using the virtual function return address 140 (the body of ISR 201) saved when the function is called to signal whether subsequent function returns should be intermodal function returns, it means that the instruction that triggers the function return itself does not need to know whether it is switching modes. This means that legacy exception handler code written without any knowledge of support for intermodal function calls and returns can still be used. This relates to the above regarding... Figure 7 and Figure 8The described interrupt privilege revocation scenario is particularly useful. That is, function return branch instructions can have the same encoding, regardless of whether it is an intermodal branch.

[0203] It should be noted that, Figure 14 and Figure 15 In this context, the instruction that triggers a branch to a given target address can be any of various instructions that cause the program counter register R15 to be modified to the branch target address. In some cases, this instruction can be a dedicated branch instruction, but it could also be a register shift instruction that moves the branch target address into 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. Specifically, if the branch is to either virtual function return address 140 or virtual exception return address 142, and further function calls are made before the corresponding function / exception return, these addresses may end up being saved to the stack. It might be more efficient for the compiler to generate code that directly pops the return address from the stack frame into the program counter register than to first load it into the link register and then execute the return branch to the specified link register. Therefore, although the real function return address, virtual function return address, or virtual exception return address may initially be saved to the link register when a function is called or an exception occurs, these addresses may no longer be in the link register when the corresponding return is executed, and it should be understood that triggering... Figure 14 and Figure 15 The instructions for branching operations in the code may not actually be dedicated branch instructions.

[0204] Figures 16A to 16D Examples of possible attacks that can be prevented using the checks described above are shown. These attacks may be based on mismatched exception or function call and return sequences that attempt to exploit mismatched stack frames established by the call and expected upon return.

[0205] exist Figure 16A In the example, during processing in safe handler mode, an exception occurs at step 1, and this exception will occur in a lower security domain, so both caller stack frame 180 and callee stack frame 182 are saved to the stack. Figure 16A In step 2, a series of exception returns and / or function calls are performed, ultimately leading to processing in thread-safe mode. Once in thread-safe mode, in step 3, based on the exception stack frames 180 and 182 set in step 1, an attempt is made to execute an inter-module function return. This can be done, for example, by branching to a value in the virtual function return value 140. This type of attack is detectable because... Figure 15The cross-check of the function return integrity at step 458 will detect that the function return address 174 is an address in the reserved address range 130 (because the pre-signature 190 will be located at the bottom of the exception stack frame loaded at step 3, instead of the expected function return stack frame 172).

[0206] Figure 16B A second example is shown, where an inter-domain function call is performed from a security domain to a lower security domain at step 1, causing function return stack frame 172 to be saved to the security main stack. At step 2, a series of other transitions are performed again, and then at step 3, an inter-modal function return is attempted based on the inter-domain stack frame set at step 1. This inter-modal function return should not be allowed to succeed because the corresponding call is an inter-domain call, not an inter-modal call. This is detected because when an inter-domain function call occurs at step 1, the HDT value 178 in the function return stack frame will be set to 0, while for the inter-modal function return at step 3, the HDT value should be 1. Figure 15 The integrity cross-check at step 458 will fail.

[0207] Figure 16C Another potential attack is illustrated, in which an intermodal function call is first performed at step 1, which deprives privileges from handler mode to thread mode, followed by a series of other transitions at step 2, and then an attempt is made at step 3 to execute an interdomain function return, transitioning from a lower security domain to a higher security domain based on the intermodal function return stack frame set at step 1. Figure 15 At step 446, an integrity check is performed to determine whether 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 can be triggered. Therefore, in Figure 16C The scenario involves an inter-module function call, an attempt to return from an inter-domain function, and then an HDT check to detect a mismatch, ensuring that the inter-module stack frame created in step 1 cannot be interpreted as an inter-domain stack frame in step 3. Note that the HDT checks at steps 446 and 458 can be considered equivalent to a comparison between the inter-module marker M146 in the virtual function return address and the HDT marker 178 in the function return stack frame, because any mismatch identified in this comparison will be reflected in the inter-module return (…). Figure 16B In the case of () or returning between domains () Figure 16C The fault is triggered under the following circumstances.

[0208] Still referencing Figure 16CInstead of performing an inter-domain return at step 3 (inter-module flag M=0), the attacker may have attempted an inter-module function return (inter-module flag M=1). Although the corresponding function call is actually an inter-module call, it still does not match the attempted inter-module function return because the current mode before step 3 is handler mode, not thread mode. In this case, although the inter-module call value 146 may match the HDT value 178 set in the function return stack frame during the inter-module call in step 1, the attack is prevented because inter-module function returns are not allowed when the current state is handler mode, which would be blocked. Figure 15 Step 458 is the integrity check capture, which checks whether the current mode is thread mode.

[0209] Figure 16D Another example is shown, where an inter-domain stack frame is established at step 1 due to an inter-domain branch instruction from a safe domain to a lower safe domain, and then a series of transitions are performed at step 2 to return to the safe domain. Then, at step 3, an attempt is made to execute an inter-module function return using the stack frame set by the inter-domain branch at step 1. This type of attack will fail because the exception number field 179 in the function return stack frame 172 will indicate that the stack frame set at step 1 was set to thread mode, not the handler mode that the inter-module function return would request to enter. Alternatively, if a combined transition of domain and mode from the lower safe thread mode to the safe handler mode is attempted as shown in step 2', this will also fail because unauthorized combined transitions are blocked at step 450.

[0210] It should be understood that some checks may overlap, and the same type of attack may trigger the failure of more than one type of check. For some architecture-specific implementations, if some of these checks are considered redundant, they may be removed from the architectural requirements, and therefore, implementing all different types of attack prevention mechanisms is not necessarily necessary for the critical content to be protected. However, any one or more of these checks may be provided. It should be understood that... Figures 16A to 16D The attack shown is just a small fraction of a large number of different combinations of similar mismatch-type attacks, in which an attacker attempts to corrupt the state of the system by trying to return an operation (function or exception return) that does not match the original transformation, thereby corrupting the type of stack frame created.

[0211] Figure 12 , Figure 14 and Figure 15 Steps 307, 406, and 442 illustrate specific examples of disabling configuration parameter (TMID) 34 for function call branches, non-function call branches, and function return checks of domain transformation, respectively. However, in some architectures, there may be other effective means to trigger domain transformations, and... Figure 17A more general approach to handling TMID value checks is illustrated. At step 500, a possible attempt to perform a security-to-lower-security domain transition within the current mode or a lower-security-to-security domain transition within the current mode is detected. This attempt could be an actual attempt to perform a domain transition, or it could simply be an operation that might trigger such a domain transition if other security or integrity checks are passed, but it may not always trigger a domain transition if the TMID check is performed early enough that it is impossible to detect whether a domain transition will be allowed, or whether the check will fail again and cause a fault.

[0212] At step 502, if a potential attempt to trigger a domain transition is detected, it is determined whether the current mode is thread mode. If the current mode is thread mode, at step 504, the processing circuitry determines whether the TMID value 34 indicates that domain transitions are disabled in thread mode. If the current mode is thread mode and domain transitions are disabled in thread mode, at step 506, a domain transition disabling fault (e.g., the INVTMI UsageFault described above) is signaled. This fault is handled in the current security domain before the attempted domain transition is performed; therefore, if the attempted domain transition is from a security domain to a lower security domain, the fault is handled in the security domain, and if the attempted domain transition is from a lower security domain to a security domain, the fault is handled in the lower security domain. Optionally, some correction information may be stored in a control register to indicate information about a failed attempt to transition. In some implementations, setting the correction information may include setting the INVTMI bit in the UsageFault Status Register (UFSR).

[0213] If at step 502 it is determined that the current mode is process mode, or at step 504 a TMID value 34 is detected indicating that domain translation is enabled in thread mode, the method proceeds to step 508. At step 508, at least if the attempted translation is from a lower security domain to a secure domain, it is checked whether any other required security checks have passed, and if they have, the translation is allowed at step 510. If no security checks are required (e.g., for some types of secure-to-lower security domain translations, checks may not be necessary because the secure code can be trusted not to attack the lower security code), the translation can be allowed at step 510 without performing any security checks (i.e., step 508 can be omitted for such translations). Alternatively, if a security check fails, a fault can be triggered at step 512, and the fault can be handled in the secure domain because it relates to not being allowed to enter or exit a secure state. The type of fault triggered at step 512 and any correctives set may depend on the type of failed security check.

[0214] Although Figure 17Steps 502 and 504 are shown to be executed sequentially, but in some examples they may also be executed in reverse order or in parallel.

[0215] Figures 18 to 20 Some examples of use cases involving TMID value 34 are shown. Figure 18 Basically corresponds to Figure 8 The example involves an inter-module call that causes the exception handler to be deprived of privileges, thus including a body 201 that processes in thread mode. In this example, the exception is an unsafe (also known as a lower-safe) exception, so the exception handling, including wrapper 203 and body 201, is all within the lower-safe domain. Any thread that crosses the boundary between safe and lower-safe domains may need to establish both safe and lower-safe resources (such as the stack pointer of the associated stack structure allocated in memory by the MPU configuration). For threads that operate only in one domain (such as...) Figure 18 As shown in T2), it may be desirable to avoid allocating resources for another domain to avoid wasting memory and increasing context switching time. Therefore, preferably, the system avoids the cost of allocating additional resources for all threads, regardless of whether those additional resources will be used. This ability to avoid configuring both safe and low-safety resources for all threads also helps improve the efficiency of deprivation and reverting to normal operation. Figure 18 The interruption delay of the thread mode shown is because this would mean that wrapper code 203 would not take a long time to execute, since it can omit either the configuration safe MPU or the lower safe MPU, as well as either the safe stack pointer or the lower safe stack pointer.

[0216] One approach to this problem could be to allocate stack and MPU configurations for threads based on individual safety states (e.g., Figure 18In the example of thread 2 (in the lower security domain), resources can only be allocated to the other domain if the thread attempts to switch to it. However, without the TMID parameter 34, the only way to force this and generate the fault required to trigger delayed allocation is to reconfigure MPU 26 so that an address error occurs when attempting to access an address that the process does not have permission to access or an address for which zone permission data is not defined in MPU 26. This would be a drawback because it would require per-thread rather than per-process MPU configuration and would also require a considerable amount of secure / lower security interaction, as it would involve MPU 26-S and MPU 26-NS for both security domains, thus negating the advantage of being able to skip the MPU configuration operation for one of the security domains. For example, the lower security OS might need to reconfigure its lower security MPU 26-NS before running a secure thread so that an attempt to branch to the lower security state causes a fault. Therefore, using MPU 26 to generate faults can be difficult and performance-intensive, and difficult to code for different parties providing secure and lower-security insecure OS code. Alternatively, if it is known in advance which threads will use only one security domain and which threads will use two security domains, this information can be used to avoid delayed allocation. However, this cannot be relied upon because the software may crash and attempt to access another state, or an attacker may attempt to exploit the vulnerability. Therefore, when resources are created for only one domain, it may still be desirable to provide a mechanism to detect failures when transitioning to another domain.

[0217] Conversely, by providing the TMID parameter 34, which selectively disables domain translation in thread mode, this means that only threads in lower security domains (such as...) are expected to... Figure 18 The T2 in the configuration can initially have its TMID parameter 34 set to disable domain switching, and then fail only if it does attempt to switch domains, thus allowing for the configuration of appropriate resources.

[0218] therefore, Figure 18An example is shown where thread mode switching is disabled when entering the privilege-deprivileged exception handler body 201 (because the exception handler body 201 is called using a BLXT variant of the intermodal call branch instruction). In this case, the exception handler body 201 remains in the lower security domain and does not attempt to switch to a security domain, so no processing resources or memory allocation is wasted when the body 201 later executes the function return to wrapper code 203, while configuring MPU or stack resources for the security domain of thread T2. Therefore, this improves performance. When the processing of body 201 is complete, a branch to the intermodal virtual function return address 140 is executed at step 604. This triggers a return to handler mode, and in some specific implementations, this may result in the indication of the TMID flag 34 in the control register 32 being, as shown in the example. Figure 15 The data is saved (e.g., saved to a general-purpose register) before being cleared as described in step 462. The program flow then continues back to wrapper 203, where the wrapper checks the indication of the saved TMID flag 34 and determines that TMID flag 34 was 1 before the inter-module function return at step 604. Therefore, wrapper 203 determines that the resources associated with the safe state are still configured for background thread T2, and that these resources do not need to be reconfigured before performing an exception return to return to background processing in T2.

[0219] Figure 19 A similar scenario is illustrated, but in this case, after the privilege-removing exception handler body 201 is invoked using the BLXT instruction and thus inter-domain conversion is disabled while in thread mode, the body does attempt to switch to a security domain this time, which triggers a usage fault as previously described. This fault results in an exception, which is then handled by handler code 608 in handler mode. Resources can then be requested to allocate or configure for thread T2 in the security MPU 26-S and the security stack pointer register before returning to the exception handler body 201, which can then... Figure 19 At point 600, a retry of the lower security to security domain transition is performed (for clarity, Figure 19 The text exaggerates the gap between the point of return to lower security T2 and inter-domain translation 600. It should be understood that inter-domain translation 600 can actually occur during the first instruction after the return to T2. After completing the processing portion that needs to be in the security domain, the inter-domain return can be performed at point 602, and then subsequent processing... Figure 18 Same as above.

[0220] Figure 19 This illustrates a scenario where, when in Figure 19When performing an intermodal return at position 604, in order to transition from privilege deprivation exception handler body 201 back to wrapper code 203, an indication is stored to indicate whether the TMID value 34 was 0 or 1 for lower-security processing in thread mode performed against thread T2 prior to the intermodal return. This is done during the intermodal return before clearing the TMID flag to re-enable domain translation in wrapper code 203. As mentioned above... Figure 15 As described in step 462, TMID 34 can be in Figure 19 The indication of whether the value is zero or one before step 604 is saved to any convenient location, such as a control register, a general-purpose register, or one of the condition codes. This is useful because once processing returns to the lower-safety wrapper code 203 for processing in handler mode, it allows subsequent code at 610 to... Figure 18 The situation shown is the same as Figure 19 The situations shown are distinguished. For example, in Figure 18 In the scenario shown, no processing has yet occurred in the security domain. During the previous processing of the background code in the security domain, any security stack pointers and MPU configurations can still be set as previously at point 606. In contrast, in Figure 19 In step 601, the attempt to enter the safety domain of thread T2 (which subsequently succeeded when retried at step 600) means that in Figure 19 Configuring MPU / stack resources for thread T2 at point 608 will change the relevant MPU contents and stack pointer registers of the thread mode. Therefore, in Figure 18 and Figure 19 The remaining wrapper code 203 executing at section 610 may need to determine whether it is necessary to update the safety stack pointer and safety MPU configuration to restore the information present at section 606 before returning processing to the safe section of thread T1. This decision can be made using an indication of whether TMID is equal to zero or one before step 604 when the inter-module function returns.

[0221] In other specific implementations, it is not important whether the instruction to disable or enable domain translation in thread mode is before saving the inter-module return; in this case, Figure 18 and Figure 19 At step 610, wrapper code 203 can simply always perform the operation to restore the security resources present at step 606. However, Figure 19 The example shown (which stores an indication of whether thread mode intermediate states are disabled) can improve performance by avoiding redundant stack pointer update operations when not needed.

[0222] For comparison, Figure 20Another scenario is illustrated where, when the IRQ exception handler performs privilege deprivation, it is expected that the exception handler will use both the security domain and the lower security domain. Therefore, during wrapper code 203 executed at point 620, appropriate operations are performed to configure security resources for both domains and the lower security resources, using a BLXTI variant of the inter-module function call branch instead of... Figure 18 and Figure 19 The BLXT function calls the body 201 of the exception handler, which will execute in thread mode under deprivileged conditions. Therefore, this time, during the intermodal function call from handler mode to thread mode, the TMID value 34 is set to 0 to indicate that domain translation is enabled in thread mode, and thus this time at step 622, when the interrupt handler body attempts to translate to a safe domain, this is allowed and no fault is required, such as... Figure 19 As in the example. Similarly, the indication that TMID was 0 before the inter-module return at point 64 can be used by wrapper code 203, which executes at point 626, to determine if it is necessary to restore the safety-side stack pointer or MPU configuration associated with thread T1 to their state at point 628 before the interrupt occurred. In some specific implementations of the wrapper code, wrapper code 203 may not check the... Figure 20 The example shows an indication of the TMID flag saved during the inter-module function return. Because the wrapper performs the configuration of both domains before executing the main body 201, the wrapper will know in advance that the resources for both domains need to be restored before returning to the background thread T1. While this might seem simpler than redundantly checking the indication of the TMID saved during the inter-module function return, it could mean that sharing code between different wrappers for different exception handlers is more difficult. Therefore, both approaches could be useful.

[0223] Figure 21 Another example of a more specific scenario is shown, where checking the TMID value 34 can be useful when attempting to switch domains. This is... Figure 17Another specific example of the general approach in this context. Another way domain translation might occur is when an attempt is made to fetch an instruction from an address within a secure address region defined by SAU 24, in a lower security domain. At step 700, the instruction fetch circuit 8 determines whether the current domain is a lower security domain and whether an attempt has been made to fetch an instruction whose address is within a secure address region defined by SAU 24. If not, instruction fetching continues normally. If the current domain is a lower security domain and an attempt is made to fetch an instruction from a secure address region, at step 702, it checks whether the current mode is thread mode and whether the intermediate state disable flag (TMID 34) indicates that domain translation is disabled in thread mode. If so, at step 704, an INVTMI UsageFault is triggered to prevent a domain translation from occurring. This fault is handled in the current domain (i.e., the lower security domain). Note that an instruction fetched from a secure address region may not actually trigger a domain translation, but a fault will still be conservatively generated, assuming that a translation might occur if subsequent security checks pass. By generating a fault at extraction level 8, this ensures that the UsageFault triggered by disabled domain translation is evaluated relatively early compared to other types of security checks that may need to be performed, so that these other security checks do not fail simply because security resources have not been configured.

[0224] On the other hand, if at step 702, it is determined at extraction level 8 that the current mode is process mode or TMID34 indicates that thread mode domain transition is enabled, then at step 706, instruction extraction is allowed to continue. If the instruction extracted from the secure address region is identified at decoding level 10 as an instruction that triggers a domain change (e.g., a secure gateway instruction that marks a valid entry point into a secure domain), then once the instruction reaches execution level 12, any additional security checks are performed on it, and if these checks pass, transition to the secure domain is allowed.

[0225] therefore, Figure 21 This is an example where the check for TMID value 34 does not necessarily occur at execution level 12 but can be performed during instruction fetching.

[0226] Figure 22A specific implementation of a usable simulator is illustrated. While the previously described embodiments implement the invention in terms of means and methods for operating specific processing hardware supporting the technologies involved, it is also possible to provide an instruction execution environment according to the embodiments described herein, which is implemented using a computer program. Such computer programs are generally referred to as simulators, in part because they provide a software-based implementation of a hardware architecture. Types of simulator computer programs include emulators, virtual machines, models, and binary converters, including dynamic binary converters. Typically, the simulator implementation can run on a host processor 830 supporting a simulator program 810, optionally running a host operating system 820. In some arrangements, multiple emulation layers may exist between the hardware and the provided instruction execution environment and / or multiple different instruction execution environments provided on the same host processor. Historically, powerful processors were required to provide simulator implementations that execute at a reasonable speed, but this approach may be reasonable in certain situations, such as when it is desirable to run code native to another processor for compatibility or reuse reasons. For example, the simulator implementation may provide additional functionality to the instruction execution environment that is not supported by the host processor hardware, or provide an instruction execution environment that is typically associated with a different hardware architecture. An overview of the simulation is given in the following literature: “Some Efficient Architecture Simulation Techniques”, Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

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

[0228] The simulator program 810 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (instruction execution environment) to the target code 800 (which may include an application program, operating system, and management program). This program interface is identical to the application interface of the hardware architecture modeled by the simulator program 810. Therefore, the simulator program 810 can be used to execute program instructions of the target code 800 (including the aforementioned inter-module call branch instructions) from within the instruction execution environment, enabling a host computer 830, which does not actually possess the hardware features of the aforementioned device 2, to emulate these features.

[0229] like Figure 22 As shown, the simulator program 810 includes instruction decoding program logic 811, processing program logic 812, exception control program logic 813, and memory access check program logic 814. These logics perform functions equivalent to the instruction decoder 10, execution level 12, exception control circuit 28, and memory access check circuit 22 described above. The instruction decoding program logic 811 decodes the instructions of the target code 800 and, based on the type of the encoded instruction, selects one of a plurality of program code sequences in the processing program logic 812. These program code sequences control the host hardware 830 to perform operations equivalent to those defined in the decoded instructions for the target code 800 in the simulated instruction set architecture. If a simulated exception occurs, the exception control program logic 813 controls exception handling in a manner similar to the exception control circuit 28 described above. The simulator program 810 also includes register emulation logic 815, which maps register references required by the instructions of the target code 800 to equivalent memory accesses to the host memory address space used by the host device, enabling the maintenance of data structures in the host memory address space corresponding to the contents of register 14 of the target data processing device simulated by the simulator program. Similarly, memory access logic 817 maps memory accesses and instruction fetches required by the target code 800, defined using addresses from the simulated address space 816, to the host memory address space used by the host data processing hardware 830. For example, memory access logic 817 can control access to stack data structures 818 that are actually stored in the host memory address space but appear to be stored in the simulated address space 816 from the perspective of the target code 800.

[0230] Therefore, the control register emulated by the register emulation program logic 815 may include the aforementioned TMID flag 34, and the processing program logic 812 may emulate whether inter-domain conversion 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, which sets the TMID flag 34 in response to events such as executing inter-module function calls and returns, exception entry or return, or other instructions for writing to the TMID flag 34. Furthermore, the instruction decoding program logic 811 may respond to inter-module call branch instructions to switch the current mode of the simulated processor represented by the processing program logic 812 from processor mode to thread mode, as described above.

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

[0232] While exemplary embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it should be understood that the invention is not limited to those precise embodiments, and various changes and modifications can be made therein by those skilled in the art without departing from the scope and spirit of the invention as defined in the appended claims.

Claims

1. A data processing apparatus, the apparatus comprising: A processing circuit, the processing circuit being configured to perform data processing in one of a plurality of modes including at least a process mode and a thread mode; An exception control circuit, in response to an exception condition, controls the processing circuit to switch to the processing mode to handle the exception handling procedure. and An instruction decoder is used to decode instructions to control the processing circuit to perform the data processing; wherein: At least when the processing circuit is in the processing mode, in response to an inter-module 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 storage location; Switch the current mode of the processing circuit to the thread mode; and The instructions identified by the branch to the target address of the branch.

2. The apparatus of claim 1, wherein the processing circuitry is configured to perform the data processing in one of a plurality of security domains, including at least a security domain and a lower security domain; The apparatus includes a memory access checking circuit, which checks whether memory access is permitted based on the current security domain of the processing circuit; and In response to an inter-domain call branch instruction at a specified branch target address, the instruction decoder is configured to control the processing circuitry to save the function return address to the function return address storage location, branch to the instruction identified at the branch target address, and switch the current security domain of the processing circuitry.

3. The apparatus of claim 2, wherein in response to the inter-modal call branch instruction, the instruction decoder is configured to control the processing circuitry to switch the current mode of the processing circuitry to the thread mode without changing the current security domain of the processing circuitry.

4. The apparatus according to any one of claims 2 and 3, wherein: In response to an inter-module function return instruction, the processing circuitry is configured to switch the current mode of the processing circuitry to the process mode; and to branch to an instruction recognized by the function return address; and In response to the inter-module function return instruction, the processing circuitry is capable of performing a combined domain / mode switch from processing in the first security domain and the thread mode to processing in the second security domain and the handler mode.

5. The apparatus according to claim 4, wherein, In response to the inter-module function return instruction, the processing circuit is configured to: When the first security domain is the security domain and the second security domain is the lower security domain, the combined domain / mode switching is allowed; as well as When the first security domain is the lower security domain and the second security domain is the security domain, the combined domain / mode switching is prohibited.

6. The apparatus according to any one of claims 1 to 3, wherein in response to the inter-modal call branch instruction, the instruction decoder is configured to trigger fault signaling when the current mode of the processing circuit is the thread mode.

7. The apparatus according to any one of claims 1 to 3, wherein the processing circuitry is configured to: The instruction identified by the branch to the return address of the function; and When the function return instruction is an inter-module function return instruction, the current mode of the processing circuit is also switched to the processing program mode.

8. The apparatus of claim 7, wherein in response to the inter-modal function return instruction, the processing circuitry is configured to trigger a fault signaling when the current mode of the processing circuitry is the process mode.

9. The apparatus according to any one of claims 1 to 3, wherein: For at least one call branch instruction other than the inter-module call branch instruction, the function return address storage location includes a link register; and For the inter-module call branch instruction, the function return address storage location includes the location on the stack data structure.

10. The apparatus of claim 9, wherein, in response to the inter-module call branch instruction, the instruction decoder is configured to control the processing circuitry to save a virtual function return address to the link register, the virtual function return address including an inter-module call indication value to indicate that the virtual function return address is saved in response to the inter-module call branch instruction; and In response to at least one type of instruction that attempts to branch to the virtual function return address when the virtual function return address includes the inter-module call indication value, the processing circuitry is configured to branch to the 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 apparatus of claim 10, wherein the virtual function return address indicates at least one of the following: Whether to request a switch from thread mode to handler mode in response to an instruction of at least one type that attempts to branch to the return address of the virtual function; Whether to request a switch of the current security domain of the processing circuit in response to an instruction of at least one type attempting to branch to the return address of the virtual function; and Which of the multiple stack data structures should be used as the stack data structure from which the function return address is obtained in response to an instruction of at least one type attempting to branch to the virtual function return address.

12. The apparatus of claim 10, wherein a portion of the virtual function return address indicates whether a switching of the current security domain of the processing circuitry is requested in response to an instruction of at least one type attempting to branch to the virtual function return address; In response to a security gateway instruction that the current security domain is the security domain, the instruction decoder is configured to set a portion of the return address to a value indicating a lower security state; as well as The portion of the return address and the portion of the virtual function return address are located at the same relative position within the return address and the virtual function return address, respectively.

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

14. The apparatus according to any one of claims 10 to 13, wherein: In response to the inter-module call branch instruction, the instruction decoder is configured to control the processing circuitry to store the cross-check value in at least a portion of a first relative position within the stack frame stored in the stack data structure; and In response to an instruction of at least one type attempting to branch to the return address of the virtual function, the processing circuitry is configured to perform a comparison of a portion of the virtual function return address used to encode the inter-module call indication value with a value in at least a portion of the first relative position in the stack frame obtained from the stack data structure, and to determine, based on the comparison, whether to trigger fault signaling.

15. The apparatus according to claim 14, wherein: In response to at least one type of call branch instruction other than the inter-module call branch instruction, the instruction decoder is configured to control the processing circuitry to store a value other than the cross-check value in at least a portion of the first relative position within the stack frame of the stack data structure.

16. The apparatus according to any one of claims 10 to 13, wherein: In response to the inter-modal call branch instruction, the instruction decoder is configured to control the processing circuitry to store a value indicating the processing mode in at least a portion of a second relative position in a stack frame stored in the stack data structure; and In response to an instruction of at least one type that attempts to branch to the virtual function return address when the virtual function return address includes the inter-modal call indication value, the processing circuitry is configured to trigger a fault signaling when the value in at least a portion of the second relative position in the stack frame does not indicate the handler mode.

17. The apparatus according to any one of claims 10 to 13, wherein the processing circuitry is configured to: respond to an instruction of at least one type that attempts to branch to the virtual function return address when the virtual function return address includes the inter-module call indication value. Before switching the current mode of the processing circuit to the process mode, it is checked whether the function return address obtained from the stack data structure is within a predetermined reserved address range from which instruction execution is prohibited, and when the function return address is within the predetermined reserved address range, a signaling attribution to a fault in the program code executed in the thread mode is triggered.

18. The apparatus according to claim 17, wherein: For the inter-module call branch instruction, the function return address storage location includes the position saved to the third relative position within the stack frame of the stack data structure; and For at least one type of exception transition triggered by an abnormal condition, the exception control circuit is configured to store a stack frame into the stack data structure, including an address stored at the third relative position within the stack frame, within the predetermined reserved address range.

19. The apparatus according to any one of claims 1 to 3, wherein: In response to the inter-module call branch instruction, the instruction decoder is configured to control the processing circuitry to perform an error synchronization barrier operation to isolate 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.

20. The apparatus of claim 7, wherein in response to the inter-module function return instruction, the processing circuitry is configured to perform an error synchronization barrier operation to isolate the detection of errors associated with data processing performed prior to the error synchronization barrier operation from the detection of errors associated with data processing performed after the error synchronization barrier operation.

21. The apparatus according to any one of claims 1 to 3, wherein the processing circuitry is configured to perform the data processing in at least one security domain; The device includes: Multiple stack pointer registers, wherein the multiple stack pointer registers include at least a process stack pointer register for each security domain and a main stack pointer register for each security domain; A selection circuit is configured to select, for each security domain, which of the stack pointer registers should be used to provide a stack pointer for accessing stack data structures in memory; and At least one stack pointer selection value storage location, wherein the at least one stack pointer selection value storage location is used to store the stack pointer selection value for each security domain; In the processing mode, the selection circuit is configured to select the main stack pointer register; In the thread mode, the selection circuit is configured to select between the process stack pointer register and the main stack pointer register based on the stack pointer selection value; and In response to the inter-mode call branch instruction executed in the current security domain of the at least one security domain, the instruction decoder is configured to control the processing circuitry to set the stack pointer selection value of the current security domain to indicate that the process stack pointer register should be selected when in the thread mode.

22. A data processing method for an apparatus, the apparatus comprising: A processing circuit, the processing circuit being configured to perform data processing in one of a plurality of modes including at least a process mode and a thread mode; and an exception control circuit, which responds to an exception condition and controls the processing circuit to switch to the processing mode to process the exception handler. The method includes: Decode inter-module call branch instructions at the specified branch target address; and At least when the processing circuit is in the processing mode, in response to the inter-module call branch instruction: Save the function return address to the function return address storage location; Switch the current mode of the processing circuit to the thread mode; and The instructions identified by the branch to the target address of the branch.

23. A computer program product comprising a computer program for controlling a host data processing device to provide an instruction execution environment for executing instructions from object program code; the computer program comprising: The processing logic is used to perform data processing in one of a plurality of modes, including at least a processing mode and a thread mode. An exception control program logic, which responds to an exception condition, is used to control the processing program logic to switch to the processing program mode to handle the exception handler. as well as The instruction decoding program logic is used to decode the instructions of the target program code in order to control the processing program logic to execute the data processing; wherein: At least when the handler logic is in the handler mode, in response to an inter-module call branch instruction specifying a branch target address, the instruction decoding logic is configured to control the handler logic to: Save the function return address to the function return address storage location; Switch the current mode of the processing logic to the thread mode; and Instructions of the target program code identified at the branch target address.

24. A computer-readable storage medium storing a computer program for controlling a host data processing device to provide an instruction execution environment for executing instructions from object program code; the computer program comprising: The processing logic is used to perform data processing in one of a plurality of modes, including at least a processing mode and a thread mode. An exception control program logic, which responds to an exception condition, is used to control the processing program logic to switch to the processing program mode to handle the exception handler. as well as The instruction decoding program logic is used to decode the instructions of the target program code in order to control the processing program logic to execute the data processing; wherein: At least when the handler logic is in the handler mode, in response to an inter-module call branch instruction specifying a branch target address, the instruction decoding logic is configured to control the handler logic to: Save the function return address to the function return address storage location; Switch the current mode of the processing logic to the thread mode; and Instructions of the target program code identified at the branch target address.

Images