Disable Domain Transition Configuration Parameter

Abstract

The processing circuit (4) has a secure domain and a less secure domain. The control memory location (32) stores a domain transition disable configuration parameter (34) that specifies whether domain transitions between the secure domain and the less secure domain are enabled or disabled in at least one mode of the processing circuit (4). If, in at least one mode of the processing circuit, the domain transition disable configuration parameter (34) specifies that the domain transition is disabled in the at least one mode, a disable domain transition fault is signaled in response to an attempt to transition between domains in either direction. This can be useful to support delayed configuration of resources for the secure domain or the less secure domain for threads that are expected to only need the other domain.

Description

[Technical field]

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

[0002] A processing circuit may have multiple security domains, including a secure domain and a less secure domain. A memory access circuit may control whether memory access is permitted based on a current operating domain. Data or program code stored in a secure area of ​​memory may not be permitted to be accessed by code operating in a less secure domain. This may help to isolate secure applications from inappropriate access by less secure applications.

[0003] At least some examples provide an apparatus that includes a processing circuit for performing data processing in one of a plurality of security domains including at least a secure domain and a less secure domain; a memory access check circuit for checking whether memory access is permitted depending on a current security domain of the processing circuit; and a control memory location for storing a domain transition disable configuration parameter that specifies whether a domain transition between the secure domain and the less secure domain is enabled or disabled in at least one mode of the processing circuit, wherein if in the at least one mode of the processing circuit the domain transition disable configuration parameter specifies that the domain transition is disabled in the at least one mode, the processing circuit is configured to trigger signaling of a disable domain transition fault in response to an attempt to transition from the secure domain to the less secure domain and to trigger signaling of a disable domain transition fault in response to an attempt to transition from the less secure domain to the secure domain.

[0004] At least some examples provide a data processing method, comprising: performing the data processing using an apparatus including a processing circuit for performing the data processing in one of a plurality of security domains including at least a secure domain and a less secure domain; and a memory access check circuit for checking whether a memory access is permitted according to a current security domain of the processing circuit; storing in a control memory location a domain transition disable configuration parameter specifying whether a domain transition between the secure domain and the less secure domain is enabled or disabled in at least one mode of the processing circuit; and in response to an attempt of a domain transition between the secure domain and the less secure domain in the at least one mode of the processing circuit, triggering signaling of a disable domain transition fault whether the attempted domain transition is from the secure domain to the less secure domain or from the less secure domain to the secure domain if the domain transition disable configuration parameter specifies that the domain transition is disabled in the at least one mode; Includes.

[0005] At least some embodiments provide a computer program for controlling a host data processing apparatus to provide an instruction execution environment for executing instructions, the computer program including: processing program logic for performing data processing in one of a plurality of security domains including at least a secure domain and a less secure domain; memory access checking program logic for checking whether memory access is permitted depending on a current security domain of the processing program logic; and configuration parameter setting program logic for setting, in a control memory location, a domain transition disable configuration parameter specifying whether a domain transition between the secure domain and the less secure domain is enabled or disabled in at least one mode of the processing program logic, wherein if, in the at least one mode of the processing program logic, the domain transition disable configuration parameter specifies that the domain transition is disabled in the at least one mode, the processing program logic is configured to trigger signaling of a disable domain transition fault in response to an attempt to transition from the secure domain to the less secure domain and to trigger signaling of a disable domain transition fault in response to an attempt to transition from the less secure domain to the secure domain.

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

[0007] Further aspects, features, and advantages of the present technology will become apparent from the following description of examples, read in conjunction with the accompanying drawings.

[0008] [Figure 1] 1 illustrates a schematic diagram of an example data processing system having processing circuitry that supports different modes of operation.

[0009] [Diagram 2]1 illustrates examples of different domains and modes of operation of a processing circuit.

[0010] [Diagram 3] 1 illustrates an example of a register of a processing circuit.

[0011] [Figure 4] Indicates the provision of reserved address ranges that cannot be used for executable instructions.

[0012] [Diagram 5] A dummy function return address and a dummy exception return address are shown.

