Apparatus and method for capability based processing

Abstract

An apparatus comprising a processor to execute program instructions stored at respective memory addresses, processing of the program instructions being constrained by at least a primary capability defining access rights to a set of one or more memory addresses; the processor comprising: control flow alteration processing circuitry to implement a control flow alteration operation defining a control flow alteration target address indicative of an address of a program instruction to execute after the control flow alteration operation; and capability generation circuitry to determine, from the control flow alteration target address, an address at which capability access rights data is stored; the capability generation circuitry configured to retrieve the capability access rights data and generate, from at least the capability access rights data, a capability to use as a next primary capability.

Description

[0001] Note

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

[0003] The present disclosure relates to apparatuses and methods.

[0004] Some examples of data processing apparatuses process procedures in which memory accesses are determined by so-called capability data. In some examples, pointers are augmented with metadata to represent specific access restrictions and / or permissions.

[0005] An example of such an arrangement is discussed in the paper "CHERI: A Hybrid Capability-System Architecture for Scalable Software Compartmentalization", IEEE Symposium on Security and Privacy, 17-21 May 2015, ISBN 978-1-4673-6949-7, the contents of which are incorporated herein by reference.

[0006] In the case of a change in control flow from a first code section to a second code section (e.g. a branch, although other examples such as exception handling are also applicable), in order to effectively exploit the security features provided by these capabilities, the first capability applicable to execute the first code section should allow access to the first code section, and therefore a change to the second capability (to allow access to the second code section) is required to effect the change in control flow.

[0007] One way of achieving this is to store data defining the second capability in the first code section, for example as literal data. This then requires at least two operations to effect the change in control flow: an operation to load the data and apply it as the new capability; and an operation to effect the change in control flow. SUMMARY

[0008] In one example arrangement, there is provided an apparatus comprising:

[0009] a processor to execute program instructions stored at respective memory addresses, processing of the program instructions being subject to at least a primary capability defining access permissions to a set of one or more memory addresses; the processor comprising:

[0010] control flow alteration processing circuitry to implement a control flow alteration operation defining a control flow alteration target address indicative of an address of a program instruction to be executed after the control flow alteration operation; and

[0011] capability generation circuitry to determine, from the control flow alteration target address, an address at which capability access right data is stored;

[0012] the capability generation circuitry is configured to retrieve the capability access right data and to generate, at least from the capability access right data, a capability to be used as a next primary capability.

[0013] In another exemplary arrangement, a method is provided, the method comprising:

[0014] executing program instructions stored at respective memory addresses, processing of which is subject to constraints of at least a primary capability defining access rights to a set of one or more memory addresses;

[0015] implementing a control flow alteration operation defining a control flow alteration target address indicative of an address of a program instruction to be executed after the control flow alteration operation;

[0016] determining, from the control flow alteration target address, an address at which capability access right data is stored;

[0017] retrieving the capability access right data; and

[0018] generating, at least from the capability access right data, a capability to be used as a next primary capability.

[0019] In another exemplary arrangement, a computer program is provided for controlling a host data processing apparatus to provide an instruction execution environment and comprising:

[0020] processor logic to execute program instructions stored at respective memory addresses, processing of which is subject to constraints of at least a primary capability defining access rights to a set of one or more memory addresses; the processor logic comprising:

[0021] control flow alteration processing logic to implement a control flow alteration operation defining a control flow alteration target address indicative of an address of a program instruction to be executed after the control flow alteration operation; and

[0022] capability generation logic to determine, from the control flow alteration target address, an address at which capability access right data is stored;

[0023] The capability generation logic is configured to retrieve the capability access right data and to generate, at least in dependence on the capability access right data, a capability for use as a next primary capability.

[0024] Further respective aspects and features of the present technology are defined by the claims appended hereto. BRIEF DESCRIPTION OF DRAWINGS

[0025] The present technology will be further described, by way of example only, with reference to the accompanying drawings in which embodiments of the application are shown:

[0026] Figure 1 A data processing apparatus is schematically illustrated;

[0027] Figure 2 A bounded pointer is schematically illustrated;

[0028] Figure 3 Use of a capability register is schematically illustrated;

[0029] Figure 4 A set of capability fields is schematically represented;

[0030] Figure 5 A control flow altering operation is schematically illustrated;

[0031] Figure 6 And Figure 7 Options for storing capability access right data are schematically illustrated;

[0032] Figure 8 A schematic overview of control flow altering processing circuitry is provided;

[0033] Figure 9 An example of capability generation circuitry is schematically illustrated;

[0034] Figure 10 And Figure 11 A respective example of capability generation is schematically illustrated;

[0035] Figure 12 Is a schematic timeline illustrating one example of capability generation;

[0036] Figure 13 A schematic overview of another example of control flow altering processing circuitry is provided;

[0037] Figure 14 Is a schematic timeline illustrating another example of capability generation;

[0038] Figure 15 Another example of control flow alteration is schematically illustrated;

[0039] Figure 16is a schematic flow diagram illustrating a method; and

[0040] Figure 17 An emulator implementation is schematically illustrated. DETAILED DESCRIPTION

[0041] The following description of implementations provides details of specific implementations. These are intended to provide specific examples of possible implementations. Other implementations can be implemented using both processes and apparatuses described below.

[0042] An example implementation provides an apparatus comprising:

[0043] a processor to execute program instructions stored at respective memory addresses, processing of the program instructions being subject to at least a primary capability defining access rights to a set of one or more memory addresses; the processor comprising:

[0044] control flow alteration handling circuitry to implement a control flow alteration operation defining a control flow alteration target address indicative of an address of a program instruction executed after the control flow alteration operation; and

[0045] capability generation circuitry to determine, from the control flow alteration target address, an address at which capability access rights data is stored;

[0046] the capability generation circuitry is configured to retrieve the capability access rights data and to generate, from at least the capability access rights data, a capability for use as a next primary capability.

[0047] In an example arrangement, instead of providing capability information for a control flow alteration at a call code portion, appropriate capability information is provided at an address defined relative to the control flow alteration target address to allow a capability to be constructed or generated for use as a capability configured to constrain processing of one or more instructions executed after the control flow alteration operation. This advantageously allows capability data to be stored only once and can provide for more efficient capability alteration on control flow alterations.

[0048] In some (but not all) examples, the control flow alteration target address can be indicative of an address of a next program instruction executed after the control flow alteration operation. In other examples, one or more so-called branch stall slots can be used such that a branch does not necessarily take effect immediately. In some such examples, the instruction next executed after a branch instruction is simply the instruction after the branch in memory, not necessarily the instruction at the target address of the branch. In the case of a single branch stall slot being used, control will move to the branch target address after the instruction after the branch in memory.

