Circuitry and method for carrying out memory operations

Abstract

A method for carrying out memory operaons in capability-based memory access-control hardware. The method comprises determining (610), for a first memory operaon for a first memory locaon, whether stored capability data associated with the first memory locaon permits the first memory operaon, based on a permissions mask in the capability data. The method further comprises, upon determining that the first memory operaon is permied together with performing the first memory operaon at the first memory locaon, modifying (620) permission-specific memory bounds informaon in the stored capability data associated with a second memory operaon and / or modifying permission-specific memory bounds informaon in the stored capability data associated with the first memory operaon. Further, there is a memory access-control circuitry.

Description

[0001] CIRCUITRY AND METHOD FOR CARRYING OUT MEMORY OPERATIONS

[0002] TECHNICAL FIELD

[0003] The present disclosure is generally related to capability-based memory access-control hardware and is more particularly related to a memory access-control circuitry and a method for carrying out memory operations in capability-based memory access-control hardware.

[0004] BACKGROUND

[0005] Capability-based addressing is a memory access-control paradigm used by some computer microprocessor architectures to improve the low-level security of computer programs. An early description of capability-based addressing is found in "Capability-based addressing," R.S. Favry, Commun. ACM 17, 7 (July 1974), 403-412. In capability-based addressing, the pointers traditionally used to store memory addresses, i.e., references to locations in computer memory, are replaced by protected objects, called capabilities, which can only be created through privileged instructions that can be executed only by the operating system kernel or some other privileged process authorized to delegate access to protected portions of computer memory.

[0006] Capabilities carry, in addition to the memory address, additional information that can be used by the microprocessor or the memory-management subsystems within a computer to decide whether memory accesses performed through a capability are correct and permitted. The exact composition of a capability varies between different hardware instantiations of a capability-based addressing, but virtually all hardware architectures that implement capabilities include hardware-supported descriptions of permissions associated with memory operations or instructions, such as read (r), write (MZ), and execute (x), that can be used to control whether the memory referenced through the capability may be used as part of load and store instructions or instruction fetches. Capabilities also incorporate bounds information that is used to limit the range of memory that can be referenced via a particular capability.

[0007] The origins of capability-based addressing can be traced to the mainframe computer architectures prevalent in the early 60's. These early systems pre-date conventional virtual memory enforced through address translation performed by memory-management units (MMUs) within a processor. Consequently, capabilities were used as the sole mechanism for memory protection, although they were eventually made obsolete by MMU-based computer architectures capable of memory isolation through the means of isolated virtual memory. However, in the last decade, there has been a new interest in capabilitybased addressing as a complement to MMU-based memory access control. The most prominent example of such a hybrid capability architecture is CHERI (Capability Hardware Enhanced RISC Instructions), a joint research project between SRI International and the University of Cambridge. CHERI is described in "An Introduction to CHERI," R. N. M. Watson et al., Technical Report UCAM-CL-TR- 941ISSN 1476-2986 (available at www.cl.cam.ac.uk / techreports / UCAM-CL-TR-941.pdf). Other examples of modern capability-based addressing schemes include guarded pointersO, and RV-CURE, which are described by "Hardware support for fast capability-based addressing," N. P. Carter, S. W. Keckler, and W. J. Dally, SIGPLAN Not. 29, 11 (Nov. 1994), 319-327 (available at doi.org / 10.1145 / 195470.195579) and "RV-CURE: A RISC-V Capability Architecture for Full Memory Safety," Y. Kim and A. Kar and J. Lee and J. Lee and H. Kim, arXiv abs / 2308.02945 (2023).

[0008] Following is a summary of capabilities in the Cambridge CHERI architecture from Watson et al. However, the CHERI capability model has so far been adapted for the MIPS (CHERI-MIPS), RISC-V (CHERI-RISCV) and ARMv8-A (Arm Morello) instruction set architectures, with currently ongoing efforts of adapting CHERI to the x86 architecture. Each of these instantiations of CHERI differs in terms of the concrete encoding of capabilities, in dependence on the architectural properties of the baseline architecture. For example, the size of a CHERI capability is twice the width of the native integer type; 64-bit platforms have 128-bit capabilities on 64-bit platforms, and 32-bit architectures have 64-bit capabilities in the CHERI protection model and so forth. Additionally, the representation of capability bounds can take different forms depending on the number of bits available in the capability representation. For example, compressed bounds encodings for 64-bit and 128-bit capabilities have been described in "CHERI Concentrate: Practical Compressed Capabilities," J. Woodruff et al., IEEE Transactions on Computers, vol. 68, no. 10, pp. 1455-1469, 2019. For simplicity, capabilities are described herein in a way that are agnostic to any given baseline architecture. Additionally, the concepts and techniques described in the detailed description below are applicable to any capability-based addressing scheme, with the recognition that the exact encoding of bounds information, permissions or other data associated with a capability may differ between different instantiations.

[0009] CHERI consists of an instruction set architecture (ISA) extension with new architectural features that enable:

[0010] • memory-unsafe programming languages such as C and C++ to be adapted to provide efficient protection against many currently widely exploited memory vulnerabilities such as buffer overflows and overreads; and

[0011] • hardware-enforced in-process or in-kernel software compartmentalization. CHERI's instantiation of capabilities, which is illustrated in Figure 1, consists of an integer address of the natural size for the architecture and additional metadata that is compressed to fit in the remaining bits of the capability.