[0013] [Figure 6] 1 illustrates the different stack frames that may be saved onto the stack in response to a function call or an exception.

[0014] [Figure 7] For comparison, an example of exception deprivilege when intermodal call branch instructions are not supported is shown.

[0015] [Figure 8] 1 illustrates an example of exception deprivilege using an intermodal call branch instruction.

[0016] [Figure 9] Examples of prohibited domain / mode switching combinations are:

[0017] [Figure 10] Examples of permitted combined domain / mode switches are given below.

[0018] [Figure 11A] FIG. 10 shows an example of a tail call where combined domain / mode switching may be useful. [Figure 11B] FIG. 10 shows an example of a tail call where combined domain / mode switching may be useful. [Figure 11C]FIG. 10 shows an example of a tail call where combined domain / mode switching may be useful.

[0019] [Figure 12] FIG. 2 is a flow diagram showing the steps performed when a function is called.

[0020] [Figure 13] FIG. 11 is a flow diagram showing the steps performed in an exception entry.

[0021] [Figure 14] FIG. 2 is a flow diagram showing steps performed in response to a branch instruction other than a function call.

[0022] [Figure 15] FIG. 1 is a flow diagram illustrating steps performed in response to a branch to a dummy function return address.

[0023] [Figure 16A] FIG. 16 illustrates a potential attack that can be detected using the integrity cross-check shown in FIG. 15. [Figure 16B] FIG. 16 illustrates a potential attack that can be detected using the integrity cross-check shown in FIG. 15. [Figure 16C] FIG. 16 illustrates a potential attack that can be detected using the integrity cross-check shown in FIG. 15. [Figure 16D] FIG. 16 illustrates a potential attack that can be detected using the integrity cross-check shown in FIG. 15.

[0024] [Figure 17] FIG. 13 is a flow diagram illustrating invalidation of domain transitions in thread mode.

[0025] [Figure 18] Here is an example of using the domain transition disable configuration parameter. [Figure 19] Here is an example of using the domain transition disable configuration parameter. [Figure 20] Here is an example of using the domain transition disable configuration parameter.

[0026] [Figure 21] FIG. 11 is a flow diagram illustrating checking of domain transition disable configuration parameters when fetching an instruction having an address within a secure address region.

[0027] [Figure 22] 1 shows an example of a simulator that can be used.

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

[0029] However, in a typical system with a handler mode and a thread mode, the mechanism for switching modes may be to use an exception to switch from thread mode to handler mode, and then switch back to thread mode when the exception returns. Simply triggering an exception to return to thread mode may not be appropriate, as this typically reduces the priority level associated with the original exception, making it difficult to properly prioritize different interrupts or exceptions. Thus, in many cases, it may be necessary to generate a "fake" second exception just to set up exception return control information that causes the original exception to be handled in thread mode rather than handler mode upon return from the second exception. This mechanism may be slower, as the invocation of the second exception may incur the cost of additional state save and restore operations, as well as the performance cost of the operations to set up the fake exception return operation. Additional state save and restore operations are typically performed on exception entry and return to save architectural state associated with the process executed prior to the exception. Thus, if an exception entry and return mechanism is used to deprivilege an exception handler, this may increase the overall interrupt / exception processing latency, which may not be acceptable in some systems, especially those intended for real-time applications. This approach is also difficult to code for a compiler and prone to errors.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0071] If, following the checking of the domain transition disable configuration parameter, a disable domain transition fault 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 process the exception handler in the first security domain. Thus, if the fault was triggered by an attempt to switch from a less secure domain to a secure domain, the fault is processed in the less secure domain, and if the attempt was to transition from a secure domain to a less secure domain, the fault is processed in the secure domain. This is useful because typically the domain in which the corresponding thread was operating before the domain switch is the domain in which the thread was initially initialized and is therefore the domain associated with the managing process that manages that thread. For example, a secure thread created in a secure domain may be managed by a secure operating system and a less secure thread created in a less secure domain may be managed by a less secure operating system, and so it may be desirable for the disable domain transition fault to be directed to the managing process associated with the thread that attempted the disable domain transition. Although the fault may be processed in the first security domain, the configuration of resources performed by the exception handler in response to the fault may be the configuration of resources associated with the second security domain. Since the domain of the invalid domain transition fault target is different from the state in which resources need to be lazily configured, a close coordination between the program code operating in the less secure state and the secure state may be required in the handler mode, and therefore it may be advantageous to exclude the handler mode from at least one mode in which the invalid domain transition check is performed.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0085] However, as mentioned above, for transitions from a less secure domain to a secure domain, security checks may depend on resources that may not be configured for threads expected to remain within a single security domain (e.g., the checks may depend on the memory protection unit attributes of the secure domain being set such that instructions fetched from the secure domain may be fetched and decoded). Thus, if a thread expected to only be in a less secure 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 of domain transition disable configuration parameters as early as possible.

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

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

