Key Capabilities Storage

Abstract

A key capability storage circuit 90 is provided that stores key capabilities specifying key boundary indication information indicating allowable boundaries of information specified by any one or more of non-capability operands, capabilities, or the key capabilities themselves. If a given software compartment executed by the processing circuit lacks a key capability operating privilege associated with at least a portion of the key capability storage circuit, the processing circuit is configured to prohibit certain operations of the key capabilities, including transmissions between the key capability storage and memory locations selected by the given software compartment. This can help support temporal stability.

Description

[Technical Field]

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

[0002] Currently used memory protection techniques tend to be relatively coarse-grained in that access permissions to respective regions of memory tend to be defined at the level of individual processes or threads accessing pages of virtual memory, rather than being tied to specific accesses to code or data objects running within a thread or process.

[0003] In a capability-based architecture, a capability storage may be provided to store capabilities, where the capabilities include some bounded information (e.g., a pointer) and boundary indication information for constraining the effective use of the bounded information. This approach means that information is referenced to perform an operation, such as accessing memory to obtain data or instructions, and associated metadata for constraining the access is provided in the capability itself. Different accesses to the same address from different instructions within the same process may reference different capabilities and therefore be subject to different constraints. This allows for more granular compartmentalization of software running on a processing circuit, making it more difficult for attackers to exploit memory usage errors.

[0004] At least some examples include an apparatus comprising: a processing circuit responsive to instructions to perform data processing; a capability storage circuit configured to store at least one capability specifying bounded information and boundary indication information indicating allowed boundaries of the bounded information; a key capability storage circuit configured to store at least one key capability specifying key boundary indication information, the key boundary indication information indicating allowed boundaries of information specified by any one or more of a non-capability operand, a capability stored in the capability storage circuit, and the key capability itself; and a capability check circuit configured to determine whether to enable an operation to be performed by the processing circuit based on a boundary check using the boundary indication information and the key boundary indication information; an apparatus wherein, if a given software compartment executed by the path lacks a key capability operation privilege associated with at least a portion of the key capability storage circuit, the processing circuit is configured to prohibit the given software compartment from causing the processing circuit to perform one or both of a first transfer operation that transfers key capabilities from at least a portion of the key capability storage circuit to the capability storage circuit or to a memory location selected by the given software compartment, and a second transfer operation that transfers key capabilities from the capability storage circuit or to at least a portion of the key capability storage circuit from a memory location selected by the given software compartment.

[0005] At least some examples include a method including: storing, in a capability storage circuit, at least one capability specifying bounded information and boundary indication information indicating allowed boundaries of the bounded information; storing, in a key capability storage circuit, at least one key capability specifying key boundary indication information, the key boundary indication information indicating allowed boundaries of information specified by any one or more of non-capability operands, capabilities stored in the capability storage circuit, and the key capability itself; and determining whether to enable an operation to be performed by a processing circuit based on a bounds check using the boundary indication information and the key boundary indication information; The method provides that, if a given software compartment lacks a key capability operation privilege associated with at least a portion of the key capability storage circuit, the processing circuit prohibits the given software compartment from causing the processing circuit to perform one or both of a first transfer operation that transfers key capabilities from at least a portion of the key capability storage circuit to the capability storage circuit or to a memory location selected by the given software compartment, and a second transfer operation that transfers key capabilities from the capability storage circuit or to at least a portion of the key capability storage circuit from a memory location selected by the given software compartment.

[0006] At least some embodiments include a computer program for controlling a host data processing apparatus to provide an instruction execution environment for executing target code, the computer program comprising: instruction decode program logic for decoding instructions of the target code to control the host data processing apparatus to perform data processing in response to the instructions of the target code; storage emulation program logic for maintaining, in host storage circuitry of the host data processing apparatus, a capability storage structure for storing at least one capability specifying bounded information and boundary indication information indicating allowed boundaries of the bounded information, and a key capability storage structure for storing at least one key capability specifying key boundary indication information, the key boundary indication information indicating allowed boundaries of information specified by any one or more of non-capability operands, capabilities stored in the capability storage structure, and the key capability itself; and storage emulation program logic for maintaining, in host storage circuitry of the host data processing apparatus, a capability storage structure for storing at least one capability specifying bounded information and boundary indication information indicating allowed boundaries of the bounded information, the key boundary indication information indicating allowed boundaries of information specified by any one or more of non-capability operands, capabilities stored in the capability storage structure, and the key capability itself. and capability check program logic that determines whether to enable an operation to be performed in response to an instruction of the target code based on a bounds check, wherein if a given software compartment of the target code lacks a key capability operation privilege associated with at least a portion of the key capability storage structure, the instruction decode program logic is configured to prohibit the given software compartment from causing the host data processing device to perform one or both of a first transfer operation that transfers key capabilities from at least a portion of the key capability storage structure to the capability storage structure or to a simulated memory location selected by the given software compartment, and a second transfer operation that transfers key capabilities from the capability storage structure or to at least a portion of the key capability storage circuitry.

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

[0008] Further aspects, features, and advantages of the present technique will become apparent from the following description of examples, read in conjunction with the accompanying drawings. [Figure 1] 1 illustrates a schematic diagram of an example of a data processing device. [Figure 2] 1 illustrates an example of a register of a device, including a key capability register, which is an example of a key capability storage circuit. [Figure 3] 1 illustrates an example of device operating states associated with different levels of privilege, including some states that are considered to have key capability operating privileges. [Figure 4] 10 illustrates an alternative example of assigning key capability operating privileges by using scope information. [Figure 5] 10 illustrates an example of boundary information for controlling which portions of key capability storage are active or inactive. [Figure 6] FIG. 10 is a flow diagram illustrating a method for processing a key capability manipulation instruction. [Figure 7] FIG. 10 is a flow diagram illustrating a method for controlling the creation or transfer of a key capability based on whether a requesting software compartment has the key capability operating privilege. [Figure 8] Indicates control over whether a capability can be loaded from memory into a capability register based on whether the capability is indicated as a key capability type. [Figure 9] FIG. 10 is a flow diagram illustrating an example of a capability check to determine whether to allow an operation based on bounds checking. [Figure 10] Examples of confidential / shared information that indicate whether a capability operand or a non-capability operand is confidential or shared are shown below. [Figure 11] Illustrates the use of key capability check success indicators. [Figure 12] FIG. 10 is a flow diagram illustrating clearing or recalculating key capability check success indicators in response to an update to a register having a key capability check success indicator set. [Figure 13] It shows the transformation of a secret capability into a shared capability. [Figure 14] An example of a simulator that may be used is shown below.

[0009] Capabilities can be useful for defining boundaries that limit the valid use of bounded information. For example, the bounded information may be a pointer, and therefore capabilities can be used to control whether memory can be accessed using the pointer. Capabilities can also be used to police the use of information other than pointers.

[0010] Capabilities can be useful to grant a particular software compartment a permanent right to perform some action, such as accessing a given range of memory addresses. This can be done by providing that software compartment with associated capabilities that define the boundaries within which the corresponding action is permissible. For example, this can be useful to ensure spatial safety in accessing memory.

[0011] However, achieving temporal safety can be more difficult. Sometimes it may be desirable to allow a given software compartment to perform a given action for a limited period of time, after which that same software compartment is no longer allowed to perform that action. For example, a compartment may be given temporary access to a particular address range in memory, but it may be desirable to later remove the right to access that address range. Achieving temporal stability using typical capability schemes is difficult because such schemes generally allow software compartments to copy capabilities between memory and registers or between different regions of memory, making it difficult to revoke access previously granted using a particular capability in an efficient manner. Revoking a previously granted capability may sometimes require scrubbing the entire address space to clear any remaining capabilities that may have been copied by the software compartment, which is an expensive operation in terms of performance.

[0012] In the following example, an apparatus includes a processing circuit that performs data processing in response to an instruction, and a capability storage circuit that stores at least one capability that specifies bounded information and boundary indication information that indicates allowed boundaries of the bounded information. The key capability storage circuit is provided with a key capability storage circuit that stores at least one key capability that specifies key boundary indication information. The key boundary indication information indicates allowed boundaries of information, and information subject to these boundaries is specified by any one or more of: (i) non-capability operands, (ii) capabilities stored in the capability storage circuit, and (iii) the key capability itself. A capability check circuit is provided that determines whether to enable an operation performed by the processing circuit based on a boundary check using the boundary indication information specified in the at least one capability in the capability storage circuit and the key boundary indication information of the at least one key capability stored in the key capability storage circuit.

[0013] Some operations may be checked by the capability check circuitry using only the boundary indication information of the capability, but not the key boundary indication information of the key capability. Other operations may be checked using both boundary indication information and key boundary indication information. In some implementations, it may also be possible to police some operations with key boundary indication information rather than boundary indication information. Thus, in general, the capability check circuitry supports checks using both types of boundary indication information, but need not necessarily use both types on every occasion when bounds checking is performed.

[0014] Some software compartments executed by the processing circuitry may be assigned key capability operating privileges associated with at least a portion of the key capability storage circuitry, while other software compartments may lack that key capability operating privilege.

[0015] If a given software compartment executed by the processing circuit lacks a key capability operation privilege associated with at least a portion of the key capability storage circuit, the processing circuit may prohibit the given software compartment from causing the processing circuit to perform one or both of a first transfer operation that transfers key capabilities from at least a portion of the key capability storage circuit to the capability storage circuit or to a memory location selected by the given software compartment, and a second transfer operation that transfers key capabilities from the capability storage circuit or from a memory location selected by the given software compartment to at least a portion of the key capability storage circuit.

[0016] Thus, a key capability operating privilege assigns the right to control the transfer of key capabilities between the key capability storage circuit and either the memory or the capability storage circuit. By restricting such transfers, this means that key capabilities can be used to assign temporary access to certain pieces of information or to provide temporary rights to perform an action. This can be done by a process with a key capability operating privilege that defines the associated key boundary indication information in the key capability storage circuit.

[0017] Because a software compartment that lacks a key capability operating privilege cannot transfer that key capability to an arbitrarily chosen location in memory or to a capability storage circuit (or alternatively, may be able to transfer the key capability to memory but not subsequently be allowed to later reload the key capability back into the key capability storage circuit), this means that if the rights granted by that key capability are later revoked, the corresponding software compartment is generally guaranteed to no longer be able to perform the associated action, unlike the regular capabilities discussed above, where the capability is simply copied into memory and may be later reloaded. This therefore provides a way to provide temporal stability.

[0018] Note that while a software compartment lacking key capability operating privileges may be prohibited from causing the processing circuit to transfer key capabilities between the key capability storage circuit and memory locations selected by the given software compartment, this does not preclude the given software compartment from allowing the processing circuit to transfer key capabilities between the key capability storage circuit and memory locations not selected by the given software compartment. To provide temporal stability, it is sufficient that key capabilities cannot be transferred to or loaded from arbitrarily selected memory locations selected under the control of the given software compartment. However, sometimes key capabilities may still be able to be transferred to / from locations in memory not selected by a given software compartment lacking key capability operating privileges. For example, in some implementations, the key capability storage circuit may have limited capacity, and therefore, to support a larger number of key capabilities being used by software, key capabilities may sometimes be spilled to memory and then loaded back into the key capability storage circuit. This may be done under hardware control, or under the control of a software compartment with key capability operating privileges. If under hardware control, an operation performed by a software compartment lacking key capability operating privileges may cause the hardware to save or load key capabilities to memory, in which case the location where the key capabilities are saved or loaded may not be selected by a given software compartment, but instead may be fixed or variable under the control of a more privileged software compartment.This means that even in implementations that support such spilling and filling of key capabilities, even if a small number of memory locations to which key capabilities can be spilled are scrubbed when revoking a key capability, this may be a relatively small area of ​​memory known to a higher privileged software compartment, and therefore it may be more efficient to ensure temporal safety because it does not require scrubbing the entire address space to protect the software compartment without causing the key operation privilege to save key capabilities to unknown locations in memory.

