Techniques for constraining access to memory using capabilities

Abstract

An apparatus and method are provided for constraining access to memory using capabilities. A processing circuit performs an operation during which a request for access to memory is generated, and a memory address for the access request is generated using a capability that identifies constraint information. A capability check circuit performs a capability check operation to determine whether a given access request, whose memory address is generated using a given capability, is permitted based on the constraint information identified by the given capability. The memory access check circuit then further constrains access to memory by the given access request depending on a trust level associated with the given access request. A given capability has a capability trust level associated with it, and the trust level associated with a given access request depends on both a current mode trust level associated with a current mode of operation of the processing circuit and the capability trust level of the given capability.

Description

[Technical Field]

[0001] This invention was made with government support under Contract No. HR001118C0016 awarded by the Defense Advanced Research Projects Agency (DARPA). The government has certain rights in this invention. [Background technology]

[0002] The present technique relates to the field of data processing, and more particularly to restricting access to memory using capabilities.

[0003] There is growing interest in capability-based architectures, in which specific capabilities are defined for a given process and an error can be triggered if there is an attempt to perform an action outside the defined capabilities. Capabilities can take various forms, but one type of capability is a bounded pointer (which may also be referred to as a "fat pointer").

[0004] A number of capability storage elements (e.g., registers) may be provided for storing capabilities for access by a processing circuit of a data processing apparatus. Each capability may include a number of permission flags identifying one or more permissions associated with the capability, e.g., to restrict the types of operations that can be performed when using the capability. For example, considering a bounded pointer in such a capability storage element, this, together with one or more permission flags identifying the associated permissions, may provide information used to identify a non-extensible range of memory addresses accessible by the processing circuit when using that capability. While the processing circuit may be enabled, at least when operating in a particular operating mode, to take steps to reduce the range and / or clear the permission flag associated with any particular bounded pointer available to it, it typically cannot expand the range or set the permission flag to attempt to increase the capability granted to the processing circuit by that bounded pointer, as this would potentially undermine the security benefits gained by using the capability.

[0005] It is desirable to provide more flexibility in how capabilities are managed while attempting to curb the ability to circumvent specific security measures implemented using capabilities. Summary of the Invention

[0006] In a first exemplary arrangement, an apparatus is provided comprising: a processing circuit for performing an operation during which a request for access to a memory is generated, the processing circuit being arranged to generate a memory address for the access request using a capability that identifies constraint information; a capability check circuit for performing a capability check operation to determine whether a given access request, whose memory address is generated using a given capability, is permitted based on the constraint information identified by the given capability; and a memory access check circuit for further constraining access to the memory by the given access request depending on a trust level associated with the given access request, wherein a given capability has a capability trust level associated with it, and the trust level associated with the given access request depends on both a current mode trust level associated with a current mode of operation of the processing circuit and the capability trust level of the given capability.

[0007] In a further exemplary arrangement, a method of constraining access to a memory is provided, the method including employing a processing circuit to perform an operation during which a request to access the memory is generated and the processing circuit generates a memory address for the access request using a capability that identifies constraint information; performing a capability check operation to determine whether a given access request, the memory address of which is generated using a given capability, is permitted based on the constraint information identified by the given capability; and further constraining access to the memory by the given access request in dependence on a trust level associated with the given access request, wherein the given capability has a capability trust level associated with it, and the trust level associated with the given access request depends on both a current mode trust level associated with a current mode of operation of the processing circuit and the capability trust level of the given capability.

[0008] In yet a further exemplary arrangement, a computer program for controlling a host data processing apparatus to provide an instruction execution environment is provided, the computer program including: processing program logic for performing operations during which a memory access request is generated, the processing program logic being arranged to generate a memory address for the access request using a capability that identifies constraint information; capability check program logic for performing a capability check operation to determine whether a given access request, whose memory address is generated using a given capability, is permitted based on the constraint information identified by the given capability; and memory access check program logic for further constraining access to memory by the given access request depending on a trust level associated with the given access request, wherein a given capability has a capability trust level associated with it, and the trust level associated with a given access request depends on both a current mode trust level associated with a current mode of operation of the processing program logic and the capability trust level of the given capability. A computer-readable medium may be provided for storing such a computer program, and the computer-readable medium may be in a non-transitory or transitory form.

[0009] In yet a further exemplary arrangement, an apparatus is provided including processing means for performing an operation during which a request for access to a memory is generated, the processing means being arranged to generate a memory address for the access request using a capability that identifies constraint information; capability checking means for performing a capability check operation to determine whether a given access request, whose memory address is generated using a given capability, is permitted based on the constraint information identified by the given capability; and memory access checking means for further constraining access to the memory by the given access request in dependence on a trust level associated with the given access request, wherein a given capability has a capability trust level associated with it, and the trust level associated with the given access request depends on both a current mode trust level associated with a current mode of operation of the processing means and the capability trust level of the given capability. [Brief explanation of the drawings]

[0010] The present technique will now be further described, by way of example only, with reference to examples of the technique illustrated in the accompanying drawings, in which: [Figure 1] FIG. 1 is a block diagram of an apparatus according to an exemplary implementation. [Figure 2] 10 shows an example of the type of instruction that can trigger an error when attempting to set or access a pointer value within a set of bounded pointer storage elements, where the pointer value is used to specify an address outside the range indicated by associated range information. [Figure 3] 1 illustrates the use of tag bits in association with bounded pointers, according to one exemplary implementation. [Figure 4] 10A-10C illustrate generally the form of capabilities that may be used in accordance with the techniques described herein, with confidence level indicators provided in association with the capabilities. [Figure 5A]FIG. 1 is a diagram illustrating schematically how a trust level for an individual access request may be generated and subsequently used to constrain access to memory, according to one exemplary implementation. [Figure 5B] 5B is a flow chart illustrating the operation of the apparatus shown generally in FIG. 5A according to one exemplary implementation. [Figure 6A] FIG. 1 is a block diagram that schematically illustrates components that may be provided within a capability processing circuit, according to one exemplary implementation. [Figure 6B] 1 is a flow diagram illustrating the performance of a capability creation operation according to one exemplary implementation. [Figure 7] 1 illustrates an example of different domains and processing states of a processing circuit according to one exemplary implementation, showing how capability generation capabilities may be provided when the processing circuit is operating in one or more particular combinations of domains and processing states. [Figure 8A] 1 is a flow diagram illustrating steps performed to load capabilities from memory according to one exemplary implementation. [Figure 8B] 10 is a flow diagram illustrating steps performed to load capabilities from memory according to a further exemplary implementation. [Figure 9] 1 is a flow diagram illustrating how the ability to reduce a capability trust level of a capability can be made dependent on a current mode trust level associated with a current operating mode of a processing circuit, according to one exemplary implementation. [Figure 10] 1 illustrates, in schematic form, how a compiler may be used to generate a set of initial capabilities, according to one exemplary implementation. [Figure 11] 1 is a flow diagram illustrating a process that may be employed in one exemplary implementation to determine whether to selectively enable modification of immutable capabilities. [Figure 12] An example simulator that can be used is shown. DETAILED DESCRIPTION OF THE INVENTION

[0011] In accordance with the techniques described herein, an apparatus is provided having a processing circuit for performing an operation during which a request for access to a memory is generated. The processing circuit is arranged to generate a memory address for the access request using a capability that identifies constraint information. The memory address generated by the processing circuit may be a virtual address in a system in which address translation is performed, or alternatively may be a physical address in a system that does not support address translation.

[0012] The device also has capability check circuitry that performs a capability check operation to determine whether a given access request, whose memory address is generated using a given capability, is permitted based on the constraint information identified by the given capability. The capability check circuitry may be a separate component from the processing circuitry or, alternatively, may be provided within the processing circuitry of the device.

[0013] There are several ways in which constraint information may be identified by an associated capability. For example, a capability may directly contain the constraint information in one exemplary implementation. However, in alternative implementations, a capability may instead indicate (directly or indirectly) a location in memory where the constraint information is located.

[0014] The apparatus further includes a memory access check circuit for further restricting access to the memory by a given access request depending on a trust level associated with the given access request. The memory access check circuit can take various forms, such as a memory management unit (MMU), a memory protection unit (MPU), a security attribute unit (SAU), or a combination of these components. Prior to the techniques described herein, such memory access check circuitry was typically arranged to consider a trust level associated with a current operating mode of the processing circuit when further restricting access to the memory, rather than associating any particular trust level with each access request. However, according to the techniques described herein, a given capability has a capability trust level associated with it, and that information can also be factored into the checks performed by the memory access check circuit. In particular, according to the techniques described herein, the trust level associated with a given access request depends on both a current mode trust level associated with a current mode of operation of the processing circuit and a capability trust level of the given capability.