[0088] Explanation of specific examples FIG. 1 illustrates generally an example of a data processing system 2 including processing circuitry 4 for performing data processing in response to instructions fetched from a memory system 6. The memory system 6 may include caches (e.g., one or more levels of data caches and / or instruction caches) in addition to a main memory. The processing circuitry 4 includes a processing pipeline including several pipeline stages, including, for example, a fetch stage 8 for fetching instructions to be executed from 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 the data processing, and an execute stage 12 for executing the decoded instructions to perform the data processing operations. Registers 14 are provided for storing input operands of instructions processed by the pipeline 4. The registers 14 include several types of registers, including general purpose (integer) registers 16 for storing integer values, and control registers 20 for storing control parameters for controlling the execution of instructions by the processing circuitry 4 and other operations such as exception handling, security checks, etc. Other types of registers may also be provided, such as floating point registers for storing floating point values, or vector registers for storing vector operands that contain multiple independent data values.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0127] In some system implementations, it may be desirable for certain types of exception handlers to run in a non-privileged state. This may be useful, for example, for certain types of exceptions associated with devices controlled by library code provided by an untrusted third party, since it may not be desirable to allow an exception handler provided by an untrusted third party to have the full privileges available to the handler mode, since it cannot be prevented from modifying certain state information. However, as shown in FIG. 2, the handler mode operates in a privileged state by default, so a switch back to threaded mode is required for the exception handler to operate in a non-privileged state. However, in a typical implementation, the mechanism for switching from the handler mode to threaded mode will be via an exception return. It is generally undesirable for the original exception to trigger an exception return, since this would lower the execution priority of the original exception (after modifying the return address, the return would go to the non-privileged library code instead of the previous background processing). Lowering the execution priority in this way can prevent exception handling routines from being correctly prioritized. It is therefore preferable if the handler code handling the original exception could switch to threaded mode without triggering an exception return.

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

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

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

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

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

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

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

[0135] Also, the approach shown in FIG. 7 is very slow, which is a major blocker to the use of non-privileged libraries that have significant interrupt latency. This poor performance is due to multiple factors including the manual creation of the exception stack frame when handling the SVC exception between steps 2 and 3 of FIG. 7, and the event that two different SVC exceptions are required that trigger four additional register state stack and unstack events at steps 2, 3, 5, and 6 of FIG. 7, which represent memory access latency that would not be needed if the exception handler to handle the IRQ simply ran in handler mode. Thus, the performance cost may mean that some system designers may feel that they simply cannot use devices such as wireless network interfaces or USB controllers that are associated with untrusted library code, which may limit system design flexibility. As shown at the bottom of FIG. 7, in this example, the entire non-privileged process runs in the less secure domain, although it will be appreciated that the process may also run within the secure domain.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0200] FIG. 16C illustrates another potential attack where first an intermodal function call is made in step 1, which deprivileges from handler mode to thread mode, then a series of other transitions are made in step 2, and then an attempt is made to perform a cross-domain function return in step 3, where a transition is made from a secure domain to a less secure domain based on the intermodal function return stack frame set in step 1. In step 446 of FIG. 15, an integrity check is performed 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 may be triggered. Thus, in the scenario of FIG. 16C, where an intermodal function call is made and a cross-domain function return is attempted, the HDT check will detect a mismatch, ensuring that the intermodal stack frame created in step 1 cannot be considered a cross-domain stack frame in step 3. It should be noted that the HDT checks in steps 446 and 458 can be considered equivalent to a comparison between the intermodal flag M 146 in the dummy function return address and the HDT flag 178 in the function return stack frame, and any mismatch identified in this comparison will trigger a fault in either the intermodal return case (FIG. 16B) or the inter-domain return case (FIG. 16C).

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

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