[0049] In some examples, only part of the new capability needs to be stored in relation to the target address. For example, where each capability comprises at least a pointer and data defining access rights to a set of memory addresses, the capability generation circuitry can be configured to generate the pointer in dependence on the control flow change target address and to generate the data defining access rights to a set of memory addresses in dependence on the capability access rights data. In other examples, the entire capability can be stored in relation to the target address.

[0050] In examples, the capability access rights data defines one or more of: (i) a lower bound memory address of an address region comprising one or more memory addresses for which access is permitted; (ii) an upper bound memory address of the address region; and (iii) a set of rights attributes applicable to the address region. In other examples, the capability access rights data defines a location at which information defining access rights to a set of memory addresses is stored.

[0051] In some examples, execution of the (at least) first instruction following the flow change can be implemented in parallel (or at least overlap) with generation of the new capability. In such cases, in response to the control flow change operation, the processor can be configured to set a state indicator to indicate that the capability generation circuitry is required to generate a capability for use as the next primary capability. In response to the state indicator being set, the processor can be configured to fetch and / or execute at least the first instruction at the control flow change target address without being subject to the primary capability.

[0052] Once the new capability is ready, the state indicator can be cleared, in which case the processor can be configured to clear the state indicator to a state indicating that processing of program instructions is subject to the primary capability in response to generation of the capability for use as the next primary capability. To allow this state to be maintained and restored in the event of an intervening exception, in some examples the processor is configured to store the state indicator in response to a processing exception event so as to be retrieved upon a processing exception return event.

[0053] In other examples, generation of the new capability can be completed before the first instruction needs to be executed, in which case the one or more instructions for execution following the control flow change operation comprise at least the instruction at the control flow change target address.

[0054] In some examples, the first instruction can be at the target address, in which case the control flow change processing circuitry is configured to determine the address at which the capability access rights data is stored as a memory address preceding the control flow change target address.

[0055] In some examples, the control flow altering operation is a branch operation responsive to execution of a branch instruction, which can include an operation code that defines at least the control flow alteration target address by encoding within the operation code a value indicative of a difference from an instruction address of the branch instruction. In other examples, the operation code can define at least a register identifier that identifies a register containing a value indicative of the control flow alteration target address.

[0056] In other examples, the control flow altering operation can be a branch and link operation responsive to execution of a branch and link instruction, in which case the branch and link operation can store a return address capability that is generated from an instruction address of the branch and link instruction and a primary capability used when executing the branch and link instruction.

[0057] In other examples, the control flow altering operation can define an alteration to control flow of processing an exception handling routine, as an alternative to (or in addition to) a branch operation. In such cases, the processor can be configured to identify an entry in a vector table in memory according to a number associated with the exception handling routine to be processed, where at least part of the entry indicates the control flow alteration target address, and at least part of the entry can indicate whether the exception handling routine is to be processed without constraint by a primary capability (e.g., the vector table can only indicate the target address, and the question of whether the exception handler uses a capability can be determined elsewhere; e.g., it can always use a capability, or there can be a configuration bit to control how all exceptions are handled). Another example of a control flow altering operation includes an exception return operation that returns from processing such an exception handling routine.

[0058] Another example embodiment provides a method comprising:

[0059] executing program instructions stored at respective memory addresses, processing of the program instructions being constrained by at least a primary capability that defines access rights to a set of one or more memory addresses;

[0060] implementing a control flow altering operation that defines a control flow alteration target address indicative of an address of a program instruction executed after the control flow altering operation;

[0061] determining an address from which capability access rights data is stored according to the control flow alteration target address;

[0062] retrieving the capability access rights data; and

[0063] generating a capability for use as a next primary capability according to at least the capability access rights data.

[0064] Another example embodiment provides a computer program for controlling a host data processing apparatus to provide an instruction execution environment, and comprising:

[0065] processor logic to execute program instructions stored at respective memory addresses, processing of which is subject to at least a primary capability defining access rights to a set of one or more memory addresses; the processor logic comprising:

[0066] control flow change handling logic to implement a control flow change operation defining a control flow change target address indicative of an address of a program instruction for execution after the control flow change operation; and

[0067] capability generation logic to determine, from the control flow change target address, an address at which capability access rights data is stored;

[0068] the capability generation logic is configured to retrieve the capability access rights data and to generate, from at least the capability access rights data, a capability for use as a next primary capability.

[0069] Apparatus overview

[0070] Reference is now made to the drawings, in which Figure 1 An example of a data processing apparatus or processor 2 comprising a processing pipeline 4 for processing instructions is shown schematically. In this example, the processing pipeline 4 comprises a plurality of pipeline stages, including a fetch stage 6, a decode stage 8, an issue stage 10, an execution stage or processing element 12 and a write back stage 14, although it will be appreciated that other types or combinations of stages can be provided. For example, in some implementations a rename stage for implementing register renaming can be included. Instructions to be processed move from one stage to another, and while an instruction is pending at one stage another instruction can be pending at a different stage of the pipeline 4.

[0071] Fetch stage 6 fetches instructions from a level 1 (LI) instruction cache 20. Fetch stage 6 can generally fetch instructions sequentially from consecutive instruction addresses. However, the fetch stage can also have a branch predictor 22 to predict the outcome of branch instructions, and if a branch is predicted to be taken, fetch stage 6 can fetch instructions from the (non-sequential) branch target address, or if a branch is predicted not to be taken, fetch instructions from the next sequential address. Branch predictor 22 can include one or more branch history tables to store information used to predict whether certain branches are likely to be taken. For example, a branch history table can include a counter to track the actual outcome of previously executed branches or to represent the confidence in a prediction made for a branch. Branch predictor 22 can also include a branch target address cache (BTAC) 24 to cache previous target addresses for branch instructions so that these addresses can be predicted when the same branch instruction is encountered later. It will be appreciated that features such as instruction cache 20 and branch predictor 22 can not be present in other embodiments (e.g., lower performance embodiments where the circuit area is important).

[0072] The fetched instructions are passed to a decode stage 8, which decodes the instructions to generate decoded instructions. The decoded instructions can include control information used to control execution stage 12 to perform the appropriate processing operations. For some more complex instructions fetched from cache 20, decode stage 8 can map those instructions to multiple decoded instructions, which can be referred to as micro-operations (μop or uop). Thus, there can not be a one-to-one relationship between instructions fetched from LI instruction cache 20 and the instructions seen by later stages of the pipeline. In general, references to “instructions” in this application should be interpreted to include micro-operations.

