Ability to track write addresses

Abstract

The device includes a capability check circuit (86) that performs a capability validity check operation to determine whether use of a capability satisfies one or more usage restriction conditions. A capability includes a pointer and pointer usage restriction information that specifies one or more usage restriction conditions. The one or more usage restriction conditions include at least an allowable range of the pointer's address. When capability write address tracking is enabled, in response to a capability write request that requests that a capability be written to a memory location associated with a capability write target address, the capability write address tracking circuit (200) updates the capability write address tracking structure (100) based on the capability write target address.

Description

[Technical field]

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

[0002] Software executing on a data processing device can use pointers to control access to memory. However, pointers sometimes provide an avenue that a malicious attacker can use to attack a victim's software, for example exploiting a buffer overflow, using a pointer to identify a location within a buffer to access an area of ​​memory beyond the buffer that the attacker would not otherwise be allowed to access. Some processor architectures can support the use of capabilities, which associate pointers with pointer use restriction information that specifies one or more use restriction conditions that limit the scenarios in which the pointer can be used effectively. The use restriction conditions can include at least a defined allowable range of the pointer's address, such that an error can be signaled if the pointer is used to access an area of ​​memory outside the allowable range. This can help to protect against some forms of attacks.

[0003] At least some examples provide an apparatus that includes a capability checking circuit that performs a capability checking operation to determine whether use of a capability satisfies one or more usage restriction conditions, the capability including a pointer and pointer usage restriction information that specifies one or more usage restriction conditions, the one or more usage restriction conditions including at least an acceptable range of an address of the pointer, and a capability write address tracking circuit that updates a capability write address tracking structure based on the capability write target address in response to a capability write request that requests that the capability be written to a memory location associated with the capability write target address when capability write address tracking is enabled.

[0004] At least some examples provide methods that include performing a capability check operation to determine whether use of a capability satisfies one or more usage restriction conditions, where the capability includes a pointer and pointer usage restriction information that specifies one or more usage restriction conditions, where the one or more usage restriction conditions include at least an acceptable range of an address of the pointer, and when capability write address tracking is enabled, updating a capability write address tracking structure based on the capability write target address in response to a capability write request that requests that the capability be written to a memory location associated with the capability write target address.

[0005] At least some examples provide a computer program for controlling a host data processing apparatus to provide an instruction execution environment for executing target code, the computer program including: capability checking program logic that performs a capability checking operation to determine whether use of a capability satisfies one or more usage restriction conditions, the capability including a pointer and pointer usage restriction information that specifies one or more usage restriction conditions, the one or more usage restriction conditions including at least an acceptable range of an address of the pointer; and capability write address tracking program logic that updates a capability write address tracking structure based on the capability write target address in response to a capability write request that requests that a capability be written to a memory location associated with the capability write target address when capability write address tracking is enabled.

[0006] The computer program may be stored in a computer-readable storage medium. The storage medium may be a transitory storage medium or a non-transitory storage medium.

[0007] At least some examples provide a method that includes enabling capability write address tracking with a capability write address tracking structure that tracks capability write target addresses of one or more capability write requests, where the capability write requests include requests to write a capability to a memory location associated with the capability write target address specified by the capability write request, where the capability includes a pointer and pointer usage restriction information that specifies one or more usage restriction conditions including at least an acceptable range of addresses for the pointer; sweeping memory to invalidate stale capabilities, where the stale capabilities include capabilities whose acceptable range of addresses overlap with one or more target areas of addresses; and after sweeping memory, re-sweeping one or more selected memory address areas corresponding to addresses tracked by the capability write address tracking structure to invalidate stale capabilities stored in the one or more selected memory address areas.

[0008] At least some examples provide a computer program for controlling a data processing apparatus to perform a method including the above-mentioned validation, sweep, and resweep steps. The computer program may be stored in a computer-readable storage medium. The storage medium may be a temporary storage medium or a non-temporary storage medium. [Brief description of the drawings]

[0009] Further aspects, features, and advantages of the present technology will become apparent from the following description of examples, read in conjunction with the accompanying drawings. [Figure 1] 1 illustrates an example of a data processing apparatus having multiple processor cores and a capable write address tracking circuit. [Diagram 2] 1 shows an example of one of the processor cores. [Diagram 3] Illustrates an example of a capability and how it can be copied to many locations in the memory address space. [Figure 4] We present an example of a revocation-based attack on a system that uses the capability. [Diagram 5] Some examples of traceability write addresses are given below. [Figure 6] FIG. 1 is a flow diagram illustrating steps taken by software executing in a multiprocessor system to perform a memory sweep of obsolete capabilities. [Figure 7] 1 illustrates an implementation of a simulator that may be used.

[0010] The data processing apparatus has a capability checking circuit that performs a capability checking operation to determine whether use of a capability satisfies one or more usage limitation conditions. A capability includes a pointer and pointer usage limitation information that specifies one or more usage limitation conditions. The one or more usage limitation conditions may include at least an allowable range of the address of the pointer. The usage limitation conditions may also optionally include other conditions, such as, for example, whether the capability may be used to control writing to memory, or whether it is allowed to fetch instructions to be executed from a memory region accessed via the capability. By providing a capability checking circuit, this provides the enforcement of some hardware-based protection against malicious use of pointers that may be used to launch attacks on software that is otherwise susceptible to attacks.

[0011] Such a capability may be written to any address in the memory address space. If a capability whose tolerance range covers a given memory region resides in memory and then the given region is deallocated, it may not be safe to reallocate this given region to a given software process until the capability in memory that covers the given region has been invalidated. If the capability that covers the deallocated region is still stored in the memory system, it may be possible for some time to simply block the deallocated memory from being reallocated, but this tends to result in memory fragmentation and performance loss. Not reusing memory is equivalent to a memory leak (loss of available memory address space due to inability to deallocate memory), which may eventually cause overflows that could compromise safety even in large address spaces. Thus, while memory may be blocked from being reallocated for some time, it may be desirable to eventually sweep the memory to identify stale capabilities with tolerance ranges of addresses that cover previously deallocated regions of memory, and allow the deallocated regions to be reused for other purposes.

[0012] During such a sweep of memory of stale capabilities (typically controlled by software), there may be a danger that other processor cores or threads may be writing capabilities into the already swept memory area while the sweep is in progress. This may be mitigated by stopping all other processor cores from continuing processing while the sweep is taking place on a given processor core, or by changing memory access permissions to prevent capability write operations from being allowed, but these approaches have a significant performance impact. Also, in such a "stop the world" approach, the sweep process would need to set a configuration register to specify that the sweep process will not be interrupted, to prevent an attacker from interrupting the sweep and copying capabilities into previously swept memory before restarting the sweep. However, this means that legitimate interrupt originators are also disabled from being serviced, increasing the latency of interrupt processing, which may be undesirable for real-time systems where a limit on the maximum time it takes to process an interrupt is required.

[0013] In the technology described below, the device includes a capability write address tracking circuit, which when the capability write address tracking is enabled, updates a capability write address tracking structure based on the capability write target address in response to a capability write request that requests that the capability be written to a memory location associated with the capability write target address. Thus, by providing tracking hardware that can track the address to which the capability is written, this allows identification of which address the capability was written to while the sweep is in progress, and thus allows relatively efficient re-sweeping of any write locations after the main sweep is finished to guard against the possibility that the capability is written into an already swept memory. Thus, providing the capability write address tracking circuit architecture in hardware allows for a more efficient sweep, since it avoids the need for the sweep process to stop processing on all other cores while the sweep is in progress, which can significantly improve performance.

