Techniques for constraining access to memory using capabilities

Abstract

Techniques are provided for constraining access to memory using capabilities. An apparatus is provided having a processing circuit for performing operations, during which a request to access a memory is generated, the processing circuit being arranged to generate a memory address for the access request using a capability providing a pointer value and associated constraint information. The apparatus also provides a capability generation circuit that, in response to the processing circuit executing a capability generation instruction identifying a location in a literal pool of memory, retrieves a literal value from a location in the literal pool and generates a generated capability in which a pointer value of the generated capability is determined from the literal value. The constraint information of the generated capability is selected from a limited set of options depending on information specified by the capability generation instruction. It has been found that such an approach provides a robust mechanism for generating capabilities while reducing code size.

Description

[Technical Field]

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

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

[0003] Because capabilities are used as security controls within the system, it is important that the ability to create capabilities is tightly controlled, for example by enforcing that memory accesses performed with reference to a capability can only be performed with respect to memory locations within a defined region determined from the capability, and only if certain permission checks also defined by the capability are satisfied.

[0004] One mechanism that can be used to generate functions involves allowing a compiler to generate capabilities when compiling associated program code, with the generated capabilities being stored in a literal pool that is then combined with the compiled program code to form a static image in non-volatile memory. As the program code is executed, the compiler-generated capabilities stored in the literal pool can be loaded into registers using instructions in the compiled code. In some systems, it may be possible to modify capabilities once they are loaded into such registers, but in typical systems, any modification is only permitted to reduce the bounds or permissions associated with the capability, thus resulting in a reduced capability relative to the original compiler-generated capability.

[0005] While using a compiler to generate capabilities allows for robust control over capability generation, it can have a significant adverse effect on the code size of a static image. In particular, storing capabilities in literal pools can significantly increase overall code size due to the inherently larger size of capabilities compared to traditional pointers, and due to alignment requirements associated with such capabilities. In many low-cost systems, devices are typically memory-constrained and non-volatile storage is at a premium; therefore, the increased code size resulting from the use of compiler-generated capabilities is unattractive in such situations. Therefore, it is desirable to provide an improved mechanism for providing such capabilities while retaining strict control over how those capabilities may be generated. Summary of the Invention

[0006] In one exemplary configuration, an apparatus is provided that includes: processing circuitry for performing operations, wherein during operation a request to access a memory is generated, the circuitry being arranged to generate a memory address for the access request using a capability providing a pointer value and associated constraint information; and capability generation circuitry that, in response to the processing circuit executing a capability generation instruction that identifies a location in a literal pool of memory, retrieves a literal value from the location in the literal pool and generates a generated capability, the pointer value of the generated capability being determined from the literal value, and the constraint information of the generated capability is selected from a limited set of options in response to information specified by the capability generation instruction.

[0007] In another exemplary configuration, a method is provided for constraining access to a memory, the method including employing a processing circuit to perform an operation, during which a request to access the memory is generated and the processing circuit generates a memory address for the access request using a capability providing a pointer value and associated constraint information; and performing a capability creation operation in response to the processing circuit executing a capability creation instruction that identifies a location in a literal pool of the memory, the capability creation operation including retrieving a literal value from the location in the literal pool and generating a generated capability, the generated capability's pointer value being determined from the literal value, and the constraint information for the generated capability being selected from a limited set of options in response to information specified by the capability creation instruction.

[0008] In yet another example configuration, there is provided a computer program for controlling a host data processing apparatus to provide an instruction execution environment, the computer program comprising: processing program logic for performing operations, during which a request to access a memory is generated, the processing program logic being arranged to generate a memory address for the access request using a capability providing a pointer value and associated constraint information; and capability generator logic, in response to the processing program logic executing a capability creation instruction that identifies a location in a literal pool of memory, to retrieve a literal value from the location in the literal pool and generate a generated capability, the pointer value of the generated capability being determined from the literal value, the constraint information for the generated capability being selected from a limited set of options in response to information specified by the capability creation instruction. A computer-readable medium may be provided for storing such a computer program, and the computer-readable medium may be in a non-transitory or transitory form. [Brief explanation of the drawings]

[0009] The present technique will now be further described, by way of example only, with reference to examples of the technique illustrated in the accompanying drawings, in which: [Figure 1] FIG. 1 is a block diagram of an apparatus according to an exemplary implementation. [Figure 2] 10 shows an example of the type of instruction that can trigger an error when attempting to set or access a pointer value within a set of bounded pointer storage elements, where the pointer value is used to specify an address outside the range indicated by associated range information. [Figure 3] 1 illustrates the use of tag bits in association with bounded pointers, according to one exemplary implementation. [Figure 4] 10A-10C schematically illustrate the types of capabilities that may be used in accordance with the techniques described herein, according to one exemplary implementation. [Figure 5] 1 illustrates schematically how a compiler may be used to generate literal values ​​for storage in a literal pool, according to one exemplary implementation. [Figure 6] FIG. 1 is a block diagram illustrating components that may be provided in an apparatus according to one exemplary implementation. [Figure 7] 1 is a flow diagram illustrating steps performed in response to a capability creation instruction, according to an exemplary implementation. [Figure 8] 8 is a flow diagram illustrating in more detail steps that may be performed to implement step 275 of FIG. 7, according to an exemplary implementation. [Figure 9] 10 is a flow diagram illustrating how permissions for a created capability may be determined, according to an example implementation. [Figure 10] FIG. 2 illustrates an example of different domains and processing states of a processing circuit, according to an exemplary implementation. [Figure 11] 1 is a flow diagram illustrating how the processing performed when creating a capability may depend on the type of capability being created, according to an example implementation. [Figure 12] 1 is a flow diagram illustrating how multiple capabilities may be generated from a single capability-generating instruction, according to an example implementation. [Figure 13] An example simulator that can be used is shown. DETAILED DESCRIPTION OF THE INVENTION

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