[0019] Also, it is not necessary that transfer of key capabilities between any location in memory and key capability storage be restricted in both directions to software compartments that do not have key capability operation privileges. Some implementations may prohibit storing key capabilities from key capability storage to any location in memory, but may allow loading of key capabilities from any location in memory to key capability storage. Other implementations may be the opposite, prohibiting software compartments that do not have key capability operation privileges from loading key capabilities, but allowing them to store key capabilities. Other implementations may prevent that software compartment from both loading and storing key capabilities.

[0020] In some implementations, key capabilities can be referenced independently of any capabilities stored in the capability storage circuit, such that at times a capability check may consider the key boundary indication information without considering the boundary indication information of the capabilities stored in the capability storage circuit. For example, some implementations may allow the key capability to provide the bounding information itself, such that the information checked using the bounds indicated by the key boundary indication information may be information provided by the key capability itself.

[0021] However, in at least one operating mode of the processing circuit, in response to an operation executed by the processing circuit with reference to a given capability stored in the capability storage circuit (which may be a general-purpose capability, or may be a program counter capability or a default capability as discussed in examples below), the capability check circuit may perform a joint capability bounds check to check whether a non-capability operand or the bounding information of the given capability satisfies both the allowed bounds indicated by the bounds indication information of the given capability and the allowed bounds indicated by the key bounds indication information of at least one key capability stored in the key capability storage circuit. Note that if the given capability is a default capability, as described below, the given capability is used to check whether a non-capability operand satisfies the allowed bounds indicated by the bounds indication information of the given capability.

[0022] Thus, in some cases, key capabilities may provide additional permissions that apply in combination with any permissions or boundaries enforced by the capabilities in the capability storage circuit. While key capabilities may provide an additional layer of permission / boundary control that can be used to temporarily assign access rights within the scope of other capabilities, in some cases an action may not be permitted to be performed if the action is not also permitted based on regular capability checks using the capabilities in the capability storage circuit. Thus, in some cases, a requested operation may be permitted if it satisfies both the bounds checks performed based on the capabilities in the capability storage circuit and the key bounds checks performed based on the key boundary indication information of the key capabilities stored in the key capability storage circuit.

[0023] In at least one mode of operation, in response to the processing circuit requesting memory access to a target address, the capability check circuit may determine that the memory access is not permitted when the key capability storage circuit does not store a valid key capability where the target address is within the allowed boundaries indicated by the key boundary indication information. Thus, in this case, successful access to memory may depend on the presence of a valid key capability defined in the key capability storage circuit that permits the access.

[0024] As described below, some implementations may also support the concept of key capabilities being active or inactive (orthogonal to being valid or invalid), in which case inactive key capabilities may not be used to allow memory access to be permitted, in addition to invalid key capabilities not being able to permit access. In such embodiments, memory access may not be permitted when there are no active and valid key capabilities stored in the key capability storage circuitry that indicate allowed boundaries that include the target address.

[0025] In any event, this can be useful in providing temporal safety guarantees by providing a mode in which it is a requirement that a valid key capability with bounds defining a range that includes the target address be present in order to allow memory access to the target address.

[0026] Note that in some implementations, the processing circuit may also have at least one other mode in which memory access is permitted even if there is no valid key capability in the key capability storage circuit, e.g., this may be a mode in which no capability check is required at all.

[0027] The key capability operating privilege not only restricts the ability to transfer key capabilities to or from the key capability storage circuitry, but may also provide the right to create new key capabilities. Thus, the processing circuitry may prohibit a given software compartment that lacks the key capability operating privilege from creating new capabilities.

[0028] The processing circuit may support one or more key capability manipulation instructions for manipulating key capabilities stored in the key capability storage circuit. Such manipulations may include creating new key capabilities, modifying existing key capabilities (e.g., to change permissions or boundaries indicated by the key capabilities), or loading or storing key capabilities for transfer between the key capability storage circuit and selected locations in memory selected by a software compartment having key capability operating privileges. The processing circuit may signal a fault in response to an attempt by a software compartment lacking key capability operating privileges for a given portion of the key capability storage circuit to execute a key capability manipulation instruction for manipulating a key capability stored in a given portion of the key capability storage circuit.

[0029] In some cases, the processing circuit may also support capability manipulation instructions for manipulating capabilities stored in the capability storage circuit. Key capability manipulation instructions may have different instruction encodings than capability manipulation instructions (e.g., key capability manipulation instructions may have different opcodes than capability manipulation instructions, or a field within the instruction may specify whether the instruction is for manipulating key capabilities or regular capabilities). Thus, some software compartments that may be enabled to execute capability manipulation instructions may nevertheless not be enabled to execute key capability manipulation instructions.

[0030] There are several ways to control which software compartments are assigned key capability operating privileges. In one example, a processing circuit may execute a software compartment in one of a running state and a restricted state. A software compartment executing in the running state may be considered to have key capability operating privileges, and a software compartment executing in the restricted state may lack key capability operating privileges. Whether a software compartment executes in the running state or the restricted state may be determined independently of one or more other privilege states assigned to the software compartment. For example, the running state and the restricted state may be orthogonal to exception states that control the privilege of access to certain registers (other than the key capability storage circuitry).

[0031] In another example, the range information may be used to define at least one range of instruction addresses associated with a key capability operating privilege. In this case, when executing instructions from a given software compartment, if those instructions have instruction addresses within a range defined as having a key capability operating privilege, that portion of the software compartment is determined to have the key capability operating privilege and therefore can execute key manipulation instructions that may allow triggering transfer of key capabilities between the key capability storage and the capability storage or memory. Other software compartments executing instructions that are not within the range defined by the key capability privilege range information may not be allowed to manipulate key capabilities because they lack the key capability operating privilege.

[0032] In some implementations, key capability operating privileges may be assigned in a uniform manner across the capacity of the key capability storage circuitry, where a software compartment is either permitted to manipulate key capabilities across the entire key capability storage circuitry or to lack key capability operating privileges such that it cannot manipulate key capabilities.

[0033] However, it is also possible to configure the processing circuit to control the assignment of key capability operating privileges separately for different portions of the key capability storage circuit. In this case, a software compartment may have key capability operating privileges for one portion of the key capability storage circuit but lack key capability operating privileges for another portion of the key capability storage circuit. For example, this may be done by providing separate indications of address ranges that have been assigned key capability operating privileges for different portions of the key capability storage circuit, or by having several orthogonal execution state indications / restriction state indications that correspond to different portions of the key capability storage circuit. By assigning separate key capability operating privileges for different portions of the key capability storage circuit, this can support the coexistence of several different control software compartments that may wish to assign different key capabilities without manipulating each other's key capabilities.

[0034] In some examples, key capabilities may be distinguished from regular capabilities in that they are identified as capabilities of the key capability type. For example, there may be a capability type identifier that may have a value that identifies the capability as a key capability (at least, the capability type identifier may be stored with the key capability when it is stored in memory). In some implementations, key capabilities may have the same format as regular capabilities, except for being distinguished as a key capability type. In other examples, a different format or encoding may be used for key capability types compared to regular capabilities. By assigning a specific key capability type, this means that when a capability or key capability is written out to memory (in the case of a key capability, under the control of a software compartment that has key capability operating privileges), the key capability type may indicate that the capability should not subsequently be transferred back to key capability storage, for example, by a software compartment that lacks key capability operating privileges. Thus, in response to execution by the processing circuit of an instruction requesting the transfer of a target capability from memory to the capability storage circuit, the processing circuit may determine whether the target capability is a key capability type capability, and if so, deny the transfer.

[0035] In other examples, it may not be necessary to assign capabilities of a particular key capability type; for example, the rights available to operate on a key capability compared to a regular capability may instead be controlled based on what types of instructions it allows to execute for a particular software compartment depending on whether it has the key capability operating privilege. Nevertheless, defining key capability types may more simply ensure that capabilities stored in memory are not inadvertently copied to capability storage circuitry and act as potentially undesirable regular capabilities.

[0036] In some cases, key capabilities may be defined in the same format as regular capabilities, but it may be useful to allow key capabilities to have a different capability format than the capabilities stored in the capability storage circuit. For example, key capabilities may not need to specify any bounding information, such as the mode in which a key capability boundary is applied in combination with a capability boundary, and the information checked using the key capability boundary may be stored in a non-capability operand or capability rather than in the key capability itself. Also, key capabilities may express their boundaries in a format different from the boundaries of the capability registers. For example, key boundary information may be expressed in a less compressed format than the boundary information of regular capabilities, which may be useful to enable faster checking of the key boundary information. Also, the range of different types of permissions that may be indicated in a key capability may differ from the range of permissions available to regular capabilities.

[0037] In some examples, in at least one operating mode of the processing circuit, the capability check circuit determines, for an operation performed by the processing circuit using a non-capability operand or a given capability, whether the confidential / shared information indicates that the non-capability operand or the given capability is confidential or shared; when the non-capability operand or the given capability is shared, the capability check circuit determines whether the operation is permitted based on whether the bounding information of the non-capability operand or the given capability satisfies the key boundary indication information of at least one key capability stored in the key capability storage circuit; and when the non-capability operand or the given capability is confidential, the capability check circuit determines whether the operation is permitted regardless of whether the bounding information of the non-capability operand or the given capability satisfies the key boundary indication information of at least one key capability stored in the key capability storage circuit.

[0038] By providing the ability to mark a non-capability operand or capability as confidential to indicate that it is not shared with other compartments and therefore does not need to be subject to key bounds checking, this can reduce the overhead of implementing key capability checks. When a confidential capability is used within a compartment that owns the associated address range, checking against key bounds may be redundant and therefore can be avoided to save power. There may be various ways to mark a particular non-capability operand or capability operand as shared or confidential. For example, confidential / shared information may be a field associated with a register that provides a non-capability operand or a given capability, which indicates whether the non-capability operand or a given capability is confidential or shared. Alternatively, confidential / shared range information may be provided to define a range of addresses within which operand values ​​are considered confidential or shared.

[0039] The processing circuit may convert a capability from secret to shared upon the occurrence of one of the following events: when the capability becomes accessible to a software compartment that did not previously have access to the capability; when the capability is loaded from memory to the capability storage circuitry under control of a shared capability; or when the capability is stored from the capability storage circuitry to memory under control of a shared capability. Enforcement of the conversion of a capability from secret to shared may, in some cases, be implemented in software, but may be stronger if hardware in the processing circuit enforces the requirement that a capability be made shared when shared with another software compartment or when transferred between the capability storage circuitry and memory under control of a shared capability. Hardware enforcement of the requirement that a capability be made shared when made accessible to a software compartment may be implemented by prohibiting the storage of secret capabilities in memory when referenced via a shared capability, which may then impose a requirement that secret capabilities must be made shared before software can write to memory. Alternatively, software may simply request the transfer or loading of capabilities to or from memory, and if this is done under the control of a shared capability, the processing circuitry, constrained by hardware circuit logic, may automatically convert secret / shared information to indicate a shared capability. This approach ensures that capabilities that have become accessible to more than one software compartment do not continue to be considered secret in order to avoid circumventing key bounds checking.

[0040] In some examples, the capability check circuit may have access to key capability active status information indicating which portions of the key capability storage circuit are active or inactive. The capability check circuit may determine whether an operation subject to a key capability check is permitted based on one or more key capabilities stored in an active portion of the key capability storage circuit, regardless of one or more key capabilities stored in an inactive portion of the key capability storage circuit. By providing the ability to mark a particular portion of the key capability storage circuit as inactive, this means that a particular key capability can be temporarily marked as unused for key capability checks without having to completely disable the key capability. This may be useful, for example, when there is a key capability that must be accessible to a calling software compartment but does not need to be accessible to a callee compartment called in a function call by the calling compartment. In that case, it may be preferable to disable the permissions indicated by a particular key capability for a period of time and re-enable them later. Disabling a key capability before invoking a compartment, and then re-establishing the same key capability upon returning from the callee compartment, can be a slow operation. By providing the ability for a key capability to remain enabled despite being designated as inactive, this means that upon returning from the callee compartment, the associated key capability can simply be re-activated, avoiding the need to recreate the key capability. This improves performance.