[0014] Tracking by the capability write address tracking circuitry may be specific to capability write requests, such that in response to a non-capability write request that requests that non-capability information be written to a memory location associated with a non-capability write target address, the capability write address tracking circuitry may ignore such non-capability write requests, such that the capability write address tracking structure is not updated based on the target address of the non-capability write request.

[0015] The capability write address tracking structure may be accessible to software executing on the device, so that when the sweeping of stale capabilities is controlled by software, the software can identify which locations in memory should be re-swept based on the information in the capability write address tracking structure.

[0016] Some systems may permanently enable capability write address tracking circuitry so that a record of addresses to which capabilities are written during normal processing is maintained, however in practice this may require a relatively large capability write address tracking structure, and the circuit area, power, and performance overhead associated with permanently tracking the addresses of capability write requests may not be justified.

[0017] In another example, an enable storage element may be provided to store a capability write address tracking enable indication, where the capability write address tracking enable indication indicates whether the capability write address tracking is enabled or disabled. When the capability write address tracking is enabled, in response to a capability write request, the capability write address tracking circuit updates the capability write address tracking structure based on the capability write target address. On the other hand, when the capability write address tracking enable indication indicates that the capability write address tracking is disabled, the capability write address tracking circuit omits updating the capability write address tracking structure based on the capability write target address of any received capability write request. By providing the ability to enable or disable capability write address tracking, this can allow a small capability write address tracking structure to be used, because address tracking only needs to be enabled when it is important to know which address a capability is being written to, and can otherwise be disabled to avoid capturing unhelpful information.

[0018] The system may have a processing circuit that executes program instructions. The processing circuit may have an instruction set architecture that supports at least one program instruction that controls the processing circuit to update a capability write address tracking enable indication. For example, the program instruction may be a dedicated capability write address tracking enable or disable instruction, or may be a system register update instruction that is used to update a general control register and specifies a parameter that identifies the updated register as a capability write address tracking enable storage element. Thus, software can set whether tracking by the capability write address tracking circuit is enabled or disabled by executing a program instruction to set or clear the capability write address tracking enable indication. For example, software controlling a sweep of stale capabilities as described above enables capability write address tracking just before starting the sweep, and then disables capability write address tracking again when the sweep is completed to allow detection of addresses to which capabilities have been written while the sweep is in progress.

[0019] The capability write address tracking structure can track addresses at a coarser granularity than the capability write request specifies the capability write target address. For example, the capability write address tracking structure can identify the page or block of the address to which the capability was written without identifying the particular address within the page / block to which the capability was written. This can reduce the storage overhead of the tracking structure.

[0020] The device may have a cache structure including several entries, each of which stores cache information associated with a corresponding memory address region. In response to a capability write request, when the capability write address tracking structure is updated based on the capability write target address, the capability write address tracking circuit may also set a capability written indicator in an entry of the cache structure corresponding to the memory address region that includes the capability write target address. Thus, the cache entry may be tagged with an indication of whether a capability write to the corresponding memory address region has been detected. In response to a capability write request, when capability write address tracking is enabled and the capability write target address corresponds to a memory address region for which the corresponding cache entry already has a capability written indicator set, the capability write address tracking circuit may omit updating the capability write address tracking structure based on the capability write target address.

[0021] Thus, by tagging a cache entry with information about whether at least one capability write request to the corresponding memory address region has been detected, it is possible to avoid redundant allocation of multiple updated entries of the capability write address tracking structure for the same region, and upon a subsequent capability write to the same region where a capability write has already been made, updating of the capability write address tracking structure may be omitted. This allows for more efficient use of the capability write address tracking structure, which may have limited capacity.

[0022] The cache structure in which the capability written indicator is set may be one of a series of different types of cache structures. For example, the cache structure may be a data cache for caching data obtained from memory, an instruction cache for caching instructions fetched from memory, or a dedicated capability write address tracking cache that may have entries solely for capability write address tracking purposes. However, in one example, the cache structure may be particularly useful if it includes an address translation cache that stores address translation information derived from a page table structure in memory. For example, the cache structure may include a translation lookaside buffer (TLB). The TLB may track address regions at a relatively large granularity, such as the page granularity at which the page table structure is defined in memory, and thus it may be more efficient at tracking the capability written indicator than alternative cache structures that may track addresses at a finer granularity. Also, unlike other cache structures, the address translation cache may in fact be probed in any manner for a capability write request to obtain the physical address of the region to which the write operation is to be performed, and thus it may be relatively efficient to check the capability written indicator in the address translation cache entry when a capability write request is received. However, other types of cache structures may also be used to track the capacity written indicator for each memory address region.

[0023] When an entry with a capability written indicator set is evicted from the address translation cache (or, in a system with multiple levels of address translation cache, when such an entry is evicted from the last level of the address translation cache), the address translation cache can discard the capability written indicator without writing it back to the page table structure in memory. This means that when an entry with a capability written indicator set is evicted, the information that a previous capability write request targeted this region is lost, and thus, if a subsequent capability write request targets the same region again, this may result in multiple entries in the capability write address tracking structure being allocated for the same region, which may be preferable to updating the page table structure with the capability written indicator. The page table structure may already occupy a very large amount of memory space, and increasing the size of each page table entry by even one bit may actually require multiple additional bits of memory space to be allocated within each page table entry to align the page table entry to a power of two address size boundary, and thus, in practice, increasing the size of the page table entry to accommodate the capability written indicator would have a large impact on the size of the page table structure, which may be undesirable. Therefore, occasionally requiring a duplicate entry to be allocated in the capability write address tracking structure may be preferable to writing the capability written indicator back to the page table structure.

[0024] The processing circuitry can process instructions from one of several software processes, each of which is associated with a corresponding execution context identifier. For example, the execution context identifier can be used by the TLB to distinguish different sets of address translation information associated with each of the software processes. When capability write address tracking is enabled, the capability write address tracking circuitry can maintain execution context identifier tracking information for tracking one or more execution context identifiers associated with one or more capability write requests. This can be useful because it means that when subsequently using the capability write address tracking structure to control which memory regions need to be re-swept for stale capabilities, the execution context identifier tracking information can be used to avoid unnecessary re-sweeping of some of the memory address regions that have not been subject to capability writes in the same execution context but have virtual addresses that alias virtual addresses used by the process being swept. This can improve the performance of the process sweeping for stale capabilities.

[0025] The processing circuit may also support a capability write address tracking reset instruction, which may be used to reset the capability write address tracking structure. For example, this instruction may be executed at the beginning of a sweep process or at the end of a sweep process. The capability write address tracking reset instruction may be the same instruction as the instruction to enable or disable capability write address tracking, or may be a separate instruction. When the capability write address tracking structure is reset, the structure may be reset to a state equivalent to indicating that no address has been requested for a capability write. For example, this may be done by clearing all data entries in the capability write address tracking structure, or by allocating a new structure in memory and updating address parameters that identify the location of the new structure.

[0026] The capability write address tracking structure can be implemented in different ways. For example, the structure can include a hardware implemented storage unit separate from the memory. Thus, a dedicated hardware implemented unit can be provided to track address information of addresses where capability write operations are made.

[0027] Alternatively, the capability write address tracking structure may simply be a data structure stored in memory at a given set of addresses. In this case, the capability write address tracking circuit may have hardware to update and access the capability write address tracking structure, but may not have hardware to hold the capability write address tracking information itself. When the capability write address tracking structure is maintained in memory, in one example, the structure may be a buffer containing several entries, each entry specifying an address of a memory region where at least one capability write is made. The address tracking may be address tracking at different granularities, for example, address tracking at cache line or address tracking at page level granularity. In one example, at least one tracking metadata storage element may be provided to help identify the location in memory where the capability write address tracking structure is stored. For example, the at least one tracking metadata storage element may store at least one of a base address of the capability write address tracking structure, an indication of the next entry to be updated in the capability write address tracking structure, and a limit indication indicating the maximum allowed size of the capability write address tracking structure. Here, the indication of the next entry to be updated may be explicit or implicit, for example, the indication of the next entry may be specified by identifying a previous entry write, which may implicitly identify which entry is next, the indication of the next entry may be expressed as a count value (the count value may be used to derive the address of the next entry to be updated by applying a number of increments to a base address, the number of increments being selected based on the count value and the increment corresponding to the size of one entry), or as an absolute address that specifies the location in memory of the next entry or the previous written entry.

