Techniques for Manipulating Encapsulated Capabilities

Abstract

An apparatus and method for manipulating sealed capabilities are described. The apparatus includes a processing circuit for performing a processing 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. The check circuit then determines 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 based on a trust level associated with the given access request. Each capability has a capability trust level associated therewith, the trust level associated with a given access request being dependent on both a current mode trust level associated with a current operating mode of the processing circuit and the capability trust level of the given capability. At least one of the capabilities is configurable as a sealed capability, and the apparatus further includes a sealed capability manipulation circuit for preventing the processing circuit from performing at least one processing operation using the given sealed capability when the current mode trust level is a trust level lower than the capability trust level of the given sealed capability.

Description

[Technical field]

[0001] The present techniques relate to the field of data processing, and more particularly, to manipulating sealed capabilities.

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

[0003] A number of capability storage elements (e.g., registers) may be provided to store capabilities for access by the processing circuitry of the data processing apparatus. Each capability may include constraint information used to limit operations that may be performed when using that capability. For example, considering a bounded pointer, this may provide information used to identify a non-extensible range of memory addresses accessible by the processing circuitry when using that capability, along with one or more permission flags that identify associated permissions.

[0004] Some capability architectures have introduced the concept of sealed capabilities. By sealing a capability, this allows the capability to be marked as non-dereferenceable (meaning that memory addresses cannot be accessed using the capability) and immutable, causing a hardware exception if an attempt is made to modify or dereference such a capability. Support for sealed capabilities is desirable because it allows software use cases such as trusted code to give less trusted code a token, e.g. a file handle, to be used during callbacks to the trusted code. This token should not be available in the less trusted mode and should not be modified by any other behavior in the software or architecture.

[0005] However, a multi-bit field (sometimes called an "object type" field) typically needs to be provided within the capability to capture information about the sealed state of the capability, and furthermore, a specific unsealing key, typically a capability with unsealing permissions and a matching object type, may typically need to be used to unseal such a sealed capability. However, in some modern systems, the number of bits available to represent the metadata of a capability is very constrained, which may make it difficult to support the use of such sealed capabilities. Furthermore, the requirement to require unsealing a key is cumbersome.

[0006] It is therefore desirable to provide an alternative mechanism for supporting the provision of sealed capabilities. Summary of the Invention

[0007] In a first exemplary arrangement, an apparatus is provided comprising: a processing circuit for performing processing operations 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; and a check circuit for determining whether a given access request, the memory address of which is generated using a given capability, is permitted based on the given constraint information identified by the given capability and based on a trust level associated with the given access request, wherein each capability has a capability trust level associated therewith, the trust level associated with the given access request being dependent on both a current mode trust level associated with a current operating mode of the processing circuit and the capability trust level of the given capability, wherein at least one of the capabilities is configurable as a sealed capability, and the apparatus further comprises sealed capability manipulation circuitry for preventing the processing circuit from performing at least one processing operation using the given sealed capability when the current mode trust level is a trust level lower than the capability trust level of the given sealed capability.

[0008] In a further exemplary arrangement, a method of manipulating sealed capabilities is provided, the method including employing a processing circuit to perform a processing operation in which a request for access to a memory is generated, the processing circuit generating a memory address for the access request using a capability that identifies constraint information, and determining whether a given access request, in which the memory address is generated using a given capability, is permitted based on the constraint information identified by the given capability and based on a trust level associated with the given access request, each capability having a capability trust level associated therewith, the trust level associated with the given access request being dependent on both a current mode trust level associated with a current operating mode of the processing circuit and a capability trust level of the given capability, at least one of the capabilities being configurable as a sealed capability, the method further including employing sealed capability manipulation circuitry to prevent the processing circuit from performing at least one processing operation using the given sealed capability when the current mode trust level is a trust level lower than the capability trust level of the given sealed capability.

[0009] In yet a further exemplary arrangement, a computer program for controlling a host data processing apparatus to provide an instruction execution environment, the computer program comprising: processing program logic for performing processing operations during which requests for access to a memory are generated, the processing program logic being arranged to generate a memory address for the access request using a capability that identifies constraint information; and checking program logic 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 based on a trust level associated with the given access request, each capability being associated with a capability trust level associated with a given access request, the capability trust level being dependent on both a current mode trust level associated with a current operating mode of the processing program logic and the capability trust level of the given capability, at least one of the capabilities being configurable as a sealed capability, the device further comprising sealed capability manipulation program logic for preventing the processing program logic from performing at least one processing operation using the given sealed capability when the current mode trust level is at a lower trust level than the capability trust level of the given sealed capability.

[0010] In yet a further exemplary configuration, an apparatus is provided comprising: processing means for performing processing operations 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; and checking means for determining 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 based on a trust level associated with the given access request, wherein each capability has a capability trust level associated therewith, the trust level associated with the given access request being dependent on both a current mode trust level associated with a current operating mode of the processing means and the capability trust level of the given capability, wherein at least one of the capabilities is settable as a sealed capability, and the apparatus further comprises sealed capability manipulation means for preventing the processing means from performing at least one processing operation using the given sealed capability when the current mode trust level is a trust level lower than the capability trust level of the given sealed capability. [Brief description of the drawings]

[0011] 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. [Diagram 2] 1 illustrates an example of a type of instruction that may 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. [Diagram 3] 1 illustrates the use of tag bits in association with bounded pointers, according to one exemplary implementation. [Figure 4]1 illustrates generally the form of a capability that may be used in accordance with the techniques described herein, where a trust level indicator is provided in association with the capability and a sealing flag is provided to indicate whether the capability is sealed. [Figure 5A] FIG. 1 is a diagram illustrating generally how trust levels for individual access requests can be generated and subsequently used to constrain access to memory, according to an exemplary implementation, which also supports appropriate manipulation of sealed capabilities. [Figure 5B] 5B is a flow diagram illustrating the operation of the apparatus generally shown in FIG. 5A according to one exemplary implementation. [Figure 6] 11 is a flow diagram illustrating the operation of a seal request according to one exemplary implementation. [Figure 7] 11 is a flow diagram illustrating the operation of an open request according to one exemplary implementation. [Figure 8] 1 illustrates an example of different domains and processing states of a processing circuit according to one exemplary implementation, and diagrammatically illustrates the sealing and unsealing capabilities that may be supported when the processing circuit is operating in a particular combination of domains and processing states. [Figure 9A] 1 is a flow diagram illustrating different ways in which a request that uses a sealed capability may be handled, according to two example implementations. [Figure 9B] 1 is a flow diagram illustrating different ways in which a request that uses a sealed capability may be handled, according to two example implementations. [Figure 10] 1 is a flow diagram illustrating how a request to modify a capability may be handled according to an example implementation. [Figure 11] 4 is a flow diagram illustrating steps performed to load capabilities from memory according to one exemplary implementation. [Figure 12] 11 is a flow diagram illustrating how an open request may be manipulated depending on whether a capability is of a given type, according to one example implementation. [Figure 13]1 shows an example simulator that can be used. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] 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 being arranged to generate a memory address for the access request using a capability that identifies the constraint information, the memory address generated by the processing circuit being a virtual address in a system in which address translation is performed, or alternatively being a physical address in a system that does not support address translation.