[0011] In accordance with the techniques described herein, the apparatus may also provide a capability generation circuit that, in response to the processing circuit executing a capability generation instruction that identifies a location in a literal pool of memory, retrieves a literal value from the location in the literal pool and generates a generated capability whose pointer value is determined from the literal value. Note that while the literal value can be used to determine the pointer value, the literal value is not itself a capability; instead, the capability generation circuit is used to generate a capability whose pointer value is determined from the literal value. To generate the capability, the capability generation circuit is further arranged to select constraint information for the generated capability from a limited set of options in response to information specified by the capability generation instruction.

[0012] Such an approach has been found to enable the generation of capabilities that can be trusted to the same extent as compiler-generated capabilities, but with a significant reduction in code size when compared to implementations incorporating compiler-generated capabilities. In particular, with respect to trusted generated capabilities, according to the techniques described herein, a capability generation circuit generates capabilities by executing capability generation instructions provided by the compiled code, and the capability generation circuit uses only literal values ​​from a literal pool (i.e., values ​​generated by the compiler and that are part of the static image) in combination with certain other information directly specified by the capability generation instructions. Because capabilities are generated from literal values ​​in the literal pool, avoiding the requirement to store compiler-generated capabilities in the literal pool, the size of the literal pool can be significantly reduced. For example, a literal value may have the size of a standard pointer value, which is typically a significantly reduced size relative to the size of the corresponding capability. Furthermore, alignment issues associated with capabilities stored in a literal pool no longer arise, leading to further efficiency and a further reduction in overall code size.

[0013] Such an approach has proven highly beneficial in many systems. For example, a significant number of required capabilities that may have previously been generated by a compiler often access only a small region of memory and typically have only a limited set of permissions. Therefore, a common subset of ranges and permissions used to form the capability's constraint information can be identified as a limited set of options available to the capability generation circuitry, and one of those options is then selected when generating the capability according to the information specified by the capability generation instruction. This therefore avoids the need to specify a potentially large number of compiler-generated capabilities in a static image and instead allows those capabilities to be generated during code execution using literal values ​​in a literal pool, allowing for a significant reduction in overall code size by constraining the information selected from the identified limited set of options. Note that for any capabilities that do not meet the requirements to be generated in the above manner (e.g., do not specify constraint information that falls within the limited set of options), the compiler-generated capabilities can instead be generated in a standard manner for storage in a literal pool.

[0014] The capability generating circuitry can take a variety of forms: for example, it can be a separate component from the processing circuitry, or alternatively it can be provided within the processing circuitry of the device.

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

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

[0017] There are several ways that a capability-creating instruction can identify the location within the literal pool from which the requested literal value is to be retrieved. For example, a base address can be provided in an appropriate system register, and the capability-creating instruction specifies an immediate value that can be used as an offset from the base address specified in the system register.

[0018] However, in one exemplary implementation, the capability-generating instruction specifies an immediate value that is used by the capability generating circuit in combination with the current program counter value to identify a location in a literal pool that contains a literal value that is used to determine the pointer value of the generated capability. This provides a particularly efficient mechanism because compilers typically store literal values ​​close to the instructions that consume them; thus, by specifying an immediate value that is used in combination with the current program counter value, the current program counter value identifies the capability-generating instruction, which in turn provides a simple and effective mechanism for identifying the location of the required literal value in the literal pool.

[0019] The immediate value can take a variety of forms, but in one exemplary implementation, it provides a program counter relative offset, allowing a location within a literal pool to be identified simply by adding (or subtracting) the immediate value to (or from) the current program counter value.

[0020] While the constraint information for the generated capability can take a variety of forms, one exemplary implementation includes bounds information that identifies a region of memory accessible using a memory address derived from the pointer value of the generated capability, and the limited set of options includes a limited set of permissible sizes of the region identified by the bounds information. As noted above, it is recognized that a significant number of capabilities require access to only relatively small structures, and therefore there may be a limited set of possible sizes of such structures that can be encoded as a limited set of options for the bounds information.

[0021] There are several ways in which a capability generation instruction can indicate to the capability generation circuit which one of a limited set of allowable sizes should be used for the generated capability. However, in one exemplary implementation, the capability generation instruction specifies a size index value that is used by the capability generation circuit to determine the size of the region from the limited set of allowable sizes. The size index value can take various forms. For example, it can specify a size directly, but alternatively, any other suitable encoding can be used. For example, the limited set of allowable sizes may vary by powers of two, and thus the size index value can identify which power of two applies to the current capability being generated. Alternatively, the size index value can identify an offset to a predetermined minimum size. Thus, the size index value then effectively forms an immediate value that can be added to the predetermined minimum size value. Using such a minimum size value allows a somewhat wider range of useful values ​​to be specified. For example, a size index value of 0 still has a sensible meaning; in this case, it simply identifies that the size of the accessible region identified by the bounds information should be the predetermined minimum size.