[0028] The limited indication can be beneficial because it can enable the capability write address tracking circuitry to track whether too many entries have been allocated to the capability write address tracking structure, exceeding or in danger of exceeding the maximum allowed size, so that it can avoid the tracking structure spilling over into subsequent areas of memory that may contain other information.

[0029] In some examples, the capability write address tracking structure can precisely track one or more capability write target addresses of one or more capability write requests received when capability write address tracking is enabled. For example, the tracking structure can maintain a list or cache-like structure that identifies unique addresses associated with received capability write requests. The precise tracking can be at different granularities as described above, for example, the precise tracking can be at address page addresses rather than at individual cache line tracking of capability write requests.

[0030] Alternatively, the capability write address tracking structure may inaccurately track one or more capability write target addresses of one or more capability write requests received when capability write address tracking is enabled. Inaccurate tracking may be such that false positives are possible (so that a query of the capability write address tracking structure may allow an address other than one of the received capability write target addresses to be spuriously identified as a member of the set of received capability write target addresses), but false negatives are not possible (when one of the received capability write target addresses is not so identified). For example, a structure such as a Bloom filter may be used. Such inaccurate tracking may reduce the amount of storage overhead required for the capability write address tracking structure, at the expense of occasionally allowing false positives, so that some memory regions may be identified as regions to be reswept, which do not actually correspond to regions where a capability write operation was performed.

[0031] In response to detecting that the capability write address tracking structure has reached a capacity limit (e.g., based on the limit indication as described above), the capability write address tracking circuitry can trigger the signaling of an exception. Software can then respond to the exception by updating the size of the address tracking structure to allow tracking to continue, or by stopping the sweep of stale capabilities that may be in progress and restarting the sweep again. In some implementations, it may not be necessary to trigger an exception, since, for example, in a Bloom filter approach, it may not be possible to exceed the capacity of the tracking structure, and then any number of addresses can be folded into the Bloom filter without increasing the size of the Bloom filter, but in other approaches such as linked lists or buffers, the size may eventually exceed the capacity of the memory space allocated to the capability write address tracking structure, and thus it may be useful to provide an architectural feature to detect that a capacity limit has been reached and then signal an exception.

[0032] In some examples, a data processing system may include multiple processor cores. The capability write address tracking structure may be shared between the cores. Also, the capability write address tracking circuitry may be shared between the cores. It may be expected that it is relatively rare for multiple cores to need to perform sweeps, and thus a shared tracking structure may be sufficient. Also, sharing the tracking between the cores makes it easier to determine whether any of the cores has issued a capability write request.

[0033] Alternatively, other approaches may provide separate capability write address tracking structures for individual cores, or some of the hardware may update a shared tracking structure specific to an individual core. For example, each core may separately update its TLB or other type of cache with an indicator to specify whether a capability write request targeted a particular address region. Thus, there are several ways in which the above circuitry may be implemented in a multi-core system. In the above examples, hardware circuits that perform capability check operations and capability write address tracking are described. It is also possible to provide a computer program that executes on a host data processing device and controls the host to provide an instruction execution environment for executing target code, so that the target code may be executed as if the target code were executing on a target data processing device that may have a different architecture than the host. This may be useful to allow legacy code written for a different processor architecture to be executed on a new platform, or to allow testing of a processor architecture under development, or to allow development of software designed for operation on a new processor architecture to begin before the hardware devices that support the new architecture are actually ready. Thus, a simulator computer program executing on the host can effectively emulate features of the processor architecture of the target data processing apparatus, so that target code may execute on the host as if the target code were executing on the target data processing apparatus. Such a simulator computer program may include capability checking program logic and capability write address tracing program logic, which emulate the functionality of the capability checking circuitry and capability write address tracing circuitry described above.

[0034] The above discussion describes architectural features of a processing system provided by hardware or corresponding simulator computer programs that enable software to identify which addresses are being written to using capability write requests that may be useful in sweeping obsolete capabilities. Although particularly useful for such sweeps, it will be appreciated that a software developer or compiler may find other uses for the capability write tracking structure.

[0035] In a corresponding method, a method for controlling the sweep to invalidate stale capabilities may be provided using a capability write address tracking structure. Thus, the method, which may be controlled by software, may include enabling capability write address tracking by a capability write address tracking structure, then sweeping memory to invalidate stale capabilities, where the stale capabilities are capabilities whose address tolerance range overlaps with one or more target regions of addresses, and then, after sweeping memory, re-sweeping one or more selected memory address regions corresponding to the addresses tracked by the capability write address tracking structure to invalidate stale capabilities stored in the one or more re-swept selected memory address regions. Thus, by using a capability write address tracking structure, the sweep process may avoid the need to stop processing in other processor cores or threads or prevent the continuation of valid capability writes, which may improve performance, because the tracking structure enables targeted re-sweeping of memory regions where capability writes are made during the main sweep.

[0036] A computer program may be provided for controlling a data processing apparatus to perform the above-mentioned method. The computer program may be stored in a non-transitory computer readable storage medium.

[0037] FIG. 1 illustrates in schematic form an example of a data processing system 2 with multiple processor cores (CPUs) 4. In this example, there are four CPUs, but it will be understood that more or fewer CPUs may be provided. The CPUs access a shared memory system via an interconnect 6, which, in addition to routing transactions between the cores 4 and the memory, may also manage coherency between cached data within each processor core 4. Although not shown in FIG. 1, the system may also include other types of master devices that may initiate memory transactions, such as graphic processing units, display controllers, network controllers, or other types of devices. Transactions initiated by the master devices are routed by the interconnect to the slave devices. In this example, the slave devices include a memory controller 8 that controls access to memory units 10, 12. In this example, the memory unit 10 is a dynamic random access memory (DRAM) unit and the memory unit 12 is a non-volatile RAM unit. It will be understood that other types of memories may also be provided and that other types of slave devices may also be provided, such as peripheral controllers, input / output units, etc. The interconnect 6 may have a shared cache 14 that is accessible to any of the CPUs 4 and that caches data from the underlying memory system.

[0038] In this example, the interconnect also includes a capability write address tracking circuit 20, which is described in more detail below. In other examples, some or all of the capability write address tracking circuit 20 may be distributed among the individual processor cores 4.

[0039] 2 illustrates an example of components within a given one of the CPUs 4. The processor core 4 may include a processing pipeline having several pipeline stages, which may include a fetch stage 30 for fetching program instructions from an instruction cache 32, a decode stage 34 for decoding the fetched instructions and generating control signals for controlling the remaining pipeline stages to perform the actions represented by those instructions, an issue stage 36 for checking whether operands required for the instructions are available in registers 38 and issuing the instructions for execution when the operands of the instructions are available, an execution stage 39 for executing the issued instructions to perform corresponding processing operations of a type depending on the particular instruction decoded, and a writeback stage 40 for writing the results of the executed instructions back to the registers 38. In this example, the execution stage 39 includes several execution units that execute different types of instructions. For example, the execution units may include an arithmetic / logic unit (ALU) 42 that executes arithmetic or logical instructions on integer operands, a floating point unit 44 that executes floating point instructions on operands represented in floating point format, and a load / store unit 46 that performs load operations to load data from the memory system into registers 38 or store data from registers 38 to the memory system. It will be appreciated that other types of execution units may also be provided. Also, this is merely one example of a possible pipeline architecture and other types of pipeline stages may also be provided. For example, in a processor that supports out-of-order processing, the pipeline may also include a rename stage to perform register renaming to map architectural registers specified by the instruction to physical registers provided in hardware.