[0013] The apparatus also has a check circuit 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 functionality of the check circuitry to perform the above check may be a separate component from the processing circuitry or may alternatively be provided within the processing circuitry of the apparatus.

[0014] 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.

[0015] The check circuitry is also arranged to further constrain access to the memory by a given access request depending on a trust level associated with the given access request. The functionality of the check circuitry can be implemented in various forms, for example, a memory management unit (MMU), a memory protection unit (MPU), a security attribute unit (SAU), or a combination of these components. Such check circuitry has traditionally been arranged to take into account a trust level associated with a current operating mode of the processing circuit when further constraining access to the memory, rather than associating any particular trust level with each individual access request. However, according to the techniques described herein, a given capability has a capability trust level associated with it, and that information may also be factored into the checks performed by the check circuitry. 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 operating mode of the processing circuit and a capability trust level of the given capability.

[0016] By providing a capability trust level in association with an individual capability, this can enhance the manner in which capabilities can be managed and used. For example, as discussed above, the capability trust level is taken into account by the checking circuitry when determining whether an access to a memory specified by a given access request can proceed, and thus can provide a mechanism that allows a capability to be generated by a processing circuitry in certain circumstances, and the capability trust level associated with a particular capability can then be effectively used to track the provenance of that capability and constrain subsequent accesses made using that capability.

[0017] In addition, such a mechanism further enables specific use case protection to be supported, for example, to counter confused proxy attacks. A confused proxy 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 operation on its behalf. Through the use of capability trust levels, this can prevent the more privileged code from misusing a pointer created by the non-privileged code that maliciously addresses an area of ​​memory that should not be accessible to the non-privileged code. In particular, in such a situation, the pointer has been generated using a capability whose capability trust level does not exceed the capability trust level of the non-privileged code, and thus, even if an access is attempted from the privileged code, the memory access circuitry prevents access to the privileged memory due to the capability trust level of the capability used to generate the pointer.

[0018] The techniques described herein also leverage the provision of capability trust levels associated with individual capabilities, and provide additional benefits by providing a lightweight mechanism for manipulating sealed capabilities that, in particular, avoids the need to utilize scarce metadata bits to indicate object type and opening permissions, and also avoids the need to open keys.

[0019] In particular, according to the techniques described herein, the apparatus further comprises a sealed capability manipulation circuit for preventing the processing circuit from performing at least one processing operation using a given sealed capability when the current mode trust level is a trust level lower than the capability trust level of the given sealed capability. Thus, when considering a sealed capability, the manner in which the processing circuit manipulates the sealed capability may be constrained taking into account both the current mode trust level of the processing circuit and the capability trust level of the sealed capability in question. In particular, by reusing the capability trust level information associated with each capability, if the capability is marked as sealed, the capability trust level information may be used to identify the particular software context (software trust level) associated with the sealed capability.

[0020] 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 conjunction with other forms of processing circuitry, such as direct memory access (DMA) controllers, cryptographic accelerators, etc.

[0021] 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 grants or permission restrictions, 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 restrictions, 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.

[0022] While there are several ways in which a capability trust level may be specified for a capability, in one exemplary implementation, the capability trust level is encoded within a given capability. This may 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.

[0023] 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 contains 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 includes a value that indicates the location of the metadata that provides the capability trust level. The identifier used to indicate the location that contains the capability trust level may take various forms. For example, it may be an offset from an address stored in a global register of the system, thus allowing a memory address to be determined that identifies where in memory the capability trust level is maintained. Alternatively, the identifier may directly identify a location in memory where the capability trust level information is stored.

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

[0025] Returning to the discussion of sealed capabilities, there are several ways in which a capability can be identified as sealed and thus have the sealed capability manipulation circuitry determine how a given sealed capability should be manipulated, taking into account both the capability trust level of the capability and the current mode trust level associated with the processing circuit. However, in one exemplary implementation, each capability has a sealing flag associated with it, and the sealed capability manipulation circuitry, in response to a sealing request for a selected capability, determines whether to set the sealing flag of the selected capability to identify the selected capability as a sealed capability as a function of a comparison of the capability trust level of the selected capability with the current mode trust level.

[0026] There are several ways in which the seal flag may indicate a set (i.e., sealed) or clear (i.e., unsealed) state. For example, either a logic 1 value or a logic 0 value may be associated with the set state, and indeed in some implementations it may be appropriate to provide a multi-bit encoding. Furthermore, the seal request may be made in a variety of ways, but in one exemplary implementation may be made as a result of, for example, a processing circuit executing a seal instruction.

[0027] In one exemplary implementation, the sealed capability manipulation circuitry is arranged to, in response to a sealing request, prohibit setting the sealing flag when the capability trust level of the selected capability is greater than the current mode trust level. The actual current mode trust level required to allow the sealing flag to be set may vary depending on the implementation. For example, sealing of a capability may be possible whenever the current mode trust level is equal to or greater than the capability trust level, or sealing of a capability may be restricted to only when the current mode trust level is the same as the capability trust level.

[0028] In one exemplary implementation, a sealed capability may also be allowed to be unsealed in certain circumstances. For example, in one exemplary implementation, the sealed capability manipulation circuitry, in response to an unseal request for a selected sealed capability, inhibits clearing of the sealing flag of the selected sealed capability when the capability trust level of the selected sealed capability is greater than the current mode trust level. As with sealing, the actual current mode trust level required to allow the sealing flag to be cleared may vary depending on the implementation. For example, unsealing of a capability may be possible whenever the current mode trust level is equal to or greater than the capability trust level, or unsealing of a capability may be restricted to only when the current mode trust level is the same as the capability trust level.

[0029] Furthermore, the request to open may occur in a variety of ways, but in one exemplary implementation may occur as a result of a processing circuit executing an open instruction, for example.

[0030] It should be noted that according to the above technique, the decision to allow a capability to be sealed or a sealed capability to be unsealed is made taking into account both the current mode trust level and the capability trust level, so there is no need to seal or unseal the key used.