[0203] It will be appreciated that some checks may overlap and that the same type of attack may trigger failures of more than one type of check. In some architecture implementations, if some of these checks are considered redundant, they may be excluded from the architecture requirements, and thus it is not necessarily required to implement all of the different types of attack prevention mechanisms, depending on what is considered important to protect. However, any one or more of these checks may be provided. It will be appreciated that the attacks shown in FIG. 16 are just a few of a huge number of different combinations of similar mismatch type attacks, where the attacker tries to corrupt the state of the system by attempting a return action (either a function or exception return) that does not match the original transition and thus the type of stack frame created.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0224] In this application, the term "configured to..." is used to mean that elements of an apparatus have a configuration that can perform a defined operation. In this context, "configuration" refers to a manner of arrangement or interconnection of hardware or software. For example, an apparatus may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform a function. "Configured to" does not mean that the apparatus elements have to be modified in some way to provide the defined operation.

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

Claims

1. An apparatus comprising: a processing circuit for performing data processing in one of a plurality of security domains including at least a secure domain and a less secure domain; a memory access check circuit for checking whether a memory access is permitted depending on a current security domain of the processing circuit, the memory access check circuit permitting the processing circuit to access a secure area of ​​the memory and a less secure area of ​​the memory when the processing circuit is performing data processing in the secure domain, and the memory access check circuit not permitting the processing circuit to access the secure area of ​​the memory when the processing circuit is performing data processing in the less secure domain; a control memory location for storing a domain transition disable configuration parameter that specifies whether domain transitions between the secure domain and the less secure domain are enabled or disabled in at least one mode of the processing circuit; When, in the at least one mode of the processing circuitry, the domain transition disable configuration parameter specifies that the domain transition is disabled in the at least one mode, the processing circuitry: triggering a signaling of an invalidation domain transition fault in response to an attempt to transition from the secure domain to the less secure domain; configured to trigger a signaling of the invalidation domain transition fault in response to an attempt to transition from the less secure domain to the secure domain; the processing circuitry is configured to perform data processing in one of a privileged state and a less-privileged state; and wherein a domain transition disable configuration parameter that specifies whether domain transitions between the secure domain and the less secure domain are enabled or disabled in at least one mode of the processing circuit when the processing circuit is in the privileged state is modifiable in the less secure domain, where access to the secure area of ​​the memory is not permitted.

2. In the secure domain, the processing circuitry is configured to control access to a memory using information stored in at least one secure configuration register; The apparatus of claim 1 , wherein in the less secure domain, the processing circuitry is configured to control access to memory using information stored in at least one less secure configuration register.

3. 3. The apparatus of claim 1, further comprising: a plurality of stack pointer registers for storing stack pointers for pointing to a stack data structure, including at least one stack pointer register associated with the secure domain and at least one stack pointer register associated with the less secure domain.

4. 4. The apparatus of claim 1, wherein in response to an attempt to perform at least one type of transition from the less secure domain to the secure domain in the at least one mode, the processing circuitry is configured to perform a disable domain transition check using the domain transition disable configuration parameters to determine whether to trigger signaling of the disable domain transition fault before performing at least one other security check to determine whether the attempt to transition from the less secure domain to the secure domain is permitted.

5. the processing circuit has a thread mode and a handler mode; In response to an exception condition, the exception control circuit is configured to control the processing circuit to switch to processing of the exception handler in the handler mode; The apparatus of claim 1 , wherein the at least one mode of the processing circuitry includes the threading mode.

6. The apparatus of claim 5 , wherein in the handler mode, the processing circuitry is configured to determine whether the domain transition is allowed independent of the domain transition disable configuration parameter.