[0015] As will be discussed in more detail below, by providing a capability trust level associated with each capability, this can enhance the way in which capabilities can be managed and used. For example, as discussed above, the capability trust level is taken into account by memory access checking circuitry when determining whether to allow access to memory specified by a given access request, and so can provide a mechanism that allows capabilities to be generated by processing circuitry in particular circumstances, and the capability trust level associated with a particular capability can then be effectively used to track the origin of that capability and constrain subsequent accesses made using that capability.

[0016] Additionally, such a mechanism further enables specific use-case protections to be supported, for example, to counter confusing deputy attacks. A confusing deputy attack can occur when less privileged code passes a pointer to more privileged code and attempts to use the more privileged code to perform a specific action on its behalf. Through the use of capability trust levels, this can prevent more privileged code from accidentally using a pointer created by the unprivileged code to maliciously address an area of memory that should not be accessible to the unprivileged code. In particular, in such a situation, the pointer was generated using a capability whose capability trust level does not exceed the capability trust level of the unprivileged code; therefore, even if an access is attempted from privileged code, the memory access circuitry prevents access to privileged memory due to the capability trust level of the capability used to generate the pointer.

[0017] The techniques described above can be used in a wide variety of different systems. For example, the processing circuitry can take a variety of forms. For example, the processing circuitry can be a central processing unit (CPU) arranged to execute program code in a variety of different operating modes, although the techniques can also be applied in connection with other forms of processing circuitry, such as direct memory access (DMA) controllers, cryptographic accelerators, etc.

[0018] There are several ways in which the trust level associated with a given access request may be determined based on both the current operating mode of the processing circuit and the capability trust level of a given capability. For example, the system may be based on permission granting or permission restriction, and the trust level associated with a given access request may depend on which of these techniques is used. However, according to one exemplary implementation, the technique is based on permission restriction, and the trust level associated with a given access request is constrained to which of the current mode trust level and the capability trust level represents the lower trust level.

[0019] While there are several ways in which a capability trust level can be specified for a capability, in one exemplary implementation, the capability trust level is encoded within a given capability. This can be implemented in a variety of ways, but in one exemplary implementation, for each capability, the constraint information provides at least one set of permissions that identify various types of memory accesses allowed for memory addresses generated using that capability, and the capability trust level is provided as an additional permission.

[0020] However, it should be noted that while in the exemplary implementations described above, the capability trust level is encoded within a given capability, this is not a requirement, and other mechanisms for associating a capability trust level with a given capability may be provided. For example, in an alternative implementation, a given capability may provide an identifier that indicates a location that includes the capability trust level. Thus, in such an implementation, the capability trust level information may reside in another location, e.g., memory, and the capability itself may include a value that indicates the location of metadata that provides the capability trust level. The identifier used to indicate the location that includes the capability trust level may take various forms. For example, it may be an offset from an address stored in a system global register, thus allowing a memory address that identifies where in memory the capability trust level is maintained to be determined. Alternatively, the identifier may directly identify a location in memory where the capability trust level information is stored.

[0021] The constraint information provided within each capability can take a variety of forms, but in one exemplary implementation, it also provides bounds information used to determine an acceptable range of memory addresses for memory addresses generated for any access request using that capability. In one exemplary implementation, the constraint information may include both such bounds information and a set of permissions identifying the types of memory access allowed for memory addresses generated using that capability. A capability may also include other information, such as a pointer value used when generating a memory address by adding that pointer value to some offset to generate the memory address. The generated memory address can then be compared with the bounds information to determine whether the generated memory address is within the acceptable range.

[0022] In one exemplary implementation, the processing circuitry includes capability generation circuitry arranged to perform a capability generation operation to generate a capability at least when the current mode trust level exceeds a threshold trust level, and to set an associated capability trust level for the generated capability to indicate a trust level lower than the current mode trust level. Thus, in such an exemplary implementation, the processing circuitry may be given limited configuration rights to create capabilities that can then be used within the system. However, when performing such capability generation operations, the processing circuitry is constrained to ensure that the associated capability trust level indicates a trust level lower than the current mode trust level, thus preventing the processing circuitry in its current operating mode from generating its own capabilities for use in its current operating mode. Instead, any generated capabilities are for use in one or more operating modes having a trust level lower than the current mode trust level used when generating the capability.

[0023] The capability creation capabilities described above may be limited to one or more particular mode trust levels, such that the processing circuitry can create capabilities only when in those one or more particular modes of operation. However, alternatively, such capability creation techniques may be supported for any mode trust level other than the lowest supported trust level when using the capability.

[0024] While in the above exemplary implementation, the capability generation function may be limited to the trust levels of one or more modes, resulting in the capability trust level associated with the generated capability being set lower than the current mode trust level, in alternative implementations, the capability generation function may be supported in different manners. For example, in one particular implementation, a processing circuit may include a capability generation circuit arranged to perform a capability generation operation to generate a capability from source data if the current mode trust level exceeds a capability trust level indicator provided in association with the source data. Thus, the source data from which a capability is to be generated may have a capability trust level indicator provided in association therewith, and the capability generation circuit may be permitted to perform the capability generation operation if the current mode trust level exceeds that capability trust level indicator. If not, then generation of a valid capability may be prevented. This may be achieved in various ways, for example, by preventing a control value provided in association with the capability from being set to identify the capability as a valid capability (such control value is also referred to herein as a tag value) or by generating a fault.

[0025] In one exemplary implementation, the processing circuit may be arranged to execute program instructions, the processing of which is constrained by a dominant capability. The processing circuit may further comprise a control flow modification processing circuit used to perform a control flow modification operation, the control flow modification operation defining a control flow modified target address indicating the address of a program instruction for execution after the control flow modification operation. In such an implementation, the aforementioned capability generation circuit may be used to generate a capability for use as the next dominant capability. In particular, the capability generation circuit may be arranged to determine an address at which capability constraint information is stored in dependence on the control flow modified target address. That capability constraint information may then be retrieved and used to generate a capability that forms the next dominant capability. The next dominant capability may be generated in dependence on at least the capability constraint information and may have an associated capability trust level that is constrained to indicate a trust level lower than the current mode trust level. Thus, the created capability can have its associated trust level demoted when necessary based on the current mode trust level (i.e., the trust level before the branch was taken).

[0026] It should also be noted that in such implementations, the current mode trust level of the processing circuit may be further constrained by the trust level associated with the prevailing capability. This can ensure, for example, that privileged code is never allowed to execute when an unprivileged capability is used to generate a program counter value. Thus, in such implementations, the mode trust level of the processing circuit may then be constrained to be the minimum of the current execution level of trust inherent in the current execution mode (e.g., depending on whether the processing circuit is operating in a secure domain or a less secure domain and / or in a privileged or unprivileged state) and the capability trust level set for the program counter capability used to execute the current code.

[0027] Capabilities can be stored in various locations within a system. For example, a device can have a set of capability registers used to store capabilities for reference by a processing circuit, but can also have a memory circuit that can be used to store one or more capabilities. The processing circuit can be arranged to perform a load operation to load a selected capability from the memory circuit into a selected capability register from the set of capability registers. During this process, the processing circuit can be arranged to selectively modify the capability trust level such that the selected capability stored in the selected capability register has a capability trust level that is constrained to not exceed the current mode trust level or the capability trust level of the selected capability stored in the memory circuit. Thus, while the original version of the capability, which may still be retained within the memory circuit, does not have its associated capability trust level altered, the version stored in the capability register may have its capability trust level altered by the processing circuit during the load operation to constrain its capability trust level and therefore constrain subsequent memory access operations performed using the loaded capability depending on the capability trust level of the capability stored in the capability register.

[0028] In some implementations, a load operation may, in some cases, be performed to load normal data (rather than capabilities) into a capability register, and in such cases, it may be important that bits in the data associated with the capability trust level were actually data that the capability would not modify, because in this case, it is not the capabilities that are being processed, and modifying those bits would corrupt the data. Thus, in one exemplary implementation, the processing circuitry may be arranged to selectively modify the capability trust level only during a load operation when a selected capability has a control value that identifies the selected capability as a valid capability. With such an approach, the above-mentioned selective modification of the capability trust level during a load operation is performed only when a capability is actually loaded into the capability register.