[0040] The processor core 4 also includes a memory management unit (MMU) 50 that manages accesses to memory when requested by the load / store unit 46. The MMU 50 may perform address translation to convert a virtual address provided by the load / store unit 46 into a physical address for locating the required data from the memory system. The address translation is performed with reference to address translation data stored in a page table structure in memory. The MMU 50 includes one or more translation lookaside buffers (TLBs) 52 that function as an address translation cache to cache information derived from the page table structures. The TLBs 52 may cache the page table entries themselves and / or may cache information about addresses where a page table entry for translating a particular virtual address may be found in memory, such that an address translation of an address for which the associated information is cached in the TLB 52 may occur more quickly than an address translation of an address for which a page table walk is required to locate the associated address translation information in the page table structure in memory. In some examples, the MMU 50 may include a single TLB. Alternatively, MMU 50 may have multiple levels of TLB 52, where the virtual address is first looked up in a level 1 TLB, and if there is a miss in the level 1 TLB, then a level 2 TLB is looked up, trading off TLB capacity for latency. Also, although not shown in Figure 1 for simplicity, instruction fetches from instruction cache 32 may also have address translation done using MMU 50, or using a separate instruction-side MMU distinct from data-side MMU 50.

[0041] The CPU 4 in this example may include a level 1 data cache 54 that is accessed in response to load / store instructions based on a physical address identified by the MMU 50, and a shared level 2 cache 56 is provided shared between data and instructions such that the shared level 2 cache 56 may be accessed if there is a miss in the level 1 instruction cache 32 or the level 1 data cache 54. It will be appreciated that this is merely one example of a possible cache hierarchy and other arrangements may also be possible. It is also possible to provide more than two levels of cache in the CPU 4 before a request is sent to memory if there is a miss in the last level cache provided in the CPU 4. Thus, there is flexibility to vary the exact design of the CPU 4.

[0042] The registers 38 include several types of registers. The registers 38 may include a set of N general purpose registers 60 that store operands for instructions and results of executed instructions. The general purpose registers 60 may include integer and floating point registers. The registers 38 may also include control registers 62 that may store control parameters that control the functioning of the processor core 4. There may be several different types of control registers, such as a program counter that indicates an address corresponding to a current execution point, status flags that may be set depending on the results of previously executed instructions, and a current mode register that may indicate a current operating mode of the system. In the example of FIG. 2, the control registers 62 are shown as including a current execution context identifier register 64 that may store an indication of a current execution context identifier associated with an execution context currently being executed by the processing pipeline. The processor may support the execution of different software processes, each of which may have a corresponding execution context identifier, more specifically, an address space identifier (ASID). The address space identifier may be used by MMU 50 to locate a different set of page table structures for each software process, and entries in TLB 52 may be tagged with a corresponding ASID to ensure that address translation requests triggered by a given execution context can only be matched against TLB entries corresponding to this execution context.

[0043] 2, the processor core 4 may also have a set of capability registers 70 for storing capabilities. In this example, M capability registers C0 to C M-1is provided. Each capability register 70 can store a capability, and each capability register 70 includes an address pointer 72 that points to a particular address in memory, and associated pointer usage restriction information 74 that defines one or more conditions that limit valid use of the pointer stored in the pointer field 72. The pointer usage restriction information includes an indication of an allowable range of addresses within which the pointer 72 is allowed to be defined. In this example, the allowable range is encoded by a base value 76 that specifies the start address of the allowable range, and a limit value 78 that specifies, either implicitly or explicitly, the end address of the allowable range (the limit 78 may be encoded as an absolute address or as a size or offset, as applied to the base address 76). It will be appreciated that there may be other ways of encoding the allowable range information, for example by a range identifier that may point to a separate table that includes the base value 76 and the limit value 78. In addition to the range information 76, 78, the capability register may also store permissions 80 that may impose further usage restrictions on the use of the pointer. For example, the permissions 80 may specify whether a range of permissible addresses corresponding to a capability may only be read, or may be both read and written. The permissions 80 may also specify whether it is permissible to fetch and execute instructions stored at addresses within the corresponding range of addresses. The permissions may also specify whether the corresponding capability is permitted to be used to control the load or store of other capabilities. Another type of permission may be a permission that specifies whether a capability may be shared with other software processes or is restricted to be used only by the current software process. The permissions may also specify which privilege levels of software are permitted to use the capability. It will be understood that any one or more of these additional usage limitations may be imposed by the permissions 80, and that not all of these permissions need be supported by a given processor architecture.

[0044] Thus, in general, by defining one or more usage restriction conditions that include at least the permissible range of pointer 72, this means that the use of pointer 72 is limited in its applicability, which can be useful in thwarting common software attacks such as buffer overflows or access to arbitrary memory addresses.

[0045] 3, when a capability is stored in a memory system, in addition to the pointer 72 and the usage restriction information 74, the capability may also have an associated tag value 82 that specifies whether the capability is valid. This tag 82 is used by the hardware to distinguish memory locations that store capabilities from memory locations that store conventional non-capability data. The tag value 82 is software transparent, i.e., it is not an address or part of memory, and therefore may be kept separate from the capability itself.

[0046] The instruction set architecture supported by the processing pipeline may include instructions that interact with capabilities. For example, the instruction set architecture may include support for a capability set instruction to write a capability to one of the capability registers 70, an instruction to load a capability from memory into the capability registers 70, an instruction to store a capability from the capability registers 70 into memory, and an instruction to use a capability stored in the capability registers 70 to control data or instruction access to memory. When a capability stored in the capability registers 70 is used to control access to memory, the use of the capability in the specified capability register is checked by a capability check circuit 86 to check whether the scenario in which the capability is being used is valid based on the range information 76, 78 and the permissions 80 of the specified capability in the referenced capability register 70. For example, the capability check circuit 86 may check whether the pointer value 72 is within the permitted range defined by the range information 76, 78 and whether the type of operation being requested (e.g., read or write or instruction fetch) is allowed considering the specified permissions 80. Thus, the capability check circuitry 86 hardware ensures that attempts to use capabilities to access information outside of the allowable address ranges will fail, and attempts to perform inappropriate types of operations within the specified address range will fail and potentially raise security exceptions. Memory permissions recorded in the page table structure for specific regions may support defining that some regions may only be accessed via capabilities (and may not be read / written to except by capabilities), which may enforce that the protection provided by capabilities is not bypassed for certain regions. Also, some implementations may provide architectural support for operating modes in which only capability-controlled accesses are allowed and accesses to memory not controlled by capabilities may be prohibited, which may be selected if it is desired to ensure that capability protection is required for all accesses to memory.

[0047] Thus, providing an architecture that supports capabilities can provide spatial protection against attacks. However, as shown in the top part of FIG. 3, problems can still arise in that software can freely move, copy, and store capabilities, and thus the same capability C0 can be held in multiple memory locations within the entire memory address space. For example, FIG. 3 shows a case where a capability C0, whose range specified by range information 76, 78 corresponds to address range A, is copied to three different locations B, C, and D in the address space. Even if memory address region A is subsequently deallocated and freed for potential use by other software processes, it can be dangerous to allow other processes to use this region for potentially sensitive information if it is not guaranteed that there is no stale capability C0 still stored in other regions of the memory address space that have range information covering the previously referenced region A.