7. In response to an intermodal call branch instruction specifying a branch target address, at least when the processing circuitry is in the handler mode, the instruction decoder configures the processing circuitry to: saving the function return address in a function return address location; switching a current mode of the processing circuitry to the threaded mode; setting the domain transition disable configuration parameter to specify whether the domain transition is enabled or disabled in the at least one mode; 7. Apparatus according to claim 5 or 6, configured to control branching to an instruction identified by the branch target address.

8. in response to a first variant of the intermodal call branch instruction, the instruction decoder configures the processing circuitry to set the domain transition disable configuration parameter to specify that the domain transition is disabled in the at least one mode; 8. The apparatus of claim 7, wherein in response to a second variant of the intermodal call branch instruction, the instruction decoder is configured to control the processing circuitry to set the domain transition disable configuration parameter to specify that the domain transition is enabled in the at least one mode.

9. In response to an intermodal function return instruction, the processing circuitry: causing the current mode of the processing circuitry to switch to the handler mode; updating the domain transition disable configuration parameter; 9. Apparatus according to any one of claims 5 to 8, arranged to branch to an instruction identified by a function return address.

10. 10. The apparatus of claim 9, wherein in response to the intermodal function return instruction, the processing circuitry is configured to set the domain transition disable configuration parameter to specify that the domain transition is enabled in the at least one mode.

11. 11. The apparatus of claim 9 or 10, wherein in response to the intermodal function return instruction, the processing circuitry is configured to record an indication of whether the domain transition disable configuration parameter specified that the domain transition was enabled or disabled in the at least one mode prior to the intermodal function return instruction.

12. 12. The apparatus of claim 1, wherein when the disable domain transition fault is signaled in response to an attempt to transition from a first security domain to a second security domain, when the processing circuitry is in the at least one mode, exception control circuitry controls the processing circuitry to process an exception handler in the first security domain.

13. 13. The apparatus of claim 1, wherein exception control circuitry is responsive to an exception condition to update the domain transition disable configuration parameter to specify that the domain transition is enabled in the at least one mode.

14. 14. The apparatus of claim 1, wherein the exception control circuitry performs a state save in response to an exception condition to save architectural state associated with processing performed before the exception condition occurred, the architectural state saved in the state save including a value indicative of the domain transition disable configuration parameter prior to the exception condition.

15. 15. The apparatus of claim 14, wherein in the state saving, the exception control circuitry is configured to save a first stack frame, including an exception return address and a first subset of architectural state, in a stack data structure and save the value indicative of the domain transition disable configuration parameter in a predetermined register accessible to an exception handler executed in response to the exception condition.

16. in response to at least an exception condition triggering a transition from the secure domain to the less secure domain, the exception control circuitry is configured to save the first stack frame, a second stack frame including a second subset of architectural state and cross-check information for checking the domain transition disable configuration parameter in the stack data structure; 16. The apparatus of claim 15, wherein upon at least an exception return transition from the less secure domain to the secure domain, the exception control circuitry is configured to trigger a fault signaling if a mismatch is detected between the value indicative of the domain transition disable configuration parameter and the cross-check information in the second stack frame.

17. In response to an inter-domain call branch instruction requesting a transition from the secure domain to the less secure domain, an instruction decoder configures the processing circuitry to: saving a function return address to a function return address location; switching the processing circuitry to the less secure domain; and branching to an instruction identified by a branch target address specified by the cross-domain call branch instruction.

18. In response to the inter-domain call branch instruction, the instruction decoder configures the processing circuitry to: performing the cross-domain call fork operation if the domain transition disable configuration parameter specifies that the domain transition is enabled in the at least one mode or if the processing circuitry is in a mode other than the at least one mode; 20. The apparatus of claim 17, further configured to control: trigger signaling of the disabled domain transition fault when the processing circuitry is in the at least one mode and the domain transition disable configuration parameter specifies that the domain transition is disabled in the at least one mode.