[0029] There are several ways in which the capability trust level may be constrained to not exceed the current mode trust level or the capability trust level of the selected capability stored in the memory circuit. However, in one particular exemplary implementation, when the current mode trust level is less than the capability trust level of the selected capability stored in the memory circuit, the processing circuit is arranged to demote the capability trust level of the selected capability stored in the selected capability register to match the current mode trust level.

[0030] Furthermore, when the current mode trust level is equal to or greater than the capability trust level of the selected capability stored in the memory circuit, the processing circuitry may be arranged to leave the capability trust level unchanged when the selected capability is stored in the selected capability register. Thus, in this scenario, the capability trust level does not change during the load operation.

[0031] In one exemplary implementation, the processing circuitry is arranged to allow the capability trust levels of selected capabilities to be reduced from their current capability trust levels when at least the current mode trust level exceeds a threshold trust level. Such a mechanism can therefore provide flexibility in how created capabilities are managed, and in particular, allow capability trust levels to be demoted. Such a technique may enable program code executing on the processing circuitry to demote the capability trust levels of one or more capabilities while at least the current mode trust level exceeds the threshold trust level (i.e., indicating that the current program code is sufficiently trusted). In some implementations, such functionality may be permitted regardless of the current mode trust level, or this ability to demote the trust levels of capabilities may be limited in a different manner, e.g., with respect to capabilities whose capability trust levels do not exceed the current mode trust level.

[0032] In one exemplary implementation, a device may be provided with one or more initial capabilities, whose capability trust levels indicate the highest trust level supported by the device when utilizing the capabilities. Such initial capabilities may be set, for example, before the device enters a capability operating mode in which access requests are constrained by the capabilities. The initial capabilities may be defined in various ways, but in one implementation, they may be defined by a compiler used to compile program code executed on the device. Due to the aforementioned techniques that can be employed when loading capabilities from memory, particularly the ability to selectively demote capability trust levels in situations where the current mode trust level is lower than the capability trust level of the loaded capability, this can ensure correct operation even if the initial capabilities, when created, were given the highest trust level supported by the device when utilizing the capabilities.

[0033] In one exemplary implementation, all initial capabilities can be set to have a capability trust level that indicates the highest level of trust, but if desired, for example, if the developer knows that a capability should always be unprivileged, one or more of the initial capabilities can be created with a lower trust level.

[0034] A processing circuit can be arranged to operate in a variety of different ways, and the current mode trust level depends on how the processing circuit is currently operating. For example, in one implementation, the processing circuit can be arranged to execute program code in one of a plurality of states including at least a privileged state and an unprivileged state, and the current mode trust level can depend on which of the plurality of states the current program code is executing in. Note that there can be two different states, i.e., a privileged state and an unprivileged state, or there can be N different states with different levels of privilege, where N is greater than 2, and in any of these scenarios, the current mode trust level can be set depending on which state the current program code is executing in. For example, a particular implementation can provide different exception levels (EL), such as EL0, EL1, and EL2, as different states, where EL2 is more privileged than EL1, and EL1 is more privileged than EL0.

[0035] Alternatively, or in addition, the processing circuitry may be arranged to execute program code in one of a plurality of security domains including at least a secure domain and a less secure domain, and the current mode trust level may depend on which of the plurality of security domains the current program code is executing in. Similar to the processing state, there may be only two domains, i.e., a secure domain and a non-secure domain, or alternatively, there may be M different domains, where M is greater than 2 and each domain has a different level of security, and the current mode trust level may then be set depending on which security domain the current program code is executing in.

[0036] It should also be noted that the current mode trust level may be set depending on multiple different orthogonal trust levels, and there may be more than two orthogonal trust levels. Thus, for example, in one implementation, the processing circuit may be capable of operating in both the different states and different security domains discussed above, and the current mode trust level may be set depending on both of those factors.

[0037] In one exemplary implementation, the capabilities may include at least one immutable capability whose constraint information is identified as immutable. Typically, this means that the processing circuitry cannot change the constraint information once the capability is established. However, according to the techniques described herein, in some circumstances, it is possible to modify the constraint information of a selected immutable capability. For example, in one implementation, at least when the current mode trust level exceeds a threshold trust level, the processing circuitry is arranged to allow the constraint information of a selected immutable capability to be modified if the selected immutable capability has a capability trust level less than the current mode trust level. In some exemplary implementations, it may not be necessary to check whether the current mode trust level exceeds the threshold trust level, and instead, the constraint information of a selected immutable capability may always be allowed to be modified if the selected immutable capability has a capability trust level less than the current mode trust level.

[0038] In alternative implementations, selective modification of immutable capabilities may be managed differently. For example, while in the above example, if the trust level criteria are not met, no modification action is performed on the immutable capability, in alternative implementations, the modification may occur even if the trust level criteria are not met, but in that case, the tag bit may be cleared, effectively disabling the capability. As a further alternative, modification may be performed, but if needed, the capability trust level may be demoted so that the above-mentioned trust criteria are met, i.e., once the immutable capability is changed, the capability trust level is lower than the current mode trust level. This may then restrict future use of the modified immutable capability, or the processing circuitry may be arranged to generate a fault in such a situation.

[0039] Note that there are several ways in which a capability can be identified as immutable: In one exemplary implementation, a bit may be designated in a capability to indicate (directly or indirectly) whether the capability is immutable.

[0040] Referring to the aforementioned process of performing a load operation to load a capability from a memory circuit into a capability register, involving selective demotion of the capability trust level of that capability when that capability is stored in a selected capability register, when considering that process in the context of immutable capabilities, the processing circuitry may then be configured to disable demotion of the capability trust level of the selected capability when the selected capability is an immutable capability. Such an approach may enable, for example, spilling privileged immutable capabilities from within a non-privileged mode without modifying the immutable capabilities.

[0041] In one exemplary implementation, the processing circuit is arranged to issue a fault signal when an attempt is made to perform an access identified by a given access request if a capability trust level associated with the given capability exceeds the current mode trust level. This may prevent the processing circuit from attempting to use a capability that is not intended for use by the processing circuit when in its current mode of operation. There are a variety of different actions that can be taken to trigger a fault. For example, a fault may be triggered based on a check of the generated address or may be triggered even before the address is generated.

[0042] In one example implementation, when taking into account the previous selective modification of the capability trust level when a capability is loaded from memory into a capability register, then in one example implementation, the selected capability stored in the selected capability register may be further constrained to have a capability trust level that does not exceed the capability trust level associated with the capability used to generate the memory address for the load operation. Such an approach may be used to further constrain the capability trust level associated with a capability loaded from memory into a capability register.

[0043] In one exemplary implementation, when performing the aforementioned load of a capability from memory to a capability register, the demotion of the capability trust level of the selected capability stored in the selected capability register can be controlled depending on control information. This control information can be stored in the capability itself, for example, in the capability being loaded, or in the capability actually used to generate the memory address for the load operation. Alternatively, this control information can be stored in a separate control register. This latter scenario makes it possible, for example, to use MPU region attributes to determine whether demotion should occur during the loading of the capability into the capability register. Thus, purely by way of example, demotion can be arranged to occur if the capability is loaded from an MPU region marked as read-only (e.g., code memory), but not if the region is instead marked as read-write (e.g., used for the heap or stack).

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

[0045] The techniques described herein can be employed in a variety of data processing systems and in association with different types of processing circuits within such systems. For example, the techniques can be used in association with processing circuits taking the form of a central processing unit (CPU), but can alternatively be used in association with other processing circuits such as direct memory access (DMA) controllers, cryptographic accelerators, etc. Purely for purposes of illustration in Figure 1 below, the processing pipeline of a CPU will be considered as an example of a processing circuit in which the described techniques can be used.

[0046] 1 illustrates schematically an example of a data processing apparatus 2 including a processing pipeline 4 for processing instructions. In this example, processing pipeline 4 includes a number of pipeline stages, including a fetch stage 6, a decode stage 8, an issue stage 10, an execute stage 12, and a writeback stage 14, although it will be understood that other types of stages or combinations of stages may be provided. For example, a rename stage for performing register renaming may be included in some example implementations. Instructions to be processed move from stage to stage, and while one instruction is pending in one stage, another instruction may be pending in a different stage of pipeline 4.