[0048] As an example of an attack exploiting such stale capabilities, Figure 4 shows a use-after-free attack between a victim application and an untrusted library. Assume that the underlying code and data segments are spatially isolated from each other based on capabilities. The attack relies on the victim intentionally sharing a portion of the victim's memory with the attacker in the form of capabilities C1 and C3, e.g., an image processing application grants a filter library access to memory holding images. The attacker hides C1 (by copying capability C1 to a region of memory allocated to the attacker) during the first call and then recovers C1 during the second call. During this time, the victim process frees the region covered by capability C1 and allocates a new memory region covered by capability C2, which will hold some sensitive data. Since memory allocators typically reuse previously freed memory, C2 may overlap with the memory covered by C1. Thus, the attacker is not given access to capability C2, and thus the victim may expect that C2 is sufficient to protect against access to the secrets, but the attacker can use the stale capability C1 to retrieve secret information held within the domain associated with C2.

[0049] One approach to mitigating attacks such as those described above is to avoid memory reuse (i.e., prohibit reusing the memory region associated with C1 after it has been deallocated). Implicit memory leaks may be tolerable for systems with large virtual address spaces and for applications that do not allocate large amounts of memory or perform frequent allocation-deallocation cycles. However, even these systems may suffer performance losses resulting from cache pollution as a result of inherent memory fragmentation. In either case, some form of revocation policy to invalidate all instances of freed capabilities may be desirable to enable safe memory reuse.

[0050] For example, capabilities to be freed may be added to a revocation list. Memory covered by these capabilities will not be reused until all instances of such capabilities have been invalidated from memory. The revocation policy may collect capabilities on the revocation list up to some threshold of stale memory, say 25% of the heap space, before triggering a revocation sweep. The sweep may then Searching for all registers and memory currently accessible by the target application; identifying all stale capabilities held in said registers and memory, where for all said stale capability addresses, the permitted range of addresses 76, 78 overlaps with at least one of the ranges identified on the revocation list; Clearing the stale ability tag 82 disables any stale abilities identified in the sweep.

[0051] However, when such a sweep is being performed, if other threads are running in parallel with the sweep thread (e.g., on other processor cores 4), or if the sweep software is suspended and then other code is executed while the sweep software is suspended before it is resumed after the suspension, there is a risk that such other threads may write stale capabilities into memory areas that have already been swept, which could create a risk that some stale capabilities will not be found in the sweep.

[0052] A simple approach to address this is to "stop the world" during the sweep, i.e., stop all other threads and disable interrupts. However, the performance impact of this approach is highly undesirable or unacceptable for real-time applications.

[0053] One approach to accelerating the undo sweep is to limit the movement of capabilities. For example, a "per capability" permission bit can be used to determine whether a capability can be used as a base address for the capability store. The allocator can then exclude all regions of memory from the sweep for which the allocator has not provided at least one capability with that permission bit set. Similar permission bits can also be assigned to pages. This allows the operating system (OS) to exclude large regions of memory from the sweep because they cannot hold capabilities.

[0054] The "capability storeable" permission bits restrict which areas of memory can hold capabilities. However, the "capability storeable" permission bits provide no information about the actual contents of these areas; for example, a page may store a capability, but the page does not contain the capability at runtime and therefore does not need to be swept. To remedy this, a "capability dirty" bit may be associated with each page. When a capability is first written to a particular page, the "capability dirty" bit is set. The sweep algorithm may evaluate the bit and skip these pages during a sweep.

[0055] However, the above approaches exhibit three major limitations. a) Scaling Applications may exhibit large memory footprints, such as databases encompassing several terabytes. The sweep process may need to obtain and evaluate permission bits corresponding to many pages and / or capabilities. This can result in a large performance overhead, especially if the corresponding page table is not present in the cache at the start of the sweep. b) The number of pages that can be excluded from the sweep Permission bits are likely to depend on information available at compile time and therefore may be overly permissive. The dirty bit is more dynamic, but over time it can approach the same number of pages as the permission bits, i.e. the likelihood of a capability store to a page increases over time. It is possible to clear the dirty bit during a sweep, but only pages that are known to no longer contain capabilities can be cleared. c) Providing information within the software to avoid the need to stop the world during a sweep To allow parallel threads or interruptions during a sweep, writing of stale capabilities to previously swept memory can be detected or prevented. Page permissions can be used to temporarily prohibit write capabilities to a swept page. However, this also affects normal write capabilities to the region. An exception handler may be needed to distinguish between these cases. The dirty bit is not suitable for tracking only stale capacity, since the dirty bit can only be cleared for pages that do not hold capacity.

[0056] Thus, the above-mentioned approach has a large impact on performance. In contrast, as shown in Figures 1 and 2, the approach described below provides a capability write address tracking circuit 20 in hardware that can track the address to which a capability write operation is made in a capability write address tracking structure 100. The capability write address tracking circuit 20 may be shared between multiple processor cores 4 as shown in Figure 1, or provided in individual processor cores as shown in Figure 2, or it may be a hybrid of these approaches, where some tracking hardware is shared and other hardware is provided separately for each core 4. The capability write address tracking structure 100 itself may be a dedicated hardware storage device, or it may be a data structure actually stored in the memory system and maintained by the capability write address tracking circuit 20. The capability write address tracking circuit 20 may be associated with an enable register 102 that controls whether tracking of the address of a capability write operation (an operation to write a capability from the capability register 70 to memory) is enabled or disabled, and several tracking metadata registers 104 that can find the location of the tracking structure in memory in an implementation that uses a tracking structure stored in the memory system. For example, the metadata registers 104 may include a base address 106 that identifies the starting address of the tracking structure, and a counter register 108 that marks the point in the tracking structure to which the next entry will be written. The metadata registers may also include a limit register 110 that may specify the maximum size allowed for the address tracking structure to guard against overflow. The various registers 102, 104 may be updatable by software.

[0057] Thus, by providing the tracking circuitry 20 in hardware, this may help to accelerate the undo sweep by avoiding the need for a stop-the-world sweep. Capability writes to memory are tracked during an undo sweep. At the end of the sweep, this tracking information may be used to selectively re-sweep to find the location of stale capabilities written by other threads or written during the suspension of the sweep process. In some examples, capability write address tracking may use a translation lookaside buffer (TLB) 52. For example, outside of an undo sweep, the TLB may not track capability writes. At the start of a sweep, tracking of capability writes may be enabled. During a sweep, the TLB 52 may set a dirty bit upon a capability write to the corresponding page of the address, and upon the transition of the dirty bit from 0 to 1, may record the address and ASID of the dirty page in the structure 100 maintained in memory at the address specified by the metadata register 104. The sweep algorithm itself does not write valid capabilities to memory. Thus, the sweep algorithm does not set the dirty bit, and a set dirty bit may be caused by a capability write made by another thread (which may be running in parallel with the sweep algorithm or during the suspension of the sweep algorithm). At the end of the sweep, the sweep algorithm may check the capability write address tracking structure 100 and selectively resweep pages marked as dirty to locate and invalidate stale capabilities written by other threads or during the suspension, and clear the record of the stale capabilities in the tracking structure 100. Optionally, to prevent further writes of stale capabilities and avoid subsequent resweeps, the sweep algorithm may set store capability permissions to prevent capability writes during the resweep, or may use a stop-the-world approach to stop the processing of other threads.