[0031] As previously described, the sealed capability manipulation circuitry prevents the processing circuitry from performing at least one processing operation using a given sealed capability when the current mode trust level is a trust level lower than the capability trust level of the given sealed capability. Although the number of prohibited processing operations can vary depending on the implementation, in one embodiment, the sealed capability manipulation circuitry is arranged to prevent the processing circuitry from performing any of a plurality of processing operations using a given sealed capability when the current mode trust level is a trust level lower than the capability trust level of the given sealed capability, but to allow the given sealed capability to be moved between storage elements.

[0032] It may be useful to allow sealed capabilities to be moved between storage elements, to allow such sealed capabilities to be transferred between registers and memory, and indeed to allow register-to-register moves as needed. Typically, however, a processing circuit may be prevented from performing most, if not all, processing operations using a sealed capability if the current mode trust level is lower than the capability trust level of that sealed capability. There may nevertheless be cases where certain activities are enabled. For example, even if the current mode trust level is lower than the capability trust level of the sealed capability in question, it may be possible to clear a field (referred to herein as a tag bit) that identifies the capability as a capability rather than general-purpose data, effectively disabling the capability.

[0033] In one exemplary implementation, the sealed capability manipulation circuitry is arranged to require a given sealed capability to be unsealed before the given sealed capability can be used by the processing circuitry in a subsequent processing operation, regardless of the current mode trust level.

[0034] However, in alternative implementations, the sealed capability manipulation circuitry may be arranged such that the processing circuitry is capable of performing one or more processing operations using a given sealed capability without unsealing the given sealed capability, at least when the current mode trust level is the same as the capability trust level of the given sealed capability. This functionality may be restricted to situations where the current mode trust level is the same as the capability trust level, for example, or may be enabled in situations where the current mode trust level is equal to or greater than the capability trust level.

[0035] The one or more processing operations that are enabled using a given sealed capability in the circumstances identified above may vary depending on the implementation. For example, a dereference operation may be enabled to generate a memory address using a given sealed capability. Alternatively, or in addition, a capability modification operation may also be enabled to modify information identified by a given sealed capability. Both the capability's information and associated metadata may be altered when performing such a modification operation (sometimes referred to as mutated, particularly when the metadata changes), but typically such operations are constrained not to reduce the constraints specified by the capability. For example, typically any changes to the range information or permissions may be enabled only if they serve to reduce the range or reduce the permissions.

[0036] The processing circuitry may be arranged to operate in a variety of different ways, and the current mode trust level may depend on how the processing circuitry is currently operating. For example, in one implementation, the processing circuitry may be arranged to execute program code in one of a number of states including at least a privileged state and a non-privileged state, and the current mode trust level may depend on which of the multiple states the current program code is executed in. Note that there may be two different states, i.e., a privileged state and a non-privileged state, or there may 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 may be set depending on which state the current program code is executed in. For example, a particular implementation may provide different exception levels (ELs), such as EL0, EL1, and EL2, as different states, where EL2 is more privileged than EL1, and EL1 is more privileged than EL0.

[0037] 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, namely 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.

[0038] 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 circuitry 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.

[0039] Capabilities can be stored in a variety of locations within a system. For example, a device may have a set of capability registers used to store capabilities for reference by a processing circuit, but may also have a memory circuit that may be used to store one or more capabilities. The processing circuit may 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 may 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 thus constrain subsequent memory access operations performed using the loaded capability depending on the capability trust level of the capability stored in the capability register.

[0040] While such selective demotion of capability trust levels may be appropriate for standard capabilities, due to the requirement that sealed capabilities not be modified, such activity needs to be inhibited for sealed capabilities. Thus, in one exemplary implementation, the processing circuitry is further arranged to inhibit modification of the capability trust level during such a load operation when the selected capability is a sealed capability. In the case of sealed capabilities, there are no security issues resulting from allowing less trusted code to be provided with a more trusted sealed capability, since the previously identified activity of the sealed capability manipulation circuitry prevents the less trusted code from using the more trusted sealed capability.

[0041] In some implementations, the load operation may be performed in some cases to load normal data (not capabilities) into the capability register, and in such cases it may be important that the bits in the data associated with the capability trust level were in fact data that the capability is not modified, because in this case it is not the capability that is 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 the load operation when the selected capability has a control value that identifies the selected capability as a valid capability (not a sealed capability). With such an approach, the above-mentioned selective modification of the capability trust level during the load operation is performed only when an actual unsealed capability is loaded into the capability register.

[0042] In one exemplary implementation, the sealed capability manipulation circuitry is arranged to generate result information indicative of the results of processing the unseal request for the selected sealed capability. The result information can take a variety of forms, but is generally sufficient to allow a determination to be made as to whether the capability was successfully unsealed. For example, if the unsealing was not successful, a fault may be generated. Alternatively, one or more status flags may be set to indicate the fault to the software. As another example, an indication may be returned to the software to identify that the capability was successfully unsealed, and, if desired, an indication may be provided to identify a situation in which the successfully unsealed capability has a capability trust level that exactly matches the current mode trust level. As another example, an unsealing operation that fails may fail silently, with no information indicative of a successful unsealing being generated and used later to determine that the unsealing operation failed.

[0043] Optionally, result information can also be generated to identify the result of processing the sealing request, e.g., to identify whether the sealing operation was successful or unsuccessful. In one exemplary implementation, success can be assumed and information can be output only if the sealing operation was unsuccessful. In yet a further exemplary implementation, no information may be generated regardless of whether the sealing request was successful or unsuccessful, and a failed sealing operation can be detected at a later stage, e.g., during opening.

[0044] In some example implementations, there may be some capabilities that are of a reserved type and are used by the architecture, for example, to indicate a particular event or function. In one example implementation, the sealed capability manipulation circuitry may be arranged to prohibit the opening of such capabilities, regardless of the current mode trust level. Optionally, an attempt to open such a capability may result in an error being asserted, a tag bit being cleared to effectively disable the capability, or some other indication being provided to the software. There are several ways in which such reserved type capabilities may be identified. As a particular example, they may have range bound information that defines an invalid range, for example, by an upper bound being below a lower bound.

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

[0046] The techniques described herein can be employed in various 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 employed in association with other processing circuits, such as direct memory access (DMA) controllers, cryptographic accelerators, etc. Purely as an example for the purposes of FIG. 1 below, the processing pipeline of a CPU is considered as an example of a processing circuit in which the techniques described can be used.

[0047] 1 illustrates generally an example of a data processing apparatus 2 comprising a processing pipeline 4 for processing instructions. In this example, the processing pipeline 4 includes a number of pipeline stages, including a fetch stage 6, a decode stage 8, an issue stage 10, an execution stage 12, and a writeback stage 14, although it will be appreciated 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 at one stage, another instruction may be pending at a different stage of the pipeline 4.