[0073] The decoded instructions are passed to an issue stage 10, which determines whether the operands needed to execute the instructions are available, and when the operands are available, issues the instructions for execution. Some embodiments can support in-order processing, such that instructions are issued to be executed in an order that corresponds to the program order in which the instructions were fetched from LI instruction cache 20. Other embodiments can support out-of-order execution, such that instructions can be issued to execution stage 12 in an order that is different from the program order. Out-of-order processing helps to improve performance because, in cases where a current instruction is stalled while waiting for an operand, a later instruction in program order for which the operand is available can be executed first. It will be appreciated that in other embodiments, issue stage 10 can be combined with other stages, or not considered at all at the expense of performance.

[0074] The issue stage 10 issues instructions to an execution stage 12 in which the instructions are executed to perform various data processing operations. For example, the execution stage can include a number of execution units 30, 32, 33, 34, including an arithmetic / logical 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 form, a control flow alteration handling unit or circuit 33 for implementing control flow alteration operations (in one example, this unit embodies the functionality of a branch instruction execution unit for determining the actual outcome of a branch operation), and a load / store unit 34 for performing load operations to load data values from a level 1 (L1) data cache 36 into registers within a set of general purpose data registers 40, or store operations to store data values from registers within the set of general purpose data registers 40 to the L1 data cache 36. It will be appreciated that these are merely some examples of the types of execution units that can be provided, and that many other kinds can also be provided. In other embodiments, the level 1 data cache 36 can not be present, and the load / store unit 34 can access memory directly. To perform processing operations, the execution stage 12 can read data values from the set of registers 40. Results of the executed instructions can then be written back to the registers 40 by the write back stage 14.

[0075] The exception handling circuit 9 will be discussed further below.

[0076] The L1 instruction cache 20 and the L1 data cache 36 can be part of a cache hierarchy including multiple levels of cache. For example, a level two (L2) cache 44 can also be provided, and optional further cache levels can 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 can have separate L2 instruction and data caches. When an instruction to be fetched is not in the L1 instruction cache 20, then the instruction can be fetched from the L2 cache 44, and if the instruction is not in the L2 cache 44, then the instruction can be fetched from the main memory 50. Similarly, in response to a load instruction, if data is not in the L1 data cache 36, then the data can be fetched from the L2 data cache 44, and if necessary, from the memory 50. Any known scheme can be used to manage the cache hierarchy.

[0077] The addresses used by the pipeline 4 to reference program instructions and data values can be virtual addresses, but at least the main memory 50 and optionally also at least some levels of the cache hierarchy and / or the memory 50 can be physically addressed. Thus, a translation lookaside buffer 52 (TLB) can be provided under the control of a memory management unit (MMU) 53 for converting virtual addresses used by the pipeline 4 into physical addresses for accessing the cache or memory. For example, the TLB 52 can comprise a plurality of entries each specifying a virtual page address (“VPA”) of a corresponding page of the virtual address space and a corresponding physical page address (“PPA”) to which the virtual page address should be mapped in order to convert virtual addresses within the corresponding page into physical addresses. For example, the virtual and physical page addresses can correspond to the most significant parts of the corresponding virtual and physical addresses, the remaining least significant parts remaining unchanged when mapping virtual addresses to physical addresses. In addition to the address translation information, each TLB entry can also include some information specifying access permissions (“perm”), for example indicating whether certain address pages are accessible in certain modes of the pipeline 4. In some embodiments, the TLB entries can also define other attributes of the corresponding address pages, for example cache policy information defining which levels of the cache hierarchy are updated in response to read or write operations (e.g. whether the cache should operate in write-back mode or in direct-write mode), or information defining whether data accesses to addresses in the corresponding page can be reordered by the memory system compared to the order in which the data accesses are issued by the pipeline 4. In other embodiments, the MMU 53 and TLB 52 can not be present, and the instructions executed by the data processing apparatus 2 can directly access physical addresses. In such embodiments, the access permissions and cache policy information can instead be provided by a memory protection unit (MPU) 54, which contains registers specifying information relating to ranges of addresses in the physical memory.

[0078] While Figure 1A single level TLB 52 is shown, but it will be appreciated that a translation hierarchy can be provided by the MMU 53 and / or multiple TLBs can be provided, such that a level one (LI) TLB 52 can comprise TLB entries for translating addresses in a number of recently accessed pages, and a level two (L2) TLB can be provided for storing entries for a larger number of pages. When a required entry is not present in the LI TLB, then the required entry can be fetched from the L2 TLB or from other TLBs in the hierarchy. Alternatively, a so-called intermediate physical address (IPA) can be used, such that a first translation is from a virtual address to an IPA, and a second level of translation is from the IPA to a physical address. In this way, multiple levels of address translation can be used, such that for example a first TLB (or hierarchy of TLBs) can be used to translate a virtual address to an intermediate address, and a second level of address translation using one or more further TLBs can then translate the intermediate address to a physical address for accessing a cache or memory. This is very useful for supporting virtualisation, where for example a first level of address translation can be managed by an operating system, and a second level of address translation can be managed by a hypervisor.

[0079] In Figure 1 For clarity of illustration, a single stage and level of TLB 52 is shown.

[0080] If a required entry for a page to be accessed is not present in any of the TLBs, then a page table walk can be implemented by the MMU 53 to access a so-called page table in the memory 50. Any known TLB management scheme can be used in the present technology.

[0081] In some examples, the execution stage 12 can be implemented by a multi-threaded processing element to execute one or more processing threads.

[0082] As Figure 1 shown, the apparatus 2 can have a set of bounded pointer registers 60. Although this set of bounded pointer registers is shown as being physically separate from the set of general purpose data registers 40 in Figure 1 In one implementation, the same physical storage can be used to provide both general purpose data registers and bounded pointer registers.

[0083] Each bounded pointer register 60 includes a pointer value 62 that can be used to determine an address of a data value to be accessed, and range information 64 that specifies an allowable range of addresses when the corresponding pointer 62 is used. The bounded pointer register 60 can also include limit information 66 (also referred to as permission information) that can define one or more restrictions / permissions with respect to use of the pointer. A validity flag (e.g., bit 65 in the case of a 64-bit bounded pointer register, or bit 129 in the case of a 128-bit bounded pointer) can be used to indicate (a) whether a valid bounded pointer is stored, and (b) whether the range and permission metadata is valid. The flag can only be set by hardware in response to an appropriate capability set instruction, and in at least some examples is automatically unset in response to any attempt to write a non-valid capability.

[0084] For example, the limit 66 can be used to limit the type of instruction that can use the pointer 62, or the mode of the pipeline 4 in which the pointer can be used. Thus, the range information 64 and the limit information 66 can be considered to define a capability Co-Cn in which the corresponding pointer 62 can be used. M-1 When an attempt is made to use the pointer 62 outside of the defined capability, an error can be triggered.