[0012] Each element of the capability in the CHERI implementation is enforced by hardware. Each capability is associated with a 1-bit validity "tag" 110, which is maintained implicitly in registers and memory. The validity tag 110 tracks the validity of a capability and ensures that only special capability write instructions can be used to create valid capabilities. Regular memory writes (even when partial) to the memory area of the capability itself clear the validity tag 110 and invalidate the capability. This prevents corrupt capabilities from being dereferenced.

[0013] A permissions mask 120 controls how the capability can be used - for example, by restricting loading (read) and storing (write) of data and / or capabilities or by prohibiting instruction fetch (execute). Every load and store instruction or instruction fetch in a CHERI-enabled microprocessor architecture must be authorized by an architectural capability with the corresponding permissions.

[0014] The CHERI capability also includes an object type 130. Object types allow multiple capabilities to be associated with each other to facilitate, e.g., software compartmentalization where only a certain set of capabilities can be used within a logically isolated compartment. The object type field also facilitates capability "sealing", a feature in the CHERI protection model that is used to render a valid capability temporarily "undereferencable" until it is explicitly unsealed by a special capability "unseal" instruction.

[0015] The capability shown in Figure 1 further comprises bounds 140. Lower and upper bounds describe the portion of the address space to which the capability authorizes loads, stores, and / or instruction fetches, depending on the permissions the capability grants via the permissions mask 120. The bounds 140 is compressed, relative to the baseline architecture address 150, which is a conventional pointer in the underlying native format of the ISA.

[0016] SUMMARY

[0017] Current approaches to capability-based addressing, including CHERI capabilities, are static in the sense that capabilities, once created, remain immutable unless they are explicitly modified or replaced by a new capability created by privileged instructions issued by an authorized reference monitor. This property is necessary to ensure the integrity of capabilities in architectures such as CHERI. However, it makes capabilities currently described in the literature ill-suited for enforcing access-control policies, where it is desirable for the permissions for a particular memory region to change over time, rather than remain static.

[0018] The reason for this is that software developed in languages such as C or C++ are written with the underlying assumption that the same pointer can be used both for both writing and reading memory and to execute code in memory marked as code pages. This is because, in a conventional operating system design, the memory permissions are associated with the page mapping and are maintained by the memory management hardware. Consequently, as the memory permissions change, e.g., as a result of memory protection operations exposed by operating system such as mprotect(), the pointer to the memory remains unchanged can be re-used for accesses memory (that are permitted) as the underlying permissions to the memory might have changed. Capabilities, by associating permissions to the object used to reference memory itself, invalidate this assumption.

[0019] Accordingly, an object of the invention is to provide enhanced capability-based addressing by extending the set of access-control policies that can be expressed though capabilities to allow "adaptive" memory access-control permissions. These include, but are not limited to, "Write-before-Read" permissions that can prevent software defects from causing uninitialized memory to be inadvertently used, as in the Heartbleed vulnerability. By "Write-before-Read" is meant a memory access control that ensures that any memory to which a capability gives read access should be written to at least once, using that capability, before the underlying hardware allows stored data to be retrieved by load instructions. The adaptive permissions enabled by the techniques and apparatuses described herein can be instantiated in a variety of ways beyond "Write-before-Read," as will be discussed in detail below.

[0020] The techniques and apparatuses described in detail below employ permission-specific memory bounds information, in or associated with a capability, to provide these adaptive permissions. An extended capability as described herein can be used to perform an operation, such as a "write" operation, at a particular memory location or range of memory locations, with the execution of that operation triggering a controlled change in the permission-specific memory bounds information for another memory operation, such as a "read" operation. Several variations of this general approach are described below.

[0021] According to a first aspect of the invention, a method comprises determining, for a first memory operation for a first memory location, whether stored capability data associated with the first memory location permits the first memory operation, based on a permissions mask in the capability data. The method further comprises, upon determining that the first memory operation is permitted, and together with performing the first memory operation at the first memory location, modifying permission-specific memory bounds information in the stored capability data associated with a second memory operation and / or modifying permission-specific memory bounds information in the stored capability data associated with the first memory operation.

[0022] According to another aspect of the invention, a memory access-control circuitry comprises a capabilities memory storage area configured to store capability data associated with one or more memory locations in an operations-accessible memory area and digital control circuitry operatively coupled to the capabilities memory storage area and to the operations-accessible memory area. The digital control circuitry is configured to determine, for a first memory operation for a first memory location in the operations-accessible memory area, whether stored capability data associated with the first memory location permits the first memory operation, based on a permissions mask in the capability data. The digital control circuitry is further configured to, upon determining that the first memory operation is permitted, and together with performing the first memory operation at the first memory location, modify permission-specific memory bounds information in the stored capability data associated with a second memory operation and / or modifying permission-specific memory bounds information in the stored capability data associated with the first memory operation.

[0023] An advantage of the solutions described herein is that they enable capability hardware to enforce a variety of novel access-control permissions beyond conventional read (r), write (w), and execute (x) permissions. These new access-control permissions can allow the permissions for a particular memory region to change over time, in a controlled way, rather than requiring those permissions to remain static.

[0024] BRIEF DESCRIPTION OF THE FIGURES

[0025] Figure 1 illustrates the layout of a CHERI capability.

[0026] Figure 2 shows a capability layout extended with adaptive permissions, in accordance with some embodiments.

[0027] Figure 3 illustrates a capability layout including per-operation bounds using baseline bounds representation, e.g., compressed relative to the baseline architecture address. Figure 4 illustrates a capability layout including per-operation bounds expressed relative to the baseline bounds: lower and higher bound expressed as an, e.g., offset relative to the baseline bounds.