[0058] FIG. 5 illustrates an example of hardware that may be employed to track pages that have been "dirty" by capability writes. TLB entries in TLB 52 may be extended to each store a dirty bit (capability written indicator) 120. Note that this bit 120 does not carry over to page tables, and thus the bit 120 has no impact on the already significant overhead associated with these tables (when a TLB entry is evicted from the last level of the TLB that stores the dirty bit 120, the dirty bit may simply be discarded). As shown in decision box 122 of FIG. 5, the updating of the dirty bit 120 may be enabled / disabled by the enable control register 102 (set by software) to limit tracking of capability stores to a period selected by software, e.g., when software is performing a stale capability revocation sweep. Thus, when not tracking capability writes, the dirty bit is not set even if there is a capability write to a given page that was not previously dirty. Also, as shown in decision box 124 of FIG. 5, writes to a given page of a type that writes data other than a capability do not cause the dirty bit 120 to be set; tracking is specific to capability write operations that require a capability to be written to a corresponding location in memory.

[0059] Also, upon a 0 to 1 transition of the dirty bit 120 for a given page of address, the address of the corresponding page and the address space identifier (ASID) of that address are recorded in the capability write address tracking structure 100. Recording the ASID is not essential, but it can be useful so software can avoid several unnecessary re-sweeps of pages associated with different ASIDs that alias pages used by the process being swept.

[0060] 5 shows two examples of a capability write address tracking structure 100 that can be used to record address / ASID information on dirtied pages. These examples are alternatives and it is not necessary to provide both.

[0061] The example at the top of FIG. 5 shows a dirty page buffer that uses base address register 104 and counter register 108 to record information in consecutive order. When capability write tracking is enabled, each time a new page (not previously indicated as dirty in the corresponding TLB entry) is made dirty by a capability write operation, capability write address tracking circuit 20 writes the ASID and base address of the dirty page to an entry at address “Dst” obtained by adding a number of increments of a given size to the base address in base register 104, the number of increments being selected based on counter register 108. Since the buffer may be held in memory, limit register 110 is used to avoid overflow by signaling an exception if the calculated address Dst exceeds a limit. In response to an exception, an exception handler may trap to the operating system or other supervisory code and may trigger various buffer overflow handling responses, including any of the following: (i) updating the limit register 110 to expand the space available for the dirty page buffer (possibly after moving data from the region of memory immediately following the buffer to a different part of the address space), (ii) allocating a new block of memory larger in size for the dirty page buffer than the previously allocated buffer, copying the current dirty page buffer entries to the newly allocated block of memory, and then updating the base address 106 and the limit register 110 to correspond to the newly allocated block of memory, or (iii) having the sweep software initiate the sweep again, with the hope that next time fewer capability writes can occur while the sweep is taking place. The metadata registers 104 and buffer contents 100 may be restricted to be accessible only by privileged software, e.g., the cancellation code. This may be ensured, for example, by using a data capability that contains the buffer that is not shared outside the cancellation code, and by setting a privileged bit in the permissions 80 in the code capability that contains the cancellation code.

[0062] With a reasonably fast undo sweep, it is unlikely that multiple threads will run on the same core. Therefore, storing an ASID with each buffer entry, as shown in FIG. 5, may be inefficient. As an alternative, the dirty page buffer 100 can record each page address dirtied by a capability write, but a smaller list of ASIDs may be maintained, and only unique ASIDs not previously seen in a capability write are added to the ASID list. Alternatively, instead of an exact list of ASIDs, a single register, a Bloom filter (separate from the exact list of page addresses dirtied in the dirty page buffer), can be used to keep track of all observed ASIDs. This trades off reduced memory overhead against the potential for false positives.

[0063] In the dirty page buffer approach shown in the upper part of FIG. 5, this may provide several advantages. A counter can be used to determine the index of the last valid entry (counter-1), thus eliminating the need for a validity bit in each entry. A single adder can be used for both address calculation and counter up data, limiting hardware complexity. The TLB circuitry within the MMU 50 is reused to process writes to memory. Addressing is highly accurate, so the software only needs to resweep pages that are known to have been dirtied by a potential write.

[0064] The bottom part of FIG. 5 shows an alternative approach, which uses a Bloom filter as a replacement for a page buffer. Like the buffer, the Bloom filter is updated upon a 0 to 1 transition of the dirty bit, but uses a hash of the page address and the ASID, and any bit in the Bloom filter that corresponds to the result of the hash is set (if not already set). This provides less accurate tracking of addresses. When reading the tracking structure 100 to determine which pages to resweep, the sweep software may assume that any page address that hits against the Bloom filter expression (i.e., for that page address, the hash of the page address gives a value where all bits 1 in the hash value match bits set in the Bloom filter expression) may be one of the pages that have been dirtied by a capability write. This may include some false positives, where a page that has not actually been dirtied by a capability write is detected as dirty due to the hash of the page's address aliasing to a combination of bits set in response to a capability write to another page. Such false positives can sometimes be costly (in terms of the performance cost of unnecessarily re-sweeping some pages), but depending on the hashing algorithm used and the distribution of addresses of the dirtied pages, the risk may be acceptable to enable other benefits such as: Reduced hardware complexity (only simple hash and OR circuits are required, no full adders or memory accesses are required) Can handle an unlimited number of pages without risk of buffer overflow Does not use system memory Exceptions to increase the number of entries are unnecessary Not affected by duplicates (if the same TLB entry is evicted, refetched, and redirted, it does not change the size of the structure or page identified as needing a resweep; this differs from a dirty page buffer, where there is a risk of duplicate entries, which require some processing to remove the duplicates, or waste performance on unnecessary resweeps).

[0065] There are many other alternatives to the presented example. For example, both examples can be combined into a table structure indexed by a hash of the page address. Each entry can then hold a Bloom filter to represent all pages that alias to the Bloom filter. This alleviates the need to increase the buffer at runtime and reduces the risk of false positives. Alternatively, using a linked list with each entry instead of a Bloom filter can eliminate the risk of false positives, but also increases the complexity of the structure. Note that the number of pages that are dirtied during an undo sweep is likely to be small, so the limited buffer size above is unlikely to be a major factor.

[0066] In the context of a multi-core environment, an undo sweep may need to prevent or detect writes of stale capabilities to previously swept memory, handle legitimate accesses to pages currently being swept, and locate stale capabilities held in registers and other memory structures associated with other cores. The dirty page tracking structure described above allows for detection of writes of stale capabilities to previously swept memory without the need to stop other threads. Because the dirty page tracking structure only detects, not prevents, such writes, the dirty pages may need to be re-swept. To avoid the need for subsequent iterations, the algorithm may stop the world during the re-sweep. Alternatively, it may temporarily clear the "capability storeable" permission bits of the pages being swept. Concurrent threads that attempt to write capabilities to these pages will therefore trap to the OS. The corresponding exception handler needs to be aware of the sweep. Outside of the sweep, it handles legitimate permission violations of the pages. During the sweep, it may delay this return until the sweep is complete, or it may return to the thread immediately. The latter will trigger a replay of the capability store that is in violation, resulting in further exception events until the sweep is completed by restoring the original page permissions. More complex handlers may allow threads to continue even while a sweep is in progress.

[0067] The proposed tracking structures may be shared between cores or may be replicated for each core. Since the initial dirtying of a page is expected to be rare, it may be possible to share the associated hardware overhead between cores. In the case of replicated structures, the ASID may be used by the sweep algorithm to skip structures that do not belong to the currently running process. As mentioned above, providing an ASID is optional.

[0068] One way for software to clear stale capabilities held in another core's registers is to identify the relevant thread based on its ASID, trigger a context switch, and evaluate the contents of the swapped-out registers in memory. These context switches can occur at the end of a cancellation sweep, i.e., when all stale capabilities have been removed from memory. This allows for an immediate return to the switched-out thread without the risk that the switched-out thread may retrieve the stale capabilities from memory.