[0085] The range information 64 can be used, for example, to ensure that the pointer remains within certain known bounds and does not stray into other regions of memory address space that can contain sensitive or secure information. In implementations in which the same physical storage is used for general purpose data registers and bounded pointer registers, then in one implementation the pointer value 62 can be stored, for example, within the same storage location as for the corresponding general purpose register.

[0086] Figure 2 An example of a type of instruction that uses an allowed range to prevent unauthorized access to data or instructions is shown. As shown in the upper portion of Figure 2 As shown in the upper portion of

[0087] For example, as shown in the lower portion of Figure 2As shown in part A of FIG. 6, in some systems, an error can be triggered if an attempt is made to set the value of a pointer 62 in a pointer register 60 to a value outside of a range specified by range information 64 (here, assume the pointer directly specifies an address). This avoids the pointer 62 ever taking on any value outside of the specified range, and thus can ensure that any access using the pointer is safely within the allowed range. Alternatively, as shown in part B of FIG. 6, an error can be triggered when an instruction attempts to access a location identified by the address of the pointer 62, if that address is outside of the specified range. Thus, it can still be allowed to set the pointer 62 to a value outside of the specified range, but once an attempt is made to access data at the pointer address (or an address derived from the pointer), an error can be triggered if the address is outside of the allowed range. Other systems can trigger an error in response to the types of instructions shown in parts A and B of FIG. 6. Figure 2 Figure 2

[0088] The range information 64 can be set in different ways and the manner in which it is set is an implementation detail, and the present technology does not depend on the particular method used. By way of example only, privileged instructions, user space code, security code, or an operating system or hypervisor can specify the range allowed for a given pointer. For example, an instruction set architecture can include multiple instructions for setting or modifying the range information 64 for a given pointer 62, and execution of these instructions can be limited to certain software or certain modes or exception states of the processor 2. Any known technique for setting or modifying the range information 64 can be used.

[0089] In addition to the set of bounded pointer storage elements 60 that can be used in the execute stage 12 when certain instructions referencing the pointers are executed, a program counter capability (PCC) register 80 can be used to provide similar functionality in the fetch stage 6 when instructions are fetched from the hierarchy of instruction caches 20. In particular, a program counter pointer can be stored in a field 82, with the PCC 80 also providing range information 84 and any appropriate limit information 86, similar to the range and limit information provided by each pointer in the set of bounded pointer storage elements 60. Figure 1 A default data capability (DDC) register 90 and a system access capability (SAC) register 95, which will be discussed below, are also shown schematically. It will be appreciated that in some embodiments, all data accesses can be directly constrained by capabilities stored in the bounded pointer storage elements 60, and thus the default data capability register 60 can not be needed. Similarly, the system access capability register 65 is not essential to the present disclosure, and can not be present in some embodiments.

[0090] Figure 3 ​​How the above type of tag bit is used in conjunction with individual data blocks to identify whether those data blocks represent capabilities (i.e. bounded pointers and associated limit information) or normal data is now illustrated schematically. In particular, the memory address space 110 will store a series of data blocks 115, which will typically have a specified size. For the purposes of illustration only, it is assumed in this example that each data block comprises 128 bits. Associated with each data block 115, a tag field 120 is provided, which in one example is a single bit field known as a tag bit, which is set to identify that the associated data block represents a valid capability and is cleared to indicate that the associated data block represents normal data and thus cannot be treated as a capability. It will be appreciated that the actual value associated with the set or clear state can vary depending on the particular implementation, but by way of illustration only, in one example implementation, if the tag bit has a value of 1, then it indicates that the associated data block is a capability, whereas if the tag bit has a value of 0, then it indicates that the associated data block contains normal data.

[0091] When a capability is loaded into one of the bounded pointer registers (also referred to as capability registers) in the bounded pointer register 60, such as the capability register 100 shown, then the tag bit moves with the capability information. Thus, when a capability is loaded into the capability register 100, the pointer 102, range information 104 and limit information 106 (hereinafter referred to as permissions information) will be loaded into the capability register. In addition, associated with or as a particular bit field within the capability register, the tag bit 108 will be set to identify that the contents represent a capability. Similarly, when a capability is stored back to memory, the associated tag bit 120 will be set in association with the data block storing the capability. In this way, capabilities and normal data can be distinguished and thus it is ensured that normal data cannot be used as a capability. Figure 3

[0092] Capabilities

[0093] Capabilities will now be discussed in more detail.

[0094] Whilst higher level applications can be arranged to run in "safe" constrained execution environments such as JAVA and JavaScript, the lower layers of the system must typically provide a link to the actual execution on the hardware. Thus, currently almost all of these layers are written in the C / C++ programming language, which is typically composed of tens of millions of lines of trusted (but not trustworthy) code.

[0095] The aim is to provide an underlying architecture to provide a stronger inherent immunity to malicious attacks. Capabilities can provide part of such a strategy.

[0096] ​Capability data types represent removable authorization tokens that access one or more architecturally defined resources. Capabilities are broadly categorized into three types:

[0097] 1) Memory capabilities for granting access to memory ranges for data transfer and instruction fetch

[0098] 2) System access capabilities for granting access to certain system operations

[0099] 3) Sealed capabilities for encapsulating other capabilities with an object type

[0100] Each capability contains a number of logical fields, some of which only exist in certain capability types. Examples of such fields are shown schematically in Figure 4 .

[0101] Capability registers are used to hold capabilities and define extensions to the memory system such that capability properties are enforced when capabilities are held in general-purpose memory. Instructions can be provided to load and store capabilities from memory, access data and capabilities in memory using capability registers, branch using capabilities, and mediate capabilities held in capability registers without forging new permissions.

[0102] The restrictions that result from using capabilities exceed those enforced by existing MMU or MPU and exception level based restrictions. Using capabilities can be arranged to not undermine the protections already provided by these mechanisms.

[0103] Environmental capabilities

[0104] One or more (e.g. three) environment capability registers can be provided that define an environment capability. Using these facilities, the environmental effects of capability extensions can be enabled and disabled at each exception level. Enabling environmental effects at an exception level enables the effects of the environment capability register, modifies the behavior of exception inputs and returns to level, and modifies the behavior of several existing instructions that naturally run on addresses. In some examples, three environment capability registers are provided:

[0105] (a) Program Counter Capability (PCC) register

[0106] This restricts the use of instruction fetches. Capability branch and return instructions can be used and the PCC bounds and permissions are updated for exception inputs and returns.

[0107] (b) Default Data Capability (DDC) register

[0108] The PCC affects data accesses relative to the program counter. Other data accesses are restricted by implicit use of the default data capability as a base register or explicit use of a capability.