[0022] However, there are other ways in which the selection of a size from a limited set of allowable sizes can be inferred by the capability generation circuit from information provided by the capability generation instruction. For example, the literal value may contain some redundant bits that are not used to determine a pointer value, and the capability generation circuit may be arranged to determine the size of the region from information provided in the redundant bits of the literal value. For example, there may be some level of alignment used in the pointer value determined from the literal value, meaning that a certain number of the least significant bits of the loaded literal value are not required to form a pointer value for the generated capability. In such cases, those redundant bits may instead be used to encode the size of the region to be identified by the constraint information of the generated capability.

[0023] While the number of redundant bits may be predetermined, in alternative implementations the number of redundant bits may vary. For example, the capability generation circuit may be arranged to determine a boundary within the literal value between a first portion specifying bits used to determine a pointer value and a second portion containing redundant bits depending on the encoding scheme used to form the literal value. As a particular example, a form of triangular encoding may be used to encode both size and pointer value information within the literal value in such a manner.

[0024] Once the size information is determined, there are several ways in which the boundary information can be determined from the information specified in the capability creation instruction. However, in one exemplary implementation, the boundary information identifies a first boundary determined from a pointer value, a second boundary determined from the first boundary, and a size of the region determined from a limited set of allowable sizes. This provides an efficient mechanism for identifying the boundary information by effectively determining the first boundary using the pointer value and then determining the second boundary from the first boundary using the size information. How the first boundary is determined from the pointer value may vary depending on the implementation, but in one specific exemplary implementation, the first boundary is set equal to the pointer value.

[0025] In one exemplary implementation, the constraint information may include an item of metadata, and the limited set of options may include a limited set of possible values ​​for the item of metadata. Thus, in one exemplary implementation, the constraint information may include both the aforementioned boundary information and additional items of metadata. While the item of metadata may take various forms, in one exemplary implementation, the item of metadata may include at least a plurality of permission indicators that identify permissible uses of the created capability, and the limited set of options may include a limited set of allowed combinations of permissions that may be indicated by the plurality of permission indicators. For example, in most cases, the permissions may indicate that an associated pointer in the capability may only be used to generate addresses for reading data from memory, or alternatively, identify that the pointer may be used to perform both read and write accesses. Using the limited set of allowed combinations of permissions, a selection from within that limited set of options may be efficiently encoded in the information provided by the capability creation instruction.

[0026] There are many different ways in which the values ​​to be assigned to items of metadata by the capability generation circuit from a capability generation instruction can be determined. For example, the capability generation instruction may specify metadata information to be used by the capability generation circuit to determine values ​​for one or more items of metadata. Such metadata information can be provided in several different ways, and in one exemplary implementation, for example, can take the form of one or more immediate values ​​that can directly identify the value to be used for the associated item of metadata or which of a limited set of options to select. Alternatively, different flag values ​​may be specified within the instruction, or different variants of the capability generation instruction may be used to identify different metadata-defining information.

[0027] Alternatively, or in addition, the device may further comprise a control register referenced by the capability generation circuit to determine the values ​​of one or more of the items of metadata. The control register may take various forms, and in one exemplary implementation may be a system configuration register.

[0028] As another alternative or additional example of how the values ​​for one or more of the items of metadata may be determined, the literal value may include some redundant bits that are not used to determine the pointer value, as described above. In such an implementation, the processing circuitry may be arranged to determine the values ​​for one or more of the items of metadata from information provided in the redundant bits of the literal value.

[0029] The manner in which the values ​​of one or more items of metadata are determined based on the information specified by the capability generation instruction may vary depending on one or more factors. For example, such determination may depend on the current operating mode of the processing circuit. Thus, regardless of which of the above options is used to provide the information used to determine the values ​​of the items of metadata, the manner in which that information is interpreted may depend on the current operating mode of the processing circuit. As another alternative, if a control register is referenced by the capability generation circuit, that control register may provide different information depending on the current operating mode of the processing circuit.

[0030] It should be noted that all of the above different examples of how values ​​for items of metadata may be determined may be used independently or in combination. For example, one or more items of metadata may have their values ​​determined using one technique, and other items of metadata may have their values ​​determined using one of the other techniques.

[0031] As mentioned above, one of the types of metadata that may be provided in the generated capability may comprise a plurality of permission indicators. In one exemplary implementation, the capability generation circuit may be arranged to determine a combination of permissions indicated by the plurality of permission indicators depending on the type of the generated capability. In particular, a limited set of appropriate permission combinations may depend on the type of the generated capability, and thus, by taking into account the type of the generated capability, the information provided for determining the combination of permissions may be interpreted differently depending on the type of the generated capability.

[0032] There are several ways in which the type of generated capability can be determined. For example, a capability creation instruction typically specifies a destination capability storage element where the generated capability is to be stored, and the capability creation circuitry can be arranged to infer the type of generated capability from the specified destination capability storage element. For example, the destination capability storage element can be a general-purpose capability storage element or a program counter capability storage element, and the determined set of permissions can depend on whether a general-purpose capability or a program counter capability is being created.

[0033] For example, it may be typical for a general-purpose capability to not have executable permission set, but for a program counter capability, executable permission may be set. In particular, the executable permission bit may indicate whether the capability may be used to generate memory addresses for instructions to be fetched and executed; such permission may typically be appropriate for a program counter capability, but may not be appropriate for a general-purpose capability generated using the techniques described above.

[0034] Typically, the processing invoked when executing a capability-generating instruction terminates with storing the generated capability in a specified destination capability storage element. However, in one exemplary implementation, if the specified destination capability storage element is a program counter capability storage element used to store program counter capabilities, the processing circuitry may also be arranged to branch program execution to a target instruction identified using the generated capability once the generated capability has been stored in the program counter capability storage element. This may improve code density by avoiding the need to specify a subsequent branch instruction following the capability-generating instruction.