[0041] The key capability active status information may indicate active or inactive portions in different ways. In one example, the key capability active status information may be a set of active / inactive flags associated with each portion of the key capability storage circuit, each flag indicating whether the corresponding portion is active or inactive. However, in some examples, it may not be necessary to individually set each portion of the key capability storage circuit as active or inactive, and it may be sufficient to provide boundary information indicating the boundary between at least one active portion on one side of the boundary and at least one inactive portion of the key capability storage circuit on the other side of the boundary. For example, the boundary information may indicate a register number or an address that marks the location of the boundary between active and inactive key capabilities.

[0042] In some examples, for an operation subject to a key capability check performed with reference to a given non-capability operand or a given capability, the capability check circuitry may determine whether a key capability check is required based on a key capability check success indicator associated with the given non-capability operand or the given capability. The key capability check success indicator indicates whether a key capability check for the given non-capability operand or the given capability was previously determined to be successful. It may be relatively common to need to check the same key capability on multiple occasions for several accesses using the same pointer, or for repeated use of other types of information whose usage is policed ​​based on key boundary information. By providing a key capability check success indicator that records whether a key capability check was previously determined to be successful, this avoids the overhead of repeating the key capability check again in the future and saves power.

[0043] At least one of the processing circuit and the capability check circuit may clear or recalculate the key capability check success indicator in response to an update to a given non-capability operand, a given capability, or a key capability. Thus, when an operand, capability, or key capability is updated, a previous key capability check may no longer be valid, and therefore the key capability check success indicator may be cleared to ensure that subsequent uses of the non-capability operand or capability undergo a key capability check. There may also be other scenarios in which the key capability check success indicator is cleared or recalculated. For example, this may be triggered by execution of a dedicated software instruction having encoding assigned to represent an explicit request to recalculate or clear the key capability check success indicator. Also, when a software compartment with key capability operating privileges updates a key capability in the key capability storage circuit, any previous key capability check may no longer be valid, and therefore the key capability check success indicator may be cleared or recalculated.

[0044] In some cases, execution of an instruction to clear or recalculate a key capability check success indicator as well as an update to the key capability storage may trigger the clearing or recalculation of key capability check success indicators associated with more than one non-capability operand or capability. For example, several registers for providing non-capability operands or capabilities may include key capability check success fields, and these fields may all be cleared when a software instruction to request the clearing or recalculation of the key capability check success indicator is executed or when the key capability storage circuitry is updated.

[0045] In one example, the processing circuit or capability check circuit sets valid boundary information associated with a given non-capability operand or a given capability to indicate a valid boundary corresponding to an intersection between the allowed boundaries indicated by the key boundary indication information specified by at least one key capability and the allowed boundaries indicated by the default boundary indication information associated with the boundary indication information specified by the given non-capability operand or the given capability, and in response to an operation subject to a key capability check being performed with reference to the given non-capability operand or the given capability, the capability check circuit performs a bounds check with reference to the valid boundary information associated with the given non-capability operand or the given capability. This approach can enable explicit key capability checks to be omitted for subsequent operations using the given non-capability operand or the given capability, so that these operations can be checked based on the valid boundary information without having to re-read the key capability storage to identify the key boundary information. Again, the effective boundary information may be cleared in response to events such as the disabling or manipulation of any key capability, or an update to the default boundary indication information or to the boundary indication information used to set the effective boundary information. An indicator associated with a given non-capability operand or a given capability may indicate whether the effective boundary information is valid (in some cases, this may be the same indicator that also serves as the key capability check success indicator described above).When effective boundary information is associated with a given non-capability operand, it is possible to specify different effective boundary information for different non-capability operands, but some implementations may specify the effective boundary information for a non-capability operand as a shared field associated with a default capability that specifies default boundary indication information to use when checking the non-capability operand, and therefore it is not required that different general-purpose registers for storing non-capability operands each have a separate field for specifying effective boundary information.

[0046] Key capability storage can be implemented in different ways. In some examples, the key capability storage circuitry may comprise at least one key capability register. The at least one key capability register may be an architecturally visible register. When key capability storage is implemented using architecturally visible registers (which can be explicitly read or written by software with key capability operating privileges), it is also possible to support spilling and filling of key capabilities between the key capability registers and memory to address the fact that software may want to define more key capabilities than can be supported within the available register capacity. Spilling and filling may be performed either implicitly by an arbiter or kernel in software, or automatically by hardware circuit logic that automatically transfers key capabilities to or from a memory area dedicated for this purpose. A memory area may be allocated for each thread of execution (by a software compartment with key capability operating privileges) to provide a location to which key capabilities may be spilled when they need to be evicted from the key capability registers.

[0047] The key capability storage circuit may also comprise at least one region of memory designated as a key capability storage area. In this case, providing an architecturally visible key capability register may not be required. From an architectural perspective, software with key capability operating privileges sets key capabilities by writing to a designated key capability storage area in memory. However, some microarchitecture implementations may choose to implement architecturally hidden registers (invisible to software) to act as a cache for caching information from the key capability storage area, which may help improve performance by reducing latency in accessing associated key capability information. Nevertheless, in implementations where an architecturally visible view of the key capability storage circuit exists as a region in memory, this may be useful to allow some implementations to save circuit area by not implementing a register designated for key capability storage.

[0048] Other implementations may use a combination of key capability registers and regions of memory. For example, from a software-visible architecture perspective, there may be several key capability registers available and a region of memory designated to handle additional key capabilities that do not fit into the key capability registers.

[0049] As mentioned above, a software compartment that lacks key capability operation privileges may not be allowed to perform one or both of the first and second transfer operations discussed above, and therefore may not be allowed to transfer key capabilities between the key capability storage circuit and the capability storage circuit, or between the key capability storage circuit and a memory location selected by the given software compartment.

[0050] In contrast, if regular capabilities are stored in the capability storage circuitry, a software compartment lacking key capability operating privileges may still be enabled to cause the processing circuitry to transfer regular (non-key) capabilities between the capability storage circuitry and any arbitrarily selected memory locations selected by the given software compartment. For example, if desired, a given software compartment lacking key capability operating privileges may be allowed to freely load or store regular capabilities (subject to any memory protection requirements and any other constraints regarding whether it is permitted to access associated regions of memory as determined based on any regular capability checks and key capability checks). Assuming any other checks pass, it may be possible for a given software compartment lacking key capability operating privileges to cause regular capabilities to be transferred. In contrast, the ability to transfer key capabilities is more restricted to provide temporal stability as discussed above.

[0051] The bounds information for a given capability may include any information whose use is controlled. However, it is particularly useful for the bounds information to include pointers that can be used to indicate addresses in memory. The bounds information can define allowable boundaries for the pointer's address value. Some implementations may allow the pointer field to be used to carry other information as well. For example, a sealed capability may be a type of capability identified as having a sealing permission that grants permission to use the sealed capability to seal other capabilities. The pointer field of a sealed capability may define an object type identifier that applies to the sealed capability, and the bounds information for the sealed capability may indicate a range of object type values ​​that can be specified as object type identifiers by the sealed capability. This may be useful to allow the sealed capability to act as a token indicating permission to perform an action (not necessarily an action that requires access to memory), with the object type identifier of the sealed capability distinguishing the token from other tokens represented by the sealed capability. Thus, while bounded information may often include pointers, it will be appreciated that other uses of capabilities are possible that provide bounded information and protect its use by defining associated boundaries within the capability.

[0052] A capability may also specify one or more permission type indicators that indicate one or more types of operations for which permission may be granted using the capability. For example, the permission type indicator may indicate whether it may be determined based on the capability that data can be read from memory, whether it may be determined based on the capability that data can be written to memory, or whether the capability may grant permission to seal other capabilities as discussed above.

[0053] Similarly, a key capability may also specify at least one permission type indicator that indicates one or more types of operations for which permission may be granted using the key capability. The range of permission types indicated in a key capability may be the same as or different from the range of permission types indicated for a regular capability.

[0054] The techniques discussed above can be implemented in a hardware device having circuit hardware that implements the processing circuitry, capability storage circuitry, key capability storage circuitry, and capability check circuitry discussed above.

[0055] However, in another example, the same technique may be implemented in a computer program (e.g., an architecture simulator or model) that may be provided to control a host data processing apparatus to provide an instruction execution environment for executing instructions from the target code. The computer program may include instruction decode program logic for decoding instructions of the target code to control the host data processing apparatus to perform data processing. The instruction decode program logic emulates the functionality of an instruction decoder of the hardware apparatus as discussed above, thereby enabling the host data processing apparatus to execute the target code with results equivalent to those obtained when the target code was executed on the processing circuitry of the hardware apparatus. The program may also include storage emulation program logic for maintaining, in host storage circuitry (e.g., registers and / or memory) of the host apparatus, capability storage structures and key capability storage structures that emulate the capability storage circuitry and key capability storage circuitry, respectively, as described above. The computer program also includes capability check program logic that performs functions in software similar to the operations performed by the capability check circuitry discussed above.

[0056] Thus, such a simulator computer program may present to target code running on the simulator computer program an instruction environment similar to that provided by an actual hardware device, even if the host computer running the simulator computer program does not have any actual hardware to provide these features. This may be useful for running code written for one instruction set architecture on a host platform that does not actually support that architecture. Simulators may also be useful during the development of software for new versions of an instruction set architecture, as this means that software development can occur in parallel with the development of hardware devices that support the new architecture. This allows software to be developed and tested on the simulator, allowing software development to begin before the hardware devices that support the new architecture are ready.

[0057] FIG. 1 illustrates a schematic diagram of an example data processing device 2. The data processing device has a processing pipeline 4 that includes several pipeline stages. In this example, the pipeline stages include a fetch stage 6 for fetching instructions from an instruction cache 8; a decode stage 10 for decoding the fetched program instructions to generate micro-operations that are processed by the remaining stages of the pipeline; an issue stage 12 for checking whether operands required for the micro-operation are available in a register file 14 and for issuing the micro-operation for execution once the operands required for a given micro-operation are available; an execute stage 16 for performing a data processing operation corresponding to the micro-operation by processing operands read from the register file 14 to generate a result value; and a writeback stage 18 for writing the results of the operation back to the register file 14. It will be appreciated that this is only one example of a possible pipeline architecture, and other systems may have additional or different configurations of stages. For example, an out-of-order processor may include a register rename stage for mapping architectural registers specified by a program instruction or micro-operation to physical register specifiers that identify physical registers in the register file 14.

[0058] The execution stage 16 includes several processing units for performing different classes of processing operations. For example, the execution units may include a scalar arithmetic / logic unit (ALU) 20 for performing arithmetic or logical operations on scalar operands read from the registers 14, a floating-point unit 22 for performing operations on floating-point values, a branch unit 24 for evaluating the results of branch operations and adjusting a program counter representing the current execution point accordingly, and a load / store unit 26 for performing load / store operations to access data in the memory systems 8, 30, 32, 34. A memory management unit (MMU) 28 is provided for performing address translation between a virtual address specified by the load / store unit 26 based on the operands of a data access instruction and a physical address that identifies the storage location of the data in the memory systems. The MMU has a translation lookaside buffer (TLB) 29 for caching address translation data from page tables stored in the memory system, whose page table entries define address translation mappings and may also specify access permissions that govern whether a given process executing on the pipeline is allowed to read, write, or execute instructions from a given memory region. The access permissions specified in the page tables accessed by the MMU 28 may be relatively coarse-grained in that they may specify permissions for a particular memory region that apply to an entire software process as a whole, making it inefficient to use page tables to provide different levels of access permissions for different sub-portions of instructions within a software process.