19. in response to an inter-domain call branch instruction requesting a transition from the secure domain to the less secure domain, the instruction decoder is configured to control the processing circuitry to save a function return address in a stack data structure and a dummy function return address in a link register; 19. The apparatus of claim 1, wherein in response to an attempt to branch to the dummy function return address when the dummy function return address indicates an inter-domain function return, the processing circuitry is configured to control the processing circuitry to trigger signaling of the disable domain transition fault when the processing circuitry is in the at least one mode and the domain transition disable configuration parameter specifies that the domain transition is disabled in the at least one mode.

20. the memory access check circuit is configured to maintain security attribute data indicative of whether each address region is a secure address region or a less secure address region; the apparatus includes an instruction fetch circuit for fetching instructions from a cache or memory for decoding by an instruction decoder; 20. The apparatus of claim 1, wherein in response to an attempt to fetch an instruction having an address in a secure address region, the instruction fetch circuitry is configured to trigger signaling of the disable domain transition fault if the processing circuitry is in the less secure domain, the processing circuitry is in the at least one mode, and the domain transition disable configuration parameter specifies that the domain transition is disabled in the at least one mode.

21. The apparatus of claim 1 , wherein triggering the signaling of the invalidation domain transition fault comprises setting a syndrome flag indicating an invalidation domain transition fault.

22. 1. A data processing method comprising the steps of: performing a data processing using an apparatus including a processing circuit for performing a data processing in one of a plurality of security domains including at least a secure domain and a less secure domain, and a memory access check circuit for checking whether a memory access is permitted according to a current security domain of the processing circuit, wherein the memory access check circuit allows the processing circuit to access a secure area of ​​the memory and a less secure area of ​​the memory if the processing circuit is performing a data processing in the secure domain, and the memory access check circuit does not allow the processing circuit to access the secure area of ​​the memory if the processing circuit is performing a data processing in the less secure domain; storing, in a control memory location, a domain transition disable configuration parameter that specifies whether domain transitions between the secure domain and the less secure domain are enabled or disabled in at least one mode of the processing circuit; triggering, in the at least one mode of the processing circuit, in response to an attempt of a domain transition between the secure domain and the less secure domain, signaling an disable domain transition fault if the domain transition disable configuration parameter specifies that the domain transition is disabled in the at least one mode, regardless of whether the attempted domain transition is from the secure domain to the less secure domain or from the less secure domain to the secure domain; Including, the processing circuitry is configured to perform data processing in one of a privileged state and a less-privileged state; 11. The data processing method of claim 10, wherein when the processing circuit is in the privileged state, a domain transition disable configuration parameter that specifies whether domain transitions between the secure domain and the less secure domain are enabled or disabled in at least one mode of the processing circuit is modifiable in the less secure domain, where access to the secure area of ​​the memory is not permitted.

23. 1. A computer program for controlling a host data processing apparatus to provide an instruction execution environment for executing instructions, comprising: The computer program comprising: processing program logic for performing data processing in one of a plurality of security domains including at least a secure domain and a less secure domain; a memory access checking program logic for checking whether a memory access is permitted depending on a current security domain of the processing program logic, the memory access checking program logic permitting the processing program logic to access a secure area of ​​the memory and a less secure area of ​​the memory if the processing program logic is performing data processing in the secure domain, and the memory access checking program logic not permitting the processing program logic to access the secure area of ​​the memory if the processing program logic is performing data processing in the less secure domain; a configuration parameter setting program logic for setting, in a control storage location, a domain transition disable configuration parameter that specifies whether a domain transition between the secure domain and the less secure domain is enabled or disabled in at least one mode of the processing program logic; If, in the at least one mode of the processing program logic, the domain transition disable configuration parameter specifies that the domain transition is disabled in the at least one mode, the processing program logic: triggering a signaling of an invalidation domain transition fault in response to an attempt to transition from the secure domain to the less secure domain; configured to trigger a signaling of the invalidation domain transition fault in response to an attempt to transition from the less secure domain to the secure domain; the processing program logic is configured to execute data processing in one of a privileged state and a less privileged state; a domain transition disable configuration parameter that specifies whether domain transitions between the secure domain and the less secure domain are enabled or disabled in at least one mode of the processing program logic when the processing program logic is in the privileged state, the domain transition disable configuration parameter being modifiable in the less secure domain where access to the secure area of ​​the memory is not permitted.

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

Images