[0035] If desired, the capability generation functionality described above can be limited to particular types of capabilities. As an example, in one implementation, the use of such capability generation instructions to generate program counter capabilities can be prevented. As a particular example, the capability generation circuitry can be arranged to trigger a fault if the specified destination capability storage element for a capability generation instruction is a program counter capability storage element.

[0036] In one exemplary implementation, the capability generation circuit may be arranged to generate multiple capabilities in response to a single instance of a capability generation instruction. Thus, when the capability generation instruction is executed, the capability generation circuit may generate not only the generated capability referenced above, but also one or more further generated capabilities. For each further generated capability, the capability generation circuit may be arranged to determine a pointer value for that further generated capability from an associated literal value obtained from an associated location in a literal pool offset from the location identified by the capability generation instruction. Thus, while the capability generation instruction may still identify the location of a single literal value, and that literal value is used to determine the pointer value for the first generated capability, the locations of the literal values ​​to be used for each of the further generated capabilities may be inferred from the location determined for the literal value for the first generated capability. The offsets may be predetermined so as not to need to be specified by the capability generation instruction, or, if desired, information regarding the offsets may be encoded within the instruction.

[0037] Although there are several ways in which constraint information for various generated capabilities generated in response to a single instance of a capability-generating instruction can be inferred, in one exemplary implementation, the capability-generating circuitry is arranged to generate the generated capability and each further generated capability with the same constraint information. Thus, the coding space within the instruction for specifying constraint information need not increase in situations where execution of a capability-generating instruction results in the generation of multiple capabilities.

[0038] With respect to the destination capability storage element into which each generated capability should be stored, the capability generation circuitry may be arranged to derive the associated destination capability storage element of each further generated capability from a specified destination capability storage element used as the destination of the initially generated capability. For example, the required destination capability storage elements may form a contiguous sequence of capability storage elements starting from a specified destination capability storage element. Alternatively, each destination capability storage element may be explicitly identified in the instruction, if required.

[0039] A processing circuit can be arranged to operate in several different operating modes. These operating modes can take a variety of forms. For example, a processing circuit may be capable of operating in a secure domain or a less secure domain, and / or within a privileged or non-privileged state; in fact, there may be more than two domains and / or more than two states that can be adopted by a processing circuit. The current operating mode of a processing circuit may depend on both the domain and processing state in which the processing circuit is operating.

[0040] If desired, the operation of the capability generation circuitry may depend on the current operating mode of the processing circuit. This may be used, for example, to limit the ability to generate capabilities for particular operating modes of the processing circuit. Thus, by way of example, a fault may occur if the capability generation circuitry is triggered to execute a capability generation instruction while the processing circuitry is in a particular operating mode in which capability generation is thus prohibited.

[0041] As another example of how the operation of the capability generation circuit may be dependent on the current operating mode, the form of the generated metadata may vary depending on the operating mode. For example, the metadata may include information indicative of the operating mode of the processing circuit when the capability was generated, and thus the capability generation circuit generates different forms of metadata depending on the current operating mode of the processing circuit when the capability generation instruction is executed. As yet a further example, the processing circuit may be capable of operating in a capability mode that is constrained by capabilities and in a further mode that is not constrained by capabilities, and the manner in which the capability generation circuit operates in response to a capability generation instruction may depend on whether the processing circuit is operating in a capability mode.

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

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

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

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

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

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

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

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

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

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

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

[0053] A device may be provided with capability storage elements (which may be referred to as bounded pointer storage elements when the capabilities take the form of bounded pointers with associated range information indicating the allowable range of addresses when using the pointer) for storing capabilities. Each capability / bounded pointer storage element may be a register, or a memory location in general purpose memory, for example a location on stack memory.

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

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

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

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

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

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

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

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

[0062] 1, the device may further provide one or more control registers for storing certain control information. In accordance with the techniques described herein, the device may generate a capability / bounded pointer in response to executing a capability-creating instruction, and in an example implementation may reference one or more of the control registers when determining appropriate constraint information for the generated capability.

[0063] Capabilities can take a variety of forms. In the example shown in Figure 4, a capability 100 includes a pointer value 102 and associated constraint information. The constraint information in this example includes some range information 104 (also referred to herein as bounds information). A set of permissions can also be provided as part of the capability's constraint information, and a capability can also include (directly or associated with) the aforementioned tag bit 108 that can be set or cleared to identify whether the corresponding block of data should be treated as a capability.

[0064] The permissions specified for a capability may vary depending on the implementation, but in one exemplary implementation, the permissions include a read permission bit 130 whose value indicates whether the capability may be used to generate memory addresses for read accesses, a write permission bit 132 whose value indicates whether the capability may be used to generate memory addresses for write accesses, and an execute permission bit 134 whose value indicates whether the capability may be used to generate memory addresses for instructions to be fetched and executed.

[0065] Such permission information can be considered metadata information about the capability. Other metadata information 136 can also be identified within the capability as needed. Purely by way of example, such metadata can indicate whether the capability is considered immutable. Such information can be specified directly as additional information within the capability, or in some exemplary implementations can be inferred from the state of other information already provided within the capability. For example, in one particular implementation, a capability is considered immutable when the execute bit is set, and the information specified by the capability cannot be modified without clearing the tag bit (effectively invalidating the capability) except through the normal incrementing of pointer values ​​that can result from instruction execution.