[0059] In this example, the memory system includes a level 1 data cache 30, a level 1 instruction cache 8, a shared level 2 cache 32, and a main system memory 34. It will be understood that this is only one example of a possible memory hierarchy and that other arrangements of caches may be provided. The particular types of processing units 20-26 shown in the execution stage 16 are merely exemplary; other implementations may have different sets of processing units or may include multiple instances of the same type of processing unit such that multiple micro-operations of the same type can be processed in parallel. It will be understood that FIG. 1 is only a simplified representation of some components of a possible processor pipeline architecture and that a processor may include many other elements that are not shown for the sake of brevity.

[0060] Figures 1 and 2 show some examples of registers 14 of processing unit 2. It will be understood that Figures 1 and 2 do not show all of the registers that may be provided, and that there may be additional registers.

[0061] As shown in FIG. 1 , the registers 14 may include a set of general-purpose integer registers 50 for storing integer operands and results of processing operations performed in response to integer processing instructions, and a set of floating-point registers 52 for storing floating-point operands or results. Some implementations may not support floating-point operations, in which case the floating-point registers may be omitted. The registers also include several control registers 54 that define various control parameters that may control the processing of instructions by the processing pipeline. For example, the control registers 54 may include a mode indicator value that specifies the current operating mode of the system, a control register for defining whether certain optional architectural features are implemented, and condition status flags that are set in response to the results of processing operations and that may be tested by conditional instructions to determine whether a conditional operation should be performed.

[0062] Although a variety of information is stored in the control registers 54, one particular item of control state may be a capability / non-capability mode indication 56 that specifies whether the processing pipeline is currently operating in capability mode or non-capability mode. Capability mode is supported by several architectural features that allow accesses to memory (either for data accesses in response to load / store instructions or instruction accesses initiated by the fetch stage 6) to be subject to additional security checks based on constraints specified in association with the pointer used to access memory.

[0063] When in capability mode, the processing pipeline has access to a set of capability registers 60 (shown in more detail in FIG. 2 ) that store capabilities, including pointers 62 that can be used to form addresses for data or instruction memory accesses, and a set of associated constraint metadata 64 that limit the permitted valid uses of the pointers 62. The capability registers 60 include a set of general-purpose capability registers 66 that can be generally referenced by instructions processed by the pipeline in capability mode, acting as either source or destination registers for processing operations. The capability registers 60 also include several dedicated capability registers, including a program counter capability (PCC) register 68 and a default data capability (DDC) register 70. The PCC register 68 provides in its pointer field a program counter value 72 that represents the instruction address of the current execution point reached by the pipeline in capability mode. The associated constraint metadata 64 can be used to check whether an instruction fetch from an address derived from the program counter is allowed to proceed (or whether updates to the PCC 68 are permitted following a branch or other program flow altering operation). The DDC register 70 defines constraint metadata 64 that can be imposed on memory accesses performed in response to non-capability memory access instructions that do not directly identify that a capability should be used, but rather reference integer register 50 to form its address operand. This can be useful to allow legacy code written for systems that did not support capability modes to have memory accesses triggered by the legacy code protected by the provided capability mechanism.

[0064] For each capability in a respective capability register 60, constraint metadata 64 may specify boundary information 74 and permissions 76. As shown in Figure 1, capability checking circuitry 80 is provided to check the capability's boundary information 74 and permissions 76 to determine whether associated actions performed with reference to the capability should be allowed or denied.

[0065] Bounds information 74 defines the allowable range for bounds checking of pointer 62 in the corresponding capability. Bounds information 74 may specify a base address that defines the lower boundary of the allowable range of pointer 62 and an upper address that specifies the upper boundary of the allowable range of pointer 62. In some implementations, bounds information 74 may be compressed, so that rather than explicitly identifying the base and upper addresses as full addresses having the same number of bits as the pointer itself, bounds 74 may be stored in an encoded form that requires fewer bits. For example, each of the upper and lower bounds may be represented in a floating-point-like format using a bound value that indicates the significant bits of the upper or lower bound address and an exponent that indicates the number of bits by which the bound value should be shifted to give the actual lower / upper bound address (both the upper and lower bounds may share the same exponent value). While this may reduce the precision available for defining the tolerance range, by compressing the bounds information, this significantly reduces the storage overhead of the capability register; otherwise, storing the upper and lower bound addresses in full address format, in addition to the pointer itself, could lead to a capability register that is at least three times the size of the integer register that stores the address. An example of an encoding scheme that can be used for the bounds information is described in Woodruff et al., "CHERI Concentrate: Practical Compressed Capabilities," IEEE Transactions on Computers 68.10 (2019): 1455-1469. However, it will be understood that other encoding techniques may also be used.

[0066] The permissions 76 for a given capability define whether one or more types of access rights are granted for use of the corresponding pointer 62. For example, the permissions may indicate whether read permission is granted, providing permission to use the capability's pointer to control read (load) data accesses, whether write permission is granted, providing permission to use the capability's pointer to control write (store) data accesses, and whether execute permission is granted, providing permission to use the capability's pointer 62 to determine branch target addresses or to control the fetching of instructions for execution. In one example, a separate permission flag may indicate whether each type of permission is granted or prohibited. Alternatively, a combined encoding of the permission field 76 may be provided that selects one of several permission states, each permission state corresponding to a different combination of whether read permission is granted, write permission is granted, and / or execute permission is granted. Therefore, it is not necessary to provide a separate flag for each type of permission; instead, a common state value can indicate which combinations of permissions are or are not enabled for use of the corresponding pointer 62.

[0067] Thus, by defining constraint metadata 64 associated with a given pointer 62, an attempt to fetch an instruction from a defined address using the pointer or to perform a data access based on an address derived from a specified capability register can be checked by capability check circuit 80 against the corresponding constraint metadata 64 to check whether the memory access is permitted. If bounds 74 are stored in compressed form, such a check may require the stored bounds value to be uncompressed to permit comparison of pointer 62 with bounds 74. Thus, if there is an attempt to perform an instruction fetch based on PCC 68 but the program counter value is outside the valid bounds 74 specified by the PCC, or if permissions 76 indicate that there is no execution permission for use of that program counter value, a fault may be triggered. Also, when a load / store instruction is executed that specifies its address using a reference to a particular capability register, then a fault may be generated if the instruction is a load instruction and there is no read permission indicated by permission 76, or if the instruction is a store instruction and there is no write permission, and a fault may also be generated if pointer 62 (or the address calculated for the pointer) is outside the valid bounds 74 of the capability.

[0068] Unlike the definition of access permissions in the MMU 28, which are typically coarsely defined per process, the use of capabilities allows for finer-grained control over memory accesses, because a program instruction specifying a particular capability register provides an indication of the instruction's intent, in the sense that it is intended to access a limited region of memory within certain boundaries and certain limits, as to what use of that region is permitted. Different instructions in different portions of program code for a given software process can specify different capability registers and thus be subject to different sets of permissions without having to separate that portion of code into different software processes (as might be required if different levels of access control were controlled using only the MMU 28). This capability approach makes it much simpler to partition access rights for different sandboxed components within a software process. This can improve security and help avoid attackers being able to exploit usage errors associated with certain memory that might otherwise allow them to access data that should not be accessible.

[0069] Similar to checking capability permissions or limits when accessing memory, it is also possible for certain instructions to check capability constraint metadata at other times. For example, some instructions that set a pointer 62 of a given capability register may trigger a check that the pointer is within the corresponding bounds 74, although this is not required (as this check when setting the pointer may be redundant if a check is subsequently performed when the pointer is used to control memory access).

[0070] The device may have a mechanism for checking whether a capability has been validly constructed. For example, although not shown in FIG. 2, a validly created capability, at least when stored in memory, may specify a tag value that distinguishes that the data stored in that memory location represents a capability rather than non-capability data. When a capability is stored in capability register 60, its tag may also be stored in register 60. The tag value may be set when a valid capability is created.

[0071] It will be appreciated that Figures 1 and 2 show architectural diagrams of registers available for access by instructions processed by pipeline 4. However, the physical registers implemented in hardware to provide the data values ​​associated with these architectural registers may differ from the layout shown in Figure 2. For example, in an out-of-order processor, register file 14 may have a larger number of physical registers than the number of architectural registers specified in a given one of integer register set 50, capability register set 60, or floating-point register set 52, and register renaming may be used to map architectural register specifiers to the physical registers provided in hardware.

[0072] Also, although the capability registers 60 are illustrated as being separate from the integer registers 50 from an architectural perspective, in some hardware implementations, the pointer fields 62 of some of the capability registers 60 may actually share the same hardware storage elements with the corresponding integer registers 50. For example, the program counter pointer field 72 of the PCC register 68 in capability mode may be reused in non-capability mode to provide the integer program counter, which indicates the address of the instruction representing the current execution point reached in non-capability mode. During non-capability mode, the constraint fields 74, 76 of the PCC 68 can be ignored. Similarly, the general-purpose capability registers 60 may be overlapped with the general-purpose registers 50.

[0073] While a common use of capabilities is to impose boundaries or permissions to constrain the valid use of pointers, capabilities can also be used for other purposes. For example, some capabilities may be “sealed” capabilities that include an object type field (not shown in FIG. 2 ) that stores a data value representing a token that grants permission to perform some action. Permission may be granted to a given software compartment by making accessible to that software compartment an associated capability with the object type field set to the token value. To support such use cases, various permission bits 76 may include a permission indicator that indicates whether a capability can act as a sealed capability, which is permitted to seal other capabilities. Capabilities may be provided with a status indicator (not shown in FIG. 2 ) that indicates whether they are unsealed capabilities (the capability's parameters are allowed to be updated) or sealed capabilities (the capability's parameters are constrained to retain their current values ​​and cannot be used directly (dereferenced)). A capability seal can protect the token represented in the object type field from modification. A sealing capability that grants permission to seal other capabilities can specify in its pointer field 62 the value of a token that is written to the object type field in a target capability that is being sealed by a sealing operation controlled using the sealing capability, and the boundary 74 of the sealing capability can constrain the range of possible token values ​​for capabilities sealed using that sealing capability.When a seal operation (which may be triggered by a capability seal instruction) is performed, the capability check circuitry checks whether the software compartment requesting the seal operation referenced a valid seal capability with permission indicator 76 set to indicate permission to seal other capabilities, and if so, may check whether the value in pointer field 62 of the seal capability is within the bounds specified in bounds field 74; if both conditions are met, the value in pointer field 62 of the seal capability may be written to the object type field of the target capability to be sealed, and the target capability may have its seal status updated to indicate a sealed capability that prevents subsequent modification of pointer field 62. Capability load / store instructions can be used to transfer capabilities between capability registers 60 and memory 34, so that the sealed capability, acting as a token, can be freely written to regions of address space accessible to the software compartment to which the token is passed, thereby granting that software compartment permission to perform the action represented by the token by referencing that token.

[0074] Thus, although the subsequent discussion of capabilities refers to pointers, it will be understood that it is not necessary that the pointer field 62 be used only to indicate an address pointer, as a sealed capability may reuse the pointer field 62, for example, to represent a token value that applies to the capability being sealed.

[0075] A processing circuit may have mechanisms for ensuring that the information defined in capabilities cannot be forged. For example, there may be architectural rules that ensure that the use of capabilities ensures that valid capabilities can only be constructed by instructions that explicitly construct them from other capabilities (e.g., not by error or by byte manipulation), and that when an instruction constructs a new capability, the capability cannot exceed the permissions and boundaries of the capability from which it is derived (except in certain specific circumstances, such as manipulating sealed capabilities and raising exceptions). More information on such architectural rules can be found in Watson et al., "An Introduction to CHERI" (September 2019, UNAM-CL-TR-941, Section 2.3).

[0076] The processing circuitry may execute various software processes. Different processes may be assigned different address translation contexts associated with respective sets of page tables, such that one process may have a different set of page table entries used to control accesses to memory by MMU 28 compared to another process. However, different parts of the same process generally share the same set of page tables, and therefore the page tables used by MMU 28 may be inefficient at compartmentalizing processes and enforcing spatial safety by dividing them into multiple compartments that may possibly have different access rights and potentially distrust each other. For example, an internet browser may have several separate browser tabs, and it may be desirable for different tabs to operate as separate software compartments that may have different access rights to memory and may not trust each other. The capabilities provided by capability registers 60 may be useful in providing this spatial separation between compartments, as one compartment may have access to capabilities that are not accessible to another compartment.