[0028] Figure 5 shows per-operation bounds expressed as bitmap relative to baseline bounds.

[0029] Figure 6 is a process flow diagram illustrating an example method for carrying out memory operations in capability-based memory access-control hardware, according to some embodiments.

[0030] Figure 7 is a block diagram showing example memory-access control circuitry, according to some embodiments.

[0031] DETAILED DESCRIPTION

[0032] As noted above, capabilities as currently described in the literature are ill-suited for enforcing accesscontrol policies, because they are static, in that the capability associated with a particular memory location or range of memory locations remains immutable unless explicitly modified or replaced by a new capability created by privileged instructions issued by an authorized reference monitor.

[0033] Consider for example the problem of uninitialized memory reads in languages such as C or C++. In these languages, reads from memory allocated on the heap or stack are undefined in the language specifications. Modern C / C++ compilers typically do not implicitly initialize memory for allocation on the heap or stack for performance considerations. Underlying process architectures therefore typically allow reads to uninitialized memory, thereby allowing access to stale memory contents, which may have belonged to previously allocated objects created by the program, which have since been freed.

[0034] This may inadvertently expose to sensitive information to cyberattacks, as was the case in CVE-2014- 0160, also known as "Heartbleed," which, due to a bug in the OpenSSL, caused different web server software to expose stale memory contents to remote information disclosure attacks. This was due to a programming mistake that involved the web server reading uninitialized memory from a buffer used to craft a response to Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) Heartbeat Extension responses. This high-severity vulnerability exposed cryptographic keys remaining in stale memory to remote attackers when it was discovered in 2014, and despite that software updates that fix the Heartbleed vulnerability were available on the date of the disclosure, many systems today remain unpatched and still vulnerable to Heartbleed. While capability-based addressing in architectures such as CHERI can address many low-level memory vulnerabilities, such as buffer overflows and overreads, they are not able to express memory accesscontrol policies that would prevent conditions such as Heartbleed, where uninitialized memory from a legitimately accessed buffer is leaked due to a software defect.

[0035] The techniques described herein for addressing this problem are based on three new approaches to capabilities-based addressing:

[0036] • associating permissions in a conventional capability-based addressing scheme with additional permission-specific bounds stored as part of a capability;

[0037] • extending the permission mask associated with capability with new, adaptive permissions that can be set on a capability which allows the state of the capability to be changed on specific hardware triggers; and

[0038] • extending hardware circuitry in the microprocessor and / or memory management subsystem to watch for conditions in a capability's state (i.e., its representation in memory) and operations (e.g., loads, stores or instruction fetches) the capability is used for, and upon specific conditions occurring, updating the state of a capability in memory, such as bounds associated with specific permissions.

[0039] The resulting extended capabilities differ from capabilities in conventional capability-based addressing in two significant ways:

[0040] • The extended capability can be used to enforce different bounds for different operations, e.g., loads, stores or instruction fetches, whereas conventional capability only enforce a single set of bounds for each operation the capability grants the corresponding permissions for.

[0041] • The permissions the extended capability grant can change over time in response to hardware triggers, unlike conventional capability architectures where privileged instructions must be used to modify or issue new capabilities.

[0042] An advantage of the solution described herein is that it allows capability hardware to enforce a variety of novel access-control permissions beyond conventional read (r), write (w), and execute (x) permissions. Examples include the following adaptive permissions and corresponding use cases:

[0043] • Write-before-Read - Memory for which the capability grants write access to must be written to (at least once) before read-access is granted. This adaptive permission can be used to prevent reads to uninitialized memory. • Write-before-Execute - Memory for which the capability grants write access to must be written to (at least once) before execute access (instruction fetch) is granted. This adaptive permission can be used to prevent the execution of uninitialized memory, e.g., in Just-in-Time compilers that simultaneously compile and execute code from memory allocated on the application heap.

[0044] • Write-before-Read-Only - Memory for which the capability grants write access to must be written to exactly once before read access is granted. Subsequent write access is not allowed. This adaptive permission can be used to enforce hardware-level immutability of program data, e.g., constant values which are generated at run-time (i.e., initialized once), but once written to memory should not change.

[0045] • Write-before-Execute-Only - Memory for which the capability grants write access to must be written to exactly once before execute access is granted. Subsequent write access is not allowed. This adaptive permission allows emulation of Execute-Only-Memory (XOM) using capabilities. Typically, XOM must be initialized by firmware during the early boot stages of the computing system, and can be used e.g., to conceal cryptographic key material from later boot stages such as from kernel code while still enabling the kernel on operate on the material in pre-defined ways. For example, firmware-controlled XOM has been used to allow kernel code to configure a cryptographic key it does not have access to into hardware registers on kernel context switches, to avoid an even higher context-switch cost a hypervisor to when initializing key registers at runtime.

[0046] • Write-once - Memory for which the capability grants write access can be written to exactly once. (Read and execute permissions may be static or adaptive).

[0047] • Read-once - Memory for which the capability grants read access can be read exactly once. (Write and execute permissions may be static or adaptive).

[0048] • Execute-once - Memory for which the capability grants execute access can be read exactly once. (Write and read permissions may be static or adaptive).