[0109] (c) System Access Capabilities (SAC) register

[0110] Access to system registers and system operations can be limited by permissions held in the SAC register.

[0111] Control flow altering operations

[0112] Figure 5 An example of a control flow altering operation is schematically illustrated.

[0113] In this first example, the control flow altering operation is a branch operation (in response to execution of a branch instruction), in which the branch instructions 500, 510 cause the program flow to alter from the respective first (or "calling") code section 505, 515 to a control flow alteration target address 522 indicating the start of a target or "called" code section 520 (or other predetermined location).

[0114] In some examples, the branch instruction can comprise an operation code which defines at least the control flow alteration target address by indicating a value which is the difference from the instruction address of the branch instruction. In other examples, the branch instruction can comprise an operation code which can define at least a register identifier which identifies a register containing a value indicating the control flow alteration target address.

[0115] In some examples, once the code section 520 has been executed, control can return to the calling or originating code section (505, 515 as appropriate). In some examples, the latter feature can be achieved by use of a so-called branch and link operation, in which a return address to the originating code (in some embodiments, actually the next instruction address after the branch instruction) is reserved, for example as part of the control flow altering operation, which can be stored on a stack data structure or in a link register within the set of general purpose data registers 40. In some embodiments, the return address can be a return address capability, containing in addition to the return address, a capability to act as the primary capability of the originating code. The return capability can be derived from the primary capability used at the point where the branch and link operation is implemented.

[0116] In the example of Figure 5 two possible originating code sections 505, 515 are shown. In practice, any number of branch instructions can result in redirection to the code section 520; Figure 5 the fact that two branch instructions are shown in

[0117] The implementation of code section 505 is performed according to a primary first capability providing access rights to a first range 508 of memory addresses for the processing of program instructions, e.g. including the entire code section 505. Similarly, code section 515 is processed according to constraints defined by the capability providing access to memory addresses 518. However, in order to execute the program instructions of code section 520, i.e. the instructions executed after the control flow altering operation, a different capability 528 providing access rights to the memory addresses containing code section 520 is required (as a new or next primary capability).

[0118] A previously proposed technique for achieving this is to execute instructions associated with branch instructions 500, 510 to load data stored within the calling code sections 505, 515 into the respective capability registers. Such data can be stored as so-called literal data, e.g. at the end of the respective code section (as shown in the lower part). However, this can require additional instructions and also storage space at each possible instance of a calling function. Such a technique can also cause a performance bottleneck as the capability has to be loaded before the target address of the branch can be determined. This in turn can slow down the execution of instructions at the target code section 520. Another example of a control flow altering operation is taken by an exception. A prior art technique for determining the target address of an exception input control flow altering operation is to have a table of addresses indexed by the number of the input exception. In order to implement the indexing into such a table, such a system typically requires all entries within the table to have the same size. In a processor 2 supporting the use of capability exception handlers, this in turn means that each entry in the table has to be large enough to store a capability, even though a large portion of exception handlers do not use capabilities. The wasted space can be significant for small embedded processors typically having very small amounts of memory or for systems having a large number of exception handlers.

[0119] In the exemplary arrangement to be discussed below, rather than storing a respective separate copy at each potential calling code section, the address at which capability access rights data is stored is determined depending on the control flow altering target address; this capability access rights data is retrieved and at least a capability is generated from this capability access rights data for use as the next primary capability. In embodiments, the generated capability is installed or otherwise established as the next primary capability. In some examples, this takes effect from the first instruction of the called code. In other examples, one or more first instructions of the called code can be processed in parallel to the primary capability.

[0120] PCC as primary capability

[0121] From an architectural perspective (to be discussed below), the control flow altering operation can involve:

[0122] • extracting the newly generated capability

[0123] • the branch is split to set the PCC to the capability

[0124] • the new PCC value is checked to see if it allows the next instruction to be fetched, and only if it does is the next instruction fetched

[0125] Thus, in these examples, reference to the constraint by the primary capability relates to setting the PCC in response to capability data associated with execution of a particular code portion.

[0126] Notes on branch prediction, speculative processing and / or out-of-order processing

[0127] In example embodiments, the capability is checked in instruction fetch to determine if there is permission to access addresses to be fetched. If not, an exception or fault can be initiated.

[0128] In a hypothetical example involving a branch to an invalid capability that points to an undefined instruction, if the capability is checked before instruction fetch occurs, an "invalid capability fault" is expected to occur, rather than an "undefined instruction fault" (which occurs if the PCC capability check is made at execution time).

[0129] However, in Figure 1 In the example shown, branch predictor 22 oversees the fetch process so that instructions related to a branch target address (or indeed another control flow change target address) can be fetched in stage (time) before the branch is resolved.

[0130] In other examples, instructions can be executed out of order, again making it possible to physically fetch instructions from addresses before the capability related to those addresses is in place. In other examples, pipelining, caching, and other techniques can change the physical way in which instructions are processed, often with the goal of improving processing efficiency.

[0131] To reconcile these situations, it is noted that there is a difference between the actual physical circuitry that provides instruction processing and the processor and instruction set architecture that define the related behavior of the instructions.

[0132] An instruction set architecture can provide a common set of instructions that are processed by in-order processors, out-of-order processors, processors with and without speculation or prediction fetch or execution, processors with and without pipelining, etc. In each case, the end result and the overall machine result are the same; it is just that the efficiency of the internal processing can be different.

[0133] From an architectural perspective, each instruction is executed completely before the next instruction is fetched.

[0134] In cases where the processor introduces some temporal overlap into instruction processing (e.g., through pipelining, superscalar, and / or out-of-order execution), the role of such circuitry is to provide exactly the same results as would apply in the architectural case described above.

[0135] Similarly, in cases where any form of speculative processing is provided, the speculative state is maintained (this can include maintaining a fault condition as speculative) as long as it is necessary to satisfy architectural requirements.

[0136] For example, the micro-architecture or physical architecture can maintain the illusion of operating according to the architecture by keeping a fault result in a speculative state, and then if the committed architectural state reaches the point at which the speculative fault occurred, the fault is moved from being a speculative fault to becoming an actual fault and actually occurring. On the other hand, if another event causes the architectural state to develop in a different direction (e.g., in the case of a branch miss prediction), the pending speculative fault will be cleared because the event that caused the speculative fault was not supposed to occur in the first place.

[0137] Thus, those skilled in the art will appreciate that established techniques such as pipelining and speculative execution can be implemented by those of ordinary skill in the art without departing from the scope of the present disclosure.

[0138] Capability access rights data store