[0047] The fetch stage 6 fetches instructions from a level 1 (L1) instruction cache 20. The fetch stage 6 may typically fetch instructions sequentially from consecutive instruction addresses. However, the fetch stage may also have a branch predictor 22 for predicting the outcome of branch instructions; the fetch stage 6 may fetch instructions from a (non-sequential) branch target address if the branch is predicted taken, or from the next sequential address if the branch is predicted not taken. The branch predictor 22 may include one or more branch history tables for storing information for predicting whether a branch is likely to be taken. For example, the branch history table may include counters for tracking the actual outcomes of previously executed branches or for indicating the confidence of predictions made for the branch. The branch predictor 22 may also include a branch target address cache (BTAC) 24 for caching previous target addresses of branch instructions so that they can be predicted when the same branch instruction is later encountered.

[0048] Fetched instructions are passed to a decode stage 8, which decodes the instructions to produce decoded instructions. The decoded instructions may include control information for controlling the execution stage 12 to perform the appropriate processing operations. For some more complex instructions fetched from the cache 20, the decode stage 8 may map those instructions to multiple decoded instructions, which may be known as micro-operations (uops or uops). Therefore, there may not be a one-to-one relationship between instructions fetched from the L1 instruction cache 20 and instructions found in later stages of the pipeline. In general, references to "instructions" in this application should be interpreted to include micro-operations.

[0049] Decoded instructions are passed to issue stage 10, which determines whether operands required to execute the instruction are available and issues the instruction for execution if the operands are available. Some example implementations may support in-order processing, such that instructions are issued for execution in an order that corresponds to the program order in which they were fetched from L1 instruction cache 20. Other example implementations may support out-of-order execution, such that instructions can be issued to execution stage 12 in an order that differs from the program order. Out-of-order processing can be useful for improving performance because later instructions in program order, whose operands are available, can execute first while earlier instructions are stalled waiting for operands.

[0050] The issue stage 10 issues instructions to an execution stage 12, where the instructions are executed to perform various data processing operations. For example, the execution stage may include several execution units 30, 32, 34, including an arithmetic / logic unit (ALU) 30 for performing arithmetic or logical operations on integer values, a floating-point (FP) unit 32 for performing operations on values represented in floating-point format, and a load / store unit 34 for performing load operations to load data values from a level 1 (L1) data cache 36 into a register 40 or store operations to store data values from the register 40 into the L1 data cache 36. These are just a few examples of the types of execution units that may be provided, and it will be understood that many other types may be provided. To perform processing operations, the execution stage 12 may read data values from a set of registers 40. The results of the executed instructions may then be written back to the registers 40 by a writeback stage 14.

[0051] The L1 instruction cache 20 and the L1 data cache 36 may be part of a cache hierarchy that includes multiple levels of cache. For example, a level 2 (L2) cache 44 may also be provided, and optionally, further levels of cache may be provided. In this example, the L2 cache 44 is shared between the L1 instruction cache 20 and the L1 data cache 36, although other examples may have separate L2 instruction and data caches. If an instruction to be fetched is not in the L1 instruction cache 20, it may be fetched from the L2 cache 44; similarly, if the instruction is not in the L2 cache 44, it may be fetched from main memory 50. Similarly, in response to a load instruction, if the data is not in the L1 data cache 36, it may be fetched from the L2 cache 44 and, if needed, from memory 50. Any known scheme may be used to manage the cache hierarchy.

[0052] Addresses used by pipeline 4 to reference program instructions and data values may be virtual addresses, but at least main memory 50, and optionally at least some levels of the cache hierarchy, may also be physically addressed. Accordingly, a translation lookaside buffer (TLB) may be provided (e.g., within memory access check circuitry 52, described in more detail below) to translate virtual addresses used by pipeline 4 into physical addresses used to access cache or memory. For example, the TLB may include multiple entries, each specifying a virtual page address for a corresponding page of the virtual address space and a corresponding physical page address to which the virtual page address should be mapped to translate the virtual address within the corresponding page into a physical address. For example, the virtual and physical page addresses may correspond to the most significant portions of the corresponding virtual and physical addresses, with the remaining least significant portions remaining unchanged when mapping the virtual address to a physical address. Similar to the address translation information, each TLB entry may also include some information specifying access permissions, such as whether the page in which the address resides is accessible in a certain mode of pipeline 4. In some example implementations, the TLB entry may also define other characteristics of the address's corresponding page, such as cache policy information that defines which levels of the cache hierarchy are updated in response to a read or write operation (e.g., whether the cache should operate in write-back or write-through mode), or information that defines whether data accesses to addresses within the corresponding page can be reordered by the memory system compared to the order of data accesses issued by pipeline 4.

[0053] It will be appreciated that a single-level TLB may be used, or alternatively, a hierarchy of TLBs may be provided, such that a level 1 (L1) TLB may contain TLB entries for translating addresses in several recently accessed pages, and a level 2 (L2) TLB may be provided to store entries for a larger number of pages. When a required entry is not present in the L1 TLB, it may be fetched from the L2 TLB or a further TLB in the hierarchy. If the required entry for the accessed page is not present in either TLB, a page table walk may be performed to access a page table in memory 50. Any known TLB management scheme may be used in the present technique.

[0054] It will also be appreciated that some systems may support multiple levels of address translation, so that, for example, a first TLB (or TLB hierarchy) may be used to translate a virtual address to an intermediate address, and a second level of address translation using one or more further TLBs may translate the intermediate address to a physical address for use in accessing a cache or memory. This may be useful, for example, to support virtualization, where the first level of address translation may be managed by an operating system and the second level of address translation may be managed by a hypervisor.

[0055] As shown in Figure 1, device 2 may have a set of bounded pointer registers 60. Although the set of bounded pointer registers is shown in Figure 1 as being physically separate from the set of general purpose data registers 40, in an alternative exemplary implementation, the same physical storage may be used to provide both the general purpose data registers and the bounded pointer registers.

[0056] Each bounded pointer register 60 includes a pointer value 62 that can be used to determine the address of a data value to be accessed and range information 64 that specifies the allowable range of addresses when using the corresponding pointer 62. The bounded pointer register 60 may also include restriction information 66 (also referred to herein as permission information) that can define one or more restrictions / permissions regarding the use of the pointer. For example, the restrictions 66 can be used to restrict the types of instructions that can use the pointer 62 or the modes of the pipeline 4 that can use the pointer. Therefore, the range information 64 and the restriction information 66 can be thought of as defining the capabilities within which the pointer 62 is permitted to be used. Any attempt to use the pointer 62 outside the defined capabilities can trigger an error. The range information 64 can be useful, for example, to ensure that the pointer stays within known boundaries and does not stray into other areas of the memory address space that may contain sensitive or secure information. In an exemplary implementation that uses the same physical storage for both general-purpose data registers and bounded pointer registers, in one exemplary implementation, the pointer values 62 may be stored, for example, within the same memory locations used for the corresponding general-purpose registers.

[0057] Figure 2 shows an example of the types of instructions in which tolerance ranges are used to protect against unauthorized access to data or instructions. As shown at the top of Figure 2, a particular bounded pointer register PR1 contains a given pointer value 62 and range information 64, which in this example is specified using a lower bound address 68 that defines the lower boundary of the tolerance range and an upper bound address 69 that defines the upper boundary of the tolerance range. For example, the bounds 68, 69 are set to define an address range of 80,000 to 81,000. If an instruction references the bounded pointer register PR1 and the address determined from the pointer 62 is outside this range, an error may be triggered.

[0058] For example, as shown in section A of FIG. 2, in some systems, an error may be triggered if there is an attempt to set the value of pointer 62 in pointer register 60 to a value outside the range specified by range information 64 (assuming the pointer directly points to an address). This prevents pointer 62 from taking on a value outside the specified range, ensuring that accesses using the pointer are within the allowed range. Alternatively, as shown in section B of FIG. 2, an error may be triggered when an instruction attempts to access a location identified by the address of pointer 62 and that address is outside the specified range. Thus, while setting pointer 62 to a value outside the specified range is acceptable, an error may be triggered if a data access is attempted at the pointer address (or an address derived from the pointer) and the address is outside the allowed range. Other systems may trigger an error in response to both types of instructions shown in sections A and B of FIG. 2.