[0077] Compartments may need to communicate with each other, for example, through synchronous or asynchronous requests. As part of the communication, a compartment may need to temporarily share a portion of memory to which it has access with another compartment. For example, while it is relatively easy to grant another compartment permanent access to an address range by granting permanent access to a capability that temporarily shares the address range, temporarily sharing an address range is an unsolved problem. This is because once a compartment is granted a capability, it can store the capability from capability register 60 in an arbitrarily chosen location in memory selected by the compartment, from which it can later load the capability back into capability register 60. Thus, a calling compartment wishing to temporarily grant access to a range in memory can ensure that the other compartment can no longer access memory using the revoked capability by clearing the capability from capability register 60 or from its controlled location in memory. One option would be to scrub the entire address space to check whether it stores any copies of the revoked capability, but this would be highly inefficient in terms of processing time and could significantly delay other operations. Therefore, it would be useful to provide a non-probabilistic mechanism for achieving temporal safety while sharing memory regions between compartments.

[0078] 1 and 2, device 2 may have a key capability storage circuit 90 for storing capabilities. In the examples of Figures 1 and 2, key capability storage is implemented as an additional register provided in addition to capability registers 60. However, other examples may implement key capability storage 90 as a region within memory 34 rather than as an architecturally visible register.

[0079] The key capability storage circuit 90 can store one or more key capabilities similar to the capabilities in the capability registers 60 in that the key capabilities specify key boundary information 94 and key permissions 96 similar to the capability boundary information 74 and permissions 76 in the capability registers 60. The key boundaries and key permissions 96 can be used as checks on operations performed by the processing circuit, similar to how capabilities can be used to constrain operations performed by the processing circuit. The key capability checks performed by the capability check circuit 80 based on the boundaries and permissions 74, 76 defined in the key capability storage 90 can be combined with regular capability checks using the boundaries 74 in the capability registers 60, such that, in at least one operating mode, an operation requested by the processing circuit can be permitted only if it satisfies both the checks based on the key boundaries 94 and the capability boundaries 74.

[0080] However, interaction with the key capability storage 90 and the creation and transfer of key capabilities between the key capability storage 90 and the capability registers 60 or memory 34 may be more limited compared to the ability to create capabilities in the capability registers 60 or transfer regular capabilities between the capability registers 60 and memory 34. A software compartment may be assigned a key capability operating privilege associated with at least a portion of the key capability storage circuitry 90. In some examples, key capability operating privileges may be assigned to a software compartment as a whole with respect to the entire capacity of the key capability storage 90, while in other examples, it may be possible to designate separate key capability operating privileges for different portions of the key capability storage. A software compartment lacking a key capability operating privilege may not be enabled to create new key capabilities. Also, a software compartment lacking a key capability operating privilege may not be enabled to cause a processing circuit to transfer key capabilities between the key capability storage 90 and the capability registers 60. Additionally, software compartments lacking key capability operating privileges may not be permitted to cause transfers of key capabilities between key capability storage 90 and arbitrarily selected locations in memory 34 selected by software compartments lacking key capability operating privileges (transfers prohibited for compartments lacking key capability operating privileges may be key capability loads only, key capability stores only, or both key capability loads and key capability stores, where key capability loads are transfers from memory (including cache) to registers and key capability stores are transfers from registers to memory).

[0081] These restrictions allow a software compartment with key capability operating privileges to create a key capability that represents temporary permission to access some region of memory or perform some other action; the software compartment with operating privileges may then set up capabilities in regular capability registers 60 that are passed to compartments that do not have key capability operating privileges to grant action permission for any action performed by the called compartment. At the point where permission to perform an action is revoked, key capability 90 may be revoked, which may effectively mean that the corresponding rights granted by the capability in capability registers 60 or the capability stored in memory 34 may no longer be valid, since capability checking circuitry 80 may perform a combined capability / key capability check to check the action being performed against both the bounds defined in capability registers 60 and the bounds defined in key capability registers 90. Since software compartments that do not have key capability operating privileges could not transfer key capabilities to memory 34, this means that upon revocation of a key capability, there is no need to scrub memory to find copies of the revoked key capability that are no longer accessible, thus addressing the temporal stability issue discussed above.

[0082] Another example may not restrict the storage of key capabilities from the key capability registers to memory 34, but instead may restrict the loading of key capabilities from memory to the key capability registers by software compartments that do not have the key capability operating privilege. By restricting the transfer of key capabilities back to the key capability registers 90, this may prevent a key capability previously saved to memory from being reused after being revoked, which is sufficient to provide time safety even when allowing key capabilities to be stored from the key capability storage 90 to memory without the key capability operating privilege.

[0083] As shown in FIG. 2, it is not necessary for key capabilities to be defined in the same format as the capabilities provided in capability registers 60. For example, when checking information specified in pointer field 62 of capability or general register 50 against non-capability operands, a key capability may define additional permissions and boundaries that apply in combination with any permissions and boundaries defined in capability registers 60, so the key capability itself need not include a pointer field as indicated by the dotted lines in FIG. 2. Also, the encoding of a key capability may differ from the encoding of a regular capability. For example, the range of permission types provided for a key capability may differ from the permission types indicated in field 76 for that capability. Also, key boundary information 94 may be represented in an uncompressed format or in a less compressed format compared to boundary information 74 for capabilities.

[0084] 3 and 4 show two examples of how a particular software compartment can be designated as having or lacking a key capability operating privilege. FIG. 3 shows a first example in which the processing circuit 4 can execute data processing in one of several operating states. The control register 54 may, for example, include a mode or state indication field that represents the current operating state of the processing circuit. As shown in FIG. 3, an operating state may correspond to the intersection of two different orthogonal types of states. On the one hand, at a given time, the processing circuit may be considered to be operating at one of several exception levels, such as user exception level EL0, kernel exception level EL1, or hypervisor exception level EL2. The exception levels EL0, EL1, and EL2 may be associated with increasing levels of system privilege, such that when the processing circuit 4 is at hypervisor exception level EL2, it has the right to perform certain actions that are not possible at lower system privilege exception levels. For example, the exception level may control what types of instructions can be executed or which registers 14 are accessible to software executing at that exception level. A transition between exception levels can occur when taking an exception or when returning from handling an exception.

[0085] Orthogonal to the exception level, it may also be indicated whether processing circuit 4 is executing in a restricted state or operating in an executing state. Thus, there may be restricted and executing versions of each of exception levels EL0, EL1, and EL2. When the processing circuit is in the executing state, the executing software compartment may be considered to have key capability operating privileges such that it may be able to execute various key capability manipulation instructions to create, modify, or transfer key capabilities to or from memory. When the processing circuit is in the restricted state, execution of such key capability manipulation instructions may not be enabled. It will be understood that FIG. 3 does not depict all possible operating states in which processing circuit 4 may be able to execute, and that additional exception levels or states may exist that are not depicted in FIG. 3.

[0086] FIG. 4 shows another example of specifying key capability operating privileges. In this example, separate key capability operating privileges may be specified for different portions of key capability storage 90. For example, table 100 may include several entries, each corresponding to one of the key capability registers or a block of several key capability registers, depending on the implementation. Each entry may define range information indicating a range of instruction addresses associated with having the key capability operating privilege for manipulating the key capability associated with the corresponding register or registers of key capability storage 90. Alternatively, if key capability storage 90 is implemented as a region of memory 34, each entry in table 100 may correspond to a sub-region of that block of memory used to represent the key capability storage. Each entry in table 100 may specify a starting address and either a length (size) parameter or an ending address parameter. The starting address and size / ending address indicate the limits of the corresponding range of addresses defined as having the key capability operating privilege. Thus, when an instruction is executed, if the instruction address of a key capability manipulation instruction is within the range indicated as having a key capability operating privilege for a given portion of key capability storage, the instruction is enabled to execute to perform the corresponding operation of the associated key capability. An instruction that is not within the range indicated for a given portion of key capability storage may not be enabled to perform such an operation. While Figure 4 illustrates the case of having a per-subregion setting of key capability operating privileges, such a range-based definition of software having key capability operating privileges may also be used in implementations where key capability operating privileges are assigned to the entire key capability storage.

[0087] 5 illustrates an example of portions of key capability storage 90 as active or inactive portions 98 and 99. For example, boundary information 102 may be set to mark the boundary between active and inactive portions 98 and 99. Key capabilities in the inactive portion 99 of key capability storage 90 may not be allowed to be used to grant permission to perform associated actions. Thus, during a key capability check, capability checking circuit 80 may ignore any boundaries or permissions specified in key capabilities stored in the inactive region 90 and may only allow actions that are verified by key boundaries 94 or key permissions 96 within key capabilities that are valid in the active region 98. This is useful for allowing a control software compartment to temporarily prevent a given key capability from being used to grant permission by moving the boundary so that the key capability is currently in the inactive region 99, without having to completely disable the key capability, thereby making it more efficient to later re-enable use of that key capability by moving the boundary again. While FIG. 5 illustrates the use of boundary information 102 to set active and / or inactive portions of key capability storage 90, other examples may represent active and inactive areas in different ways, for example, using active / inactive indicators associated with each portion of key capability storage 90.

[0088] The boundary information 102 may be modified in response to a boundary information modification instruction executed by a software compartment having key capability operating privileges. For example, the boundary information 102 may be defined in a location (e.g., a software-accessible register or memory system location) whose access is restricted to software compartments having key capability operating privileges.

[0089] 6 is a flow diagram illustrating a method for processing a key capability manipulation instruction. In step S100, a given software compartment executing on processing pipeline 4 attempts to execute a key capability manipulation instruction to manipulate a key capability stored in a given portion of key capability storage 90. For example, the manipulation instruction may request the creation of a new key capability in the given portion of key capability storage. Alternatively, the manipulation instruction may request a modification to a new key capability in the given portion of key capability storage. Another type of manipulation instruction may request that a key capability be written from key capability storage 90 to memory 34, or that a given portion of key capability storage 90 be loaded with a key capability read from memory 34.

[0090] In response to the given software compartment, processing circuit 4 determines, in step S102, whether the given software compartment has a key capability operating privilege associated with the given portion of the key capability storage circuit. For example, this may include determining whether the current operating state is the run state or whether the instruction address of the key capability manipulation instruction falls within a range indicated by range information table 100 as having a key capability operating privilege for the given portion of the key capability storage circuit. If the given software compartment has the key capability operating privilege, in step S104, the instruction is enabled if any other requirements are met. For example, these other requirements may include whether the exception level has sufficient privilege to execute the key capability manipulation instruction, or whether the address specified by the key capability manipulation instruction for transferring key capabilities to or from memory is permitted to be accessed by the current software process, as determined based on page table information or other protection information checked by MMU 28.

[0091] If a given software compartment does not have the key capability operating privilege in step S102, then the request made by the key capability manipulation instruction is denied in step S106. For example, a fault may be signaled. This prevents inappropriate software from establishing or manipulating key capabilities, which may give the software inappropriate access rights to access memory.

[0092] It should be noted that there may be corresponding capability manipulation instructions to manipulate capabilities stored in the capability register 60. A software compartment that does not have a key capability operating privilege may still be able to execute such a capability manipulation instruction, as opposed to a key capability manipulation instruction, if any other requirements checked in step S104 (e.g., an exception level sufficient to execute the capability manipulation instruction) are met. Thus, for a capability manipulation instruction intended to manipulate a regular capability, the permission acting on such an instruction may not depend on whether the software compartment requesting the operation has a key capability operating privilege.