[0048] The fetch stage 6 fetches instructions from a level 1 (L1) instruction cache 20. The fetch stage 6 may typically fetch instructions sequentially from successive instruction addresses. However, the fetch stage may also have a branch predictor 22 for predicting the outcome of a branch instruction, and the fetch stage 6 may fetch instructions from a (non-sequential) branch target address if the branch is predicted as taken, or from the next sequential address if the branch is predicted as 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 representing the confidence of predictions made for a 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 may be predicted when the same branch instructions are later encountered.

[0049] The 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 the 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.

[0050] 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 exemplary implementations may support in-order processing, such that instructions are issued for execution in an order that corresponds to the program order in which the instructions were fetched from L1 instruction cache 20. Other exemplary 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 be executed first while earlier instructions are stalled waiting for operands.

[0051] 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 one (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. It will be appreciated that these are just a few examples of the types of execution units that may be provided, and many other types may be provided. To perform processing operations, the execution stage 12 may read data values ​​from a set of registers 40. Results of the executed instructions may then be written back to the registers 40 by the write-back stage 14.

[0052] 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. When an instruction to be fetched is not in the L1 instruction cache 20, it may be fetched from the L2 cache 44, and similarly, when an instruction is not in the L2 cache 44, it may be fetched from the main memory 50. Similarly, in response to a load instruction, when data is not in the L1 data cache 36, it may be fetched from the L2 cache 44, and when needed, it may be fetched from the memory 50. Any known scheme may be used to manage the cache hierarchy.

[0053] Although the addresses used by the pipeline 4 to reference program instructions and data values ​​may be virtual addresses, at least the main memory 50, and optionally also at least some levels of the cache hierarchy, may be physically addressed. Thus, a translation lookaside buffer (TLB) may be provided (e.g., in the memory access check circuitry 52, described in more detail below) to translate the virtual addresses used by the pipeline 4 to physical addresses used to access the cache or memory. For example, the TLB may include a number of entries, each of which specifies a virtual page address of 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 to 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. As well as the address translation information, each TLB entry may also include some information specifying access permissions, such as indicating whether a page with an address is accessible in a certain mode of the 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 the levels of the cache hierarchy that 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.

[0054] It will be appreciated that a single level TLB may be used, but alternatively a hierarchy of TLBs may be provided such that a level 1 (L1) TLB may contain TLB entries for translating addresses in a few recently accessed pages, and a level 2 (L2) TLB may be provided for storing 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 from a further TLB in the hierarchy. If the required entry for the page being accessed 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.

[0055] It will also be appreciated that some systems may support multiple levels of address translation, such that, for example, a first TLB (or a 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.

[0056] 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.

[0057] Each bounded pointer register 60 includes a pointer value 62 that may 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 may define one or more restrictions / permissions regarding the use of the pointer. For example, the restriction 66 may be used to restrict the types of instructions in which the pointer 62 may be used, or the modes of the pipeline 4 in which the pointer may be used. The range information 64 and the restriction information 66 may therefore be considered to define the capabilities within which the pointer 62 is permitted to be used. Any attempt to use the pointer 62 outside the defined capabilities may trigger an error. The range information 64 may be useful, for example, to ensure that the pointer stays within certain 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, for example, be stored within the same memory locations used for the corresponding general purpose registers.

[0058] Figure 2 shows an example of the types of instructions for 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 80000 to 81000. 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.

[0059] For example, as shown in part 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 that is outside the range specified by range information 64 (assuming here that the pointer points directly to an address). This prevents pointer 62 from taking on a value outside the specified range so that accesses using the pointer can be assured to be within the acceptable range. Alternatively, as shown in part 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 of the pointer address (or an address derived from the pointer) is attempted and the address is outside the acceptable range. Other systems may trigger an error in response to both types of instructions shown in parts A and B of FIG. 2.

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

[0061] In addition to the set of bounded pointer storage elements 60 that may be used in execution state 12 when executing certain instructions that reference pointers, a program counter capability (PCC) register 80 may also be used to provide similar functionality in the fetch stage 6 when instructions are 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 suitable 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.

[0062] 3 shows a schematic diagram of how tag bits are used in association with individual data blocks to identify whether they represent capabilities (i.e., bounded pointers and associated restriction information) or normal data. Specifically, memory address space 110 stores a series of data blocks 115, typically having a specified size. Purely for illustrative purposes, in this example, each data block is assumed to contain 128 bits, although in other exemplary implementations data blocks of different sizes may be used, e.g., 64-bit data blocks when capabilities are defined by 64 bits of information. In association with each data block 115, in one example, a tag field 120 is provided, which is a single-bit field referred to as a tag bit, which is set to identify that the associated data block represents a capability and is cleared to indicate that the associated data block represents normal data and therefore cannot be treated as a capability. It will be appreciated 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.

[0063] When a capability is loaded into one of the bounded pointer registers 60 (also referred to herein as capability registers), such as the capability register 100 shown in FIG. 3, the tag bit travels with the capability information. Thus, when a capability is loaded into the capability register 100, the pointer 102, range information 104, and limit information 106 (hereinafter referred to as permission information) will be loaded into the capability register. In addition, in association 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 ensures that capabilities are distinguished from normal data, and therefore normal data cannot be used as a capability.

[0064] Returning to Figure 1, device 2 may be provided with capability check circuitry 33 capable of performing a capability check operation in relation to 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 may be performed, for example, with reference to the range information and limit / permission information discussed above, which may collectively 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 only used 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.

[0065] 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 operational mode may be associated with, for example, a particular privilege state and / or a particular security domain in which the device operates, and a particular region of memory may only be accessible when the processing circuit is operating in one or a subset of the possible operational modes.

[0066] The memory access check circuit 52 may thus check whether access to the memory system is permitted based on attribute data specified for various regions of the memory address space. The memory access check circuit may include a security attribute unit (SAU) 56 that stores security domain definition data defining a security domain associated with each of the corresponding regions of the memory address space. Based on the security attribute data, the security attribute unit 56 may check whether the memory access is permitted depending on the current security domain of the operation of the processing circuit and the security domain associated with the region containing the target address and the memory access. In other implementations, the SAU 56 may access security definition data stored in other locations to perform the memory access check, rather than directly storing the security domain definition data. In some systems, the security domain definition data may be stored in the memory system 50 or may be stored in configuration registers in other locations within the system 2.

[0067] 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 executed instruction (although there may be some exceptions, for example, when handling transitions between domains). While operating in the secure domain, the processing circuit may access data in memory regions associated with both the secure and less secure domains, and 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 specifies as associated with the secure domain. This allows for 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 of the access request.

[0068] 1, the memory access check circuit 52 may include a memory protection unit (MPU) 54 that checks whether a memory access to the memory system 50 satisfies access permissions, which may specify, for example, which privilege level of the processing circuit 4 is allowed to access a given region of memory, or which memory region of the address space may 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, and thus, for a given memory access request to be allowed, checks based on the access permissions defined for both the MPU 54 and the SAU 56 must be passed. 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 or less secure domain (e.g., a region is read-only in the less secure domain but readable and writeable in the secure domain).

[0069] 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.

[0070] 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 that of the current operating mode of the processing circuit, although this behavior may be controlled by a separate bit in the control register 90. Similarly, failures 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 the control register 90. Also, as will be discussed later, capabilities may be loaded from memory into the capability registers, and 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 the control register 90.

[0071] In accordance with the techniques described herein, capabilities are provided with associated capability trust level information, and that trust level indication 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 indication 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.

[0072] The permissions specified for a capability may vary depending on the implementation, but in one exemplary implementation, the permissions include a read permission bit 130 whose value indicates whether the capability may be used to generate memory addresses for read accesses, a write permission bit 132 whose value indicates whether the capability may be used to generate memory addresses for write accesses, and an execute permission bit 134 whose value indicates whether the capability may be used to generate memory addresses for instructions to be fetched and executed. For example, other information may be identified within the capability to indicate whether the capability is considered immutable. Such information may be specified directly as additional information within the capability, but in some exemplary 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.

[0073] 4, in one exemplary implementation, the permission field is extended to provide a trust level indicator field 136, which identifies a trust level associated with the capability 100. The trust level may be directly encoded in the 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 a location containing the trust level information.

[0074] 5A is a block diagram that illustrates, in a schematic manner, how capability trust level information is used to constrain access to memory, according to one exemplary implementation. In this example, the processing circuit 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 an access request in which a memory address is generated using the given capability is considered. Thus, the capability check may involve reference to the capability scope and permission information to determine whether the access is permitted to proceed. If the capability check is unsuccessful, a failure indication can be provided to the processing circuit, which can take various forms, such as, for example, a fault signal. However, if the capability check is passed, this is indicated to the trust level generation block 160, which also receives the capability trust level information 136 of the capability 100.

[0075] In addition to the capability trust level, the 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 the trust level generation block 160 can use both the current mode trust level and the capability trust level to determine a trust level for the access request, in one exemplary implementation, the trust level associated with the access request is constrained to the one representing the lower trust level of the current mode trust level and the capability trust level.

[0076] Memory access check circuitry 170 receives both the memory address of the request and an associated confidence level for the access request, and may perform a memory access check operation with 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 may 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 may be rejected; otherwise, the access to the memory may be propagated from memory access check circuitry 170 over path 180.

[0077] As discussed above, in accordance with the techniques described herein, the provision of capability trust levels associated with individual capabilities is also leveraged to provide a lightweight mechanism for manipulating sealed capabilities that avoids the need to utilize scarce metadata bits to indicate object type and opening permissions, and also avoids the need to open keys.

[0078] In particular, in accordance with the techniques described herein, a sealed flag field 138 is added to a capability to identify whether the associated capability is sealed or unsealed, and is illustrated in FIG. 4 (sometimes referred to herein as an IsSealed flag). In one implementation, this may be a single bit with one state indicating that the capability is sealed (e.g., a logic 1 value) and another state indicating that the capability is unsealed (e.g., a logic 0 value). However, the sealed flag need not be a single bit value, and in some implementations, a multi-bit value may be used to capture some additional information.

[0079] Further, as shown in Figure 5A, sealed capability manipulation circuitry 185 is used to determine how to manipulate a sealed capability. The sealed capability manipulation circuitry 185 may be provided as a separate component or may be incorporated within processing circuitry 150 as shown in Figure 5A. When manipulating a sealed capability, the sealed capability manipulation circuitry 185 need not use a seal or open key, but instead may reference capability trust level information captured in association with a given capability to assess how the given capability should be manipulated in combination with the current mode trust level associated with processing circuitry 150. Based on this information, the sealed capability manipulation circuit 185 can, for example, determine whether a given capability can be sealed, in which case all that is required is for the sealed capability manipulation circuit to set a sealed flag, determine whether a given sealed capability can be unsealed, in which case all that is required is for the sealed capability manipulation circuit to clear a sealed flag, and determine how the sealed capability can be used by the processing circuit depending on a comparison of the capability trust level of the sealed capability with the current mode trust level of the processing circuit.

[0080] FIG. 5B is a flow diagram illustrating the operation of the circuit of FIG. 5A in an exemplary embodiment. In step 200, it is determined that an access request is necessary. Then, in step 205, it is determined whether the capability specified for the access request is a sealed capability. If so, in step 210, it may be determined whether the use of the sealed capability is enabled. In some implementations, there may always be cases where a sealed capability cannot be dereferenced to generate a memory address (instead, such a sealed capability needs to be unsealed first), in which case the process may proceed directly to step 215 without needing to perform the check of step 210, thereby preventing the access request. However, in some implementations, depending on the relative trust level of the current mode of the processing circuit and the capability trust level of the specified capability, a sealed capability may be provided to be used without needing to be unsealed first. For example, in one implementation, if the current mode trust level is equal to or greater than the capability trust level, the use of the sealed capability may be enabled.

[0081] Thus, if in step 210 it is determined that use of a sealed capability is possible, the process proceeds to step 220, and in fact also proceeds to step 220 if, previously in step 205, it was determined that the specified capability is not a sealed capability. However, if in step 210 it is determined that use of a sealed capability is not possible, the process proceeds to step 215, and the access request is prevented from occurring. There are several ways in which the access request may be prevented. For example, a capability check failure signal may be asserted, or some other activity may be performed to identify that the access request was attempted using a sealed capability.

[0082] Assuming the process proceeds to step 220, in which step the memory address for the access request is determined with reference to the pointer value of the specified capability. In step 225, a capability check is performed with reference to the bounds and permission information of the specified capability to determine whether the access can proceed.

[0083] Thus, in step 230, it is determined whether the capability check passed, and if not, the process proceeds to step 235 where a capability check fail signal is asserted. Step 235 may be implemented in the same manner as step 215 in one exemplary implementation.

[0084] Typically, the trust level information is not used when performing the capability check in step 225, but instead is retained to pass to the memory access check circuitry 170. However, in some implementations, the trust level information may also be used during the capability check process. For example, the processing circuitry may be arranged to issue a fault signal in step 235 when an attempt is made to perform an 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 that access request exceeds a current mode trust level associated with the current operating mode of the processing circuitry. In particular, in some implementations, it may be considered incorrect behavior for a processing circuit operating at a certain trust level to attempt to utilize a capability having a higher capability trust level.

[0085] If, in step 230, it is determined that the capability check is passed, then, in step 240, 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 245, the access request is propagated along with the determined trust level for the access request 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.

[0086] 6 is a flow diagram illustrating steps performed when processing a seal request according to one exemplary implementation. The seal request may be generated in a variety of ways, but in one exemplary implementation may result from a processing circuit executing a seal instruction. In step 300, it is determined whether a seal request has been received, and if so, as an optional step, in step 305, it may be determined whether sealing is possible at the current mode trust level. In some implementations, such a check may be deemed unnecessary, since the implementation may in principle allow sealing at any current mode trust level, subject to further checks described below. However, in alternative implementations, sealing may be limited to certain operating modes, in which case the check in step 305 may be performed.

[0087] If it is determined that sealing is not possible at the current mode trust level, sealing of the identified capability is prevented in step 310. In step 310, the device may further output information to identify failure of the sealing process, for example by asserting a failure signal or by updating a certain status flag. However, in alternative implementations, it may not be necessary to output any indication of success or failure of the sealing process, since failure of the sealing may be arranged to be picked up at a later stage, for example during a subsequent unsealing process.

[0088] If in step 305 it is determined that sealing is possible at the current mode trust level, or whenever a sealing request is received in step 300 where optional step 305 is not performed, the process proceeds to step 315 where the capability trust level of the identified capability is determined. As discussed above with reference to Figure 4, this information may be available directly in the capability, in particular in the trust level indicator field 136, for example.

[0089] In step 320, the sealed capability manipulation circuit 185 then determines whether the current mode trust level of the processing circuit is greater than or equal to the capability trust level of the identified capability. If not, the process proceeds to step 310 where sealing of the identified capability is prevented.

[0090] However, assuming that the current mode trust level is equal to or greater than the capability trust level, the process proceeds to step 325, where the identified capability is sealed by setting the sealing flag 138. In much the same manner as described above with reference to step 310, if desired, the device may be arranged to output information indicating that the sealing of the capability was successful. However, in one exemplary implementation, it is assumed that the sealing was successful, and therefore no information is output. If the sealing was unsuccessful, this may be indicated by the information output in step 310, or may be picked up at a later stage, for example during the unsealing of the capability, as described above.

[0091] 7 is a flow diagram illustrating steps performed in response to receiving an unsealing request. When such a request is received in step 350, an optional step 355 may determine whether unsealing is possible at the current mode trust level. If desired, the ability to unseal may be limited to a particular mode of operation, as discussed above with respect to the equivalent step 305 in the sealing process of FIG. 6. However, in one exemplary implementation, no such general restriction is imposed, and thus step 355 is not required.

[0092] If step 355 is implemented and it is determined that unsealing is not possible at the current mode trust level, then in step 360, the unsealing of the identified capability is prevented. Information may be output at this point to identify that the unsealing has failed. For example, a fault signal may be generated, or one or more status flags may be set to indicate the failure to the software. As another example, the unsealing operation may fail silently, with no information generated to indicate that the unsealing was successful, which may be used later to determine that the unsealing operation has failed.

[0093] If in step 355 it is determined that opening is possible at the current mode trust level, or in direct response to the opening request in step 350 where step 355 is not required, the process proceeds to step 365 where the capability trust level of the identified capability is determined by reference to the trust level indicator field 136.

[0094] Next, in step 370 it is determined whether the current mode trust level is greater than or equal to the capability trust level, and if not, in step 360 the identified capability is prevented from being opened.

[0095] However, assuming that the current mode trust level is equal to or greater than the capability trust level, the identified capability is unsealed in step 375 by clearing the sealing flag. Optionally, information can be output at this point to indicate that the capability was successfully unsealed. In one particular implementation, two output signals are generated at this point. The first signal is used to identify that the capability was sealed and successfully unsealed, and the second signal can identify whether the capability was sealed and unsealed from the same mode trust level of the processing circuit. Thus, the second signal can be used to indicate that the capability was associated with the current mode trust level, which in some implementations can be useful for software to ensure, for example, that the capability was generated by the same context as the context in which it is intended to reference it.

[0096] FIG. 8 is a diagram illustrating a variety of different modal trust levels that may be present in a system, showing the seal / unseal capabilities that may be supported in such an arrangement. As shown in FIG. 8, 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 executed in. Additionally or alternatively, the processing circuitry may be arranged to execute program code in a number of different states, and in the example of FIG. 8, may be arranged to operate the program code in a privileged or non-privileged 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 / non-privileged state. Thus, as shown in FIG. 8, in the example shown, there may be four different trust levels.

[0097] With regard to the seal and unseal capabilities described above, when the processing circuit is operating in the secure and privileged modes, as indicated by the arrows in Figure 8, the processing circuit may be able to seal and unseal capabilities whose capability trust levels are associated with any of the other three trust level operating modes, and, as indicated by the circular arrows, it may also perform seal and unseal operations on capabilities whose capability trust levels indicate a secure privileged trust level.

[0098] Similarly, when the processing circuit is operating in a less secure privileged mode, the processing circuit may perform seal and unseal operations in relation to capabilities associated with a less secure unprivileged trust level, and again may be able to seal and unseal capabilities associated with its own trust level, as indicated by the circular arrows in Figure 8. Furthermore, if desired, when the processing circuit is operating in a secure unprivileged mode, the processing circuit may be able to seal and unseal capabilities associated with a less secure unprivileged trust level, and again may also be able to seal and unseal capabilities associated with its own trust level. Finally, in the less secure unprivileged mode, the processing circuit may only be able to seal and unseal capabilities associated with a less secure unprivileged trust level.

[0099] 8 illustrates four different trust levels, it will be appreciated that the techniques described herein are not limited to such configurations, and additional trust levels may be provided in either or both of the orthogonal directions illustrated in FIG. 8. Privileged and non-privileged mode operation may take a variety of forms, but purely by way of example, the privileged mode may in some implementations be referred to as a handler mode, and the non-privileged mode may be referred to as a thread mode. The handler mode is typically used for exception handling, and thus, for example, a trusted exception handling routine may be executed in the handler mode. The thread mode is typically used to execute multiple different threads, e.g., multiple different application threads.

[0100] 9A and 9B are flow diagrams illustrating different approaches that can be taken when considering the use of a sealed capability. First, as shown in FIG. 9A, if in step 400 a request attempts to use a sealed capability, in step 405 such use may be prevented, according to one exemplary implementation, regardless of the current mode trust level. In particular, according to the implementation illustrated in FIG. 9A, the system allows the use of a sealed capability only if it is first unsealed. Thus, in such an implementation, all processing operations attempted with respect to the sealed capability will fail. However, it should be noted that the processing circuitry may still be able to move the sealed capability between storage structures, for example, between a register and a memory, or between different registers. Furthermore, in one exemplary implementation, it may still be possible to disable a sealed capability by clearing the aforementioned tag bit normally associated with the capability.

[0101] 9B is a flow diagram illustrating an alternative implementation in which some use of a sealed capability may be possible in certain circumstances. Thus, if it is determined in step 410 that the request is attempting to use a sealed capability, it is determined in step 415 whether the current mode trust level is equal to or greater than the capability trust level. If not, in step 420, the use of the sealed capability is prevented, but if not, the process proceeds to step 425, where it is determined whether the particular use in question is of a type that is possible for the sealed capability. If not, again in step 420, the use of the sealed capability is prevented, but if not, the process proceeds to step 430, where the requested operation is possible using the sealed capability, subject to any normal checks that may be performed before allowing the use to proceed.

[0102] With respect to step 425 above, use of a sealed capability may be restricted to certain types of operations. For example, when the current mode trust level is equal to or greater than the capability trust level of a sealed capability, the processing circuitry may be allowed to perform a dereference operation using the sealed capability to generate a memory address. This may result in some performance benefits by avoiding the need to unseal the capability before it is used.

[0103] Another type of processing operation that may be envisioned is the modification of a sealed capability, which again may be supported in some cases. In particular, Figure 10 is a flow diagram illustrating steps that may be performed when handling a request to modify a capability. As shown in Figure 10, if a request to modify a capability is received in step 450, it is determined in step 455 whether the capability is sealed. If not, the process proceeds to step 460, where the usual checks required to determine whether the capability can be modified are performed.

[0104] However, if the capability is sealed, optionally, in step 465, it may be determined whether the trust level associated with the current operating mode of the processing circuit is sufficient to allow modification of the capability to occur. This may be, for example, if the current mode trust level is equal to or greater than the capability trust level. If so, the process may proceed to step 460 described above and the usual checks may be performed. However, if the trust level is insufficient, the process may instead proceed to step 470 and modifications to the capability are prevented or the capability is instead disabled. In an alternative implementation in which optional step 465 is omitted, if the capability is sealed, the process may proceed directly from step 455 to step 470 to prevent modification of the capability or to disable the capability.

[0105] In all of the above examples described with reference to Figures 6-10, when the current mode trust level is compared to the capability trust level, it is assumed that the described activities may be permitted whenever the current mode trust level is equal to or greater than the capability trust level. In alternative implementations, the ability to perform those activities may be restricted to situations where the current mode trust level matches the capability trust level.

[0106] 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, and one exemplary implementation of this approach is shown in FIG. 11. In step 500, it is determined whether a capability load from memory is requested. In step 505, it is determined whether the capability identified for the load operation is a sealed capability. If so, the process proceeds to step 515, where the capability is stored in an unmodified form in the identified capability register for the load operation. In particular, due to the characteristics of sealed capabilities, it is inappropriate for any change in the capability trust level to be made during the load operation. Furthermore, due to the aforementioned mechanism employed by the sealed capability manipulation circuitry 185 to control the use of sealed capabilities, security can still be guaranteed for sealed capabilities, even if no reduction in the capability trust level is made when loading the sealed capabilities into the capability registers.

[0107] If in step 505 it is determined that the capability is not a sealed capability, the process proceeds to step 510, where it is determined whether the current mode trust level is less than the capability trust level of the capability to be loaded from memory. If not, in one exemplary implementation, the process proceeds to step 515, where the capability is stored unmodified in the capability register.

[0108] However, according to the technique shown in FIG. 11, if the current mode trust level is less than the capability trust level, the process proceeds to step 520, where the capability trust level 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 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 capability register of the processing circuit has its capability 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 moved to the capability register. This can avoid accidental promotion of capabilities, for example, when an exception handler accidentally promotes a stacked value.

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

[0110] As indicated by step 520 of FIG. 11, the ability to selectively demote a capability trust level can be made configurable, for example, by being conditional on control information stored in control registers 90. Selective demotion of capabilities can also be disabled for certain types of capabilities (in addition to sealed capabilities already discussed above), and thus, for example, 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 capability. Furthermore, as discussed above, while the control information used to conditionally enable or disable selective demotion of capabilities being loaded from memory can be stored in control registers, the control information can also be stored in other locations, for example, as fields within the capabilities themselves, or, for example, to enable demotion based on MPU region attributes. In this latter approach, a mechanism can be provided such 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.

[0111] FIG. 12 is a flow diagram illustrating how the unsealing of a capability can be selectively prohibited for a certain type of capability. In particular, when an unsealing request is received in step 550, it is determined in step 555 whether the identified capability is of the predetermined type. If not, in step 565, the process proceeds as in the remainder of FIG. 7 discussed above. However, if in step 555 the identified capability is of the predetermined type, the process proceeds to step 560, where the unsealing of the identified capability is prevented. As previously described in describing step 360 of FIG. 7, various information can be output if desired to identify that the unsealing of the identified capability has not occurred, in which case, for example, a flag can be raised or an error can be asserted indicating that an attempt has been made to unseal a capability of the predetermined type. As another option or in addition, the tag bit can be cleared to disable the capability.

[0112] The predefined type capabilities for which the above process may be employed may take various forms, but may for example be one or more types of capabilities used by the architecture to indicate a particular event or function. There are several ways in which such reserved type capabilities may be identified. As a particular example, they may have range bound information that defines an invalid range, for example by an upper bound being below a lower bound.

[0113] Optionally, in addition to the sealing flag described above, a capability may have one or more extra fields to provide additional indications used to identify the particular purpose for which the capability may be used. Furthermore, if desired, the address values ​​encoded within the capability may provide an indirection that allows software to validate against its own records rather than directly identifying a memory address.

[0114] FIG. 13 illustrates a simulator implementation that may be used. While the above examples implement the invention in terms of apparatus and methods for operating specific processing hardware that supports the technique, it is also possible to provide an instruction execution environment according to the examples described herein, which is implemented through the use of a computer program. Such computer programs are often referred to as simulators insofar as they provide a software-based implementation of a hardware architecture. Various simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may run on a host processor 615, which optionally runs a host operating system 610, which supports the simulator program 605. 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 run code native to another processor for compatibility or reuse reasons. For example, a simulator implementation may provide an instruction execution environment that has additional functionality not supported by the host processor hardware, or that is 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.

[0115] To the extent that examples have been described above with reference to particular hardware constructs or features, in the simulated implementation, equivalent functionality may be provided by suitable software constructs or features. For example, particular circuits may be provided as computer program logic in the simulated implementation. Similarly, memory hardware such as registers or caches may be provided as software data structures in the 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 605 to a virtual address space used by host operating system 610. In arrangements where one or more of the hardware elements referred to in the preceding examples are present in host hardware (e.g., host processor 615), some simulated implementations may use the host hardware, if suitable.

[0116] The simulator program 605 may be stored in a computer-readable storage medium (which may be a non-transitory medium) and provides a virtual hardware interface (instruction execution environment) to the target code 600 (which may include applications, 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 605. Thus, the program instructions of the target code 600 may be executed from within the instruction execution environment using the simulator program 605, so that the host computer 615, which does not actually have the hardware features of the device 2 discussed above, can emulate these features. The simulator program may include processing program logic 620 for emulating the behavior of the processing pipeline 4, check program logic 622 for emulating the behavior of the capability check circuit 33 and the memory access check circuit 52 of the hardware device 2 of FIG. 1, and the encapsulated capability manipulation program logic 605 for emulating the behavior of the encapsulated capability manipulation circuit 185. Thus, the techniques described herein for managing capabilities and their associated capability trust levels, along with the described techniques for manipulating sealed capabilities, may be implemented in software by simulator program 605 in the example of FIG. 13.

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

[0118] Although exemplary 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 of ordinary skill 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 processing operations 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 check circuit that determines 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 based on a trust level associated with the given access request; each 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 operating mode of the processing circuit and the capability trust level of the given capability; At least one of the capabilities is configurable as a sealed capability; The apparatus further comprises sealed capability manipulation circuitry for preventing the processing circuitry from performing at least one processing operation using the given sealed capability when the current mode trust level is a trust level lower than the capability trust level of the given sealed capability.

2. 2. The apparatus of claim 1, wherein each capability has a sealed flag associated therewith, and wherein the sealed capability manipulation circuit, in response to a sealing request for a selected capability, determines whether to set the sealed flag of the selected capability to identify the selected capability as a sealed capability in response to a comparison of the capability trust level of the selected capability with the current mode trust level.

3. 3. The apparatus of claim 2, wherein the sealed capability manipulation circuitry is arranged to, in response to the sealing request, inhibit setting of the sealing flag when the capability trust level of the selected capability is greater than the current mode trust level.

4. 4. The apparatus of claim 3, wherein the sealed capability manipulation circuitry is arranged to, in response to the sealing request, set the sealing flag when the capability trust level of the selected capability matches the current mode trust level.

5. 3. The apparatus of claim 1, wherein each capability has an associated sealed flag that is settable to indicate the capability as a sealed capability, and wherein the sealed capability manipulation circuitry, in response to an unseal request for a selected sealed capability, inhibits clearing of the sealed flag for the selected sealed capability when the capability trust level of the selected sealed capability is greater than the current mode trust level.

6. 6. The apparatus of claim 5, wherein the sealed capability manipulation circuitry is arranged to, in response to the unseal request, clear the seal flag when the capability trust level of the selected sealed capability matches the current mode trust level.

7. 3. The apparatus of claim 1, wherein the sealed capability manipulation circuitry is arranged to prevent the processing circuitry from performing any of a plurality of processing operations using the given sealed capability when the current mode trust level is at a trust level lower than the capability trust level of the given sealed capability, but to allow the given sealed capability to be moved between storage elements.

8. 3. The apparatus of claim 1, wherein the sealed capability manipulation circuitry is arranged to require the given sealed capability to be unsealed before the given sealed capability can be used by the processing circuitry in a subsequent processing operation, regardless of the current mode trust level.

9. 2. The apparatus of claim 1, wherein the sealed capability manipulation circuitry is arranged such that the processing circuitry can perform one or more processing operations using the given sealed capability without unsealing the given sealed capability, at least when the current mode trust level is the same as the capability trust level of the given sealed capability.

10. 10. The apparatus of claim 9, wherein the sealed capability manipulation circuitry is arranged to be capable of performing the one or more processing operations using the given sealed capability if the current mode trust level is greater than or equal to the capability trust level of the given sealed capability.

11. The one or more processing operations that are enabled include: a dereference operation to generate a memory address using the given sealed capability; and a capability modification operation for modifying the information identified by the given sealed capability.

12. 3. 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 the current program code is executing.

13. 3. 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.

14. The apparatus of claim 13 , wherein the current mode trust level depends on both the state and the security domain in which the current program code is executing.

15. a set of capability registers for storing capabilities for reference by said processing circuitry; a memory circuit for storing one or more capabilities; 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; the processing circuitry is arranged to selectively modify the capability trust level during the load operation so 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; the processing circuitry inhibits modification of the capability trust level during the load operation when the selected capability is a sealed capability.

3. The device according to claim 1, further comprising:

16. 6. The apparatus of claim 1 or 2 when dependent on claim 5, wherein the sealed capability manipulation circuitry is arranged to generate result information indicative of a result of processing an unsealing request for the selected sealed capability.

17. 17. The apparatus of claim 16, wherein the encapsulated capability manipulation circuitry is arranged to generate the result information by setting one or more status flags accessible to the processing circuitry.

18. 3. Apparatus according to claim 1 or 2, wherein the sealed capability manipulation circuitry is arranged to inhibit the opening of at least one predetermined type of capability regardless of the current mode trust level.

19. The apparatus of claim 1 or 2, 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.

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

21. 1. A method of manipulating an encapsulated capability, comprising: employing a processing circuit to perform a processing operation during which a request for access to a memory is generated, the processing circuit using capabilities to identify constraint information to generate a memory address for the access request; determining 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 based on a trust level associated with the given access request; each 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 operating mode of the processing circuit and the capability trust level of the given capability; At least one of the capabilities is configurable as a sealed capability; The method further includes employing sealed capability manipulation circuitry to prevent the processing circuit from performing at least one processing operation using the given sealed capability when the current mode trust level is a trust level lower than the capability trust level of the given sealed capability.

22. 1. A computer program for controlling a host data processing device to provide an instruction execution environment, comprising: processing program logic for performing processing operations during which memory access requests are generated, said processing program logic being arranged to generate memory addresses for said access requests using capabilities that identify constraint information; checking program logic that determines 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 based on a trust level associated with the given access request; each 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 operating mode of the processing program logic and the capability trust level of the given capability; At least one of the capabilities is configurable as a sealed capability; The apparatus further comprises sealed capability manipulation program logic for preventing the processing program logic from performing at least one processing operation using the given sealed capability when the current mode trust level is at a trust level lower than the capability trust level of the given sealed capability.

Images