[0066] As another example of other metadata information 136 that may be included, such metadata may include a trust level indicator, for example, to indicate the operational mode in which the processing circuit was operating when the capability was created. The trust level may be encoded directly in field 136 of capability 100, or alternatively, trust level indicator 136 may provide an identifier used to indicate a memory address containing the trust level information. Such an identifier may directly indicate the memory location of the trust level information or may, for example, specify an offset that can be applied to an address stored in a global register in the system to identify the location containing the trust level information.

[0067] 5 is a diagram that schematically illustrates how compiler 150 may be arranged to populate literal pool 155 in memory when compiling program code. In particular, when compiling code to be executed on a processing circuit, compiler 150 may store a variety of different literal values ​​in literal pool 155. As previously explained, prior to the techniques described herein, such a compiler may have also generated several compiler-generated capabilities that may be stored in the literal pool, so that those capabilities are available for loading into capability registers by the processing circuit during execution of the code. However, as previously mentioned, providing such compiler-generated capabilities in the literal pool can significantly increase overall code size (consisting of the compiled code and associated literal pool), and it is desirable to reduce overall code size, particularly in memory-constrained devices where non-volatile storage is at a premium.

[0068] The inventors have noted that a significant number of capabilities that may typically be generated by a compiler only access small data structures, such as global variables, peripherals, control registers, etc., and therefore the number of typical sizes used to represent the bounds information of such capabilities is limited. Furthermore, note that only a limited number of combinations of possible permission bits are typically used for such capabilities. According to the techniques described herein, for such capabilities, the compiler may be arranged to store, in literal pool 155, literal values ​​that may be used to determine a pointer value for each such capability, rather than generating those capabilities at compile time. Storing such literal values ​​rather than complete capabilities can significantly reduce the size requirements of the literal pool, and thus reduce the overall code size.

[0069] Furthermore, when using the techniques described herein, a processing circuit can be arranged to generate a required function using those literal values ​​stored in the literal pool, naturally, without compromising confidence in such a capability. In particular, a capability can be created by the processing circuit by executing a particular capability-generating instruction (which can also be issued by a compiler, if necessary) that naturally uses one of the literal values ​​in the literal pool (and therefore can be trusted), and whose constraint information is selected from a limited set of possible options using information directly derivable from the instruction (and therefore can be trusted). Because the intent of the compiled program can be trusted, the capabilities generated in this way can also be trusted, and therefore can be as highly trusted as capabilities generated by the compiler itself and stored in the literal pool.

[0070] 6 is a block diagram illustrating components that may be provided within an apparatus according to one exemplary implementation. In this example, processing circuitry 200 is provided for executing a sequence of instructions, and during execution of data processing operations specified by those instructions, the processing circuitry can access general purpose data registers 215, general purpose capability registers 220, and program counter capability register 225. Processing circuitry 200 may take various forms, but may, for example, take the form of processor pipeline 4 shown in FIG. 1.

[0071] In the example shown in FIG. 6 , a processing circuit 210 may be provided that, in response to executing a capability creation instruction that identifies a location in a literal pool of memory, retrieves a literal value from a location in literal pool 230 and generates a generated capability where the pointer value of the generated capability is determined from the literal value. Associated constraint information for the generated capability is then selected by the capability creation circuit from a limited set of options according to the information specified by the capability creation instruction. The generated capability may then be written by the capability creation circuit 210 to an identified destination capability register (typically, the identified destination register is specified by the capability creation instruction). This may be, for example, one of the general-purpose capability registers 220, but in some implementations may be the program counter capability register 225.

[0072] The capability generation circuitry 210 may be a separate component from the processing circuitry 200, but in the example shown in FIG. 6 is considered to be provided by the processing circuitry 200.

[0073] As also shown in FIG. 6 , capability check circuit 205 may also be provided as a separate component or as part of processing circuit 200, as shown in FIG. 6 . Capability check circuit 205 is employed to perform a capability check operation to determine whether an access request is permitted based on constraint information identified by a given capability when a memory address is considered for access based on constraint information identified by the given capability. Thus, the capability check may involve, for example, reference to the capability range and permission information to determine whether the access is permitted to proceed. If the capability check fails, a failure indication may be provided to the processing circuit, which may take various forms, such as, for example, a fault signal. However, if the capability check passes, an access request may be issued to memory. In some implementations, one or more further checks may be performed before the access is permitted to proceed, for example, within a component such as a memory management unit (MMU), a memory protection unit (MPU), a security attribute unit (SAU), or a combination of these components.

[0074] 7 is a flow diagram illustrating steps performed by capability generation circuit 210 when a capability-generating instruction is executed by processing circuit 200. If it is determined in step 250 that a capability-generating instruction is being executed, it is determined in step 255 whether the generation of the capability is permitted, taking into account any criteria that may constrain the ability to generate the capability. As an example, the techniques described herein, in which capability generation circuit 210 is used to generate a capability in response to a capability-generating instruction, may be limited to certain operating modes of the processing circuit; if the processing circuit is not within one of the permitted operating modes, it may be determined in step 255 that the capability cannot be generated, in which case a fault may occur in step 260. As another example, the ability to generate a capability may be limited to certain types of capabilities. For example, in some implementations, if a capability is to be used as a program counter capability, generating the capability using the mechanism described above may be prohibited; an attempt to generate a program counter capability in such a situation may also cause a fault in step 260.