[0093] Figure 7 illustrates in more detail the specific types of operations that may be controlled based on key capability operating privileges. Figure 7 is similar to Figure 6, except that in step S110, a request is made by a given software compartment to either create a key capability in a portion of the key capability storage circuitry or to copy a key capability between a given portion of the key capability storage circuitry 90 and a memory location selected by the given software compartment. The memory location selected by the given compartment is identified by a memory address, and the data corresponding to that address may be physically stored in cache 30, 32 or in main system memory 34. As in Figure 6, in step S112, it is checked whether the given software compartment has the key capability operating privilege; if so, the request may in principle be allowed if other permission requirements are met, as described in step S114; alternatively, if the software compartment does not have the key capability operating privilege, the request may be denied and a fault may be signaled in step S116.

[0094] In some examples, capabilities may be defined using a capability type indicator that may indicate the type of capability. In some examples, key capabilities may be assigned to a dedicated key capability type. This may be useful to allow capabilities in memory to be distinguished as key capabilities or regular capabilities. It may be desirable to prevent information derived from key capabilities from being loaded into capability registers 60. Thus, as shown in FIG. 8 , when processing circuitry 4 makes a request to copy a capability from memory 34 to capability registers 60 in response to an associated software instruction in step S120, processing circuitry 4 or capability check circuitry 80 checks in step S122 whether the capability is indicated as a key capability type. If the capability is not a key capability type, the request may in principle be allowed in step S124, but whether it is actually allowed may depend on whether any other permission requirements (e.g., memory permission checks, capability bounds checks) are satisfied. If the capability is indicated as a key capability type, the request may be denied and a fault may be signaled in step S126. This prevents the boundaries defined in the key capability from straying into the capability registers. If the capability desired to be copied into the capability registers 60 is not a key capability type, it may in principle allow the capability to be copied if any other permission requirements are met, such as checks performed by the MMU 28 or capability checks 80 based on the capability boundaries 74 and permissions 76 in the capability registers 60 being used to control the copying of the target capability from memory to the capability registers 60.

[0095] 9 shows the capability and key capability checks performed by capability check circuitry 80. In step S160, processing circuitry 4 requests an operation to be performed by referring to a given capability in response to an instruction decoded by decode stage 10. The given capability may be default capability 70 if the instruction requests an operation to be performed on a non-capability operand (e.g., an operand in general-purpose register 50), or it may be one of the general-purpose capabilities stored in capability register 60 if the operation is to be performed in response to an instruction that explicitly references one of those registers.

[0096] In step S162, capability check circuit 80 determines whether processing circuit 4 is operating in a mode in which key capabilities are used. In some implementations, the processing circuit may support several modes in which key capabilities are not used, for example, to save power by avoiding key capability checks if the capabilities themselves provide sufficient protection. If key capabilities are not used, then in step S164, any key capability bounds checks are omitted, and capability check circuit 80 performs bounds checks to check whether non-capability operands or bounded information (e.g., pointers) 62 of the given capability satisfy the bounds specified by bounds information 74 for the given capability, and also checks whether the operation satisfies any permissions 76 set for the given capability. In step S166, capability check circuit 80 determines whether any capability bounds / permissions checks were successful; if not, in step S168, the request to perform the operation is denied and a fault may be signaled. For example, this may be because the requested operation is a memory access to an address that is not within the relevant boundaries 74 specified by a given capability, or it may be an operation type that is not allowed by permissions 76 (e.g., write when the capability specifies read-only permission). On the other hand, if the capability bounds and permission checks are successful, then in step S170 the operation may be allowed if other permission checks are satisfied. For example, there may also be orthogonal checks performed by MMU 28 using page tables or other protection information, and therefore, even if the operation could, in principle, be allowed based on the capability check, it is not guaranteed that other checks will also allow the operation.

[0097] If it is determined in step S162 that the key capability can be used in the current mode, the method can proceed to step S172, where in some implementations a check can be made as to whether a given capability is secret or shared, where the operation is checked with reference to a non-capability operand checked using default capabilities 70 or a general-purpose capability in the capability registers 60. FIG. 10 shows an example of indicating secret or shared operands or capabilities. For example, each capability register 60 can include a secret / shared field 200 that indicates whether the corresponding capability is secret or shared. The secret / shared field 200 can also be included when capabilities are written to memory, so that when the capabilities are subsequently loaded back from memory, they retain their status unless the status needs to be changed as a result of the transfer between memory and the register, as further described with reference to FIG. 13 below. Similarly, non-capability operands may be marked as confidential or shared by defining confidential pointer range information 202, which may specify one or more ranges, each defined by a start address and a length or end address indicating the range of address space within which pointers or other non-capability operands falling within the range may be considered confidential. Alternatively, other approaches may use shared pointer range information to define the range of pointer values ​​that are considered shared. It will be appreciated that there may be other ways to mark non-capability operands as shared or confidential, such as by adding additional fields to general registers 50, similar to the confidential / shared field 200 shown for capability registers 60.

[0098] Providing the ability to mark a capability or non-capability operand as sensitive can be useful because key capability checks may not need to be performed on capabilities / operands that are used only within a given software compartment and not shared with other compartments, and therefore power can be saved by omitting key capability boundary checks for sensitive capability or sensitive non-capability operands. Thus, if in step S172 it is determined based on the sensitive / shared status information 200, 202 that the non-capability operand or the given capability is a sensitive operand or capability, the method continues to step S164 and proceeds as described above to perform a capability boundary or permission check, but omitting any key capability boundary or permission check. If it is determined that the non-capability operand or the given capability is shared, a key capability check may be required, and the method continues to step S174.

[0099] It will be appreciated that support for secret and shared capability or non-capability operands is not required, and some implementations may not distinguish between secret and shared capabilities, in which case step S172 may be omitted, and the method of Figure 9 may proceed straight from step S162 to step S174 when in a mode in which key capabilities are used.

[0100] In step S174, the capability check circuit 80 may perform a check of the key capability check success indicator associated with the non-capability operand or the given capability to check whether it indicates that the key capability check has previously been determined to be successful. As shown in FIG. 11 , the general-purpose registers 50 providing the non-capability operands and the capability registers 60 providing the capability operands may be extended with an architecturally hidden portion 210 that is invisible to software but that is readable and writable by the hardware circuit logic of the capability check circuit 80. The hidden portion may include a key check success indicator 212. The hidden portions of the capability registers (including the default capability register 70 used to check non-capability operands) may also include validity bounds / permissions information 214. A successful key capability check for a given non-capability operand in general register 50 or a capability operand in capability register 60 may set key capability success indicator (Kv or key check valid indicator) 212 to a given value, such as 1, indicating that the key capability check need not be repeated on subsequent uses of the same operand if the requested operation is within the valid boundaries and permissions indicated in field 214. In response to a successful key capability check, valid boundaries and permissions 214 may be set to correspond to the intersection of any boundaries or permissions established by the associated key capabilities in fields 94, 96 with any boundaries or permissions 74, 76 specified by the corresponding capabilities or default capabilities.This protects against the fact that a key capability check may be successful on one occasion, but if the associated capability's non-capability operand or pointer 62 later changes, it may no longer be within the key boundaries 94 of the previously checked key capability (even if still within the boundaries 74 allowed by regular capabilities); therefore, by storing the valid boundaries / permissions corresponding to the key capability / regular capability boundary / permission combination, this allows the capability check circuit 80 to avoid having to look up the key capability register 90 again while still enforcing the appropriate boundaries / permissions. This approach may be useful for saving power by avoiding repeating operations whose results are already known from previous checks. In some examples, the "key capability check success indicator" 212 may be considered to indicate whether the valid boundaries / permissions field 214 is valid.

[0101] Thus, if in step S174 the key capability check success indicator 212 associated with the associated non-capability operand or given capability indicates that the key capability check was previously determined to be successful (or, equivalently, the valid bounds / permissions valid field 212 indicates that the valid bounds / permissions 214 are valid), then in step S176 the lookup in key capability storage 90 can be omitted and instead the pointer value 62 of the non-capability operand or given capability can be checked against the valid bounds or permissions 214 established for the default capability 70 used to check the associated non-capability operand or given capability. If in step S178 these valid bounds and permission checks are determined to be successful, then again in step S170, operation can be allowed if any other permission checks are satisfied; however, if the valid bounds checks and permissions were not successful, then in step S180 the request may be denied and a fault may be signaled.

[0102] On the other hand, if it is determined in step S174 that the key capability check success indicator 212 does not indicate that a key capability check has previously been determined to be successful for the associated non-capability operand or the given capability (or does not indicate valid effective boundaries / permissions 214), the method proceeds to step S182 to perform a combined boundary and permission check based on both the capability and the key capability.

[0103] In step S182, capability check circuit 80 performs a joint bounds / permissions check to check whether non-capability operands or bounds information 62 of a given capability satisfy both the bounds and permissions specified by the given capability and the key boundaries 94 and key permissions 96 specified by valid and active key capabilities in key capability storage 90. Here, key capabilities in the inactive portion 99 of key capability storage 90 may not be used to grant permission to perform an action. Also, key capability storage may have a valid indicator that indicates whether each portion of the key capability storage stores a valid key capability; therefore, an invalid key capability may not grant permission to perform an action.

[0104] In step S184, capability check circuitry 80 determines whether the combined bounds and permission check was successful. If either the capability check based on the associated capability bounds 74 and permissions 76 or the key capability check based on the key capability bounds 94 and permissions 96 was not successful, the combined check is not successful. If both the capability check and the key capability check are successful, operation may be enabled in step S170. In implementations that support a key capability check success indicator, capability check circuitry 80 also performs step S186 to set the key capability check success indicator 212 associated with the relevant non-capability operand or given capability to indicate the success of the key capability check if the check was successful, and (if effective boundaries / permissions field 214 is supported) also sets the effective boundaries and permissions field 214 based on the logical AND combination of the key boundaries 94 and permissions 96 of the matching key capability (the key capability that granted permission to perform the requested action in step S160) and the capability boundaries 74 and permissions 76 of the given capability. Implementations that do not support a key capability check success indicator can omit step S186.

[0105] On the other hand, if it is determined in step S184 that either the key capability bounds check or the permission check, or the capability bounds or the permission check, is not successful, then in step S180 the request is again denied and a fault is signaled.

[0106] The dotted arrow between steps S178 and S182 in Figure 9 indicates an alternative implementation that may be used when the effective bounds / permissions check in step S178 is not successful. Rather than fault, the method may proceed to step S182 to perform a combined bounds / permissions check using the bounds 74 / permissions field 76 and the key bounds 94 / permissions field 96, and then, depending on the outcome of the combined bounds / permissions check in step S182, may allow the operation in step S170 or deny the operation in step S180. This option may be useful in some scenarios because it may be possible that a requested operation may not fall within the effective bounds / permissions 214 indicated for a given capability or non-capability operand, yet the operation may still satisfy both the capability bounds 74 / permissions 76 of the associated capability and the key bounds 94 / permissions 96 of the effective / active key capability. For example, this may occur if effective boundaries / permission checks are preset based on checks against a given capability and key capability A, which has broad boundaries but few permissions (e.g., allows load but not store), and then a later operation (e.g., store) of a type not permitted by key capability A is requested using the same given capability; therefore, the later operation is not permitted based on the effective permissions, but may be permitted if another key capability B exists that has narrower boundaries but a broader range of permissions (e.g., allows both load and store). This is just one example of intersecting sets of permissions / boundaries for key capabilities; while other examples are possible, it illustrates that it may be useful to provide an alternative, indicated by the dotted arrow between steps S178 and S182.

[0107] It will be appreciated that not all implementations need support the key capability check success indicator, and in implementations that do not support this, steps S174, S176, and S178 may be omitted, and instead the method may proceed directly from step S162 to S182 or from S172 to S182 without performing step S174.