[0059] Range information 64 may be set in different ways. For example, a security code or an operating system or hypervisor may specify the allowed range for a given pointer. For example, an instruction set architecture may include several instructions for setting or modifying range information 64 for a given pointer 62, and execution of these instructions may be restricted to particular software or to particular modes or exception states of processor 4. Any known technique for setting or modifying range information 64 may be used.

[0060] In addition to the set of bounded pointer storage elements 60 that may be used in execution state 12 when executing an instruction that references a pointer, a program counter capability (PCC) register 80 may also be used to provide similar functionality in fetch stage 6 when an instruction is fetched from level 1 instruction cache 20. Specifically, the program counter pointer may be stored in field 82, with PCC 80 also providing range information 84 and any appropriate limit information 86 similar to the range and limit information provided for each of the pointers in the set of bounded pointer storage elements 60.

[0061] 3 illustrates schematically how tag bits are used in association with individual data blocks to identify whether the data blocks represent capabilities (i.e., bounded pointers and associated restriction information) or regular data. Specifically, memory address space 110 stores a series of data blocks 115, each typically having a specified size. Purely for illustrative purposes, this example assumes that each data block contains 128 bits, although other exemplary implementations may use data blocks of different sizes, e.g., 64-bit data blocks when capabilities are defined by 64 bits of information. Associated with each data block 115, in one example, is provided tag field 120, a single-bit field referred to as a tag bit, which is set to identify that the associated data block represents a capability and cleared to indicate that the associated data block represents regular data and therefore cannot be treated as a capability. It will be understood that the actual values associated with a set or clear state may vary depending on the exemplary implementation, but purely for purposes of illustration, in one exemplary implementation, when a tag bit has a value of 1, it indicates that the associated data block is a capability, and when it has a value of 0, it indicates that the associated data block contains normal data.

[0062] When a capability is loaded into one of the bounded pointer registers 60 (also referred to herein as a capability register), such as the capability register 100 shown in FIG. 3, the tag bit travels along with the capability information. Thus, when a capability is loaded into the capability register 100, the pointer 102, range information 104, and restriction information 106 (hereinafter referred to as permission information) will be loaded into the capability register. Additionally, associated with that capability register, or as a particular bit field therein, the tag bit 108 will be set to identify that the contents represent a capability. Similarly, when a capability is stored back from memory, the associated tag bit 120 will be set in association with the data block in which the capability is stored. Such an approach distinguishes between capabilities and regular data, and therefore ensures that regular data cannot be used as a capability.

[0063] 1 , device 2 may be provided with capability check circuitry 33 that can perform a capability check operation in association with a given access request whose memory address is generated using a given capability to determine whether the access request is permitted based on the constraint information identified by the capability. This can be performed, for example, with reference to the range information and limit / permission information discussed above, which collectively may be referred to as capability constraint information. Thus, purely by way of example, if a write access request to a memory address seeks to be performed using a capability indicating that the capability is to be used only for reading and not for writing, capability check circuitry 33 may determine that the access request cannot proceed and may, for example, issue a fault signal in such circumstances.

[0064] However, assuming the capability check operation passes, the memory access request may be propagated to memory access check circuitry 52, which may provide some further checks to ensure that the access is allowed to proceed. For example, the processing circuit may be capable of operating in a number of different operational modes, each of which may be associated with, for example, a particular privilege state and / or a particular security domain in which the device operates, and particular regions of memory may only be accessible when the processing circuit is operating in one or a subset of the possible operational modes.

[0065] Memory access check circuit 52 may therefore check whether access to the memory system is permitted based on attribute data specified for various regions of the memory address space. Memory access check circuitry may include a security attribute unit (SAU) 56 that stores security domain definition data defining a security domain associated with each corresponding region of the memory address space. Based on the security attribute data, security attribute unit 56 may check whether a 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 and memory access. In other implementations, SAU 56 may access security definition data stored in other locations to perform memory access checks, rather than directly storing security domain definition data. In some systems, security domain definition data may be stored in memory system 50 or in configuration registers elsewhere within system 2.

[0066] Processing circuit 4 may operate in a current security domain of operation, which may generally correspond to the security domain associated with the address of the currently executing instruction (although there may be some exceptions, for example, when processing transitions between domains). While operating in the secure domain, the processing circuit may access data in memory regions associated with both the secure domain and the less secure domain; when operating in the less secure domain, the processing circuit 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 56 designates as associated with the secure domain. This enables protection of sensitive data against unauthorized access from code operating in the less secure domain. As discussed in more detail herein, SAU 56 considers not only the current security domain of the processing circuit when performing such checks to determine whether the access can proceed, but also detailed information associated with the particular access request being considered. This detailed information is based on both the security domain of the processing circuit and a trust level indicator associated with the capability used to generate the memory address for the access request.

[0067] 1 , the memory access checking circuit 52 may include a memory protection unit (MPU) 54 that checks whether a memory access to the memory system 50 satisfies access permissions. The access permissions may, for example, specify which privilege levels of the processing circuit 4 are allowed to access a given region of memory, or may specify whether a memory region of an address space can be accessed by both read and write operations or is a read-only region where writing is prohibited. The access permissions used by the MPU 54 may be specified, for example, by a high-privilege process (such as a hypervisor or operating system) to control which regions of memory a low-privilege process (such as an application) is allowed to access and how (read-only or read / write). The permissions provided by the MPU 54 may be independent of the permissions provided by the SAU 56; thus, a given memory access request must pass checks based on the access permissions defined for both the MPU 54 and the SAU 56 to be granted. Although MPU 54 is shown as a single entity in FIG. 1, in some examples separate secure and less secure MPUs may be provided, each associated with one of the security domains, so that different memory access permissions can be specified for a given region of memory depending on whether the current domain is the secure domain or the less secure domain (e.g., a region may be read-only in the less secure domain, but readable and writable in the secure domain).

[0068] Similar to the previous discussion of the SAU, when the MPU is performing its access permission checks, it can take into account the trust level associated with a given access request, which depends not only on the current operating mode of the processing circuitry but also on the capability trust level associated with the capability used to generate the memory address.

[0069] One or more control registers 90 may be provided to store enable / disable flags for particular features provided by the implementations described herein. As a particular example, it may be possible to selectively modify immutable capabilities that have a lower trust level than the trust level of the processing circuit's current operating mode; this behavior may be controlled by a separate bit in control register 90. Similarly, a failure may occur when attempting to dereference a capability with an associated higher trust level from within a less privileged operating mode of the processing circuit; again, such functionality may be gated by an enable control bit in control register 90. Also, as discussed below, capabilities may be loaded from memory into a capability register; during this process, the associated trust level of the capability being loaded may be selectively demoted; again, such functionality may be controlled by a separate control bit in control register 90.

[0070] According to the techniques described herein, capabilities are provided with associated capability trust level information, and that trust level indicator may be factored into the memory access checking procedure implemented by memory access checking circuitry 52. While there are various ways in which this trust level indicator may be provided in association with a capability, FIG. 4 illustrates one exemplary implementation. In the example shown in FIG. 4, a capability 100 includes a pointer value 102 and some range information 104 (also referred to herein as bounds information). A set of permissions may also be provided within the capability, along with the aforementioned tag bit 108, which may be set or cleared to identify whether the corresponding block of data should be treated as a capability.

[0071] The permissions specified for a capability may vary depending on the implementation, but in one implementation, the permissions include a read permission bit whose value indicates whether the capability may be used to generate memory addresses for read accesses, a write permission bit whose value indicates whether the capability may be used to generate memory addresses for write accesses, and an execute permission bit whose value indicates whether the capability may be used to generate memory addresses for fetched and executed instructions. For example, other information may be identified within a capability to indicate whether the capability is considered immutable. Such information may be specified directly as additional information within the capability, but in some example implementations may be inferred from the state of other information already provided within the capability. For example, in one particular implementation, when the execute bit is set, the capability is considered immutable, and the information specified by the capability cannot be modified without clearing the tag bit (effectively invalidating the capability) except through the normal incrementing of pointer values that may result from instruction execution.

[0072] 4, in one exemplary implementation, the permission field is extended to provide a trust level indicator field 136, which identifies the trust level associated with the capability 100. The trust level may be encoded directly in field 136 of the capability 100, or alternatively, the trust level indicator field 136 may provide an identifier used to indicate a memory address containing the trust level information. Such an identifier may directly indicate the memory location of the trust level information or may specify, for example, an offset that can be applied to an address stored in a global register in the system to identify the location containing the trust level information.