[0049] This set of adaptive permissions allow the definition of "single-use" code and data which enable policies that can be used to harden software against run-time attacks that aim to re-use existing program resource, e.g., code-reuse attacks. For example, code-reuse attacks such as Return-Oriented- Programming can use pre-existing sequences of instructions to craft malicious control-flows that can be used to compromise program behavior. Code that a process runs only once, e.g., a fixed sequence of initialization code could, using the "Execute-once" adaptive permission be called once during program initialization after which is rendered useless for code-reuse attacks later during the process' lifetime.

[0050] Note that the above set is simply an example - other adaptive permissions can be implemented using the techniques described herein.

[0051] Figure 2 illustrates an example of changes to a pre-existing capability layout, e.g., to a CHERI capability, after extending the capability with support for adaptive permissions. As seen in the figure, the existing permissions mask is extended with additional entries, referred to here as adaptive access permissions (AAC permissions) 210. Different instantiations may support different sets of adaptive permissions. For simplicity, for the description here it is assumed the permissions mask is extended to support a "Write- before-Read" operation.

[0052] The capability is also extended with additional elements for storing per-operation bounds 220 and 230. These elements or fields can alternatively be referred to as permission-specific memory bounds information, each of which defines the memory bounds, i.e., the range or map of memory locations within which a particular permission, e.g., for a "write" or "read" operation, may be utilized - thus, the memory bounds specified by operations bounds 220 and 230 are each specific to a respective operation or permission. In this example, the first operation bounds 220 consists of lower and upper bounds that describe the portion of the address space the first operation (write) is granted for, while the second operation bounds consists of the lower and upper bounds that describe the portion of the address space the second operation (read) is granted for.

[0053] Note that whereas the baseline bounds 240 are fixed as per the immutability requirement of conventional capability architectures, either or both of the per-operation bounds 220 and 230 may change in response to hardware triggers, e.g., operations the capability is used for. The AACs indicate which triggers are active for any given capability.

[0054] In the following, the triggers for the "Write-before-Read", "Write-before-Read-Only", and "Write-once" AACs are described. The triggers for Write-before-Execute", "Write-before-Execute-Only", "Read-once", and "Write-once" are similar, but defined according to the corresponding second operation permissions. Write-before-Read: When a capability has the Write-before-Read AAC, the write and read operation bounds may change in response to certain trigger events, as follows:

[0055] • When the capability is created, the write-before-read AAC is set, and the write operation bounds are set to equal the baseline bounds (the whole portion of the address space the capability grants access to is writable) and the read operation bounds are set to '0' (none of the portion the capability grants access to is readable). As a result, the capability can be used as an operand for store operations, but attempts to use the capability for loads or instructions fetches within the baseline bounds will trigger hardware faults.

[0056] • A typical use case for the Write-before-Read AAC permission is likely to be sequential writes of the portion of the address space the capability grants access to, e.g., initializing memory buffers from uninitialized state to initialized state. Thus, when the memory access control hardware detects the capability is used as an operand for a sequential store (i.e., the address of the store is adjacent to the lower or upper bound of the write operation bound), as part of the store operation hardware circuitry in the microprocessor or part of the memory management subsystem sets the read operation bounds to include the target address of the store. As a result of this change, the capability now grants write access to the whole portion of the address space described by the write operation bounds, and grants read access to the portion of the address space described by the read operation bounds, i.e., to that portion of the address space that has been the object of at least one prior store operation.

[0057] Write-before-Read-Only: When the capability has the Write-before-Read-Only AAC, the write and read operation bounds change in response to the following trigger events:

[0058] • When the capability is created, the Write-before-Read-Only AAC is set, and the write operation bounds are set to equal the baseline bounds (the whole portion of the address space the capability grants access to is writable) and the read operation bounds are set to '0' (none of the portion the capability grants access to is readable). As a result, the capability can be used as an operand for store operations but attempts to use the capability for loads or instructions fetches will trigger hardware faults.

[0059] • When the hardware detects the capability is used as an operand for a sequential store (i.e., the address of the store is adjacent to the lower or upper bound of the write operation bound), as part of the store operation hardware circuitry in the microprocessor or part of the memory management subsystem sets the read operation bound to include the target address of the store.

[0060] • When the hardware detects the capability is used as an operand for a sequential store (i.e., the address of the store is adjacent to the lower or upper bound of the write operation bound), as part of the store operation hardware circuitry in the microprocessor or part of the memory management subsystem sets the write operation bound to exclude the target address of the store. As a result of this change, the capability now grants write access to the portion of the address space described by the write operation bounds that has not been the object of a prior write operation and has and read access to the portion of the address space described by the read operation bounds, i.e., has been the object to of exactly one prior store operation.

[0061] In each of these cases (write-before-read and write-before-read-only), the microprocessor or memorymanagement subsystem circuitry is designed to enforce the invariant that per-operation bounds cannot extend beyond the baseline bounds (e.g., the baseline bounds 240 illustrated in Figure ).

[0062] Write-once: When the capability has the Write-once AAC, the write operations bounds change response to the following trigger events:

[0063] • When the capability is created, the Write-once AAC is set, and the write operation bounds are set to equal the baseline bounds (the whole portion of the address space the capability grants access to is writable. As a result, the capability can be used as an operand for store operations.

[0064] • When the hardware detects the capability is used as an operand for a sequential store (i.e., the address of the store is adjacent to the lower or upper bound of the write operation bound), as part of the store operation hardware circuitry in the microprocessor or part of the memory management subsystem sets the write operation bound to exclude the target address of the store. As a result of this change, the capability now grants write access to the portion of the address space described by the write operation bounds that has not been the object of a prior write operation.

[0065] As noted above, the exact encoding of bounds information may vary between different schemes proposed for capability-based addressing and the integration of capabilities to pre-existing baseline instruction set architectures. Therefore, there also exist many alternatives for the AAC per-operation bounds information. Below, two general strategies for extending pre-existing (hybrid) capability architectures with per-instruction bounds are outlined: the addition of per-operation bounds using baseline bounds representation, e.g., using bounds information compressed in the same manner as the baseline bounds, i.e., relative to the baseline architecture address in CHERI; and the addition of per- operation bounds expressed relative to the baseline bounds, e.g., a lower and higher bound expressed as an offset relative to the baseline bounds.

[0066] In the description of the solution so far, we have shown the operation of AAC permissions with respect to instantiations that support two distinct per-operations bounds, e.g., read and write. In other instantiations, it may be desirable to support a larger subset of the AAC permissions, or even the full set of possible ACC permissions. In such instantiations, the representation of the capabilities must accommodate per-operations bounds beyond two operations. Figure 3 and Figure 4 illustrate the generalization of the strategies 1. and 2. for extending the capability representation for n-operation bounds. Some instantiations may also make use of the fact that the per-operations bounds for certain pair of operations can be calculated from the first operation bound to the baseline upper (or lower) bound. As such, the bounds for one-way sequential operations (either from the beginning to the end of the portion of the address space OR from the end to the beginning, but not both) can be expressed through a single operation bound and its complement with respect to be baseline bounds.

[0067] It is likely that practical instantiations of AAC permissions will require increasing the size of the capability representation beyond the 2xbaseline architecture width used, for example, in CHERI. This comes with a tradeoff in terms of the memory and cache footprint and the processor data-path width required to support AAC-enabled capabilities. For this reason, it is desirable to limit the impact on the size of the capability representation, prioritizing where possible the re-use of the existing (unused or used) bits in capabilities, in combination of the two strategies described above.

[0068] Some of the discussion above focused on what is expected to be a typical use case for AACs permissions, i.e., in sequential memory operations, e.g., writes or reads over continuous portion of the address space, such as a memory buffer. Therefore, the logic for operating on the bounds information in some of the description above assumes that the AAC per-operation bounds narrow or grow from the end(s) of the established bounds. However, in some instantiations it may be desirable to support AACs for randomaccess operations, i.e., operations targeting any part of a contiguous region.

[0069] In some instantiations, then, instead of representing the lower and upper bound of per-operation bounds the per-operation bounds may the represented as a bitmap relative to the baseline bounds stored of the capability, where each bit in the per-operation bounds bitmap represents a sub-region of the portion of the address space described by the baseline bounds. An example of this is shown in Figure 5. In such instantiations, the per-operation bitmaps can, together with circuitry in the microprocessor of memory-management subsystem, be used to enable / disable permissions to individual sub-regions, regardless of their position in the portion of the address space described by the per-operation bounds. The resolution of the bitmap, i.e., the size of each sub-region corresponding to a bit in the bitmap, may vary, in various implementations, but subject to the fact that greater resolution (i.e., smaller subregions) will require larger bitmaps, and thus larger capability sizes.

[0070] Figure 6 is a process flow diagram illustrating an example method, according to the techniques described herein, for carrying out memory operations in capability-based memory access-control hardware. The method illustrated in Figure 6 is intended to be a generalization of and to encompass the specific examples described above. Hence, where the terminology used to describe Figure 6 differs somewhat from that used above, the terms used in the description of Figure 6 should be understood to at least encompass similar or clearly related terms used above, except where the context indicates otherwise.

[0071] As shown at block 610 in Figure 6, the illustrated method comprises the step of determining, for a first memory operation for a first memory location, whether stored capability data associated with the first memory location permits the first memory operation, based on a permissions mask in the capability data. The term "capability data" is used here and elsewhere in this document, as an alternative to simply "capability," or "capability object," to indicate that the "capability data" refers to the capability as stored in and as manipulated by memory-access-control hardware, regardless of its form or structure. The term "capability" alone might sometimes be understood as referring to the concept of a "capability" in the abstract, while the term "capability object" might sometimes be understood as referring to a capability as instantiated in a particular data structure. "Capability data," as that term is used herein, refers to a concrete instantiation of a capability, but without limitations to a specific structure. Thus, while Figures 2-5 illustrate representations of capability data, and might be understood as illustrating certain capability objects, the term capability data as used herein may include, but is not limited to, the specific representations shown in those figures.

[0072] Likewise, the term "permissions mask" refers to a portion of the stored capability data that indicates which permissions are enabled by that capability data. This permissions mask may take the form of an extended AAC permission mask, i.e., an extension of the masks used in a scheme like CHERI for indicating which of a known set of operations / permissions are enabled by the capability, but might use other formats as well.

[0073] Returning to Figure 6, block 620 shows the step of modifying permission-specific memory bounds information in the stored capability data associated with a second memory operation and / or modifying permission-specific memory bounds information in the stored capability data associated with the first memory operation, upon determining that the first memory operation is permitted, and together with performing the first memory operation at the first memory location, modifying permission-specific memory bounds information in the stored capability data associated with a second memory operation and / or modifying permission-specific memory bounds information in the stored capability data associated with the first memory operation. Note that in various instances or embodiments, the permission-specific memory bounds information that is modified may correspond to the first memory operation referred to in block 610, such as to a write operation. Thus, for example, performing a write operation at a certain memory location may cause permission-specific memory bounds information for the write operation to be modified to exclude that memory operation from further write operations. In others, the permission-specific memory bounds information that is modified may correspond to a second memory operation. Thus, performing a write operation at a certain memory location may cause permission-specific memory bounds information for a read operation to be modified to include that memory location, for example, when it was previously excluded, so as to implement a write-before-read permission. Note also that the performing of the first memory operation and the modifying of the permission-specific memory bounds information in the stored capability data may happen in any order, or simultaneously, depending on the specific hardware implementation - for this reason, the modifying of the permission-specific memory bounds information is described here and elsewhere in this document as being performed "together with" the performing of the memory operation that effectively triggers the modification.

[0074] The term "permission-specific memory bounds information" is used herein to refer to an instantiation of the operation bounds described herein, without regard to any particular format or encoding. As discussed above, these bounds, and thus the permission-specific memory bounds information referred to in Figure 6, may be encoded, for example, in compressed form relative to a baseline architecture address, in some embodiments or instances. In others, the permission-specific memory bounds information may be encoded as one or more offsets relative to a baseline bounds for the capability. Other formats or encoding may be used, in still other embodiments or instances. In some embodiments or instances of the method shown generically in Figure 6, determining whether the capability data associated with the first memory location permits the first memory operation, as shown at block 610, may be based further on permission-specific memory bounds information associated with the first memory operation, in the capability data. Each of the examples shown in Figures 2-5 includes a "first operation bound," corresponding to this permission-specific memory bounds information associated with the first memory operation, and several of the examples described above involve modifying this permission-specific memory bounds information, instead of or in addition to modifying permission-specific memory bounds information for a second memory operation. However, some embodiments and / or instances may omit this permission-specific memory bounds information, and / or may not condition the execution of a particular first memory operation on an evaluation of permission-specific memory bounds information associated with the first memory operation.

[0075] In various embodiments, modifying the permission-specific memory bounds information associated with either the second memory operation or the first memory operation comprises modifying the permissionspecific memory bounds information to include or exclude the first memory location from the permission-specific memory bounds. This modifying of the permission-specific memory bounds information to include or exclude the first memory location from the permission-specific memory bounds may comprise modifying an upper or lower bound of the permission-specific memory bounds. Several examples of these variations were given above, e.g., where the first memory operation is a write operation and permission-specific memory bounds information for the write operation is modified to exclude the target memory location from subsequent write operations (write-once) or where the first memory operation is a write operation and permission-specific memory bounds information for a read operation is modified to include the target memory location (write-before-read). Other examples were also provided above, and other variations are possible.

[0076] In some embodiments or instances, the first memory operation referred to in block 610 of Figure 6 is a Write operation and the second memory operation is a Read operation, and the method comprises modifying the permission-specific memory bounds information for the Read operation to include the first memory location, so as to implement a write-before-read permission. In some of these embodiments or instances, modifying the permission-specific memory bounds information for the Read operation may be further conditioned on determining that the first memory location is adjacent to a lower or upper bound of a memory range defined by permissions-specific memory bounds associated with the first memory operation. In some of any of these embodiments or instances, the method may further comprise modifying permission-specific memory bounds information for the Write operation to exclude subsequent Write operations to the first memory location, so as to implement a write-before- read-only permission.

[0077] In some embodiments or instances, the first memory operation referred to in block 610 of Figure 6 is a Write operation and the second memory operation is an Execute operation, and the method comprises modifying the permission-specific memory bounds information for the Execute operation to include the first memory location. This embodiment might be understood as implementing a write-before-execute permission. In some of these embodiments or instances, the method may further comprise modifying permission-specific memory bounds information for the Write operation to exclude subsequent Write operations to the first memory location, e.g., so as to implement a write-before-execute-only permission.

[0078] In still other embodiments or instances, the first memory operation referred to in block 610 of Figure 6 is a Write operation and the method comprises modifying permission-specific memory bounds information associated with the Write operation to exclude the first memory location, so as to implement a write- once permission. In yet other embodiments or instances, the first memory operation is a Read operation, and the method comprises modifying permission-specific memory bounds information associated with the Read operation to exclude the first memory location, so as to implement a read-once permission.

[0079] As discussed above, the permission-specific memory bounds information associated with the first memory operation and / or the permission-specific memory bounds information associated with the second memory operation may be encoded, in some embodiments or instances, as an offset relative to an upper or lower bounds of baseline bounds for the capability data. In other embodiments, permissionspecific memory bounds information may be encoded in a compressed form relative to a baseline architecture address.

[0080] In some embodiments or instances, the permission-specific memory bounds information associated with the first memory operation and / or the permission-specific memory bounds information associated with the second memory operation may be encoded as a bit map, each bit of the bit map corresponding to a respective memory location or range of memory locations. In these embodiments or instances, modifying the permission-specific memory bounds information to include or exclude the first memory location from the permission-specific memory bounds comprises modifying a bit of the bit map corresponding to the first memory location.

[0081] Figure 7 is a block diagram illustrating an example of memory-access control circuitry 700, configured to carry out any one or more of the various techniques described herein. The memory-access control circuitry 100 comprises a capabilities memory storage area 710 configured to store capability data associated with one or more memory locations in an operations-accessible memory area 730. The operations-accessible memory area 730 may be considered part of the memory-access control circuitry 700, in some embodiments, or as distinct from and thus external to the memory-access control circuitry 700, in others.

[0082] Memory-access control circuitry 700 further comprises digital control circuitry 720 operatively coupled to the capabilities memory storage area 710 and to the operations-accessible memory area 730. The digital control circuitry 720 is configured to carry out any one or more of the techniques described above, including the method illustrated in Figure 6. Thus, digital control circuitry 720 is configured to determine, for a first memory operation for a first memory location in the operations-accessible memory area, whether stored capability data associated with the first memory location permits the first memory operation, based on a permissions mask in the capability data, and to modify permission-specific memory bounds information in the stored capability data associated with a second memory operation and / or modifying permission-specific memory bounds information in the stored capability data associated with the first memory operation, upon determining that the first memory operation is permitted and together with performing the first memory operation at the first memory location.

[0083] In some embodiments or instances, the digital control circuitry 720 is configured to determine whether the capability data associated with the first memory location permits the first memory operation based further on permission-specific memory bounds information associated with the first memory operation, in the capability data.

[0084] In some embodiments or instances, the digital control circuitry 720 is configured to modify the permission-specific memory bounds information associated with either the second memory operation or the first memory operation by modifying the permission-specific memory bounds information to include or exclude the first memory location from the permission-specific memory bounds. In some of these embodiments or instances, the digital control circuitry 720 is configured to modify the permissionspecific memory bounds information to include or exclude the first memory location from the permission-specific memory bounds by modifying an upper or lower bound of the permission-specific memory bounds.

[0085] In some embodiments or instances, the first memory operation is a Write operation and the second memory operation is a Read operation, and the digital control circuitry 720 is configured to modify the permission-specific memory bounds information for the Read operation to include the first memory location. In some of these embodiments or instances, the digital control circuitry 720 is configured to modify the permission-specific memory bounds information for the Read operation further conditioned on determining that the first memory location is adjacent to a lower or upper bound of a memory range defined by permissions-specific memory bounds associated with the first memory operation. In some of these embodiments or instances, the digital control circuitry 720 is configured to modify permissionspecific memory bounds information for the Write operation to exclude subsequent Write operations to the first memory location.

[0086] In some embodiments or instances, the first memory operation is a Write operation and the second memory operation is an Execute operation, and the digital control circuitry 720 is configured to modify the permission-specific memory bounds information for the Execute operation to include the first memory location. In some of these embodiments or instances, the digital control circuitry is configured to modify permission-specific memory bounds information for the Write operation to exclude subsequent Write operations to the first memory location.

[0087] In some embodiments or instances, the first memory operation is a Write operation, and the digital control circuitry 720 is configured to modify permission-specific memory bounds information associated with the Write operation to exclude the first memory location.

[0088] In some embodiments or instances, the first memory operation is a Read operation, and the digital control circuitry 720 is configured to modify permission-specific memory bounds information associated with the Read operation to exclude the first memory location.

[0089] In some of the several embodiments or instances descried above, the permission-specific memory bounds information associated with the first memory operation and / or the permission-specific memory bounds information associated with the second memory operation is encoded, in the stored capability data, as an offset relative to an upper or lower bounds of baseline bounds for the capability data. In others, the permission-specific memory bounds information associated with the first memory operation and / or the permission-specific memory bounds information associated with the second memory operation may be a bit map, each bit of the bit map corresponding to a respective memory location or range of memory locations, where the digital control circuitry 720 is configured to modify the permission-specific memory bounds information to include or exclude the first memory location from the permission-specific memory bounds by modifying a bit of the bit map corresponding to the first memory location.

Claims

CLAIMSWhat is claimed is:

1. A method for carrying out memory operations in capability-based memory access-control hardware, the method comprising: determining (610), for a first memory operation for a first memory location, whether stored capability data associated with the first memory location permits the first memory operation, based on a permissions mask in the capability data; upon determining (610) that the first memory operation is permitted, and together with performing the first memory operation at the first memory location, modifying (620) permission-specific memory bounds information in the stored capability data associated with a second memory operation and / or modifying permissionspecific memory bounds information in the stored capability data associated with the first memory operation.

2. The method of claim 1, wherein determining (610) whether the capability data associated with the first memory location permits the first memory operation is based further on permission-specific memory bounds information associated with the first memory operation, in the capability data.

3. The method of claim 1 or 2, wherein modifying (620) the permission-specific memory bounds information associated with either the second memory operation or the first memory operation comprises modifying the permission-specific memory bounds information to include or exclude the first memory location from the permission-specific memory bounds.

4. The method of claim 3, wherein modifying (620) the permission-specific memory bounds information to include or exclude the first memory location from the permission-specific memory bounds comprises modifying an upper or lower bound of the permission-specific memory bounds.

5. The method of any one of claims 1-4, wherein the first memory operation is a Write operation and the second memory operation is a Read operation, and wherein the method comprises modifying the permission-specific memory bounds information for the Read operation to include the first memory location.

6. The method of claim 5, wherein modifying (620) the permission-specific memory bounds information for the Read operation is further conditioned on determining that the first memory location is adjacent to a lower or upper bound of a memory range defined by permissions-specific memory bounds associated with the first memory operation.

7. The method of claim 5 or 6, wherein the method further comprises modifying permission-specific memory bounds information for the Write operation to exclude subsequent Write operations to the first memory location.

8. The method of any one of claims 1-4, wherein the first memory operation is a Write operation and the second memory operation is an Execute operation, and wherein the method comprises modifying the permission-specific memory bounds information for the Execute operation to include the first memory location.

9. The method of claim 8, wherein the method further comprises modifying permission-specific memory bounds information for the Write operation to exclude subsequent Write operations to the first memory location.

10. The method of any one of claims 1-4, wherein the first memory operation is a Write operation, and wherein the method comprises modifying permission-specific memory bounds information associated with the Write operation to exclude the first memory location.

11. The method of any one of claims 1-4, wherein the first memory operation is a Read operation, and wherein the method comprises modifying permission-specific memory bounds information associated with the Read operation to exclude the first memory location.

12. The method of any one of claims 1-4, wherein the first memory operation is an Execute operation, and wherein the method comprises modifying permission-specific memory bounds information associated with the Execute operation to exclude the first memory location.

13. The method of any one of claims 1-12, wherein the permission-specific memory bounds information associated with the first memory operation and / or the permission-specific memory bounds informationassociated with the second memory operation is encoded, in the stored capability data, as an offset relative to an upper or lower bounds of baseline bounds for the capability data.

14. The method of any one of claims 1-12, wherein the permission-specific memory bounds information associated with the first memory operation and / or the permission-specific memory bounds information associated with the second memory operation is a bit map, each bit of the bit map corresponding to a respective memory location or range of memory locations, and wherein modifying (620) the permissionspecific memory bounds information to include or exclude the first memory location from the permission-specific memory bounds comprises modifying a bit of the bit map corresponding to the first memory location.

15. Memory access-control circuitry (700), comprising: a capabilities memory storage area (710) configured to store capability data associated with one or more memory locations in an operations-accessible memory area (730); and digital control circuitry (720) operatively coupled to the capabilities memory storage area (710) and to the operations-accessible memory area (730), the digital control circuitry (720) being configured to: determine, for a first memory operation for a first memory location in the operations- accessible memory area (730), whether stored capability data associated with the first memory location permits the first memory operation, based on a permissions mask in the capability data; upon determining that the first memory operation is permitted, and together with performing the first memory operation at the first memory location, modify permission-specific memory bounds information in the stored capability data associated with a second memory operation and / or modifying permissionspecific memory bounds information in the stored capability data associated with the first memory operation.

16. The memory access-control circuitry (700) of claim 15, wherein the digital control circuitry (720) is configured to determine whether the capability data associated with the first memory location permits the first memory operation based further on permission-specific memory bounds information associated with the first memory operation, in the capability data.

17. The memory access-control circuitry (700) of claim 15 or 16, wherein the digital control circuitry (720) is configured to modify the permission-specific memory bounds information associated with either the second memory operation or the first memory operation by modifying the permission-specific memory bounds information to include or exclude the first memory location from the permissionspecific memory bounds.

18. The memory access-control circuitry (700) of claim 17, wherein the digital control circuitry (720) is configured to modify the permission-specific memory bounds information to include or exclude the first memory location from the permission-specific memory bounds by modifying an upper or lower bound of the permission-specific memory bounds.

19. The memory access-control circuitry (700) of any one of claims 15-18, wherein the first memory operation is a Write operation and the second memory operation is a Read operation, and wherein the digital control circuitry (720) is configured to modify the permission-specific memory bounds information for the Read operation to include the first memory location.

20. The memory access-control circuitry (700) of claim 19, wherein the digital control circuitry (720) is configured to modify the permission-specific memory bounds information for the Read operation further conditioned on determining that the first memory location is adjacent to a lower or upper bound of a memory range defined by permissions-specific memory bounds associated with the first memory operation.

21. The memory access-control circuitry (700) of claim 19 or 20, wherein the digital control circuitry (720) is configured to modify permission-specific memory bounds information for the Write operation to exclude subsequent Write operations to the first memory location.

22. The memory access-control circuitry (700) of any one of claims 15-18, wherein the first memory operation is a Write operation and the second memory operation is an Execute operation, and wherein the digital control circuitry (720) is configured to modify the permission-specific memory bounds information for the Execute operation to include the first memory location.RECTIFIED SHEET (RULE 91)23. The memory access-control circuitry (700) of claim 22, wherein the digital control circuitry (720) is configured to modify permission-specific memory bounds information for the Write operation to exclude subsequent Write operations to the first memory location.

24. The memory access-control circuitry (700) of any one of claims 15-18, wherein the first memory operation is a Write operation, and wherein the digital control circuitry (720) is configured to modify permission-specific memory bounds information associated with the Write operation to exclude the first memory location.

25. The memory access-control circuitry (700) of any one of claims 15-18, wherein the first memory operation is a Read operation, and wherein the digital control circuitry (720) is configured to modify permission-specific memory bounds information associated with the Read operation to exclude the first memory location.

26. The memory access-control circuitry (700) of any one of claims 15-18, wherein the first memory operation is an Execute operation, and wherein the method comprises modifying permission-specific memory bounds information associated with the Execute operation to exclude the first memory location.

27. The memory access-control circuitry (700) of any one of claims 15-26, wherein the permissionspecific memory bounds information associated with the first memory operation and / or the permissionspecific memory bounds information associated with the second memory operation is encoded, in the stored capability data, as an offset relative to an upper or lower bounds of baseline bounds for the capability data.

28. The memory access-control circuitry (700) of any one of claims 15-26, wherein the permissionspecific memory bounds information associated with the first memory operation and / or the permissionspecific memory bounds information associated with the second memory operation is a bit map, each bit of the bit map corresponding to a respective memory location or range of memory locations, and wherein the digital control circuitry (720) is configured to modify the permission-specific memory bounds information to include or exclude the first memory location from the permission-specific memory bounds by modifying a bit of the bit map corresponding to the first memory location.

Images