[0108] Also, some approaches support the key capability check success indicator 212 but not the valid boundaries / permissions field 214. In implementations that do not provide the valid boundaries / permissions field 214, steps S176 and S178 of Figure 9 may be modified to check the requested operation against the boundaries 74 / permissions field 76 of a given capability rather than based on the valid boundaries / permissions field 214. Also, the setting of the key capability check success indicator 212 in step S186 of Figure 9 may rely on checking whether the boundaries / permissions defined for a given capability are entirely within the boundaries / permissions defined for one or more valid and active key capabilities. If the bounds / permissions defined for a given capability are entirely within the bounds / permissions defined for one or more valid and active key capabilities, then a key capability check success indicator can be set because a subsequent operation that passes a capability check based on the given capability will also implicitly pass a key capability check based on one or more valid and active key capabilities (because the bounds / permissions of the key capability are more permissive or equally permissive compared to the bounds / permissions of the capability).In contrast, if the boundaries / permissions of a given capability are more permissive than the boundaries / permissions of one or more valid and active key capabilities (e.g., because the given capability has broader boundaries than the key capabilities that allow additional action types to be permitted, or has boundaries that span an address range that falls into the gap between the address ranges defined by the boundaries for two or more valid and active key capabilities), then in step S186, the key capability check success indicator 212 is not set (because even if the currently requested operation is permitted based on both the capability check and the key capability check, it cannot be guaranteed that any future operation that satisfies the capability check will also satisfy the key capability check). Also, the capability check circuit 80 may clear / recalculate the key capability check success indicator field when the boundaries / permissions 72, 74 of a given capability are updated, or when a key capability is updated, disabled, or deactivated.

[0109] 12 shows a method for maintaining a key capability check success indicator 212 in an implementation that supports this. In step S300 of FIG. 12, processing circuitry 4, in response to decoding the associated instruction, updates a given register 50, 60 with the key capability check success indicator 212 set to indicate a successful key capability check. In response to updating the register, in step S302, processing circuitry 4 or capability check circuitry 80 clears the key capability check success indicator, or alternatively, performs a key capability check based on the updated value of the register and, if successful, recalculates the key capability check success indicator 212 and valid bounds 214. This ensures that a previously valid key capability check is no longer automatically indicated as valid after the register update, ensuring that key capability permissions are respected after the update. 12 may be performed in response to updates to the permissions 76 and bounds 74 of a corresponding capability register, but may not be necessary when a pointer 62 of that capability register or a non-capability operand in a general register 50 is modified, since the new pointer / operand value may still be checked against the valid bounds / permissions field 214. In implementations that do not support the valid bounds / permissions field 214, step S302 may also be performed in response to an update to a pointer field 62 or non-capability operand stored in a capability register 60 or general register 50 that has a key capability check success indicator set to indicate the success of a previous key capability check.

[0110] 13 shows actions to maintain the confidential / shared status 200 for a capability operand or a non-capability operand. In step S320, one or more instructions are executed to control the processing circuitry 4 to request either: Sensitive capabilities (Confidential / Shared Information 200 designates capabilities as sensitive) become accessible to another software compartment; The secret capabilities are loaded into the capability storage circuit 60 from memory under the control of the shared capabilities, or The secret capabilities are stored in memory from the capability storage circuit 60 under the control of the shared capabilities.

[0111] If any of these actions occur, in step S322, the sensitive capability is converted to a shared capability by updating the sensitive / shared status indication 200 associated with the capability (which may be included in the capability information stored in memory). Some implementations may not need to convert a sensitive capability as shared in response to all of the actions shown in step S320, but these are all available options. By providing a hardware infrastructure that can enforce the conversion of a capability from sensitive to shared when the capability is potentially shared with another software compartment, this avoids circumventing key capability checks for capabilities intended to be used by multiple compartments.

[0112] Further examples are given below: It will be understood that not all embodiments need to have all these features.

[0113] A "capability" is typically a pointer extended with additional information (such as permissions or boundaries) and may include additional tag bits to indicate the validity of the additional information. However, various capability types may, for example, not include a pointer value but may include others. A characteristic of a capability is that it contains some unforgeable information so that the system can check whether the capability was constructed in a valid way. There are many possible ways to encode / represent a capability, which may be explicit or implicit in its representation in the system state, or both, depending on the specific design.

[0114] A "capability type" defines a category of capabilities that have common characteristics and / or intended uses, regardless of how they are represented and / or encoded.

[0115] A "compartment," in some examples, may be part of a process that owns an address space range and potentially a set of other resources (other examples may use different definitions). Ownership of an address space range may be granted to a compartment through a capability.

[0116] A "compartment privilege" may be the set of permissions for a compartment determined by the capabilities to which the compartment has access. Permission may be granted by a single capability or by a combination of a capability with other capabilities that are directly expressed or otherwise derived from the system state.

[0117] A "compartment hierarchy" can be the structure of compartments or compartment groups (types) in a particular design, where compartments have different compartment privileges, and compartment A is superior to compartment B if the privileges of compartment A are a strict superset of the privileges of compartment B.

[0118] The running and restricted states referred to below are execution modes associated with capabilities, with different levels of privilege orthogonal to the exception level (hypervisor / kernel / user space). This is an example of a compartment hierarchy with two compartment types.

[0119] "Generic register" refers to a generic CPU register (eg, general purpose register 50 or capability register 60 described above).

[0120] A. Key Capabilities 1. General description. a. The above example introduces the following concept of key capability storage: i. Contains items that can hold key capabilities - which can be a set of registers or a set of memory ranges defined by the current system state, or both ii. May be active or inactive in the current system state b. Introduce the KeyOperate privilege, which gives the right to operate key capabilities. c. Some designs may introduce the following key capability types: i. Can only operate (construct, move, or destroy) in key capability storage unless the current compartment has the KeyOperate privilege ii. Is active when placed in active key capability storage iii. When active, it defines boundaries / permissions to control whether actions governed by other explicit or implicit capabilities or capability types can be performed. d. However, other designs may achieve a similar level of functionality specified below without introducing special key capability types. i. Key capabilities in the active key capability storage affect whether certain memory accesses are allowed when they match. ii. There are certain restrictions on when capabilities can be copied to key capability storage and revoked or modified there. e. This scheme can be extended by allowing for finer granularity in granting KeyOperate privileges to specific key capability storage instances or subsets of them, e.g., privileges can be delegated and restricted to a subset of active key capability storages. 2. An illustrative description of a specific,design case assuming a compartment hierarchy with two compartment,types—execution / restriction—where the restriction compartments,communicate with each other with the help of the,execution compartment. a. An extension of the architecture with a set of KR registers (a version of Key Capability Storage 90) that can hold capabilities and are not accessible by normal capability instructions. i. Capabilities in the KR register can be encoded in different ways, and the encoding of a capability in the KR register does not necessarily have to be the same as other capabilities or capabilities stored in other parts of the system. Furthermore, capabilities in the KR register do not necessarily have all the fields that are present in other capabilities, and may have additional fields. b. Introduction of capability type K (a version of the key capability type) that is created in the KR register, cannot be moved to a register other than KR, can be invalidated in the KR register, and cannot be loaded from or stored to memory by the restricted compartment itself, but can be loaded / stored by the execution compartment (i.e., the execution compartment has the KeyOperate privilege). CK capabilities allow access to specific memory regions using other pointers (or capabilities). d. Introducing additional restrictions on whether addresses can be accessed using pointers (or capabilities) i. If there is no K capability in the key capability storage that is valid and has bounds that include the target region, the memory access is invalid. This allows for the introduction of temporal safety for communication between compartments. B. Use cases based on the specific design cases described in section A.2 above, and further details on additional modifications that can be introduced.

[0121] B.1 Synchronous communication Compartment P calls compartment Q and, with the assistance of a more privileged compartment (the arbiter), shares memory buffer M, for purposes of illustration, until the call from P to Q is completed. When the arbiter receives the call request, it creates a K capability for buffer M's address range in the KR register. When Q receives control as part of the call process, it can access buffer M, provided other architectural rules do not prevent it. When Q returns control, the arbiter invalidates the K capability it previously created. Because Q cannot store the K capability in memory for later use, Q can no longer access buffer M unless access is granted again. This means that buffer M remains time-safe.

[0122] B.2 Asynchronous Communication A similar way of temporarily granting access to a memory buffer M is possible in asynchronous mode, i.e., when granting temporary access to another thread of execution. This can be implemented with the help of (for example) a kernel that can transfer K values ​​between KR registers associated with different threads of execution. For this to work correctly, the kernel may need to track ownership of address ranges to ensure that the K capability is only transferred by compartments that are allowed to do so.

[0123] B.3 Additional modifications that can be implemented to reduce the number of checks against the KR register. 1. Introduce a secret / shared distinction for capabilities and check only memory accesses using pointers or shared capabilities against the KR register. Secret capabilities are used within the compartment that owns the relevant address range, where checking against the KR register is redundant. a. Sensitive capabilities become shared capabilities when they are given to another compartment. b. If a capability is loaded using shared capabilities, it becomes a shared capability. 2. Additionally, checks against the KR register can be skipped for pointers that are known to be sensitive to the executing compartment by some means (eg, the sensitive pointer range information 202 described above). For example, an architecture may define a system register that determines the range of pointers that are considered sensitive. 3. Introduce a Kv bit (eg, the Kv indicator 212 mentioned above) as a hidden part of each generic register (general purpose register 50 or capability register 60) that can be passed to a memory access instruction. a.Kv bits are as follows: i. -0 when the generic register value has not yet been checked against the KR register ii. -1 when the value of a generic register is checked against a KR register and a KR register is found whose bounds encompass the bounds of the value. b. The Kv bits are recalculated when: i. The value of the corresponding generic register is changed (in which case it may simply be cleared to delay recalculation). 1. An optimization is (optionally) possible so that not every change to the value of a generic register results in a recalculation of the Kv bits. For example, when the value of a generic register is copied from another generic register, the Kv bits may be copied along with the value. ii. When there is a request from software (e.g., using a dedicated instruction) to recalculate the Kv bits. iii. Optionally, when any of the KR registers are updated (it may be sufficient to provide support for B.3.3.b.ii, but software updating KR may also include instructions to recalculate the Kv bits, so it is not necessary for hardware to automatically recalculate / clear Kv when the KR register is updated). c. If the Kv bit is set, the address check against the KR register can be skipped. 4. Optionally, B.3.3 can be extended to relax the bounds requirement by introducing effective bounds base and length fields as hidden parts of each generic register that can be passed to a memory access instruction. a. The effective bounds field is the intersection of the bounds specified by the KR register and the bounds of the generic register value itself (or the implied bounds if the register contains a non-capability value). b. The value of the generic register is checked against the KR register, and the Kv bit is set to 1 when an intersecting KR register is found and the hidden portion of the valid boundary is updated accordingly. c. If the Kv bit is set, an address check may be performed against the valid bounds field. 5. Another extension of the scheme is to support spilling / filling of KR registers, thus relaxing the limitations arising from the number of registers; spilling / filling can be performed, for example, implicitly by an arbiter or kernel, or automatically, into a memory area dedicated to each execution thread for this purpose. 6. Additionally, for efficiency purposes to avoid invalidating and reconstructing K capabilities that must be accessible to the calling compartment but should not be accessible to the called compartment, the scheme may implement KR register boundaries that indicate the range of KR registers that are currently accessible.

[0124] FIG. 14 illustrates a simulator implementation that may be used. While the above embodiments implement the invention in terms of apparatus and methods for operating specific processing hardware that supports the techniques, it is also possible to provide an instruction execution environment according to the embodiments described herein 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 430, which optionally runs a host operating system 420 and supports the simulator program 410. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or there may be multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations that run at reasonable speeds, but 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 with additional functionality not supported by the host processor hardware, or may provide an instruction execution environment typically associated with a different hardware architecture. An overview of simulation is given in "Some Efficient Architecture Simulation Techniques," Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

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

[0126] Simulator program 410 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provide target code 400 (which may include applications, an operating system, and a hypervisor) with a program interface (an instruction execution environment) that is the same as the interface of the hardware architecture modeled by simulator program 410. Thus, program instructions of target code 400, including instructions that interact with the capabilities and key capabilities discussed above, may be executed from within an instruction execution environment using simulator program 410, thereby allowing host computer 430, which does not actually have the hardware features of device 2 described above, to emulate these features.