[0069] 5 shows tracking of dirty pages in a TLB, it is also possible to use another type of cache (such as L1 data cache 54) to track blocks of addresses to which capability writes are made. Also, in some examples, the use of dirty bit 120 to track addresses to which capability writes are made may be unnecessary, and in these examples for capability writes to a given address, when capability write address tracking is enabled, tracking circuitry 20 may simply update capability write address tracking structure 100 regardless of whether a capability write to the same address has already been made previously. For example, in the Bloom filter example, there is less penalty in redundantly updating the structure multiple times for the same address, and thus the overhead of checking dirty bit 120 may not be considered necessary. On the other hand, for the dirty page buffer example, the use of dirty bit 120 may be very useful in reducing the likelihood that duplicate entries are allocated to the buffer.

[0070] Figure 6 shows a flow diagram illustrating a method for sweeping stale capabilities using a capability write address tracking structure 100 of the type described above. The method shown in Figure 6 shows steps performed by software responsible for sweeping memory to find stale capabilities. The method of Figure 6 does not show operations that the hardware performs in the background, such as updating the capability write address tracking structure 100 in response to detected capability write requests from the various processor cores 4.

[0071] At step 200, the capability sweep software may optionally reset the capability write address tracking structure 100, for example, by clearing all addresses from the capability write address tracking structure 100 and all dirty bits in the TLB or other cache used to mark pages on which a capability write operation has been made. The reset operation may be unnecessary if the capability write address tracking structure can be guaranteed to already be cleared, for example, if the software always clears the capability write address tracking structure 100 after using it. The reset at step 200 may also be unnecessary if the software has just allocated a new capability write address tracking structure 100 and is thus using this tracking structure for the first time (in implementations where the capability write address tracking structure is a region of memory that may have been cleared as a result of allocating a capability write address tracking structure).

[0072] In step 202, the sweep software executes an instruction to set enable register 102 to enable capability write address tracking by capability write address tracking circuit 20. Thus, capability write address tracking circuit 20 now begins marking entries in TLB 52 as dirty when it detects that a capability write operation has occurred on the corresponding page, and writes the addresses of such dirty pages to capability write address tracking structure 100 (or alternatively updates an inaccurate representation of the addresses of pages to which capability writes are made, e.g., using a Bloom filter as described above). This capability write address tracking continues in the background while the sweep is in progress.

[0073] At step 204, a sweep of the memory address space for stale capabilities begins. At step 204, the next memory address region to be swept is read by the sweep software, and when the contents of this memory address region become available, at step 206, the software checks whether the read address region stores a stale capability. A capability is now considered stale if its valid tag 82 is set and the range information 76, 78 specified for the capability overlaps with any of one or more memory address regions specified in the revocation list of the address region to be revoked. This revocation list may have been updated because regions of memory have been deallocated by the operating system, but the sweep of stale capabilities may have been postponed until a sufficient number of regions have been listed to avoid incurring the performance cost of a sweep each time an address region is deallocated. If the read memory address region stores a stale capability, at step 208, the stale capability is disabled by clearing the stale capability tag value 82. Step 208 is omitted if the read memory address area does not store stale capabilities. In step 210, the software checks whether there is at least one memory address area that still needs to be swept, and if so, the method returns to step 204 and loops through steps 204-210 until eventually all required memory address areas have been swept.

[0074] If there are no memory address regions that need to be swept, the method proceeds to step 212. Since there is a risk that other threads or processor cores may have written capabilities to previously swept memory address regions after the sweep process has already checked these regions to see if they store stale capabilities, there is a risk that the memory address space may still contain some stale capabilities, and thus a selective resweep is performed to check the address regions indicated by the capability write address tracking structure 100 for stale capabilities. However, to ensure that no further capability writes are performed during the resweep, in step 212, before performing the resweep, the sweep software takes action to ensure that no capability write operations are performed in the reswept memory. This can be done in different ways. One example could be simply using a "stop the world" approach, where all processing in other cores is stopped. However, while the "stop the world" approach does have a performance impact, because it is only used during the re-sweep of the small number of memory address regions indicated in capability write address tracking structure 100, this has a much lower performance impact than if the world were stopped during the entire main sweep loop of steps 204 through 210. Alternatively, rather than stopping processing in other cores, software can update the memory permissions of the swept memory address space to indicate that they will not be used to store capabilities temporarily during the re-sweep.

[0075] In step 214, the sweep process also disables capability write address tracking by clearing enable register 102 since it is no longer necessary to track capability write operations.

[0076] In step 216, the sweep software then re-sweeps the memory address regions indicated in the capability write address tracking structure 100 and invalidates any stale capabilities found within those regions. Step 216 itself may include a loop similar to steps 204-210 performed for the main sweep operation, but it will be appreciated that the loop typically needs to iterate many fewer times than the main loop because it checks only selected regions indicated in the capability write address tracking structure 100. Once a given region has been re-swept, the corresponding portion of the capability write address tracking structure may be cleared in the example where a dirty page buffer is used as described above. In the case of a Bloom filter or other imprecise expression, the re-sweep may cover addresses that generate hits when the filter expression is queried for the addresses, which may include some false positive addresses that do not in fact have a capability write operation during the period in which the capability write address tracking was performed, but are re-swept because these addresses alias against the pattern of bits in the filter expression that were set as a result of a capability write operation to another address.

[0077] Once the resweep process 216 is complete, in step 218 the sweep software can re-enable capability write operations to the swept memory, for example, by resuming processing in other processor cores or by updating the "capability storeable" permission to again allow capabilities to be stored within the swept memory region.

[0078] Step 212 is optional, and in an alternative approach, rather than blocking capability writes during the memory resweep, capability write address tracking can remain enabled during the resweep, and then multiple iterations of the resweep process 216 can be performed until no additional addresses are recorded in the capability write address tracking structure 100 and the resweep is complete.

[0079] When capability write address tracking is enabled, if the capability write address tracking structure 100 reaches or exceeds a maximum capacity specified by the limit register 110 during a main sweep or resweep, an exception may be triggered. The exception handler may respond to this exception in a variety of different ways. The exception handler may update the metadata register 104, may allocate additional memory space for the tracking structure 100, or may simply restart the sweep process of FIG. 6 from the beginning again in the hope that next time fewer capability writes may occur during the sweep process.

[0080] So, in summary, by providing in hardware a capability write address tracking circuit 20 which maintains tracking information capable of identifying the selected address to which a capability write operation was made, this means that the sweep software does not have to stop the world during a main sweep of the entire memory address space, which can greatly improve performance.

[0081] FIG. 7 illustrates a simulator implementation that may be used. While the above embodiments implement the invention in terms of apparatus and methods for operating specific processing hardware supporting the technology, it is also possible to provide an instruction execution environment according to the embodiments described herein 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 run on a host processor 330, optionally running a host operating system 320 that supports the simulator program 310. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or there may be multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations that run at reasonable speeds, but such an approach may be justified in some situations, for example when it is desired to run code native to another processor for compatibility or reuse reasons. For example, a simulator implementation may provide an instruction execution environment that has additional features not supported by the host processor hardware, or that are 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.

[0082] To the extent that embodiments are described with reference to particular hardware constructs or features, in the simulated embodiments, equivalent functionality may be provided by suitable software constructs or features. For example, particular circuits may be implemented as computer program logic in the simulated embodiments. Similarly, memory hardware such as registers or caches may be implemented as software data structures in the simulated embodiments. In arrangements where one or more of the hardware elements referenced in the foregoing embodiments reside in host hardware (e.g., host processor 330), some simulated embodiments may use the host hardware where appropriate.

[0083] Simulator program 310 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (an instruction execution environment) to target code 300 (which may include applications, operating systems, and hypervisors) that is the same as the application program interface of the hardware architecture being modeled by simulator program 310. Thus, program instructions of target code 300, including instructions that interact with the capabilities described above, may be executed from within an instruction execution environment using simulator program 310, such that a host computer 330 that does not actually have the hardware features of device 2 described above can emulate these features.