[0073] 5A is a block diagram that schematically illustrates how capability trust level information is used to constrain access to memory, according to one exemplary implementation. In this example, processing circuitry 150 includes a capability check block 155 that can be used to perform a capability check operation to determine whether an access request is permitted based on the constraint information identified by a given capability when a memory address is considered for access based on the constraint information identified by the given capability. Thus, the capability check can involve reference to the capability's scope and permission information to determine whether the access is permitted to proceed. If the capability check fails, a failure indication can be provided to the processing circuitry, which can take various forms, such as, for example, a fault signal. However, if the capability check passes, this is indicated to trust level generation block 160, which also receives trust level information 136 for capability 100.

[0074] In addition to the capability trust level, trust level generation block 160 also receives an indication of a current mode trust level, which is the trust level associated with the current operating mode of the processing circuit. Both the capability trust level and the current mode trust level are then used in combination to form a trust level for the access request, which is propagated over path 167 in association with the memory address of the request issued over path 165. While there are various ways in which trust level generation block 160 can use both the current mode trust level and the capability trust level to determine the trust level for the access request, in one exemplary implementation, the trust level associated with the access request is constrained to the current mode trust level or the capability trust level, whichever represents the lower trust level.

[0075] Memory access check circuit 170 receives both the memory address of the request and the associated confidence level for the access request and can perform memory access check operations by reference to stored access permission information 175, which may be specified for different memory regions. In particular, for each of several different memory regions, the access permission information can effectively indicate a required confidence level that must be provided to the access request to allow the access to proceed. If the confidence level for the access request received over path 167 does not meet the required confidence level, the access can be failed; otherwise, the access to memory can be propagated from memory access check circuit 170 over path 180.

[0076] Figure 5B is a flow diagram illustrating the operation of the circuit of Figure 5A in one exemplary embodiment. In step 200, it is determined that an access request is necessary, after which in step 205 the memory address for the access request is determined by reference to the pointer value of the specified capability. In step 210, a capability check is performed by reference to the limit and permission information of the specified capability to determine whether the access can proceed.

[0077] Thus, in step 215 it is determined whether the capability check passed, and if not the process proceeds to step 220 where a capability check failed signal is asserted.

[0078] Typically, the trust level information is not used when performing the capability check in step 210, but instead is retained to pass to memory access check circuit 170. However, in some implementations, the trust level information may also be used during the capability check process. For example, the processing circuit may be arranged to issue a fault signal in step 220 when an attempt is made to perform the access identified by a given access request in a situation where a capability trust level associated with a capability being used to generate a memory address for the given access request exceeds a current mode trust level associated with the current operating mode of the processing circuit. In particular, in some implementations, it may be considered incorrect behavior for a processing circuit operating at a particular trust level to attempt to utilize a capability having a higher capability trust level.

[0079] If it is determined in step 215 that the capability check is passed, then in step 225, a trust level for the access request is determined by trust level generation block 160 based on both the current mode trust level and the capability trust level. Thereafter, in step 230, the access request along with the determined trust level for the access request is propagated to memory access check circuit 170 so that memory access check circuit 170 can perform an access permission check based on the indicated trust level for the access request.

[0080] 6A is a block diagram that generally illustrates a capability processing circuit 250 that may be provided within a device, according to one exemplary implementation, and in particular shows several different components that may be provided within the capability processing circuit 250. The capability processing circuit may be provided as a separate component within the device, or in one exemplary implementation, may be integrated within the processing circuit.

[0081] The capability processing circuitry 250 includes the capability check circuitry 33 discussed above that is arranged to perform a capability check operation on an access request. In particular, the capability check operation is used to determine whether a memory address generated for that access request from a capability is permitted based on the constraint information identified by that capability.

[0082] As will become apparent from the preceding discussion, a capability may be provided with a capability trust level, which in one exemplary implementation allows a processing circuit to be given limited configuration permission when operating in at least a particular operating mode to allow the capability to be generated. To enable the generation of the capability, a capability generation circuit 255 may be provided, which in one exemplary implementation may be arranged to operate as shown by the flowchart of FIG. 6B . Accordingly, in step 265, it is determined whether a capability generation operation has been requested. If it is determined that a capability is desired to be generated, then in step 270, it is determined whether the current mode trust level (i.e., the trust level associated with the current operating mode of the processing circuit) exceeds a threshold trust level; if not, in step 275, the capability generation operation fails. This can be implemented in various ways, but in one exemplary implementation, it can take the form of an abort process. Alternatively, processing may proceed to allow capability information to be generated, but with the tag bit cleared, thus generating an invalid capability.

[0083] However, if step 270 determines that the current mode trust level exceeds the threshold level and therefore allows the processing circuitry to generate a capability in principle, the process proceeds to step 280, where the necessary capability information is obtained and then used to construct the capability. The capability information can be obtained in various ways, for example, by retrieving it from a location in memory identified by the capability generation request. Furthermore, step 285 ensures that if a valid capability is generated, the capability trust level is set below the current mode trust level. This requirement can be implemented in various ways. For example, capability generation circuit 255 can be arranged to set a tag bit in the generated capability information only if the capability trust level is below the current mode trust level; otherwise, the tag bit is not set and an invalid capability is generated. Alternatively, the capability generation circuit 255 may be arranged to always set the tag bit of the generated capability, but to demote the capability trust level if required such that the conditions set in step 285 are met.

[0084] Through use of the process shown in FIG. 6B, a processing circuit can be enabled to create capabilities, at least when in a particular operating mode, but when doing so, the processing circuit is constrained such that the associated capability trust level for the created capability is less than the processing circuit's current mode level, thus preventing the processing circuit in its current operating mode from generating capabilities that can be used in its current operating mode.

[0085] The threshold trust level evaluated in step 270 can be set in various ways, for example, to limit the use of the capability to generate a function to one or a small subset of the processing circuit's possible modal trust levels. Alternatively, such capability generation techniques may be supported for any modal trust level other than the minimum trust level supported when using the capability.

[0086] 6B illustrates one mechanism that may be used by capability generation circuit 255 to enable capability generation in certain circumstances, although other mechanisms may be used if desired. For example, when it is determined that a capability generation operation is required, capability generation circuit 255 may be enabled to generate a capability from specified source data if the current mode trust level exceeds a provided capability trust level indicator associated with that source data. If such conditions are not met, then the capability generation operation fails, for example, by issuing an abort or by clearing the tag bits of any generated capabilities.

[0087] Returning to FIG. 6A , the capability processing circuit 250 may optionally be provided with a control flow change processing circuit 260 that interacts with the capability generation circuit 255 and can cause a capability to be generated upon the occurrence of a control flow change in a program running on the processing circuit. In particular, the processing circuit may be arranged to execute program instructions, the processing of which is constrained by a dominant capability. When a control flow change operation is performed, a target address is identified that indicates the address of the program instruction for execution after the control flow change operation. Depending on the control flow change target address, the capability generation circuit 255 may be arranged to identify an address where capability constraint information is stored, retrieve the information, and then use the capability constraint information to generate a capability for use as the next dominant capability. In such a situation, the associated capability trust level for the generated capability may be constrained to indicate a trust level lower than the current mode trust level.

[0088] It should also be noted that the current mode trust level of a processing circuit may be further constrained by the trust level associated with the prevailing capability. Such a mechanism may be useful, for example, to ensure that when a non-privileged function is used to generate a program counter value, this does not allow privileged code to execute.

[0089] FIG. 7 is a diagram that schematically illustrates various different modal trust levels that may exist within a system and indicates capability creation capabilities that may be supported in such an arrangement. As shown in FIG. 7, the processing circuitry may be arranged to operate in a secure domain and a less secure domain, and the current modal trust level may depend on which of the security domains the current program code is executing in. Additionally or alternatively, the processing circuitry may be arranged to execute program code in multiple different states, and in the example of FIG. 7, may be arranged to operate the program code in a privileged or unprivileged state. The levels of privilege and the different security domains may be considered to be orthogonal trust levels, and a different modal trust level of the processing circuitry may be associated with each combination of secure / less secure domain and privileged / unprivileged state. Thus, as shown in FIG. 7, in the illustrated example, there may be four different trust levels.

[0090] With the previously described limited configuration rights allowing for capabilities to be created, then, as indicated by the arrows in Figure 7, when the processing circuit is operating in the secure mode and the privileged mode, the processing circuit may be able to create capabilities for any of the other three lower trust level operating modes. Similarly, when the processing circuit is operating in a less secure privileged mode, the processing circuit may still be given limited configuration rights to allow it to create capabilities for the less secure unprivileged mode. Furthermore, if desired, when the processing circuit is operating in the secure unprivileged mode, the processing circuit may still be given limited configuration rights to allow it to create capabilities for the less secure unprivileged mode.