[0139] Figure 6 and Figure 7 Some options for accessing capability access rights data in relation to an address 600 indicated by a control flow altering operation (e.g., a branch target address) as a control flow alteration target address are illustrated schematically. In Figure 6 In the example of FIG. 6A, the address 600 indicates a location of a first instruction 610 to be executed after the control flow altering operation, with capability access rights data 620 (shown as shaded in Figure 6 and Figure 7 stored in the 32 bits of memory immediately preceding the address 600. For example, if the capability access rights data 620 is 32 bits long, it is stored in the 32 bits of memory immediately preceding the address 600.

[0140] Thus, in the example of Figure 6 the one or more instructions for execution after the control flow altering operation include at least the instruction at the control flow alteration target address.

[0141] In the example of Figure 7In this case, the capability access permission data 700 is stored at address 600, with the first instruction 710 to be executed after the control flow altering operation (instruction 710) immediately following the stored capability access permission data 700. Again, in the example where the capability access permission data 620 is 32 bits long, the first instruction 710 will be stored at a 32-bit address following address 700.

[0142] Thus, in Figure 7 In this case, the capability access permission data 700 is stored at address 600, with the first instruction 710 to be executed after the control flow altering operation (instruction 710) immediately following the stored capability access permission data 700. Again, in the example where the capability access permission data 620 is 32 bits long, the first instruction 710 will be stored at a 32-bit address following address 700.

[0143] Control flow altering processing

[0144] Figure 8 Provided is a control flow altering processing circuit 33 as mentioned above, comprising a control flow altering processing program 800 and a capability generation circuit 810. Figure 1 A schematic overview of the control flow altering processing circuit 33 is mentioned above, comprising a control flow altering processing program 800 and a capability generation circuit 810.

[0145] Referring to Figure 9 This figure schematically illustrates an example of the capability generation circuit 810 of Figure 8 detecting a control flow altering target address 900 (such as a branch target address) by an address detector 910, and in response thereto, the address detector 910 determines the location of the capability access permission data (capability metadata). This determination can be as simple as “the address equal to the control flow altering target address” as in the example of Figure 7 or can be “an address offset from the address 900 by a predetermined difference” as in the example of Figure 6 for example “the address 900 minus 32 bits”.

[0146] In response to determining the address of the metadata, a metadata loader 920 loads the capability access permission data 930. A capability generator 940 generates the capability. Examples of this operation are described below with reference to Figure 10 and Figure 11 In some examples, the capability generator 940 can optionally concatenate the loaded metadata 930 and the target address 900 using a tag to produce a valid capability which is stored as the capability 950 by a storage circuit 960. For example, the storage circuit 960 can store the generated capability 960 to the PCC 80. The generated capability 950 is provided for use as the next primary capability, for example to constrain the processing of one or more instructions executed after the control flow altering operation.

[0147] Capability generation

[0148] Referring to Figure 10The capability generator 940 constructs the capability 1000 as a concatenation of the metadata 930 and the pointer 935 derived from the target address 900. The capability generation circuit 940 can add a tag bit 1010 indicating that this is a valid capability (note that allowing the storage of a tag bit in response to a valid instruction under hardware control).

[0149] In Figure 11 the metadata 930 includes a tag bit 1020 so that after concatenation, the resulting capability 1100 includes the tag bit.

[0150] Note that in Figure 10 and Figure 11 any of the examples above, the concatenation with the pointer derived from the control flow change target address 900 means that the capability access rights data can be smaller than the regular capability, only needing to provide the part of the capability not represented by the pointer part itself. In this example, this means that the capability access rights data can be only 32 (or 33) bits, rather than the actual size of the capability, which in this example is 65 bits. Thus, it is possible to save storage space using this technique. Since the capability metadata 930 can only be stored once per code section 520, additional storage space can be saved if the code section is called from multiple locations, e.g. 500 and 510 in Figure 5

[0151] Thus, in these examples, each capability includes at least a pointer and data defining access rights to a set of memory addresses; and the capability generation circuit is configured to generate the pointer from the control flow change target address and to generate the data defining access rights to the set of memory addresses from the capability access rights data.

[0152] In some examples, the capability access rights data defines one or more of: (i) a lower limit memory address of an address region comprising one or more memory addresses for which access is permitted; (ii) an upper limit memory address of the address region; and (iii) a set of rights attributes applicable to the address region. However, it should be noted that in other examples, the capability access rights data can instead define a location storing information defining access rights to the set of memory addresses.

[0153] Timing in relation to generation of next primary capability

[0154] Figures 12 to 14 Timing considerations relating to the generation of capabilities in the manner discussed above.

[0155] Figure 12 ​is a schematic timeline from an architectural perspective (in which instruction execution is atomic, so instructions are treated as having been executed or not executed, and the boundaries between instructions are indicated schematically by the vertical lines drawn), in which time runs from left to right 1200, showing one example of generating a capability from capability access rights data. It will be appreciated that common microarchitectural techniques such as pipelining and no-ops (as previously discussed) can alter the actual ordering of events, but such techniques will preserve the illusion of the architectural ordering shown in Figure 12

[0156] Schematic block 1210 represents the process implemented to generate the next capability (e.g., to constrain the processing of one or more instructions executed after the control flow change operation), and schematic block 1220 represents the actual processing of the first instruction after the control flow change operation. The control flow change operation itself is indicated by schematic block 1230 on the timeline.

[0157] In the example of Figure 12 , the generation of the new capability is completed before the first instruction needs to be processed after the control flow change operation, and so the instruction can be processed with respect to the constraints defined by the newly generated capability.

[0158] With reference to Figure 13 , another option is shown schematically, which allows the first instruction (or, in other examples, a predetermined number of first instructions) to be fetched and / or executed after the control flow change operation without being subject to the primary capability constraints. In this example, Figure 8 The control flow change processing unit of

[0159] In some examples, in response to the control flow change operation, the processor (e.g., control flow change processing program 800) is configured to set a state indicator to indicate that the capability generation circuit 810 needs to generate a capability to use as the next primary capability. In response to the state indicator being set, the processor is configured to fetch and / or execute at least the first instruction at the control flow change target address without being subject to the primary capability constraints. It will be noted that in some example implementations, such instructions can still be executed under the constraints of the new capability, although this technique is used, but the use of the state indicator can at least allow instruction fetching of the instruction to proceed before the capability is available. Then, in response to a signal from the capability generation circuit indicating that the next capability has been generated, the processor (e.g., control flow change processing program 800) is configured to clear the state indicator to a state indicating that the processing of program instructions is subject to the primary capability constraints.

[0160] Figure 14 Another option is shown schematically Figure 12 ​another version of the timeline (again from an architectural perspective), but in this example, the execution 1410 of at least the first instruction can proceed (under the conditions defined by the state indicator 1300) in a manner that overlaps the generation 1420 of the new capability (that is, the capability to constrain the processing of the instruction or instructions executed after the control flow change operation) after the initiation 1400 of the control flow change operation.

[0161] Exception handling example

[0162] Figure 15 Another example of a control flow change is shown schematically from an architectural perspective. Here again, time runs from left to right, and a branch operation 1500 occurs at the time indicated by the corresponding arrow. The branch operation forms one example of a control flow change operation.

[0163] At the time indicated by arrow 1510, a processor interrupt or other exception event occurs. This causes the program flow to change to an exception or interrupt handling routine 1530, as shown by the vertical rise in dashed line 1520, for example. In the example shown, the first instruction is executed after the implementation of the initiating control flow change operation. Figure 15 In the example shown, this additional program flow change occurs before the first instruction is executed after the implementation of the initiating control flow change operation. To accomplish this, the processor state information stored prior to time 1510 is stored, for example, by being pushed onto the processor stack. With respect to the newly generated capability, the processing of the instruction or instructions executed after the branch operation is constrained:

[0164] (a) in the case of the generation of the capability prior to the processing of the relevant instruction after the branch operation (similar to the case of Figure 12 ), such as operation 1505, the newly generated capability can be stored and / or pushed onto the stack, etc., for retrieval and use upon return 1540 from the exception event processing. In this case, the execution 1560 of the first instruction after the initiating control flow change operation is implemented under the constraints defined by the capability (in the same context / thread as the initiating control flow change operation); or

[0165] (b) in the case of an implementation that uses the state indicator 1300 (similar to the implementation of Figure 14 ), this indicator is set in response to operation 1505, and this indicator is also pushed onto the stack, for example, as part of the processor state information. Upon return 1540 from the interrupt handling routine, the processor state information is retrieved and the generation 1550 of the new capability and the execution 1560 of the first instruction after the initiating control flow change operation are commenced.

[0166] The state tag can be cleared at time 1570 upon the completion of the generation of the new capability, and (in this example) the first instruction is executed.

[0167] In these examples, the control flow change operation can also define an exception handling routine processing control flow change and / or an exception return operation (or vice versa in other examples) that returns from processing the exception handling routine.

[0168] An example method of branching to initiate an exception handling routine (corresponding to stage 1510 in Figure 15 ) is as follows. Each exception "type" has an associated number or index. Examples can include reset, system call exception, interrupt request, various types of fault, etc. Each exception type has an associated number (e.g. between 0 and 15) that is generated by the exception handling circuit 9 Figure 1 ) in response to an external or internal condition indicating an exceptional situation. In response to the exception event, the processor is configured to identify an entry in a vector table in memory according to the number associated with the exception handling routine to be processed, where at least part of that entry indicates a control flow change target address. The control flow change handler 800 then uses the techniques discussed above to change program flow control to the control flow change target address. As discussed above, this can involve saving primary processor state information to e.g. the processor stack for retrieval when processing the exception return operation. This can include storing the state indicator 1300 as mentioned above for retrieval when processing the exception return event.