[0075] However, assuming that it is determined in step 255 that the capability is permitted to be created, in step 265 the immediate value specified by the capability creation instruction is used as an offset to apply to the current program counter value to identify a location in the literal pool. In step 270, the literal value at the identified location is retrieved from the literal pool and used to determine a pointer value for the created capability. In some examples, the entire literal value may be used “as is” to form the pointer value, while in other implementations, steps may be taken to derive the pointer value from the retrieved literal value. As a particular example, a certain number of the least significant bits of the literal value may be ignored for purposes of generating the pointer value due to some alignment requirements of the generated pointer value. As will be described in more detail below, these ignored least significant bits may be reused, as needed, to provide other information used in generating the capability in some exemplary implementations.

[0076] In step 275, boundary information for the generated capability can be determined from size information derived from information provided by the instruction. In particular, the information provided by the instruction can be used to encode a size within a limited set of possible sizes, and the capability generation circuit can then determine which size to use for the boundary based on such information. A first boundary can then be determined by referencing the pointer value identified in step 270, for example, by setting it equal to the pointer value. A second boundary can then be determined by applying the determined size to the first boundary to create the second boundary.

[0077] Other metadata, such as the permission bits mentioned above, can be determined from the information specified by the instruction, as shown in step 280. Again, a limited set of possible values ​​is available, and therefore the information provided by the instruction can be used to determine which combination of values ​​to use from the limited set of possible values.

[0078] The capability creation instruction can take a variety of forms, but in one particular example it has the following format: LDRCC Cd, <label>,#sz