[0091] While Figure 7 illustrates four different trust levels, it will be understood that the techniques described herein are not limited to such a configuration, and additional trust levels may be provided in either or both of the orthogonal directions shown in Figure 7. Privileged and non-privileged mode operation may take various forms, but purely by way of example, privileged mode may in some implementations be referred to as handler mode, and non-privileged mode may be referred to as thread mode. Handler mode is typically used for exception handling, and thus, for example, a trusted exception handling routine may be executed in handler mode. Thread mode is typically used to execute multiple different threads, e.g., multiple different application threads.

[0092] When loading a capability from memory into one of the capability registers 60, 80, the processing circuitry may be arranged to selectively modify the capability trust level in certain circumstances; one exemplary implementation of this approach is shown in Figure 8A. In step 300, it is determined whether a capability load from memory is requested, and if so, in step 305, it is determined whether the current mode trust level is less than the capability trust level to be loaded from memory. If not, in one exemplary implementation, the process proceeds to step 310, where the capability is stored unmodified in the capability register.

[0093] However, according to the technique shown in FIG. 8A , if the current mode trust level is less than the capability's trust level, the process proceeds to step 315, where the trust level of the capability associated with the copy of the capability stored in the capability register is demoted so that the current mode trust level is no longer less than the capability's trust level. Such an approach can ensure that even if a capability being loaded from memory has a higher associated privilege level, the resulting capability loaded into the processing circuit's capability register has its trust level demoted so that it cannot be used to access memory that should not be accessed by the processing circuit when operating at the current mode trust level. Conversely, if a capability in memory has a lower trust level than the current mode trust level, its trust level remains “as is” when it is moved to the capability register. This can avoid accidental promotion of capabilities, such as when an exception handler accidentally promotes a stacked value.

[0094] In one exemplary implementation, the capability load process may, in certain circumstances, be used to load general-purpose data into a capability register rather than a capability, which may be detected in step 300 and, if the load operation is in fact being used to load general-purpose data, may prevent the selective demotion of the bits specifying the capability trust level in the capability, thus avoiding corruption of the data being loaded.

[0095] As indicated by step 315 of FIG. 8A , the ability to selectively demote capability trust levels can be made configurable, for example, by being conditional on control information stored in control register 90. Selective demotion of capabilities can also be disabled for particular types of capabilities and thus, for example, can be disabled when the capability being loaded is an immutable capability. Such a capability can be useful, for example, to allow for spilling privileged immutable capabilities from within a non-privileged mode of operation without modifying the immutable capabilities. Furthermore, as described above, while the control information used to conditionally enable or disable selective demotion of capabilities being loaded from memory can be stored in a control register, the control information can also be stored in other locations, for example, as a field within the capability itself or, for example, to enable demotion based on MPU region attributes. In this latter approach, a mechanism can be provided so that demotion occurs when a capability is loaded from an MPU region marked as read-only (e.g., code memory), but not when the associated region is marked as read-write (e.g., heap or stack memory). In some implementations, a dedicated control bit in the MPU can be used to dictate the behavior.

[0096] FIG. 8A illustrates one mechanism that may be used to selectively demote a capability trust level when loading a capability from memory into a capability register, although other mechanisms may be used if desired. FIG. 8B illustrates an alternative mechanism in which selective demotion is based on the capability trust level of the capability used to generate the memory address for the load. Specifically, as shown in FIG. 8B, when it is determined in step 350 that a capability load from memory is necessary, it is then determined in step 355 whether the capability trust level of the function being loaded exceeds the capability trust level of the capability used to generate the memory address for the load. If not, in step 360 the capability is stored in the capability register without modification; if so, the capability trust level of the capability being loaded into the capability register is demoted so that its trust level no longer exceeds the trust level of the capability used to generate the memory address for the load. As with the previous discussion of FIG. 8, this selective demotion function may be conditional on control information.

[0097] 8B can be used as an alternative to the process of FIG. 8A, but in one exemplary implementation, the techniques are combined so that both checks are performed. Thus, it will be appreciated that the capability trust level of the capability being loaded is then selectively demoted to be the minimum of the current mode trust level associated with the current operating mode of the processing circuit and the capability trust level of the capability used to generate the memory address for the load.

[0098] 9 is a flow chart illustrating how, in one exemplary implementation, a processing circuit may be enabled to reduce the capability trust level of a capability in at least a particular operating mode. In step 400, it is determined whether the current mode trust level of the processing circuit exceeds a threshold level. If not, in step 405, the current program code executed by the processing circuit cannot reduce the capability trust level of the capability. Conversely, if the current mode trust level exceeds the threshold level, then in step 410, the current program code executing on the processing circuit can reduce the capability trust level of the capability. Optionally, this ability can be limited to capabilities whose capability trust level does not exceed the current mode trust level.

[0099] In FIG. 9, the ability to reduce the capability trust level of a capability is limited to a particular mode trust level, but this is not a requirement, and in alternative implementations, the processing circuitry may be allowed to demote a capability trust level regardless of the current mode trust level.

[0100] In one exemplary implementation, before a device enters a capability mode in which access is restricted using capabilities, the device may be given one or more initial capabilities. Typically, these initial capabilities may be set to have a capability trust level that indicates the highest trust level supported by the device when operating in the capability mode. This is a safe approach when using the selective demotion of capabilities loaded from memory discussed above, as this allows the capability trust levels of those initial capabilities to be selectively demoted when needed, for example, when loaded into a capability register, depending on the current operating mode of the processing circuit.

[0101] Initial capabilities can be established in a variety of ways, but in one exemplary implementation, as illustrated in FIG. 10, a compiler 420 can be used to define initial capabilities during compilation of program code to be executed on the device, and these generated initial capabilities are stored in memory as a literal pool of initial capabilities 425.

[0102] As mentioned above, in one exemplary implementation, all initial capabilities may be set to have the highest trusted capability level supported by the device when operating in capability mode, but if desired, a developer can create one or more capabilities with a lower trusted capability level. For example, if a developer knows that a capability should always be unprivileged (e.g., in OS-managed code), they can use compiler intrinsics to create the capability that is marked as unprivileged in static data, thus further enhancing security.

[0103] In some exemplary implementations, a capability may include at least one immutable capability whose constraint information is identified as immutable. Typically, this means that the processing circuit cannot change the constraint information once the capability is established. However, according to one exemplary implementation generally illustrated by the flowchart of FIG. 11, it is possible to allow the constraint information of selected immutable capabilities to be modified in certain circumstances. In step 450, it is detected when an attempt to modify an immutable capability is being made. In such a situation, it is then determined in step 455 whether the current mode trust level of the processing circuit exceeds the capability trust level of the immutable capability. If not, in step 460, the modification is prevented. Additionally, the tag bit may be cleared in situations where the capability is no longer valid.

[0104] However, if in step 455 it is determined that the current mode trust level exceeds the capability trust level of the immutable capability, then in step 465 modification of the immutable capability is enabled.

[0105] The functionality of FIG. 11 may be enabled in all cases, but if desired, the ability to perform the functionality of FIG. 11 may be further restricted, for example, by checking whether the current mode confidence level of the processing circuitry exceeds a threshold level.

[0106] Furthermore, it should be noted that selective modification of immutable capabilities can be handled in other manners and is not limited to the approach shown in Figure 11. For example, in one implementation, modification of immutable capabilities may be generally enabled, but the tag bit is cleared in situations where the level of trust criteria of step 455 is not met, thus effectively disabling the capability. As a further alternative, modification may be performed, but the capability trust level of the modified immutable capabilities may be demoted, if necessary, so that the level of trust criteria of step 455 is met.

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

[0108] To the extent that examples are described above with reference to particular hardware constructs or features, equivalent functionality may be provided in a simulated implementation by suitable software constructs or features. For example, a particular circuit may be provided as computer program logic in a simulated implementation. Similarly, memory hardware such as registers or cache may be provided as software data structures in a simulated implementation. Also, the physical address space used to access memory 50 in hardware device 2 may be emulated as a simulated address space, which is mapped by simulator 505 to a virtual address space used by host operating system 510. In arrangements where one or more of the hardware elements referred to in the preceding examples reside in host hardware (e.g., host processor 515), some simulated implementations may use the host hardware, if preferred.