[0169] In some examples, at least part of the entry in the vector table indicates whether the exception handling routine is to be processed regardless of the primary capability. If this indication is set, then (a) the processor executes the exception handling routine according to the indication regardless of the primary capability, and optionally (b) the capability generation circuit does not even attempt to generate a capability regarding the capabilities used by the exception handling routine.

[0170] Apparatus features summary

[0171] Using the techniques described in more detail above, Figure 1An example of an apparatus is provided, the apparatus comprising a processor to execute program instructions stored at respective memory addresses, processing of the program instructions being constrained by at least a primary capability defining access rights to a set of one or more memory addresses; the processor comprising: control flow alteration processing circuitry 33 to implement a control flow alteration operation defining a control flow alteration target address indicative of an address of a program instruction to be executed after the control flow alteration operation; and capability generation circuitry 810 to determine, from the control flow alteration target address, an address at which capability access rights data is stored; the capability generation circuitry configured to retrieve the capability access rights data and to generate, from at least the capability access rights data, a capability to be used as a next primary capability. In an example, the capability to be used as a next primary capability is configured to constrain processing of one or more instructions to be executed after the control flow alteration operation.

[0172] Summary method

[0173] Figure 16 is a schematic flow chart illustrating an example method comprising:

[0174] executing program instructions stored at respective memory addresses, processing of the program instructions being constrained by at least a primary capability defining access rights to a set of one or more memory addresses;

[0175] implementing a control flow alteration operation defining a control flow alteration target address indicative of an address of a program instruction to be executed after the control flow alteration operation;

[0176] determining, from the control flow alteration target address, an address at which capability access rights data is stored;

[0177] retrieving the capability access rights data; and

[0178] generating, from at least the capability access rights data, a capability to be used as a next primary capability.

[0179] Exemplary simulator implementation

[0180] Figure 17 A simulator implementation is shown that can be used to implement a simulation of the apparatus and / or methods discussed above.

[0181] While the previously described embodiments implement the present technology in terms of apparatus and methods for operating specific processing hardware that support the present technology, it is also possible to provide an instruction execution environment in accordance with the embodiments described herein, implemented through the use of a computer program.

[0182] Such computer programs are often referred to as simulators, in part because they provide a software-based implementation of a hardware architecture. Categories of simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. In general, a simulator implementation can run on a host processor 1730 that supports the simulator program 1710, which optionally runs a host operating system 1720. In some arrangements, there can be multiple simulation layers between the hardware and the provided instruction execution environment and / or multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide a simulator implementation that executes at a reasonable speed, but such an approach can be reasonable in certain situations, such as when it is desirable to run code native to another processor for compatibility or re-use reasons. For example, a simulator implementation can provide an instruction execution environment that provides additional functionality not supported by the host processor hardware, or that provides an instruction execution environment normally associated with a different hardware architecture. Simulation is outlined in the paper “Some Efficient Architecture Simulation Techniques”, Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

[0183] To the extent that embodiments have been previously described with reference to specific hardware configurations or features, in a simulated embodiment, equivalent functionality can be provided by suitable software configurations or features. For example, a particular circuit can be implemented as computer program logic in a simulated embodiment. Similarly, memory hardware such as registers or cache memory can be implemented as software data structures in a simulated embodiment. To the extent that one or more of the hardware elements referenced in the previously described embodiments exist on host hardware (e.g., host processor 1730), some simulated embodiments can utilize the host hardware, as appropriate.