[0084] The simulator code 310 may include instruction decode program logic 312 that decodes program instructions of the target code 300 and maps the program instructions of the target code 300 to a corresponding set of instructions defined in the native instruction set of the host processor 330. The simulator code 310 may also include register emulating program logic 314 that manages data structures in the memory of the host hardware that emulate the registers 38, 102, 104 of the simulated target architecture. Capability validity check program logic 316 may also be provided that emulates the capability check circuit 86 described above to check whether the requested use of a capability is allowed given the capability scopes 76, 78 and permissions 80. Capability write address tracking program logic 318 may also be provided that detects capability writes to memory when tracking is enabled and maintains a capability write tracking structure to provide an indication of which page the capability write was made to. The simulator code 310 may thus present architectural features to the target code equivalent to those of the hardware implementation described above, so that, again, the target code can perform a sweep of obsolete capabilities as if the target code were running on a device that has capability write address tracking circuitry 20, again in the same manner as on a host data processing device (which may not itself have capability write address tracking circuitry).

[0085] In this application, the term "configured to..." is used to mean that elements of an apparatus have a configuration that can perform a defined operation. In this context, "configuration" refers to a manner of arrangement or interconnection of hardware or software. For example, an apparatus may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform a function. "Configured to" does not mean that the apparatus elements have to be modified in some way to provide the defined operation.

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

Claims

1. a capability check circuit that performs a capability check operation to determine whether the use of a capability satisfies one or more usage limitation conditions, the capability including a pointer and pointer usage limitation information that specifies the one or more usage limitation conditions, the one or more usage limitation conditions including at least an allowable range of an address of the pointer; a capability write address tracking circuit that, when capability write address tracking is enabled, updates a capability write address tracking structure based on a capability write target address in response to a capability write request requesting that a capability be written to a memory location associated with the capability write target address; An apparatus comprising: The capability write address tracking structure comprises a hardware provided storage unit separate from the memory or a data structure stored within the memory.

2. The apparatus of claim 1 , further comprising an enable storage element configured to store a capability write address tracking enable indication indicating whether the capability write address tracking is enabled or disabled.

3. 3. The apparatus of claim 2, wherein when, in response to the capability write request, the capability write address tracking enable indication indicates that capability write address tracking is disabled, the capability write address tracking circuit is configured to omit updating the capability write address tracking structure based on the capability write target address of the capability write request.

4. The apparatus includes processing circuitry for executing program instructions; 4. An apparatus as claimed in claim 2 or 3, wherein the capability write address tracking enable indication is updatable by the processing circuitry in response to program instructions executed by the processing circuitry.

5. The apparatus includes a cache structure including a plurality of entries, each entry storing cache information associated with a corresponding memory address range; In response to the capability write request, the capability write address tracking circuit is configured to set a capability written indicator in an entry of the cache structure corresponding to a memory address range that includes the capability write target address; The apparatus of any one of claims 1 to 4, wherein in response to the capability written indicator in an entry of the cache structure transitioning from unset to set, the capability write address tracking structure is updated based on the capability write target address.

6. 6. The apparatus of claim 5, wherein in response to the capability write request, when capability write address tracking is enabled and the capability write target address corresponds to a memory address region for which a corresponding cache entry already has the capability written indicator set, the capability write address tracking circuit is configured to omit updating the capability write address tracking structure based on the capability write target address.

7. 7. Apparatus according to claim 5 or 6, wherein the cache structure comprises an address translation cache that stores address translation information derived from a page table structure in memory.

8. 8. The apparatus of claim 7, wherein when an entry having the capability written indicator set is evicted from the address translation cache, the address translation cache is configured to discard the capability written indicator without writing the capability written indicator back to the page table structure in memory.

9. the apparatus comprises a processing circuit for processing instructions from one of a plurality of software processes, each software process being associated with a corresponding execution context identifier; The apparatus of any one of claims 1 to 8, wherein when capability write address tracking is enabled, the capability write address tracking circuitry is configured to maintain execution context identifier tracking information for tracking one or more execution context identifiers associated with one or more capability write requests.

10. The apparatus includes processing circuitry for executing program instructions; Apparatus according to any preceding claim, wherein in response to a reset capability write address tracking command, the processing circuitry is configured to reset the capability write address tracking structure.

11. A base address of the write address tracking structure; an indication of the next entry to be updated in the capability write address tracking structure; and A limiting indication of the maximum allowable size of the capability write address tracking structure. The apparatus of claim 1 , further comprising at least one tracking metadata storage element configured to store at least one of:

12. The apparatus of any one of claims 1 to 11, wherein the capability write address tracking structure tracks one or more particular capability write target addresses of one or more capability write requests received when capability write address tracking is enabled.

13. 13. The apparatus of claim 1, wherein the capability write address tracking structure tracks one or more capability write target addresses of one or more capability write requests received when capability write address tracking is enabled, such that querying of the capability write address tracking structure may allow an address other than the one or more capability write target addresses to be pseudo-identified as one of the one or more capability write target addresses.

14. 14. The apparatus of claim 1, wherein in response to detecting that the capability write address tracking structure has reached a capacity limit, the capability write address tracking circuit is configured to trigger signaling of an exception.

15. The apparatus includes a plurality of processor cores; The apparatus of any preceding claim, wherein the capability write address tracking structure is shared among the multiple processor cores.

16. A capability check circuit performing a capability check operation to determine whether use of a capability satisfies one or more use limitation conditions, said capability including a pointer and pointer use limitation information specifying said one or more use limitation conditions, said one or more use limitation conditions including at least an allowable range of an address of said pointer; updating, in the capability write address tracking circuit, a capability write address tracking structure based on the capability write target address in response to a capability write request requesting that a capability be written to a memory location associated with the capability write target address when capability write address tracking is enabled; A method comprising: The method of claim 1, wherein the capability write address tracking structure comprises a hardware provided storage unit separate from the memory or a data structure stored within the memory.

17. 1. A computer program for controlling a host data processing apparatus to provide an instruction execution environment for executing target code, comprising: a capability checking program logic that performs a capability checking operation to check whether the use of a capability satisfies one or more usage restriction conditions, the capability including a pointer and pointer usage restriction information that specifies the one or more usage restriction conditions, the one or more usage restriction conditions including at least an allowable range of an address of the pointer; capability write address tracking program logic for, when capability write address tracking is enabled, updating a capability write address tracking structure based on a capability write target address in response to a capability write request requesting that a capability be written to a memory location associated with the capability write target address; Including, The capability write address tracking structure comprises a storage unit provided in program logic separate from the memory program logic or a data structure stored within the memory program logic.

18. A method performed by a data processing device, comprising: enabling capability write address tracking by a capability write address tracking structure that tracks capability write target addresses of one or more capability write requests, the capability write requests including requests to write a capability to a memory location associated with a capability write target address specified by the capability write requests, the capabilities including a pointer and pointer usage restriction information that specifies one or more usage restriction conditions including at least an allowable range of addresses of the pointer; sweeping memory to invalidate stale capabilities, the stale capabilities including capabilities where the allowed range of addresses overlaps with one or more target regions of addresses; after sweeping the memory, re-sweeping one or more selected memory address regions corresponding to addresses tracked by the capability write address tracking structure to invalidate stale capabilities stored within the one or more selected memory address regions; Including, The method of claim 1, wherein the capability write address tracking structure comprises a hardware provided storage unit separate from the memory or a data structure stored within the memory.

19. 20. A computer program product for causing said data processing apparatus to carry out the method of claim 18.

Images