[0109] The simulator program 505 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a virtual hardware interface (an instruction execution environment) to the target code 500 (which may include an application, an operating system, and a hypervisor), the virtual hardware interface being the same as the hardware interface of the hardware architecture modeled by the simulator program 505. Thus, the program instructions of the target code 500 may be executed from within the instruction execution environment using the simulator program 505, thereby enabling a host computer 515, which does not actually have the hardware features of the device 2 discussed above, to emulate these features. The simulator program may include processing program logic 520 for emulating the behavior of the processing pipeline 4, capability check program logic 522 for emulating the behavior of the capability check circuit 33, and memory access check program logic 525 for emulating the behavior of the memory access check circuit 52 of the hardware device 2 of FIG. 1 . Thus, the techniques described herein for managing capabilities and their associated trust levels may be implemented in software by the simulator program 505, in the example of FIG. 12 .

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

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

Claims

1. 1. An apparatus comprising: a processing circuit for performing an operation, during which a request to access a memory is generated, the processing circuit being arranged to generate a memory address for the access request using a capability that identifies constraint information; a capability check circuit for performing a capability check operation to determine whether a given access request, the memory address of which is generated using a given capability, is permitted based on the constraint information identified by the given capability; a memory access check circuit for further restricting access to the memory by the given access request depending on a trust level associated with the given access request; Equipped with The apparatus, wherein the given capability has a capability trust level associated therewith, and the trust level associated with the given access request depends on both a current mode trust level associated with a current mode of operation of the processing circuit and the capability trust level of the given capability.

2. The apparatus of claim 1 , wherein the trust level associated with the given access request is constrained to which of the current mode trust level and the capability trust level represents a lower trust level.

3. The apparatus of claim 1 or 2, wherein the capability trust level is encoded within the given capability.

4. for each capability, the constraint information provides at least one set of permissions identifying types of memory accesses permitted to memory addresses generated using that capability; The apparatus of claim 3 , wherein the capability trust level is provided as an additional permission.

5. The apparatus of claim 1 or 2, wherein the given capability provides an identifier indicating a location that includes the capability trust level.

6. 6. The apparatus of claim 1, wherein for each capability, the constraint information further provides bounds information used to determine an allowable range of memory addresses for the memory addresses generated for any access request using that capability.

7. 7. The apparatus of claim 1, wherein the processing circuitry comprises a capability generation circuit arranged to perform a capability generation operation to generate a capability at least when the current mode trust level exceeds a threshold trust level, and to set the associated capability trust level for the generated capability to indicate a trust level lower than the current mode trust level.

8. 7. The apparatus of claim 1, wherein the processing circuitry comprises a capability generation circuit arranged to perform a capability generation operation to generate a capability from the source data if the current mode trust level exceeds a capability trust level indicator provided in association with the source data.

9. the processing circuitry is arranged to execute program instructions, processing of the program instructions being constrained by a prevailing capability; the processing circuitry further comprises control flow modification processing circuitry for performing a control flow modification operation, the control flow modification operation defining a control flow modification target address indicating an address of a program instruction for execution after the control flow modification operation; 8. The apparatus of claim 7, wherein the capability generation circuitry is arranged to determine an address at which capability constraint information is stored in dependence on the control flow change target address, retrieve the capability constraint information, and generate a capability for use as the next dominant capability in dependence on at least the capability constraint information, and wherein the associated capability trust level for the generated capability is constrained to indicate a trust level lower than the current mode trust level.

10. a set of capability registers for storing capabilities for reference by said processing circuitry; a memory circuit for storing one or more capabilities; Further provided with the processing circuitry is arranged to perform a load operation to load a selected capability from the memory circuit into a capability register selected from the set of capability registers; 10. The apparatus of claim 1, wherein the processing circuitry is arranged to selectively modify the capability trust level during the load operation such that the selected capability stored in the selected capability register has a capability trust level that is constrained to not exceed the current mode trust level or the capability trust level of the selected capability stored in the memory circuitry.

11. 11. The apparatus of claim 10, wherein the processing circuitry is arranged to selectively modify only the capability trust level during the load operation when the selected capability has a control value that identifies the selected capability as a valid capability.

12. 12. The apparatus of claim 10 or 11, wherein when the current mode trust level is less than the capability trust level of the selected capability stored in the memory circuit, the processing circuitry is arranged to perform a demotion of the capability trust level of the selected capability stored in the selected capability register to match the current mode trust level.

13. 13. The apparatus of claim 10, wherein when the current mode trust level is greater than or equal to the capability trust level of the selected capability stored in the memory circuit, the processing circuitry is arranged to leave the capability trust level unchanged when the selected capability is stored in the selected capability register.

14. 14. The apparatus of claim 1, wherein the processing circuitry is arranged to enable the capability trust level of a selected capability to be reduced from its current capability trust level at least when the current mode trust level exceeds a threshold trust level.

15. An apparatus according to any preceding claim, wherein the apparatus is provided with one or more initial capabilities, the capability trust level of which indicates the highest trust level supported by the apparatus.

16. 16. The device of claim 15, wherein the initial capabilities are provided before the device enters a capability mode of operation in which access requests are constrained by the capabilities.

17. 17. The apparatus of claim 1, wherein the processing circuitry is arranged to execute program code in one of a plurality of states including at least a privileged state and a non-privileged state, and the current mode trust level depends on in which of the plurality of states current program code is executing.

18. 18. The apparatus of claim 1, wherein the processing circuitry is arranged to execute program code in one of a plurality of security domains including at least a secure domain and a less secure domain, and the current mode trust level depends on in which of the plurality of security domains the current program code is executing.

19. The method of claim 18, wherein the processing circuitry is arranged to execute program code in one of a plurality of states including at least a privileged state and a non-privileged state; the processing circuitry is arranged to execute program code in one of a plurality of security domains, the security domain including at least a secure domain and a less secure domain; The apparatus of any one of claims 1 to 16, wherein the current mode trust level depends on both the state and the security domain in which current program code is executed.

20. the capabilities include at least one immutable capability for which constraint information is identified as immutable; 20. The apparatus of claim 1, wherein at least when the current mode trust level exceeds a threshold trust level, the processing circuitry is arranged to enable the constraint information of a selected invariant capability to be modified if the selected invariant capability has a capability trust level below the current mode trust level.

21. 21. The apparatus of claim 20 when dependent on claim 12, wherein the processing circuitry is configurable to disable the demotion of the capability trust level of the selected capability when the selected capability is an immutable capability.

22. 22. The apparatus of claim 1, wherein the processing circuitry is arranged to issue a fault signal when an attempt is made to perform the access identified by the given access request if the capability trust level associated with the given capability exceeds the current mode trust level.

23. 23. The apparatus of any one of claims 1 to 22 when dependent on claim 10, wherein the selected capability stored in the selected capability register is further constrained to have a capability trust level that does not exceed the capability trust level associated with a capability used to generate the memory address for the load operation.

24. 24. The apparatus of any one of claims 1 to 23 when dependent on claim 12, wherein the implementation of the demotion of the capability trust level of the selected capability stored in the selected capability register is controlled in dependence on control information.

25. 1. A method of restricting access to a memory, comprising: employing a processing circuit to perform an operation, during which a request to access a memory is generated, and wherein the processing circuit generates a memory address for the access request using a capability that identifies constraint information; performing a capability checking operation to determine whether a given access request, the memory address of which is generated using a given capability, is permitted based on the constraint information identified by the given capability; further constraining access to the memory by the given access request in dependence on a trust level associated with the given access request, wherein the given capability has a capability trust level associated therewith, and the trust level associated with the given access request depends on both a current mode trust level associated with a current mode of operation of the processing circuit and the capability trust level of the given capability; A method comprising:

26. 1. A computer program for controlling a host data processing device to provide an instruction execution environment, comprising: processing program logic for performing an operation, during which a request to access a memory is generated, the processing program logic being arranged to use capabilities that identify constraint information to generate a memory address for the access request; capability check program logic for performing a capability check operation to determine whether a given access request, the memory address of which is generated using a given capability, is permitted based on the constraint information identified by the given capability; memory access checking program logic for further restricting access to the memory by the given access request depending on a trust level associated with the given access request; Equipped with 1. A computer program, comprising: a computer program, the computer program comprising: a processor logic ...

Images