[0184] The emulator program 1710 can be stored on a computer readable storage medium, which can be a non-transitory medium, and provides a virtual hardware interface (instruction execution environment) to the target code 1700, which can include an application program, an operating system, and a hypervisor, that is identical to the interface of the hardware architecture being modelled by the emulator program 1710. Thus, program instructions of the target code 1700, including the above-described functionality, can be executed from within the instruction execution environment using the emulator program 1710, so that a host computer 1730 that does not actually have the hardware features of the above-described apparatus can emulate these features.

[0185] Such a computer program provides an example of a computer program for controlling a host data processing apparatus to provide an instruction execution environment, and comprises:

[0186] processor logic to execute program instructions stored at respective memory addresses, the processing of which is subject to at least a primary capability defining access rights to a set of one or more memory addresses; the processor logic comprising:

[0187] control flow change processing logic to implement a control flow change operation defining a control flow change target address indicative of an address of a program instruction for execution after the control flow change operation; and

[0188] capability generation logic to determine, from the control flow change target address, an address at which capability access rights data is stored;

[0189] the capability generation logic is configured to retrieve the capability access rights data and to generate, from at least the capability access rights data, a capability for use as a next primary capability.

[0190] In this application, the words "configured to" are used to mean that an element of an apparatus has a configuration able to perform the defined operation. In this context, a "configuration" means an arrangement or manner of interconnection of hardware or software. For example, the apparatus can have dedicated hardware which provides the defined operational behaviour, or a processor or other processing device (such as processing elements discussed above) can be programmed to perform the function. "Configured to" does not imply that the apparatus needs to be changed in any way in order to provide the defined

[0191] While example embodiments of the present technology have been described in detail herein in connection with the appended drawings and various implementations, it is to be understood that the present technology is not limited to those precise embodiments, and that various modifications, and changes, and substitutions can be made therein by those skilled in the art without departing from the scope and spirit of the present technology as set forth in the appended claims. For example, features of one claim can be combined with features of another claim while not departing from the scope of the present technology.

Claims

1. Apparatus for capability based processing comprising: a processor to execute program instructions stored at respective memory addresses, processing of said program instructions being subject to at least a primary capability defining access rights to a set of one or more memory addresses; said processor comprising: control flow alteration processing circuitry to implement a control flow alteration operation defining a control flow alteration target address indicative of an address of a program instruction to be executed after said control flow alteration operation; and capability generation circuitry to determine, from said control flow alteration target address, an address at which capability access rights data is stored as a memory address preceding said control flow alteration target address; said capability generation circuitry being configured to retrieve said capability access rights data and to generate, from at least said capability access rights data, a capability to be used as a next primary capability.

2. Apparatus according to claim 1, wherein said capability to be used as a next primary capability is configured to constrain processing of one or more instructions executed after said control flow alteration operation.

3. Apparatus according to claim 1 or claim 2, wherein: each capability comprises at least a pointer and data defining access rights to said set of memory addresses; and said capability generation circuitry is configured to generate said pointer from said control flow alteration target address and to generate said data defining access rights to said set of memory addresses from said capability access rights data.

4. The apparatus of claim 1 or claim 2, wherein the capability access right data defines one or more of: (i) a lower limit memory address of an address region comprising the one or more memory addresses for which access is permitted; (ii) an upper limit memory address of said address region; and (iii) a set of rights attributes applicable to said address region.

5. Apparatus according to claim 1 or claim 2, wherein said capability access rights data defines a location at which information defining access rights to said set of memory addresses is stored.

6. Apparatus according to claim 1, wherein in response to said control flow alteration operation, said processor is configured to set a status indicator to indicate that said capability generation circuitry needs to generate said capability to be used as said next primary capability.

7. Apparatus according to claim 6, wherein in response to said status indicator being set, said processor is configured to fetch and / or execute at least a first instruction at said control flow alteration target address without constraint by a primary capability.

8. Apparatus according to claim 6 or claim 7, wherein said processor is configured to clear said status indicator to a state indicating that processing of program instructions is subject to constraint by a primary capability in response to generation of said capability to be used as said next primary capability.

9. Apparatus according to claim 6 or claim 7, wherein said processor is configured to store said status indicator in response to a processing exception event for retrieval on a processing exception return event.

10. Apparatus according to claim 2, wherein said one or more instructions executed after said control flow alteration operation comprise at least an instruction at said control flow alteration target address.

11. Apparatus according to claim 1 or claim 2, wherein the control flow altering operation is one of: a branch operation responsive to execution of a branch instruction; and a branch and link operation responsive to execution of a branch and link instruction, the branch and link operation storing a return address capability, the return address capability being generated from an instruction address of the branch and link instruction and the primary capability in use when the branch and link instruction is executed.

12. Apparatus according to claim 11, wherein the branch instruction comprises an operation code which defines at least the control flow alteration target address by indicating a value which is a difference from an instruction address of the branch instruction.

13. Apparatus according to claim 11, wherein the branch instruction comprises an operation code which defines at least a register identifier identifying a register containing a value indicating the control flow alteration target address.

14. Apparatus according to claim 1 or claim 2, wherein the control flow altering operation defines an alteration of control flow to a processing exception handling routine.

15. Apparatus according to claim 14, wherein the processor is configured to identify an entry in a vector table in memory according to a number associated with the exception handling routine to be processed, wherein at least part of the entry indicates the control flow alteration target address.

16. Apparatus according to claim 15, wherein at least part of the entry indicates whether the exception handling routine is to be processed irrespective of a primary capability.

17. Apparatus according to claim 1 or claim 2, wherein the control flow altering operation comprises an exception return operation returning from processing an exception handling routine.

18. A method for capability based processing, comprising: executing program instructions stored at respective memory addresses, processing of the program instructions being subject to a primary capability defining at least access rights to a set of one or more memory addresses; implementing a control flow altering operation, the control flow altering operation defining a control flow alteration target address indicating an address of a program instruction to be executed after the control flow altering operation; determining an address storing capability access rights data as a memory address preceding the control flow alteration target address according to the control flow alteration target address; retrieving the capability access rights data; and generating a capability for use as a next primary capability at least according to the capability access rights data.

19. A computer program product for controlling a host data processing apparatus to provide an instruction execution environment, and comprising: processor logic for executing program instructions stored at respective memory addresses, processing of the program instructions being subject to a primary capability defining at least access rights to a set of one or more memory addresses; the processor logic comprising: ​ control flow change processing logic to implement a control flow change operation, the control flow change operation defining a control flow change target address indicative of an address of a program instruction to be executed after the control flow change operation; and capability generation logic to determine, from the control flow change target address, an address of capability access right data as a memory address before the control flow change target address; the capability generation logic is configured to retrieve the capability access right data and to generate, at least from the capability access right data, a capability to be used as a next primary capability.

Images