[0079] Thus, in this example, the capability creation instruction is a capability creation load instruction that specifies the destination capability register Cd, provides an immediate value (called a "label") used to identify a location in the literal pool, and specifies size information (#sz) used to determine the allowable size of the created capability. However, this is just one exemplary format that may be used, and other formats may be used, provided that the information needed to create the capability can be derived from the instruction itself in combination with literal values ​​retrieved from the literal pool.

[0080] FIG. 8 is a flow chart illustrating in more detail steps that may be performed in step 275 of FIG. 7 to determine the boundaries of the generated capability. In step 300, it is determined whether a size index value is specified directly in the instruction, as in the LDRCC instruction format described above. If a size index value is specified, the process proceeds to step 305, where the size is determined from the specified size index. The size index value may specify the size directly, or an appropriate encoding scheme may be used to identify the size. For example, the sizes within the restricted set of options may vary by a power of two, and the size index may indicate the power of two to apply. Alternatively, the size index may specify an offset from a predetermined minimum size index. Regardless of how the size index is formed, it will be appreciated that in step 305, the capability generation circuit 210 may determine the size of the region associated with the capability from the size index.

[0081] In alternative implementations, the size indicator value may not be specified directly in the instruction; instead, as shown in Figure 8, it may be possible to determine the size from redundant bits in the literal value retrieved from memory, as indicated by step 310. In particular, as mentioned earlier, due to some alignment constraints on pointer values, there may be bits in the literal value that are otherwise unused, and these bits can be reused for several possible uses, one of which is to encode size information. That information may be encoded in the redundant bits of the literal value in much the same way as if the size indicator were specified directly in the instruction, and thus may take any of the forms described above with reference to step 305.

[0082] As yet another alternative, not specifically shown in Figure 8, the size may be fixed and therefore no size index value needs to be specified. Instead, the boundaries may be determined directly by identifying a first boundary and then applying a fixed size to determine the location of the second boundary from the first boundary.

[0083] Regardless of whether step 305 or 310 is performed, the process then proceeds to step 315, where a first boundary is determined from the pointer value. Any suitable technique can be used to determine the boundary from the pointer value, so, for example, the first boundary may be at some fixed offset from the pointer value. However, in one particular exemplary implementation, the first boundary is set equal to the pointer value.

[0084] Next, in step 320, a second boundary is determined from the first boundary and the determined size. By way of example, the second boundary may be set equal to the pointer value plus the determined size. It will be understood that once the first and second boundaries are set, the capability range information has now been determined.

[0085] 9 is a flow diagram illustrating various different ways in which permission bit values ​​may be determined. The same type of approach can be used for any other metadata that may be provided as part of a capability's constraint information. In step 350, it is determined whether the permission is specified by an immediate operand in the instruction. For example, the permission bit value may be specified directly in the instruction by such an immediate operand, if desired. Alternatively, the value of the immediate operand may be encoded in a manner that can be used to determine which of a limited set of possible permission combinations should be used, which may require less bit space in the instruction than if the permission were specified directly by an immediate operand.

[0086] If the permission is specified by an immediate operand, the process proceeds to step 355 where the capability generation circuit 210 determines the permission from the immediate operand.

[0087] If step 350 determines that permissions are not specified by immediate operands in the instruction, then step 360 determines whether control registers should be used to provide permission information. In particular, in one exemplary implementation, for at least some generated capabilities, the necessary permission information may be stored in one or more control registers 90. If it is determined that a control register should be referenced for permission information, the process proceeds to step 365, where the permissions are determined from the permission information in the control register. As with immediate operands in the instruction, such information in the control register may directly identify the permission information or may provide an encoding used to identify any of a limited set of permission combinations to be used.

[0088] If step 360 determines that a control register is not used to provide the permission information, then step 370 obtains the permission information from redundant bits in a literal value retrieved from the literal pool, and then determines the permissions from the permission information. Thus, in some cases, rather than specifying an immediate operand or obtaining the permission information from a control register, the permission information may be encoded within redundant bits of a literal value that are not needed to form a pointer value. As with the previously described example, the permission values ​​may be specified directly within the bits, or the bits may provide an encoding used to determine which of the possible combinations of permission bits should be used.

[0089] 9, regardless of which mechanism is used, in situations where the permission information provides an encoding that allows an appropriate combination of permissions to be determined from a limited set of options, the determined permissions may depend on the operating mode of the processing circuit when the capability is generated. For example, if the processing circuit is operating in a particular privileged operating mode, the permission bits determined from a particular value of the permission information may be different from the permission bits determined if the processing circuit were operating in a less privileged mode. Furthermore, the permission bits determined from the permission information may depend on the type of capability being generated; thus, for example, the determined permission bits may differ depending on whether a general-purpose capability or a program counter capability is being generated.

[0090] FIG. 10 illustrates various different operational modes of a processing circuit that may be provided within a system. As shown in FIG. 10, the processing circuit may be arranged to operate in a secure domain and a less secure domain. Additionally or alternatively, the processing circuit may be arranged to execute program code in multiple different states, and in the example of FIG. 10, may be arranged to execute program code in a privileged or non-privileged state. Levels of privilege and different security domains may be considered orthogonal levels of trust, and thus different combinations of domains and states may be used to define different operational modes of the processing circuit. As previously explained, the manner in which constraint information for a generated capability is determined may depend on which operational mode the processing circuit is in. Furthermore, if desired, the ability to generate a capability using the techniques described herein may be limited to one or more of the operational modes; for example, a fault may be generated if an attempt is made to generate a capability in one of the unauthorized operational modes.

[0091] 11 is a flow diagram illustrating how, in one exemplary implementation, the steps taken when creating a capability may depend on whether the capability being created is a program counter capability or a general-purpose capability. In step 400, it is determined whether the destination capability register specified by the capability-creation instruction is a program counter capability register. If not, the process proceeds to step 405, where the capability is created in the manner discussed above and stored in the target general-purpose capability register identified by the instruction.

[0092] However, in one exemplary implementation, if the destination capability register is a program counter capability register, in addition to generating a capability in the manner described above and storing the generated capability in the program counter capability register in step 410, an additional step 415 is also performed, whereby program execution is caused to branch to the target instruction identified using the generated program counter capability. This avoids the need to provide a separate branch instruction to branch to that target instruction following the generation of the program counter capability.

[0093] If desired, the capability generation circuit 210 can be arranged to generate multiple capabilities in response to execution of a single capability generation instruction, as shown in FIG. 12 . For example, a type of capability generation instruction may be specified that identifies that multiple capabilities should be generated when the capability generation instruction is executed. In such a case, if it is determined in step 450 that a particular form of the capability generation instruction is being executed, the process proceeds to step 455, where a first capability is generated using the previously described process of FIG. 7 . Then, in step 460, each subsequent capability is generated using literal values ​​obtained from locations offset from the location used to obtain the literal value of the first capability. The offsets used to identify the literal values ​​for each subsequent capability may be predetermined, e.g., to identify a series of adjacent literal values ​​stored in a literal pool, or the offset information needed to identify the literal values ​​for each subsequent capability may be encoded in some format within the instruction.

[0094] According to the example shown in FIG. 12, as shown in step 460, the same constraint information is used for each of the generated capabilities and therefore does not vary between capabilities generated from a single capability-generating instruction.

[0095] In step 465, the generated capabilities are stored in a series of general-purpose capability registers. Typically, a first general-purpose capability register is explicitly identified by the capability-creating instruction, and then each additional general-purpose capability register can be inferred. For example, each subsequent general-purpose capability can follow a determined sequence. For example, a series of adjacent general-purpose capability registers starting from the capability register specified by the capability-creating instruction can be used as the sequence of general-purpose capability registers in which the generated capabilities are stored. Alternatively, some sequence-defining information can be provided in the instruction and used to identify each general-purpose capability register in which the generated capabilities should be stored. As yet another example, the instruction can explicitly identify each general-purpose destination capability register.

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

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

[0098] The simulator program 505 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a virtual hardware interface (an instruction execution environment) to the target code 500 (which may include an application, an operating system, and a hypervisor), the virtual hardware interface being the same as the hardware interface of the hardware architecture modeled by the simulator program 505. Thus, the program instructions of the target code 500 may be executed from within the instruction execution environment using the simulator program 505, thereby enabling a host computer 515, which does not actually have the hardware features of the device 2 discussed above, to emulate these features. The simulator program may include processing program logic 520 for emulating the behavior of the processing pipelines 4, 200, capability check program logic 522 for emulating the behavior of the capability check circuit 205, and capability generator logic 525 for emulating the behavior of the capability generation circuit 210 of the hardware device of FIGS. 1 and 6. Thus, the techniques described herein for generating capabilities in response to capability-generating instructions of the type described above may be performed in software by simulator program 505 in the example of FIG.

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

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

Claims

1. 1. An apparatus comprising: a processing circuit for performing an operation, during which a request to access a memory is generated, the processing circuit being arranged to generate a memory address for the access request using a capability providing a pointer value and associated constraint information; a capability generation circuit that, in response to execution by the processing circuit of a capability generation instruction that identifies a location within a literal pool of the memory, retrieves a literal value from the location within the literal pool and generates a generated capability, the pointer value of the generated capability being determined from the literal value, and the constraint information of the generated capability is selected from a limited set of options in response to information specified by the capability generation instruction; An apparatus comprising:

2. 2. The apparatus of claim 1, wherein the capability creation instruction specifies an immediate value used by the capability creation circuit in combination with a current program counter value to identify the location within the literal pool containing the literal value used to determine the pointer value of the created capability.

3. 3. The apparatus of claim 1, wherein the constraint information includes boundary information identifying a region of memory accessible using a memory address derived from the pointer value of the created capability, and the limited set of options includes a limited set of allowable sizes of the region identified by the boundary information.

4. 4. The apparatus of claim 3, wherein the capability generation instruction specifies a size index value used by the capability generation circuitry to determine the size of the region from the limited set of allowable sizes.

5. 4. The apparatus of claim 3, wherein the literal value includes some redundant bits that are not used to determine the pointer value, and wherein the capability generation circuitry is arranged to determine the size of the region from information provided in the redundant bits of the literal value.

6. 6. The apparatus of claim 5, wherein the capability generation circuitry is arranged to determine a boundary within the literal value between a first portion specifying bits used to determine the pointer value and a second portion containing the redundant bits depending on an encoding scheme used to form the literal value.

7. 7. The apparatus of claim 3, wherein the boundary information identifies a first boundary determined from the pointer value, a second boundary determined from the first boundary, and a size of the region determined from the limited set of allowable sizes.

8. 8. The apparatus of claim 1, wherein the constraint information comprises an item of metadata, and the restricted set of options comprises a restricted set of possible values ​​for the item of metadata.

9. The apparatus of claim 8 , wherein the capability generation instructions specify metadata information used by the capability generation circuitry to determine values ​​for one or more of the items of metadata.

10. 10. The apparatus of claim 8 or 9, further comprising a control register referenced by the capability generation circuit to determine values ​​for one or more of the items of metadata.

11. 11. Apparatus according to claim 8, wherein the literal value includes some redundant bits that are not used to determine the pointer value, and wherein the processing circuitry is arranged to determine values ​​for one or more of the items of metadata from information provided in the redundant bits of the literal value.

12. 12. Apparatus according to any one of claims 9 to 11, wherein the determined values ​​for the one or more items of metadata depend on a current operating mode of the processing circuitry.

13. 13. The apparatus of claim 8, wherein the item of metadata includes a plurality of permission indicators identifying permissible uses of the created capability, and wherein the restricted set of options includes a restricted set of allowed combinations of permissions that may be indicated by the plurality of permission indicators.

14. The apparatus of claim 13 , wherein the capability generation circuitry is arranged to determine the combination of permissions indicated by the plurality of permission indicators depending on the type of the generated capability.

15. 15. The apparatus of claim 14, wherein the capability creation instruction specifies a destination capability storage element, and wherein the capability creation circuitry is arranged to infer the type of the created capability from the specified destination capability storage element.

16. the capability creation instruction specifies a destination capability storage element; 16. The apparatus of claim 1, wherein if the specified destination capability storage element is a program counter capability storage element used to store a program counter capability, the processing circuitry is arranged to cause program execution to branch to a target instruction identified using the generated capability once the generated capability is stored in the program counter capability storage element.

17. the capability creation instruction specifies a destination capability storage element; 16. Apparatus according to any preceding claim, wherein the capability generation circuitry is arranged to trigger a fault if the specified destination capability storage element is a program counter capability storage element.

18. 18. Apparatus according to any one of claims 1 to 17, wherein the capability generation circuitry is arranged to generate the generated capability and one or more further generated capabilities in response to the processing circuitry executing the capability generation instruction, and wherein, for each further generated capability, the capability generation circuitry is arranged to determine the pointer value to that further generated capability from an associated literal value obtained from an associated location in the literal pool that is offset from the location identified by the capability generation instruction.

19. 20. The apparatus of claim 18, wherein the capability generation circuitry is arranged to generate the generated capability and each further generated capability having the same constraint information.

20. 20. Apparatus according to claim 18 or 19, wherein the capability creation instruction specifies a destination capability storage element for the created capability, and wherein the capability creation circuitry is arranged to derive an associated destination capability storage element for each further created capability from the specified destination capability storage element.

21. 21. The apparatus of claim 1, wherein the processing circuitry is operable in several different modes of operation, and the operation of the capability generation circuitry depends on the current mode of operation of the processing circuitry.

22. 22. The apparatus of claim 1, further comprising a capability check circuit for performing a capability check operation to determine whether a given access request, the memory address of which is generated using a given capability, is permitted based on the constraint information provided by the given capability.

23. 1. A method of restricting access to a memory, comprising: employing a processing circuit to perform an operation, during which a request to access a memory is generated, the processing circuit generating a memory address for the access request using a capability providing a pointer value and associated constraint information; performing a capability creation operation in response to the processing circuit executing a capability creation instruction that identifies a location within a literal pool of the memory, the capability creation operation including retrieving a literal value from the location within the literal pool and generating a generated capability, the pointer value of the generated capability being determined from the literal value, and the constraint information of the generated capability being selected from a limited set of options in response to information specified by the capability creation instruction; A method comprising:

24. 1. A computer program for controlling a host data processing device to provide an instruction execution environment, comprising: processing program logic for performing an operation, during which a request to access a memory is generated, the processing program logic being arranged to generate a memory address for the access request using a capability providing a pointer value and associated constraint information; capability generator logic that, in response to execution by the processing program logic of a capability creation instruction that identifies a location within a literal pool of memory, retrieves a literal value from the location within the literal pool and generates a generated capability, the pointer value of the generated capability being determined from the literal value, and the constraint information for the generated capability is selected from a limited set of options in response to information specified by the capability creation instruction; A computer program comprising:

Images