[0127] The simulator code 410 may include instruction decode program logic 411 that decodes instructions of the target code 400, maps them to corresponding instructions in a native instruction set supported by the host, and controls the host 430 to perform functionality equivalent to the operations represented by the instructions of the target code 400.

[0128] Capability check program logic 412 is provided that defines instructions for controlling host hardware 430 to perform capability checks and key capability checks that apply similar checking criteria to the checks performed in hardware by capability check circuitry 80 in the example of FIG. 1.

[0129] The simulator code 410 also includes storage emulation program logic 413, which includes instructions for maintaining and accessing various data structures within host storage circuitry 432 (e.g., host registers and / or host memory) of the host device 430 that emulates the data storage provided in hardware in the example of FIG. 1.

[0130] For example, register emulation program logic 414 may track addresses in host storage that represent emulated registers 434 that correspond to architectural registers 50, 52, 56, 60 that are expected to exist in hardware in the example of Figure 1. When an instruction in target code 400 references a particular architectural register, register emulation program logic 414 causes the corresponding emulated instruction generated by instruction decode program logic 411 to request access to a location in emulated register data structure 434 that corresponds to the requested simulated architectural state. The architectural registers emulated by register emulation program logic 414 include capability register 60; therefore, capability storage structure 436 is maintained in host storage (although shown separately in Figure 14, in other examples capability storage structure 436 may be considered part of emulated registers 434).

[0131] When target code 400 executes load / store instructions (which would access cache 30, 32 or memory 34 if executed on a hardware device), in the simulated environment, these instructions actually access simulated memory space 440 maintained in host storage 432 by simulated memory mapping program logic 418. Simulated memory mapping program logic 418 may also include program logic for emulating address translation or memory protection functions similar to the operations performed by MMU 28 in a hardware embodiment.

[0132] Key capability storage emulate program logic 416 may also be provided to maintain simulated data structures 438 in host storage corresponding to key capability storage 90 of Figure 1. If key capability storage 90 is architecturally implemented as registers, then key capability storage emulate program logic 416 and key capability storage structures 438 may be considered part of register emulate program logic 414 and emulated registers 434, respectively. If key capability storage 90 is architecturally implemented as a region in memory, then key capability storage emulate program logic 416 and key capability storage structures 438 may be considered part of simulated memory program logic 418 and simulated memory space 440, respectively.

[0133] Thus, the simulator code 410 can provide support for key capabilities in a manner similar to the hardware example of FIG. 1, allowing the same target code 400 to run in either the example of FIG. 1 or the example of FIG. 14, with time safety provided using key capabilities.

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

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

Claims

1. 1. An apparatus comprising: processing circuitry for performing data processing in response to instructions; a capability storage circuit for storing at least one capability specifying bounded information and boundary indication information indicating an allowable boundary of the bounded information; a key capability storage circuit that stores at least one key capability specifying key boundary indication information, the key boundary indication information indicating allowable boundaries of information specified by any one or more of non-capability operands, capabilities stored in the capability storage circuit, and the key capability itself; a capability check circuit that determines whether to enable an operation to be performed by the processing circuit based on a boundary check using the boundary indication information and the key boundary indication information; Equipped with If a given software compartment executed by the processing circuitry lacks a key capability operating privilege associated with at least a portion of the key capability storage circuitry, the processing circuitry may instruct the processing circuitry to: a first transfer operation to transfer key capabilities from the at least a portion of the key capability storage circuit to the capability storage circuit or to a memory location selected by the given software compartment; and a second transfer operation to transfer key capabilities from the capability storage circuit or from the memory location selected by the given software compartment to the at least a portion of the key capability storage circuit; configured to prohibit the execution of one or both of Device.

2. 2. The apparatus of claim 1, wherein, in at least one operating mode of the processing circuit, in response to an operation performed by the processing circuit with reference to a given capability stored in the capability storage circuit, the capability check circuit is configured to perform a joint capability bounds check to check whether a non-capability operand or the bounding information of the given capability satisfies both the allowed bounds indicated by the bound indication information of the given capability and the allowed bounds indicated by the key bound indication information of at least one key capability stored in the key capability storage circuit.

3. 3. The apparatus of claim 1, wherein in at least one operating mode of the processing circuit, in response to the processing circuit requesting memory access to a target address, the capability check circuit is configured to determine that the memory access is not permitted when a valid key capability is not stored in the key capability storage circuit such that the target address is within the allowed boundary indicated by the key boundary indication information.

4. The apparatus of any one of claims 1 to 3, wherein the processing circuitry is configured to prohibit the given software compartment lacking the key capability operating privilege from creating new key capabilities.

5. 5. The apparatus of claim 1, wherein the processing circuitry is configured to support one or more key capability manipulation instructions for manipulating key capabilities stored in the key capability storage circuitry.

6. 6. The apparatus of claim 5, wherein the processing circuitry is configured to signal a fault in response to an attempt by a software compartment that lacks the key capability operating privilege for a given portion of the key capability storage circuitry to execute a key capability manipulation instruction to manipulate a key capability stored in the given portion of the key capability storage circuitry.

7. the processing circuitry is configured to execute the software compartment in one of a running state and a restricted state; a software compartment executing in said execution state having said key capability operating privileges; a software compartment executing in the restricted state lacks the key capability operating privilege; An apparatus according to any one of claims 1 to 6.

8. 7. The apparatus of claim 1, wherein the processing circuitry is configured to determine whether a software compartment has the key capability operating privilege based on range information defining at least one range of instruction addresses associated with the key capability operating privilege.

9. 9. Apparatus according to any one of claims 1 to 8, wherein the processing circuitry is configured to control the allocation of the key capability operating privileges separately for different parts of the key capability storage circuitry.

10. In response to execution by the processing circuit of an instruction requesting transfer of a target capability from memory to the capability storage circuit, the processing circuit is configured to determine whether the target capability is a key capability type capability, and when the target capability is a key capability type capability, to deny the transfer of the target capability to the capability storage circuit. An apparatus according to any one of claims 1 to 9.

11. 11. The apparatus of claim 1, wherein the key capabilities stored in the key capability storage circuitry have a different capability format than the capabilities stored in the capability storage circuitry.

12. In at least one mode of operation of the processing circuitry, the capability check circuitry is configured to determine, for an operation performed by the processing circuit using a non-capability operand or a given capability, whether confidential / shared information indicates that the non-capability operand or the given capability is confidential or shared; when the non-capability operand or the given capability is shared, the capability check circuitry is configured to determine whether the operation is permitted based on whether the bounding information of the non-capability operand or the given capability satisfies key boundary indication information of at least one key capability stored in the key capability storage circuitry; when the non-capability operand or the given capability is sensitive, the capability check circuitry is configured to determine whether the operation is permitted regardless of whether the bounding information of the non-capability operand or the given capability satisfies key boundary indication information of at least one key capability stored in the key capability storage circuitry. An apparatus according to any one of claims 1 to 11.

13. The processing circuitry may further include: when the capability becomes accessible to a software compartment that did not previously have access to the capability; when the capability is loaded into the capability storage circuit from memory under the control of a shared capability; or when the capability is stored in memory from the capability storage circuitry under control of a shared capability; The apparatus of claim 12 configured to convert from secret to shared.

14. 14. The apparatus of claim 1, wherein the capability check circuit has access to key capability active status information indicating which portions of the key capability storage circuit are active or inactive, and the capability check circuit is configured to determine whether an operation subject to a key capability check is permitted based on one or more key capabilities stored in at least one active portion of the key capability storage circuit, regardless of one or more key capabilities stored in at least one inactive portion of the key capability storage circuit.

15. 15. The apparatus of claim 14, wherein the key capability active status information includes boundary information indicating a boundary between the at least one active portion and the at least one inactive portion of the key capability storage circuit.

16. 16. The apparatus of claim 1, wherein for an operation subject to a key capability check performed with reference to a given non-capability operand or a given capability, the capability check circuitry is configured to determine whether a key capability check is required based on a key capability check success indicator associated with the given non-capability operand or the given capability, the key capability check success indicator indicating whether the key capability check for the given non-capability operand or the given capability has previously been determined to be successful.

17. 17. The apparatus of claim 16, wherein at least one of the processing circuitry and the capability check circuitry is configured to clear or recalculate the key capability check success indicator in response to an update to the given non-capability operand, the given capability, or a key capability.

18. the processing circuit or the capability check circuit is configured to set valid boundary information associated with a given non-capability operand or a given capability to indicate a valid boundary corresponding to an intersection between the allowed boundary indicated by the key boundary indication information specified by at least one key capability and the allowed boundary indicated by default boundary indication information associated with the given non-capability operand or the boundary indication information specified by the given capability; the capability check circuitry is configured to, in response to an operation that is the subject of a key capability check and that is performed with reference to the given non-capability operand or the given capability, perform a bounds check with reference to the valid bounds information associated with the given non-capability operand or the given capability. An apparatus according to any one of claims 1 to 17.

19. the key capability storage circuitry comprises: at least one key capability register, and / or at least one area of ​​memory designated as a key capability storage area; 19. The apparatus of any one of claims 1 to 18, comprising:

20. 20. The apparatus of claim 1, wherein the processing circuitry is configured to enable the given software compartment that lacks the key capability operating privilege to cause the processing circuitry to transfer capabilities between the capability storage circuitry and a memory location selected by the given software compartment.

21. The apparatus of any preceding claim, wherein the bounding information comprises a pointer.

22. 22. An apparatus according to any preceding claim, wherein each key capability also specifies at least one permission type indicator that indicates one or more types of operations for which permission may be granted using the key capability.

23. 1. A method comprising: storing, in a capability storage circuit, at least one capability specifying bounded information and boundary indication information indicating an allowable boundary of the bounded information; storing, in a key capability storage circuit, at least one key capability specifying key boundary indication information, the key boundary indication information indicating allowable boundaries of information specified by any one or more of non-capability operands, capabilities stored in the capability storage circuit, and the key capability itself; determining whether to enable an operation to be performed by the processing circuit based on a boundary check using the boundary indication information and the key boundary indication information; Including, If a given software compartment executed by the processing circuitry lacks a key capability operating privilege associated with at least a portion of the key capability storage circuitry, the processing circuitry may instruct the processing circuitry to: a first transfer operation to transfer key capabilities from the at least a portion of the key capability storage circuit to the capability storage circuit or to a memory location selected by the given software compartment; and a second transfer operation to transfer key capabilities from the capability storage circuit or from the memory location selected by the given software compartment to the at least a portion of the key capability storage circuit; prohibits the execution of one or both of the following: method.

24. 1. A computer program for controlling a host data processing apparatus to provide an instruction execution environment for executing target code, comprising: The computer program instruction decoding program logic responsive to instructions of the target code for decoding instructions of the target code to control the host data processing apparatus to perform data processing; a host memory circuit of the host data processing device; a capability storage structure that stores at least one capability that specifies bounded information and boundary indication information that indicates allowable boundaries of the bounded information; and a key capability storage structure that stores at least one key capability that specifies key boundary indication information, the key boundary indication information indicating allowable boundaries of information specified by any one or more of non-capability operands, capabilities stored in the capability storage structure, and the key capability itself; and a storage emulation program logic for maintaining the capability check program logic that determines whether to enable an operation to be performed in response to the instruction of the target code based on a boundary check using the boundary indication information and the key boundary indication information; Equipped with If a given software compartment of the target code lacks a key capability operating privilege associated with at least a portion of the key capability storage structure, the instruction decode program logic causes the given software compartment to instruct the host data processing apparatus to: a first transfer operation to transfer key capabilities from the at least a portion of the key capability storage structure to the capability storage structure or to a simulated memory location selected by the given software compartment; and a second transfer operation to transfer key capabilities from the capability storage structure or from the simulated memory location selected by the given software compartment to the at least a portion of the key capability storage circuit; configured to prohibit the execution of one or both of Computer program.

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

Images