Confidential computing mechanism

Abstract

According to a first aspect, execution logic is configured to perform a linear capability transfer operation that transfers a physical capability from a partition of a first software module to a second partition of the software module without retaining it in the partition of the first software module. According to a second, alternative, or additional aspect, execution logic is configured to perform a sharding operation whereby the physical capability is partitioned into at least two instances that can subsequently be combined.

Description

Background Art

[0001] Traditionally, an operating system (OS) can see all the data of all applications running on the OS. "Seeing" here means being able to inspect and modify all the same application data from the same memory area(s) that the applications can access. Similarly, if the OS runs on a hypervisor, then the hypervisor can see all the data of both the OS and the applications. This implies a layered trust system, whereby applications trust the OS, and the OS trusts the hypervisor.

[0002] Recently, the concept of "enclaves" has been introduced, allowing applications to run in a confidential environment where the operating system or hypervisor cannot access the application's data. This removes the concept of layered trust: the application does not need to trust the operating system, and the operating system does not need to trust the hypervisor. As an example application, this would enable data center tenants to keep their data confidential, hidden from the data center operator.

[0003] Access to memory can be restricted by a capability system. A "capability" is a technical term that refers to an unforgeable digital token of authority that authorizes access to a specified memory address range, for example. It is known to provide a capability system that is enforced in hardware. This means that a machine code instruction (such as a load or store instruction) that attempts to access a certain target address in memory will trigger a hardware check for the corresponding capability that authorizes access to the target address. The software in question must possess and be able to present the capability in order to be granted access.

[0004] One example is CHERI (Capability Hardware Enhanced RISC Instructions). This is achieved through a "fat" pointer system and some specialized additions to the processor's instruction set architecture. For example, the source operand of a traditional load instruction will typically specify a register that holds a pointer to the target address (in this case, the source of the load). In CHERI, the instruction also needs to specify a register that holds the capability that authorizes access to the target address, thereby enhancing the pointer with the capability. The capability in the register can only be manipulated through specialized machine code instructions specifically included in the instruction set according to the CHERI architecture.

[0005] Capabilities are protected in memory. Hardware memory capability systems do this in two ways. The first is to restrict where capabilities can be stored in memory. Capabilities can only be stored in specific areas, and everything in those areas is either a capability or an explicitly invalid capability value (usually zero). For example, the CAP computer uses this model. The second is to use some form of tag memory where the unaddressable bit is set when a valid capability is stored and cleared when any other data is stored to the same location. CHERI (as well as the M-Machine and some other systems) uses this model.

[0006] In existing CHERI systems, capabilities grant access to a specified range of virtual addresses on the virtual address side of address translation. As those skilled in the art are familiar with, nearly all general-purpose computer systems today employ virtual memory. Specifically, the system includes a page table (typically implemented as a tree) that maps between the virtual address space and the physical address space of (multiple) actual physical memory devices. This is done to abstract the address space used by software from the actual underlying physical memory resources. The target address is specified by software as a virtual address, and the system automatically uses the page table to translate it into the corresponding physical address. Typically, this translation is performed automatically in hardware by a memory management unit (MMU). The page table can be populated and managed by low-level system code, such as a hypervisor or operating system kernel. A translation lookaside buffer (TLB) can also be used to cache page table entries. In a software-managed TLB, the TLB is populated by software by traversing the page table (or equivalent data structure), while in a hardware-managed TLB, the hardware checks the page table to populate the TLB.

[0007] The CHERI capability also provides access to physical memory on systems without address translation, but is not used for physical memory on systems that provide address translation. Summary of the Invention

[0008] The present disclosure relates to a system comprising: execution logic comprising one or more execution units; memory comprising one or more memory units; and memory access logic for finding a mapping between a physical address space and a virtual address space of the memory. The execution logic is arranged to run a plurality of software modules, each in a corresponding partition of the physical address space, including for executing a memory access operation performed by a currently executing software module of the software modules. The memory access operation specifies a virtual address within a virtual address range as a target of the memory access operation. The memory access logic is configured to perform the following operations: find a physical address that is mapped to a virtual address in the physical address space, check whether the ability to authorize access to the physical address is found in a storage location to which the currently executing software module has access, and, conditionally, authorize access to the physical address for performing the memory access operation.

[0009] According to one aspect disclosed herein, execution logic is configured to perform a linear capability transfer operation that transfers one of the capabilities from a partition of a first one of the software modules to a partition of a second one of the software modules without retaining it in the partition of the first software module.

[0010] According to a second aspect disclosed herein, the execution unit is configured to perform a sharding operation, whereby one of the capabilities is divided into at least two instances, and the execution unit is further configured to perform a shard reassembly operation, whereby the instances are reassembled.

[0011] The first and second aspects may be used together or independently.

[0012] This summary is provided to introduce in simplified form a series of concepts that will be further described in the detailed description below. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. The claimed subject matter is also not limited to implementations that solve any or all of the disadvantages mentioned herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] To assist in understanding the embodiments of the present disclosure and to show how these embodiments may be implemented, reference is made, by way of example only, to the accompanying drawings, in which:

[0014] Figure 1 is a schematic representation of the program stack,

[0015] Figure 1A is a schematic block diagram of a computing system according to an embodiment disclosed herein,

[0016] Figure 2 is a schematic illustration of memory address translation between virtual addresses and physical addresses,

[0017] Figure 2A is a schematic block diagram of a physical address space with a tag bit according to an embodiment disclosed herein,

[0018] Figure 3 is a schematic block diagram of a set of capability registers according to an embodiment disclosed herein,

[0019] Figure 4 is a schematic block diagram of an enclave or other such memory partition according to embodiments disclosed herein,

[0020] Figure 5 is a schematic block diagram of an enclave execution program according to an embodiment disclosed herein,

[0021] Figure 6 is a schematic representation of an example of physical linear capability according to embodiments disclosed herein, and

[0022] Figure 7 is a flowchart of a method of partitioning a memory according to an embodiment disclosed herein. DETAILED DESCRIPTION

[0023] The present disclosure relates to a system for hardware-enforced isolation based on capabilities. According to a first aspect, it provides a system of capabilities that are applied in a physical address space on the physical side of address translation rather than in a virtual address space on the virtual side of address translation. In addition, the disclosed system provides a mechanism whereby capabilities can be passed between modules of software in a "linear" manner, i.e., passed from one module to another like a baton without being retained by the first module. Because capabilities are both physical and linearly transferred, these features together mean that low-level system software such as a hypervisor or operating system can pass capabilities for a specific physical address range to higher-level software such as an application, which then keeps any data in the corresponding address range private from the operating system or hypervisor. Because capabilities are enforced on physical address ranges, even low-level system code responsible for populating address translation page tables cannot bypass it.

[0024] Without capabilities, enclaves are implemented via reverse lookup. After address translation, the MMU looks up who owns the page. Typically, there's a flat table with one entry for each physical page, defining the page's owner. Sometimes this is done via a mix of hardware and software, with the hardware checking a bit indicating "this page is secret" and the software enforcing the invariant that secret pages are owned by a single owner. Alternatively, sometimes it's done entirely in software, with a small set of trusted software enforcing the invariant. This achieves the same goal as can be expressed with purely linear capabilities: running software can verify that it is the sole owner of a given page and that it is not exposed to others. One advantage of linear capabilities over table-based or hardware-based access control approaches is that lookups only run one way, and delegation from one isolated area to another doesn't need to go through a single trusted entity. This hybrid approach simplifies verification at the software level. Another benefit is that it makes it easy to implement pages that can be written by one party and read by one or more others (such as a virtual device's ring buffer).

[0025] According to a second aspect, a system for sharding capabilities that can be split a known number of times is provided. Slicing capabilities provides greater flexibility than strictly linear capabilities, but does not allow for uncontrolled proliferation of capabilities. Because the system keeps track of which portion of the original (exclusive) capability the current shard is, these shards can be rebuilt later to restore exclusivity. Preferably, the capability is also only allowed to be split a limited number of times, so that a given area of ​​physical memory can be shared among only a limited number of applications or other such software modules.

[0026] Sharding can be used advantageously in conjunction with the concept of linear capabilities. For example, using an 8-bit split field, a page can be shared between up to 256 entities (enclaves, isolated VMs, etc.), and each entity can cheaply check the maximum number of others that own it. This makes it easy to enforce guarantees, such as sharing a page between two enclaves or between an isolated VM and an enclave, while hiding it from the hypervisor. Doing this with a table-based scheme means that each table entry would need to be able to identify all entities that could potentially access the page, which would give you a very large table (and a large lookup cost). Doing this with capabilities gives you a simple forward check.

[0027] The disclosed mechanism makes it possible to build isolated virtual machines (VMs), hardware enclaves, etc. It can be used as a standalone mechanism, or for example it can be used in conjunction with existing schemes such as the CHERI memory capability model (combined with CHERI, and doing so will allow certain aspects of the hardware implementation to be shared). One aspect provides linear capabilities that involve adding authorized access to physical memory. Another alternative or additional aspect involves slicing of physical capabilities (limited, recorded division of physical capabilities). Traditional CHERI capabilities work with virtual addresses and are checked before memory translation. Physical capabilities are used after address translation and can restrict system software.

[0028] In an embodiment, as with normal CHERI capabilities, the set of rights granted by the capability can be manipulated using a small secure instruction set.

[0029] Unlike existing systems with strict trust relationships, the disclosed design makes it possible to express mutual distrust. For example, two VMs can share memory pages that are inaccessible to other VMs (or the hypervisor). This makes it possible to implement complex confidential computing designs.

[0030] An example application is cloud-based confidential computing, which is currently a growing area. The ability for customers to run complex workloads with strong assurance that the hypervisor or operating system cannot access their data is a key differentiator.

[0031] Figure 1 An example program stack 100 of an example application according to the presently disclosed technology is illustrated. The stack 100 includes a plurality of programs 102, including at least an operating system (OS) 102OS and one or more applications 102AP running on the operating system. Optionally, in some cases, the stack 100 may also include a hypervisor 102HV, and the operating system 102OS may be arranged to run on the hypervisor. In this case, the operating system 102OS and the application 102AP together form a virtual machine (VM) 103. A hypervisor, also known as a virtual machine monitor (VMM), is low-level software for running virtual machines. There may be one or more virtual machines 103 running on the hypervisor 102HV, each virtual machine 103 having its own operating system 102OS. An example is that multiple virtual machines 103 of different tenants are all running on the same data center or cloud computing host service.

[0032] In an embodiment, the same mechanism may also implement a TrustZone-like abstraction where one may have one or more of these layers in the secure and non-secure worlds, for example allowing an OS to run without the hypervisor being able to forcibly relinquish resources.

[0033] Figure 2 1. The diagram illustrates a memory mapping scheme that can be employed to facilitate access to memory. The memory 104 includes a physical address space 202 spanning one or more memory devices, i.e., the actual hardware addresses by which physical regions of memory in those one or more memory devices 106 are addressed. The physical memory space 202 in question can include the memory space of one or more volatile memory devices (RAM) and / or one or more non-volatile memory devices (e.g., HDD or SSD).

[0034] The memory page table 112 maps the physical addresses of the physical address space 202 to the corresponding virtual addresses of the virtual address space 204. Figure 2 This is schematic. In practice, the page table can be implemented in physical memory. The page table is the protocol used by system software to communicate with the memory management unit (MMU). The MMU performs lookups with the help of a page table managed by system software or a trusted trap handler that performs cacheable address translation.

[0035] When a program 102 (such as an application 102AP) wants to access memory, such as to perform a load, store, or fetch, it specifies an address in the virtual address space 204 as the target memory address, i.e., the source of the load or fetch, or the destination of the store. This is then automatically converted to a virtual address by performing a lookup based on the page table 112. The lookup is typically performed automatically by dedicated hardware circuitry in a memory management unit (MMU). The entries in the page table 112 are populated and managed by low-level system code, such as the hypervisor 102HV or the kernel of the operating system 102OS.

[0036] In an embodiment, the lookup is performed via a translation lookaside buffer (TLB), which is a form of cache. Only when the TLB is missed is the page table or address translation error handler consulted directly. In either case, address translation occurs via some mechanism provided by the MMU, and there are policies controlling address translation, which are provided by one or more layers of privileged software (as code or data).

[0037] Note: In scenarios where there are three layers in the stack 100—the hypervisor, 102HV, operating system 102OS, and application layer 102AP—then in some such embodiments, the operating system may publish a target address in a second-layer virtual address, which is translated into a first-layer virtual address, sometimes also referred to as a pseudo-physical address, and the hypervisor 102HV or MMU translates it into a (real) physical address. That is, the virtual machine 103 may need to perform two address translations. In such scenarios, when it is said herein that an application specifies a virtual address, etc., this can be taken to mean that the application, via the operating system, instead specifies a first-layer virtual address (pseudo-physical address). A physical address refers to a real physical address in the actual physical address space 202.

[0038] More generally, the present application can be applied to any program stack, for example in scenarios involving only an operating system and application(s) but no hypervisor, or in scenarios involving more layers.

[0039] The present disclosure relates to providing isolation between different software modules so that one software module cannot access the code or data of another software module. This is important for privacy and data security. For example, a software module may include a hypervisor 102HV, an operating system 102OS running on the hypervisor, and / or one or more applications 102AP running on the operating system. For example, it may be desirable to create an enclave so that the operating system 102OS and the hypervisor 102HV cannot view the data of a particular application 102AP, even if the application is running on the operating system. Alternatively, it may be desirable to prevent an application 102APi from gaining access to the data of another application 102APii, without trusting the OS or hypervisor to prevent this.

[0040] In the traditional model, the hypervisor 102HV partitions an area of ​​virtual address space for use by the operating system. The operating system 102OS then partitions out an area within this memory area for each application 102AP running on that operating system. This is done as part of dynamic partitioning (i.e., memory can be added to or removed from any higher layer while the program is running). The operating system 102OS has access to all data of the applications 102APs across all memory address spaces allocated to them, and the hypervisor 102HV has access to all data across all address spaces allocated to the operating system 102OS. The hypervisor 102HV can also restrict what the operating system 102OS can access, and the operating system 102OS can restrict what its applications 102APs can access. Therefore, a layered trust system must exist between the different layers of the stack 100: the operating system 102OS must trust the hypervisor 102HV, and the applications 102APs must trust the operating system 102OS. For example, the hypervisor 102HV could be compromised and snoop on the data of either the operating system 102OS or the applications 102APs, or it could be malicious from the outset.

[0041] It is desirable to modify this "nested" model so that each level or layer in stack 100 can access the memory address space allocated to the next level, for example, so that the operating system 102OS does not have to fully trust the hypervisor 102HV, and / or the enclave application 102AP does not have to fully trust the operating system 102OS. Thus, the concept of a more trusted component always having access to the memory of a less trusted component running on it is no longer necessary, and the confidentiality and integrity of data owned by the application 102AP can be guaranteed even if the hypervisor 102HV or operating system 102OS is compromised. In embodiments, the hypervisor and OS can still be kept in a TCB (Trusted Computing Base) for availability, rather than confidentiality or integrity. In this case, a malicious hypervisor can simply choose not to run a particular VM, and the VM cannot prevent this from happening. However, the disclosed mechanism ensures that the hypervisor cannot inspect or tamper with the memory owned by the VM.

[0042] The hypervisor 102HV may still be responsible for partitioning memory for the operating system 102OS, and the operating system may still be responsible for partitioning memory for its applications 102AP. However, once partitioning is complete, the hypervisor 102HV may no longer necessarily access the memory it has allocated to the operating system 102OS, and / or the operating system may no longer necessarily access the memory it has allocated to one or more of its applications 102APs. Furthermore, the new owner of the memory can easily verify that it has exclusive ownership.

[0043] The present disclosure achieves this via a system of physical capabilities, which are preferably also enforced in hardware. A "capability" is a token that a software module needs in order to access a specific memory area. Each capability specifies a corresponding address range to which it grants access. If a given software module does not possess the associated token, it is not allowed to access that memory area. This can be achieved by providing tokens (i.e., "capabilities") only to one or more (but not all) software modules running on the system.

[0044] Physical capabilities are capabilities that operate at the physical memory address level, rather than the virtual address level. Only software modules that can be given the relevant token (i.e., capability) are allowed to access the corresponding area of ​​physical memory. Hardware-enforced capabilities are capabilities where the capability check is enforced, at least in part, by the processor's dedicated hardware. If the check fails, the memory access fails and an exception may be raised.

[0045] According to a first aspect disclosed herein, a mechanism for linear physical capabilities is provided.

[0046] A linear capability is one that is passed between software modules like a baton. That is, once it is passed from one software module to the second, the first module does not retain a copy. For example, an operating system starts with a capability and then passes it to an application. The application now has that capability, but the operating system cannot retain a copy, so the operating system relinquishes its access to the corresponding memory area. With a nonlinear capability, the operating system can choose to pass the capability and retain a copy itself.

[0047] The inventors are unaware of no previous disclosure providing a system having both physical and linear capabilities.

[0048] According to a second, alternative or additional aspect disclosed herein, there is provided a mechanism for "slicing" physical capabilities

[0049] A "sharded" capability can be divided and therefore shared between different software modules (e.g., two applications, or both the OS and an application), but the system keeps track of how many copies ("shards") have been made. Shards can thus be reassembled back into each other to reduce the number of loops. In embodiments, a capability can also only be split up to a maximum number of times. A limit on the number of times a capability can be split is not necessary. The split count allows the owner of a shard to identify the maximum number of other shard owners. For example, an enclave may wish to verify that the operating system can access a shared area, but the hypervisor cannot. This is possible with a finite split count, and the enclave shares all but one of them. If there were an infinitely divisible split count, the two-party case would be identical to the multi-party case (a protocol would be required to ensure that all cooperating groups share a fraction that sums to 1).

[0050] The inventors are unaware of any previous disclosures that provide a system that is both physical and capable of being sharded.

[0051] Through a small and simple set of hardware extensions, the system of the present disclosure is therefore able to provide strict isolation and / or controlled sharding, thereby limiting the communication boundaries between different software modules.

[0052] The combination of the linear capabilities of the physical slices and their interaction with the system (such as the MMU and interrupt mechanism) enables a flexible way to provide mutual distrust.

[0053] Figure 1A An example computer system 150 for implementing embodiments disclosed herein is illustrated. System 150 includes execution logic 104, memory 106, memory access logic 108, page tables 112, and an optional translation lookaside buffer 114. System 150 may also include a set of capability registers 116 in accordance with embodiments disclosed herein.

[0054] Execution logic 104 includes one or more execution units (i.e., cores) implemented in hardware. Execution logic 104 may also be referred to as a processor or processing unit. For example, it may take the form of a CPU (central processing unit) or a dedicated processor (such as a GPU (graphics processing unit), a DSP (digital signal processor), etc.). Each execution unit may take the form of an execution pipeline, including multiple pipeline stages, such as an instruction fetch stage, a decode stage, an execution stage, an arithmetic logic unit (ALU), a floating point logic unit (FPU), a load / memory unit (LSU), etc. Execution logic 104 is configured to execute instances of instructions from a specific instruction set, which is a basic set of machine code types recognized by the execution logic. Each machine code instruction includes an opcode definition, the type of instruction, and one or more operand fields for taking zero or more operands, depending on the instruction type.

[0055] Memory 106 includes one or more physical memory devices 106. This / these may include one or more memory devices on the same die as execution logic 104, one or more memory devices on a different die in the same IC package, and / or one or more units external to the IC package and die of execution logic 104. In the case of an execution unit external to the device, an MMU will be used for DMA or a logical MMU will be implemented as multiple physical MMUs controlling access from different devices. The one or more memory devices may include one or more volatile memory devices (e.g., RAM) and / or one or more non-volatile memory devices (e.g., ROM or a writable storage drive). The one or more memory devices 106 may employ any suitable storage medium or media; for example, magnetic storage media such as tape or disk (e.g., in the case of a hard disk drive, HDD); electronic storage media such as EEPROM or flash memory (e.g., in the case of a solid-state drive, SSD); uniform optical media such as optical disks or glass-based storage; and the like.

[0056] Memory access logic 108 schematically represents a functional block. In practice, it may be implemented at least in part in dedicated hardware, such as in a memory management unit (MMU). The MMU is typically implemented in the same die as the execution logic. Alternatively or additionally, the memory access logic may be implemented at least in part in low-level firmware or privileged executive-level software arranged to run on the execution logic. It may also be implemented in any combination of hardware, firmware, and / or executive-level software.

[0057] The functionality of the page table 112 has been described previously. It may be implemented in an area of ​​memory 106 (e.g., in a special executive or reserved area of ​​memory 106) and / or in a separate dedicated memory unit. In an embodiment, the page table 112 also provides a mapping of where to find corresponding capabilities for various physical address ranges. Note that while a page table may be referred to as a page "table" as is customary in the art, it is more often implemented today in the form of a tree. The term "table" in this context is not intended to limit the form of the data structure, and the phrase "page table" may refer to a flat table, a tree, or any other suitable form of data structure used to coordinate between virtual and physical memory addresses. The page table may be an entirely software construct that forms an implementation detail of the firmware or software that provides policy to the MMU. More generally, the page table 112 may represent any logic or data structure that enforces memory protection and translation policies defined in software and may optionally cache these translations.

[0058] Execution logic 104 is configured to execute machine code instructions from a predetermined instruction set that defines a predetermined set of instruction types, such as addition, multiplication, etc. Some types of these instructions are memory access instructions, such as load and store instructions in RISC-type architectures. An instance of any of these will specify at least one target address for the corresponding memory access, i.e., a source address in the case of a load or a destination address in the case of a store. Typically, instructions specify a target address instead by means of an operand of the instruction that indicates a general register in the register file of execution logic 104, which in turn holds a pointer (target address). The target address or pointer will be a virtual address within a virtual address range. Other types of operations will also implicitly operate on a target address in memory 106, such as an instruction fetch from the current program counter (PC) value. The PC will specify a virtual address in the virtual address space. Alternatively, in CISC-type architectures, almost any operation may have a memory address operand.

[0059] The memory access logic 108 includes a page table walker 109, which may be implemented in hardware, firmware, or software. This is configured to automatically translate a virtual target address into a physical address in memory 106 when a memory access instruction is executed by the execution logic 104. It does this by looking up the physical address that maps to the virtual target address in the page table 112. The memory access is then automatically performed on the physical address in memory 106. The same may be done for one or more other types of memory access operations, such as instruction fetches.

[0060] The translation lookaside buffer (TLB) is an optimization for caching page table lookups in order to speed up the address translation process on average. The TLB 114 can be implemented as a dedicated cache unit, such as an associative cache, which can be implemented in the MMU or separately, but will typically be implemented in the same die as the MMU and execution logic 104.

[0061] Root capability register 302 is a dedicated system register. System registers, also known as "machine-specific registers" or "hardware registers," are registers that are not part of the general register set. Root capability register 302 can only be used by one or more of a set of special capability operation instructions, which will be discussed in more detail later. Capability registers 116 can be implemented in the execution logic, or as part of the MMU that implements part of the memory access logic 108, or as a separate dedicated register file. For practical purposes, they are preferably implemented on the same die as the execution logic and the MMU.

[0062] The additional capability registers 302 may be implemented as general capability registers that will be explicitly used as operands for capability instructions. For example, in a system with a complete CHERI implementation, these registers may be identical to the registers disclosed for virtual capabilities.

[0063] The general purpose capability register is tightly coupled with the CPU's pipeline(s) and must therefore be implemented as part of the CPU.A system register will typically have write-through behavior so that setting it updates the corresponding state in the MMU.

[0064] Figure 2A An example implementation of the physical memory space 202 of the physical memory device(s) 106 is illustrated. Note that Figure 2A This is illustrative only and is not necessarily intended to imply that the physical address space 202 consists of a single contiguous address range. For example, it may represent the address space of more than one physical memory device, and / or a fragmented range of a given device with unusable regions.

[0065] Physical memory 106 / 202 takes the form of a tagged memory. That is, it includes multiple words for storing data (i.e., actual data content or payload data), and also includes a corresponding tag bit (tagbit) cascaded with each word. When the corresponding word is part of a capability, the tag bit is enabled (e.g., set to 1), and when the word is instead available for other data (payload), the tag bit is disabled (e.g., set to 0). In such an embodiment, checking capabilities by a hardware-enforced mechanism implicitly includes checking the tag bit, where each capability is only valid when the tag bit is enabled. In an embodiment, the tag bit is not addressable except by the executive code running in the executive mode. In addition, if any of the words is loaded from the memory, the tag bit is propagated along with it. Such a feature helps ensure that these capabilities act as unforgeable authorization tokens to authorize access to their corresponding designated memory address ranges. This creates a strict chain of origin and makes the physical capabilities unforgeable.

[0066] Tags are propagated through the cache hierarchy and into capability registers. In a full CHERI system, all memories must preserve tags, but in current systems, it is sufficient for a subset of memories to preserve tags (although this limits the number of isolated regions that can be supported). Additionally, the linearity property is enforced by ensuring that loads from memory to registers clear the tag bit. The simplest way to enforce this in hardware is to require atomic swap operations to move linear capabilities between registers and memory, and not propagate the tag for linear capabilities when performing normal load / store operations.

[0067] However, tag memory is not required. As mentioned in the background section, capabilities are protected in memory, and there are at least two ways a hardware memory capability system can do this. The first way is to restrict where capabilities can be stored in memory. Capabilities can only be stored in specific areas, and everything in those areas is either a capability or an explicitly invalid capability value (usually zero). For example, the CAP computer uses this model. The second way is to use some form of tag memory where the unaddressable bit is set when a valid capability is stored and cleared when any other data is stored in the same location. CHERI (as well as M-Machine and some other systems) use this model. The system disclosed herein can support the former approach if specific areas within the address space execution program are marked as storing capability tables (although this would be a slightly weaker model since access to the capabilities would be forgeable).

[0068] Figure 3 Capability registers 116 are shown. These may include a single root capability register 302 and a set of further capability registers 304, also referred to herein as "general purpose" capability registers. Figure 3 is schematic, and does not rule out the possibility of merged register files (where there is overlap between general purpose registers and capability registers: e.g. there are 32 GPRs, 16 of which are 64 bits and 16 of which are 129 bits, with the low bits available for integer operations).

[0069] A capability is a small data structure that specifies at least the address range it authorizes access to. It may also include other parameters, such as one or more types of permissions it authorizes (e.g., read, write, and / or execute).

[0070] Figure 6 1 shows an example form that a capability data structure 600 may take according to the embodiments disclosed herein. The capability data structure 600 includes at least one pair of fields 600 that specify address ranges. Because the capabilities herein are physical capabilities, they specify ranges within the physical address space 202. In the illustrated example, the address fields specify the ranges in terms of a low address and a high address of the address range. However, they may alternatively specify the ranges, for example, in terms of a low address and an additive offset, or in terms of a high address and a subtractive offset. Regardless of how this is represented, this is the corresponding address range in the physical address space 202 that the corresponding capability is authorized to access.

[0071] In an embodiment, the capability data structure 600 may also include one or more additional fields. For example, if the system supports different types of capabilities, in an embodiment, the capability data structure 600 may include a capability type field 601 for specifying the capability type of the corresponding capability. And / or, the capability data structure 600 may include a permissions field 406 for specifying one or more types of permissions granted by the corresponding capability, such as read, write, or execute.

[0072] The capability data structure 600 may also include a split count field 606 for recording the number of times the corresponding capability has been fragmented, which will be discussed in more detail later.

[0073] A capability acts like a token or "bearer bond" that grants access to it. Only software modules that possess a given capability can access the physical address range specified by that capability. For a given software module to "have" a capability for the present purpose means that the capability is stored in a memory location accessible to the software module. This memory location can be a register, another area of ​​memory, or both. This will be discussed in more detail later.

[0074] With linear capabilities, tokens or "bonds" are moved without a copy operation. Sharding can be thought of as an extension of the linear concept, allowing for the extraction of partial capabilities. This is similar to splitting capabilities by scope or splitting them into different permission sets.

[0075] According to the present disclosure, the physical memory space 202 is partitioned into a plurality of separate address space partitions 400. Examples of such partitions 400 are shown in FIG. Figure 4 is shown in the figure.

[0076] In an embodiment, each partition 400 may include a corresponding base area 402 and a corresponding non-executable area 404 in the physical address space 202. Note that these areas do not have to be adjacent to each other in the physical address space 202, nor do they need to be internally continuous. In an embodiment, the base area 402 may be a single range of continuous addresses, but this is not essential for all possible implementations. The non-executable area 404 may include a single range of continuous addresses or multiple non-contiguous ranges. Corresponding capabilities authorize access to each range.

[0077] The executable area 402 of each corresponding program 102 includes a corresponding address space executable 403, which is a special portion of the executable-level code used to manage the partition 400. The non-executable area 404 can be used to store any corresponding non-executable data 405 and / or non-executable program code 102 desired by the developer.

[0078] The executive area 402 is implemented in an area of ​​memory that is isolated from everything else and can only be accessed by executive-level code running in a special executive mode of the execution logic 104. In order to create an executive, a full capability must be given to the memory area (a full capability means an exclusive capability, i.e., there is only one instance and it is not fragmented so that there is only one owner of the capability and that owner has exclusive access to the address range of the capability). This ensures that no other part of the system can access the memory. This capability is then consumed and a (copyable) entry capability is created. When the executive is invoked, the root capability register will contain a capability with the same rights as the original linear capability and a flag indicating that it is an executive. Software running in the area identified by the root capability can access memory in that area, while software running elsewhere (in the extended area identified by the capability table) cannot. This effectively adds another ring to the existing userspace / supervisor / manager privilege levels.

[0079] The executive mode is operable to switch between executive mode and non-executive mode. The code running in executive mode can perform certain operations, such as accessing the executive area of ​​memory, which the code running at any other privilege level cannot. This mode is a hardware setting for the execution unit. After startup, the execution logic starts with the boot code in executive mode. The boot code then hands over to the executive level code 403 of the partition 400 at the lowest level in the stack 100, for example, the hypervisor 102A in the illustrated case. The executive level code can then jump to the non-executive code 102, and when doing so the mode is switched to non-executive mode. When the program 102 exits, the execution logic automatically jumps back to the executive code of the boot program and switches back to executive mode.

[0080] Many existing architectures have a privileged mode, known as supervisor mode (or ring 0 on x86). In one embodiment, the address space execution mode is distinct from existing privilege levels such as supervisor mode and is used to manage code in memory regions containing software that will use one or more privilege levels. For example, enclaves will only use user mode, isolated VMs will only use user and supervisor modes, and a hypervisor running on a system with an isolation mechanism like a trust zone will use hypervisor, supervisor, and user modes.

[0081] Note that "non-executable mode" refers only to any mode other than executable mode. In an embodiment, it can cover multiple non-executable privilege levels, such as supervisor or kernel mode and user mode. All existing privilege levels still exist. Address space executive mode is largely orthogonal to the other privilege levels. The amount of code running in address space executive mode is expected to be very small and only do a small part of what a hypervisor or operating system does (i.e. provide memory isolation and sharing, and a set of interfaces for securely configuring sharing, and very little else). Non-executable 102 can refer to any non-executable program that is not running in executive mode. This can be an application 102AP, an operating system 102OS, or a hypervisor 102HV.

[0082] The non-executable data 405, non-executable programs 102 and address space executable programs 403 of each partition 400 together form the partition's software module 401. The module 401 includes different programs 102APi, 102APii, 102OS, 102HV, etc. They can be kept secure from each other through the mechanisms discussed below.

[0083] In an embodiment, a partition 400 may have exclusive access to at least one secure area within a corresponding non-executable program area 404, and shared access to the rest of the process's memory. Similarly, an isolated virtual machine may have exclusive access to its own memory and shared access to a portion of it used for communication. In general, the system supports a single entity having memory where portions are completely private, shared with a single other party, or shared with multiple other parties but not everyone. A partition that includes at least some exclusive memory may be referred to as an "enclave," but note that this term is not always used consistently in the art.

[0084] In some cases, a given partition 400 can be completely isolated, i.e., only software modules 401 within that partition 401 can access the physical address ranges of that partition, and no software modules 401 from any other partition 400 can access those physical address ranges. In other words, a partition 400 is a separate partition of physical memory 106 / 202 (non-overlapping address ranges). However, in practice, a system may have a mixture of memory that is completely private to the environment and shared memory. Complete isolation may not be very useful because some mechanism is required to communicate with the outside world, and usually at least a small amount of shared memory is involved.

[0085] A given range of memory may be shared among restricted subsets of one or more software modules 401, and / or different modules 401 may have different levels of permissions on the same region of memory (e.g., one may only read, while another may only write, or may both read and write, etc.). Generally speaking, the term "partition" herein may be used to refer to any division or allocation of the physical memory space 202, and does not, by itself, imply complete isolation of the entire memory range of a partition.

[0086] Also note that Figure 4 A partition 400 is shown that can be an enclave, but it does not explicitly illustrate an isolated VM because it does not illustrate the concept of multiple privilege levels. It should be understood that multiple privilege levels can also be employed in the embodiments disclosed herein. This mechanism is orthogonal to the existing privilege mechanism in the CPU and thus would allow isolated areas to have only user space, user space + hypervisor, or even user space + hypervisor + hypervisor privilege levels.

[0087] Figure 5 An example data structure for an address space executive 403 is illustrated. This includes a number of fields, including at least a memory access table 508 and a portion of executable executive code 510. The memory access table 508 is where one or more capabilities of the non-executable program area 404 of the corresponding partition 400 are stored. The address space executive may optionally include one or more additional fields, such as a version field 502 for storing a version number of the address space executive, and / or a program state field 504 for storing a program state of the address space executive, and / or a key field 506 for storing one or more keys required if the memory is encrypted and / or integrity protected. The program state may include individual thread states for each of a plurality of threads. For present purposes, this does not necessarily imply a userspace concept of a thread, and may be closer to the VM abstraction of a virtual CPU, on which the system (e.g., OS) within the isolated area implements threads.

[0088] The address space executive code 510 is responsible for managing capabilities, including transferring capabilities between software modules 400. It may also be responsible for one or more additional capabilities, such as a revocation policy, e.g., specifying whether a capability can be revoked by the hypervisor 102HV or the operating system 102OS.

[0089] In operation, consider a portion of code - a program 102 in the non-executable program space 404 or an address space executable program in the executable program area 402 - requesting access to a target address in the virtual address space 204 (either directly, or in the form of a first-level "pseudo-physical" virtual address transformed from a second-level virtual address). For example, this may include executing a load instruction to load a value from the target address into a register, or storing a value from a register to the target address. In response, the memory access logic 108 automatically converts the target virtual address to a physical address in the physical address space by referencing the page table 112. The memory address logic 108 then automatically checks whether access to the physical memory address is authorized. If so, the memory access operation (e.g., load or store) is allowed to proceed. Otherwise, it is not, and an exception is raised in an embodiment.

[0090] Access is allowed if either: i) the capability to overwrite a physical address is found in the root capability register 302 while the code performing the memory access operation is executing, or ii) the capability to overwrite a physical address is found in the base region of the currently executing software module 400 (where the capability to overwrite a given physical address means the capability to specify a range of physical addresses that includes that address). This assumes a direct correspondence between root capabilities and code running with the privileges of the address space executive, but this is not required (it simply simplifies certain aspects of the implementation). Similarly, the requirement that linear capabilities never leave the memory assigned to the address space executive is intended to simplify verification of code and prevent capabilities from being accidentally corrupted, rather than being a core part of the model.

[0091] The check of capabilities is performed by the memory access logic 108 (and the results of the check are enforced). The check can be implemented, for example, by dedicated hardware circuitry in the MMU or by low-level trusted firmware or executive software, or a combination thereof (for example, the hardware can be provided with a mechanism for triggering more executive-level software or firmware to run when an interrupt is raised). In an embodiment, all of this is triggered in response to a single machine code instruction of the execution logic's instruction set (for example, a single load or single store instruction). For efficiency, in an embodiment, the results of the check will also be cached in hardware (for example, TLB 114), regardless of how it actually occurs.

[0092] The root capabilities in the root capabilities register 302 grant access to the base address region 402 containing the address space executive 403. The memory access table 508 in the address space executive 403 contains zero or more additional capabilities that grant access to one or more additional address ranges that constitute the corresponding non-executable region 404. (It is possible that the isolated region consists only of software running in the base region 402 and with the privileges of the address space executive—unlikely common, but some lightweight trusted agents running in this mode may be useful.) When the address space executive 403 of one software module 401 calls another software module 401, a domain transfer is then performed to transfer from one partition 400 to another (e.g., the hypervisor calls the OS or the OS calls the application). At the time of the domain transfer, the root capabilities in the root capabilities register 302 are replaced with the root capabilities of the address space executive 403 of the called software module 401. The call jumps to a point (e.g., a predetermined point) within the executable code 510 of the address space executive 403 of the called module 401, causing the new address space executive to begin running. The address space executive 402 can then jump to any location in the corresponding program 102 in the non-executable area 404 based on having one or more corresponding capabilities for that area in its corresponding memory access table 508. The address space executive 403 or non-executable program 102 can also access data 405 from anywhere in the non-executable area 404 based on having one or more corresponding capabilities for that area in the corresponding memory access table 508.

[0093] Preferably, the instruction set of execution logic 104 includes one or more dedicated capability manipulation instructions, i.e., dedicated machine code instructions for modifying physical capabilities and / or transferring capabilities between software modules 401. In an embodiment, one, some, or all of these instructions may be reserved for use by executive-level code running in executive mode, so that within partition 400, they can only be used by trusted address space executive 403, and not by non-executive software 102. However, this is not necessarily the case. Alternatively, one, some, or all may be non-privileged instructions, but can only be used with valid capabilities, and thus, if the software stack maintains the invariant that linear capabilities are only stored in memory owned by the address space executive, then these instructions can only be used implicitly by the executive, rather than explicitly.

[0094] Capability operation instructions may include any one, more than one, or all of the following: a partition creation instruction (e.g., EnclaveCreate) for use when creating a partition; a partition call instruction (e.g., EnclaveCall) for calling an address space execution program 403 in another partition; a capability slicing instruction (e.g., CShard) for slicing a source capability into two destination capabilities; a range splitting instruction (e.g., CSplitRange) for splitting a source capability into two destination capabilities and splitting a source range between them; a permission splitting capability (e.g., CExtractPerms) for splitting a source capability into two destination capabilities and having different types of permissions within the same range; and / or one or more capability combining instructions (e.g., CCombine) for recombining two slicing, range splitting, or permission splitting capabilities (this may be all of the same instruction type or separate types of recombining different types). Alternatively, on some architectures, such as those where microcode is desired to be avoided, any of the above operations (e.g., EnclaveCall) may be implemented as a multi-instruction sequence.

[0095] Capabilities can be transferred linearly from the memory access table 508 of one software module 401 to the memory access table 508 of another software module, thereby modifying the size of their partitions 400. Linear transfer means transferring capabilities from the partition 400 of one software module 401 to the partition 400 of the second software module 401 without retaining them in the first software module's partition. In the illustrated embodiment, this means transferring capabilities from the memory access table 508 in the base area 402 of the first software module 401 to the memory access table 508 in the base area 402 of the second software module 401 without retaining them in the first software module's memory access table.

[0096] Capabilities can also be sharded. While linearity is a property of how capabilities are transferred (i.e., moving is allowed, copying is not), sharding is a property of the things being moved. Sharding defines additional ways to split linear capabilities. A capability can be split (sharded) into two parts (shards), which may then be further split into smaller shards. Both parts are linear: they can be moved, but not copied. If a capability is split into two parts, then another party that later receives both parts can reassemble the complete capability. The linearity property of the sharded parts guarantees them that no other entity holds a copy of the capability. Between the initial split and the final reassembly, any number of split and reassemble operations can be performed, but the linearity property must be respected for all of them.

[0097] One shard can be transferred linearly from the memory access table 508 of the first partition 400 to the memory access table 508 of the second partition 400. Then both the first and second (source and destination) partitions 400 have one shard. Any software module 400 that has a shard covering the same address range (putting it in its memory access table 508) will have access to that physical address range, i.e., the memory range will therefore be shared but only between a limited number of modules 401 that have one of the capable shards.

[0098] According to one aspect disclosed herein, the sharding operation also implicitly modifies the split count value 606 to record how much of the original unsharded (i.e., exclusive) capacity each resulting sharded capacity is, and what fraction of the original exclusive capacity it is. This split count allows the sharded capacity to be reassembled again later, enabling exclusivity to be restored, and sharing of memory need not be indeterminate or unconstrained.

[0099] For example, in one possible encoding, consider an 8-bit split count field, which can be represented using a 1-biased representation. That is, the representable values ​​are 1-256 (having 1 / 0 of the capacity is meaningless, as it would be meaningless), with a value of 256 indicating full ownership (no sharding at all), a value of 128 indicating half of the original capacity, and so on, so that a value of 1 indicates 1 / 256 of the original capacity. In this encoding, reassembly requires only addition (and splitting requires subtraction).

[0100] There are many operations that can be allowed on a capability. Linearity is the property that all operations on a linear capability are allowed: that is, no copying occurs, and the output of any operation produces a capability set that contains exactly the same rights as the input.

[0101] The Split operation performs a split based on scope or permissions, yielding two capabilities with disjoint subsets of the rights of an initial capability. Slicing yields two capabilities with the same rights as the original, but with smaller split parts (the sum of the split parts is the same as the original). Combining yields a single capability with the sum of the rights held by both parties. An atomic swap moves a pair of capabilities between a register and a memory location (if one capability is null, this is equivalent to a load or store that enforces linearity). Enclave creation consumes a full capability (full split parts, all rights) and yields an entry capability, which then allows the system to reconstruct the full capability with the execute bit set in the root register. The execute bit prevents any software from moving this capability out of the root capability register until the enclave is destroyed. Enclave destruction implicitly invalidates all entry capabilities for the enclave and reconstructs the full capability into memory. A revocation mechanism exists for entry capabilities and will be discussed in more detail later.

[0102] When a sharded or split capability is reassembled, the reassembled parts can be equal, but it is also possible to reassemble two unequal parts. Any split operation (whether via sharding, authority, or rage splitting) can be reversed, and if all split operations are reversed, the result will be the final capability.

[0103] As an optimization, in an embodiment, instances of capabilities from the memory access table base region 508 in the base region 402 of at least the currently executing module 400 can be stored in the general capability registers 304. The root capability register(s) 302 are used for base lookups. The additional (general) capability registers 304 are used as a place for execution program code to manipulate capabilities and as a place to store capabilities when transferring capabilities between domains. Capabilities from the base region are not stored in these registers and memory simultaneously. Instead, software can move capabilities between the base region (or, if software policy allows, other memory) and these registers. The additional capability registers 304 can therefore store capabilities loaded from and stored to memory for manipulation by the execution logic 104. However, they do not store copies simultaneously with memory, as copying would violate the linearity property.

[0104] In an embodiment, general capability registers 304 are used as operands for capability manipulation instructions that perform operations such as transferring from one module 401 to another, slicing a capability, splitting the address range of a capability between two new capabilities, and reassembling capabilities.

[0105] In one embodiment, the enclave call instruction (or, more precisely, the storage of capabilities in registers 304 during an enclave call) is a mechanism for transferring capabilities linearly between partitions, but each load, store, split, or combine is also linear. An enclave call swaps the root capabilities and provides the incoming capabilities for the previous one in the link register. It does not clear any other registers, so a module 401 loads the capabilities from its memory access table 508 into the capability registers and then executes the enclave call. If it is desired to send more than one distinct, non-contiguous capability to an enclave or partition before calling it, then, if the system has sufficient capability registers, all of these capabilities can be placed as register parameters and then the enclave call executed to call the target. If there are not enough registers, multiple calls may be required to transfer all capabilities.

[0106] Instead of or in addition to using enclave calls, other implementations may provide other mechanisms for performing linear transfers of capabilities, such as dedicated linear transfer instructions for transferring linear capabilities from one enclave / partition to another. Doing this in a single instruction is preferably microcoded. The recipient will typically want to do something (decide whether and / or how to accept the capability), so implementing this will preferably involve a function call or the like. This can also be done asynchronously (without any dedicated hardware support) by providing the capability to a buffer shared between the two executors and using it as a ring buffer to store other capabilities.

[0107] Figure 7 1 is a flow chart showing a method of booting the system 100 and then partitioning the physical address space 202 and allocating corresponding capabilities between different software modules 401 running in different partitions 400. Figure 1 , wherein an operating system 102OS runs on a hypervisor 102HV and one or more applications 102AP run on the operating system. However, it should be understood that the same principles can be applied to other combinations of programs 102, such as no hypervisor, where the operating system 102OS is the lowest-level program 102 in the stack 100.

[0108] At step 710, the method begins by running boot code on execution logic 104. Boot code is executive-level code that runs in executive space and initially possesses one or more root primitive capabilities that cover the entire physical address space 202 (or at least the entire protected address space if only part of the address space is protected by the capabilities mechanism).

[0109] At step 720, the boot code then creates a partition 400 for the lowest-level program 102 in the stack 100 (in this case, the hypervisor 102HV). This creates a base region 402 and an address space executive 403 for the hypervisor 102HV and allocates corresponding capabilities that cover the base region 402. The boot code may also allocate one or more additional capabilities to the memory access table 508, covering one or more non-executable program regions for running the hypervisor's non-executable program code 102HV.

[0110] At step 725, the boot code calls the software module 401 including the hypervisor 102HV. This includes switching the root capability in the root capability register 302 to the root capability of the hypervisor's base region 402 and executing the program 403 by jumping to an address within the hypervisor's 102HV address space. The hypervisor's executive program 403 can then jump to its non-executable program code 102HV and / or create and call a partition of the operating system 102OS.

[0111] At step 730, the hypervisor's address space executive 403 creates a partition 400 for the operating system 102OS. This creates a base region 402 and an address space executive 403 for the operating system 102OS, and allocates corresponding capabilities that cover this new base region 402. The hypervisor's executive 403 may also allocate one or more additional capabilities to the memory access table 508 of the operating system's executive 403, thereby adding one or more non-executable regions for running the operating system's non-executable code 102OS.

[0112] At step 735, the hypervisor 102HV or its executive 403 calls the software module 401 that includes the operating system 102OS. This involves switching the root capability in the root capability register 302 to the root capability of the base region 402 of the operating system and jumping to an address within the address space executive 403 of the operating system 102OS. The OS executive 403 may then jump to its non-executable program code 102OS and / or create and call a partition of one or more applications 102AP.

[0113] At step 740, the operating system's address space executive 403 creates a partition 400 for at least one application 102AP. This creates a base area 402 and address space executive 403 for the application 102AP, and allocates corresponding capabilities covering the new base area 402. The operating system executive 403 may also allocate one or more additional capabilities to the operating system executive 403's memory access table 508, thereby adding one or more non-executable areas for running the operating system's non-executable code 102OS.

[0114] At step 740, the operating system 102OS or its executive program 403 calls the software module 401 including the application 102AP. This involves switching the root capability in the root capability register 302 to the root capability of the application's base area 402 and executing the program 403 by jumping to an address within the application's 102AP address space. The application's executive program 403 can then jump to its non-executable program code 102AP.

[0115] At step 750 , the application 102AP may access the data 405 from within its allocated non-executable program space 404 based on having a corresponding capability for the address range in its memory access table (and in embodiments, the capability register 304 ).

[0116] Notice, Figure 7It is not meant that all of these steps are necessarily required in all possible scenarios. They are only required if isolation is required at every level in the system (hypervisor, operating system, and applications). For example, one could launch an executive for the operating system and run the operating system isolated from the hypervisor, but not enforce any isolation of the applications from the operating system. This may be a common use case (e.g., cloud customers trust the operating system they deploy, but do not trust the hypervisor provided by the cloud operator). The address space executive 403 is only required for components that do not wish to rely on a hierarchical trust relationship where they are strictly less trusted than the components to which resources are assigned.

[0117] Some examples of operations that can be performed on capabilities are now described in more detail below. It should be understood that these example details are given by way of illustration only and are not necessarily limiting.

[0118] As mentioned, root capabilities are specific to the current address space executive. During a domain transfer, root capabilities register 302 is replaced with the target executive's capabilities. A domain transfer is a call between two isolated address spaces. In one embodiment, it is the result of an enclave call instruction. Note that a trusted hypervisor can call the operating system (the operating system can call the trusted hypervisor), and a trusted operating system can call applications, and vice versa, without going through the executive. Cross-domain calls are only required between mutually untrusted parties (e.g., a hypervisor and an isolated VM, an operating system and a userspace enclave).

[0119] In an embodiment, establishing a partition (e.g., an enclave) 400 may involve a sequence of instructions. For example, high-level operations for booting may be:

[0120] i) loading the initial software state into an area of ​​physical memory,

[0121] ii) extracting the physical capabilities for the region from the root capabilities using one or more capability split instruction sequences,

[0122] iii) Issue an enclave creation command with the capability, grant "enter capability", and then iv) issue an enclave call command.

[0123] A similar sequence can be performed for subsequent isolated regions, but step ii) involves directly using one of the physical capabilities stored in the address space execution program's memory access table 508. Enclave creation takes full linear capabilities of the region and constructs entry capabilities. In embodiments, it also generates an initial attestation that can be used to verify that the initial state of the execution program is running trusted code.

[0124] An entry capability is a term derived from the existing capability system. It grants the right to invoke (enter) specific code, but does not check its capabilities. An entry capability enables domain transitions. Once an executable for an isolated address space is created, a mechanism is needed to invoke it. It must grant the right to call the executable without granting direct access to any of its information. This is an entry capability. It can be used as an operand to an enclave call. The hardware will check that it is valid and, if so, construct the enclave capabilities (linear capabilities, with a bit set to prevent them from being removed from the root capabilities register except during executable teardown). Once entry capabilities exist, a mechanism is needed to invalidate (revoke) them so that if the executable is corrupted, the original linear memory capabilities can be reconstructed without violating linear invariants. In one embodiment, entry capabilities are not linear; they provide a mechanism that allows multiple isolated units to invoke each other. In alternative embodiments, entry capabilities can be linear, but they can also have different revocation mechanisms. In either case, entry capabilities have some revocation mechanism. One possible revocation mechanism involves an additional per-enclave flag bit and a revocation counter at the start of execution. If non-executable code is not allowed to retain access capabilities directly, then the same linear mechanism can be used, although this will complicate the teardown process (to destroy an isolated enclave, all access capabilities must be restored to it).

[0125] To call a partition (e.g., an enclave) 400, the enclave call instruction acts like a jump and link register instruction. The caller is responsible for placing any parameters (including capabilities) into registers. The callee executable typically has a dispatcher that checks the caller and some equivalent vtable index, then jumps to the correct location.

[0126] To transfer capabilities linearly from one partition (e.g., enclave) 400 to another, this can be accomplished simply by a cross-domain call (enclave call instruction) with linear capabilities in registers. Alternatively, the possibility of providing a separate enclave transfer instruction in the instruction set of the execution logic 104 is not excluded.

[0127] The enclave calls get_entry_capability and:

[0128] i) Check whether the entry capability is valid.

[0129] ii) Construct an exec capability corresponding to the entry capability and install it in the root register.

[0130] iii) Get the old value of the root register, and,

[0131] a. If it is an execute program capability, construct an entry capability from it and place it in the capability link register, but

[0132] b. If it is not an execute program capability, place it directly into the capability link register.

[0133] Execution is then resumed inside the target executable.

[0134] To slice capabilities, the capability slice instruction may take the following form, for example:

[0135] CShard$cd,$cs,$rs

[0136] Where $cd is the capacity destination register, $cs is the capacity source register, and $rs is the integer source register. This deducts the value in $rs from the split portion field in $cs and constructs a capacity in $cd that is the same as the original value of $cs, with the split portion field set to the value in $rs. If $rs is greater than the split portion in $cs, it gives an empty capacity in $cs and the original capacity in $cd (or vice versa - both are equal for the model).

[0137] Similarly, the instruction form is:

[0138] CSplitRange$cd,$cs,$rs

[0139] Splits $cs into two components, which are split into the address range provided in the $rs register according to the offset.

[0140] Another instruction form is:

[0141] CExtractPerms$cd,$cs,$rs

[0142] The same thing can be done to extract a set of permissions from $cs into $cd.

[0143] To restructure the scope splitting or authority splitting capabilities, in an embodiment, there may be a single CCombine instruction of the form:

[0144] CCombine$cd,$cs1,$cs2

[0145] This will check that $cs1 and $cs2 are either adjacent and have the same permissions and split parts, the same range and permissions but different split parts, or the same range and split count but different permissions, then the values ​​in $cs1 and $cs2 will be replaced with null and the combined capabilities will be placed in $cd.

[0146] To reassemble shard capabilities, this can also be done with a single CCombine instruction or with separate instructions for combining permissions, split counts, and ranges.

[0147] Capability manipulation operations are atomic. That is, a thread cannot perform a partial update to a capability before switching to another thread. In other words, moving or modifying a capability is an indivisible operation. For example, interrupting a capability operation in the middle should not allow observation of partial state. This is preferably enforced in hardware.

[0148] A mechanism may also be provided for disassembling a partition (e.g., an enclave) 400. The policy allowing this may be specified in the address space executive 403.

[0149] Based on the various possibilities discussed above, a set of extensions to an architecture that provides CHERI-like capabilities is provided, which would allow for partitioning such as SGX-like enclaves. Both SGX and CHERI facilitate compartmentalization, but with very different threat models. SGX assumes that trusted applications attempt to protect themselves from untrusted operating systems and / or hypervisors. CHERI assumes that mutually untrusted components of an application attempt to protect each other, running on a trusted operating system. It is desirable that applications be protected against risks from both. This disclosure provides various embodiments for achieving this.

[0150] Also by way of illustration only, some further example implementation details are now set forth below.

[0151] In summary, a capability grants rights to an address range. In the existing CHERI work, it grants rights to a virtual memory range, and thus can be used wherever the program has a notion of virtual addresses (most commonly as the underlying implementation of the source language's notion of pointers). When a capability grants access to a physical memory range, it must be used wherever the software has a notion of physical addresses, such as in page tables and similar structures.

[0152] A linear capability on physical memory is a token that grants exclusive access to a range of physical memory. System code responsible for defining virtual-to-physical translations (e.g., an operating system kernel) will define page table entries that reference this capability. There are at least two possible mechanisms for implementing this.

[0153] As a first possibility, the capabilities are stored in a structured form by the address space executive. The operating system updates the traditional page tables to reference physical addresses and an additional stage at the end of the page table walk checks this structure and verifies that the capabilities of the represented address range are held by the address space executive of the currently executing component.

[0154] As a second possibility, capabilities are stored in a flat table by the address space executive, and the leaf page table entry contains an index into that table and an offset into that capability. The page table walker then has a simpler extra step to check that this is a valid capability and that the offset into the page table is within the specified range. This approach allows arbitrary levels of delegation (i.e., equivalent to nested virtualization) with lower overhead than the single level of virtualization in the current implementation.

[0155] The first possibility is more complex, but does not require the operating system to be modified to know the mechanism. The second possibility does require the operating system to be modified to know the mechanism, but has the advantage of lower complexity.

[0156] The address space executor is trusted by all privilege levels of the code it directly manages. Malware running in an executor is unlikely to violate the isolation guarantees enforced by the hardware. Individual executors can decide whether to trust other executors based on their attestation offers. If an executor fails to disable interrupts, it may lose its own capabilities, but it cannot steal the capabilities of anyone else. If the executor receiving the capabilities does not perform a proper TLB invalidation, the sending enclave may (temporarily) be able to access memory, but once again, a flawed enclave can only compromise its own security. The hypervisor trusts any running enclave with some availability guarantees (i.e., they cannot accidentally corrupt capabilities, rendering certain memory inaccessible until the system is rebooted).

[0157] This risk is mitigated by restricting which entities in the system can create new executables, so that lower-level software (e.g., boot firmware and hypervisors) can limit the set of allowed executables to a small set that enforces specific policies. This is done in conjunction with attestation mechanisms (see below).

[0158] The address space executor may also be responsible for ensuring some invariants, such as all updates to the capability table being performed safely (interrupts are disabled so capabilities in registers are not accidentally overflowed by code that doesn't know how to save them, TLB invalidations are broadcast to ensure there are no stale references to the owned set of capabilities in other parts of the system).

[0159] Sharding adds a controlled sharing mechanism to this. The same capability checks are performed by the page table walker when installing TLB entries, but now two address space execution programs can communicate that all references to a page are considered between them and are therefore shared by them, but not by any other entity in the system. For example, a shielded VM and a userspace enclave can share pages that are invisible to the hypervisor.

[0160] Capabilities are stored in memory and in capability registers. They are protected by a flag bit in both (the flag bit is not addressable. For capability registers, it can be queried and cleared, but not set (and for linear capabilities, it cannot be cleared). The linearity guarantee is enforced by allowing only atomic swap operations to move capabilities between registers and memory.

[0161] The hardware enforces a strict provenance tree for all kinds of capabilities: capabilities cannot be created from scratch; they can only be constructed by applying permitted operations to existing capabilities. The set of operations for linear capabilities is slightly different, as all operations are destructive: they can be split and combined, but doing so destroys the original capability, and likewise they can be moved between registers and memory but not copied.

[0162] Steering Figure 1 , the page table 112 is preferably stored in memory. In principle, it could be implemented in hardware or a register file, but for the use case, it would be a large data structure and implementation outside of memory might be impractical. There are a number of different possible implementations for the data structure of the page table 112, such as a flat table lookup, a tree, etc. Broadly speaking, there are two mechanisms used by the MMU (in which at least a portion of the memory access logic 108 can be implemented).

[0163] The first uses a software-managed TLB 114. These are used in MIPS and early SPARCs (newer SPARCs are a mix). When the CPU encounters a TLB miss, it delivers an exception, and some system code installs a new TLB entry. The idea behind implementing this with a software TLB is to deliver the exception to the address space executive, which will issue a TLB fill instruction, presenting a (physical) address in memory at linear capabilities. The CPU will then check if the physical address is within the executive (by checking it against bounds in the address space executive capabilities register), load the capabilities, and then install the TLB entry.

[0164] The second type of MMU mechanism uses a hardware-managed TLB 114. This defines a data structure (usually a page table, but there are some other variations) that provides a partial mapping from virtual to physical address space. When the CPU encounters a miss in the TLB, a dedicated hardware state machine traverses the data structure to find an entry to insert into the TLB. If the hardware page table walker fails to find the entry, it delivers an exception, which allows the software to add the missing entry to the page table and restart the walk. In systems that support virtualization, there are typically two levels of page tables. One, managed by the guest operating system, translates from virtual addresses to pseudo-physical addresses. The other, managed by the hypervisor, translates between pseudo-physical addresses and physical addresses. In the event of a TLB miss, the page table walker will traverse both and combine them to give a virtual to physical mapping. Both layers may have entries missing, and the exception is delivered to either the operating system or the hypervisor, depending on which layer has the missing entry. This allows both the operating system and the hypervisor to perform swaps independently. For systems with hardware-managed TLBs, there are three options.

[0165] In the first option for a hardware-managed TLB, software running inside the isolated enclave is aware of the isolation mechanism. In this scenario, the address space executive manages a data structure (e.g., an array) that simply indexes the physical capabilities, and the software inside the enclave maintains a set of page tables (or equivalent). In a traditional page table, the last hop provides the physical address of the page start and the set of permissions. In this model, however, the last hop is an index into a data structure managed by the translation. From a security model perspective, the page table is untrustworthy: only the last check (of capabilities owned by the executive and referenced from that table) is important. Note that this model may involve additional mechanisms for address protection of the page table itself, such as explicitly managed TLB entries or registers that provide capabilities for the entire memory range used by the current page table, or simpler tables managed by the enclave executive for use during page table walks.

[0166] In the second option, a hardware-managed TLB, software running inside the isolated area is unaware of the isolation mechanism (or, at least, the part that manages address translations). This code manages some untrusted page tables that map virtual addresses to pseudo-physical addresses, just like a normal VM. The executive manages the mapping from pseudo-physical to physical. The last entry in the second-level translation is the memory's capacity, and this is checked when the TLB is filled.

[0167] For the userspace enclave model, the third option is a slight variation of the second. This variation has a single-level page table managed by the executive for the enclave, and provides interfaces for the operating system to add mappings of untrusted memory. From a hardware perspective, this is identical to the second option, with the only difference being that the software running in the enclave executive has interfaces that allow some pages to be delegated exclusively and some to shared regions, along with external APIs that allow the operating system to update the page tables for shared regions.

[0168] In an embodiment, the capabilities are held in registers 302 , 304 , but are also part of the executive program 403 stored in memory 106 .

[0169] The registers are an architectural abstraction, while the TLB 114 is (primarily) a microarchitectural implementation detail. The capability registers are used to explicitly load and store capabilities. In this model, they are primarily used by software running inside the address space executive to manipulate the data structures that the MMU will check to determine if an entry is valid. The TLB responds to explicit invalidations (i.e., "remove the address translation for this capability"). For hardware-managed TLBs, it is implicitly filled by the page table walker (in software-managed TLBs, it is explicitly filled in response to interrupts).

[0170] In principle, this model could be implemented without the TLB 114, but it would be much slower. The interaction with the TLB is a significant part of the design of the preferred embodiment.

[0171] The root capabilities register 302 is a system register. System registers, also known as "machine specific registers" or "hardware registers," are registers that are not part of the general register set. The root capabilities system register 302 is provided because a resource cannot be accessed unless a capability is given to the resource. Because capabilities are both stored in memory and authorize access to memory, some mechanism is needed to direct access. Therefore, an embodiment uses at least one register 302 to contain capabilities that identify (and authorize access to) an executable program, which contains other capabilities that may be used by a particular isolated area. (One register is sufficient, but more than one register may be convenient for some implementations, such as for explicitly separating the code, data, and capability tables of an executable program). In a software-managed TLB system, this capability identifies an area to which an exception will be delivered in the event of a TLB miss. In a hardware-managed TLB system, this capability identifies an area that a page table walker may check when attempting to perform a TLB fill.

[0172] At system startup, before entering the first address space execution program, any second level translation is disabled and all memory accesses are simply checked against this capability. There is a mechanism to guide the first address space execution program to manage these capabilities. This includes:

[0173] i) loading the code and initial data structures for the program to be executed in the address space into the region of the address space,

[0174] ii) segmenting the region from the initial capability, and

[0175] iii) Start the address space to execute the program and provide it with access to the remaining memory.

[0176] The enclave call instruction will provide the callee with one of two things from the caller's root capabilities (in either the system register or the general capabilities register):

[0177] - If the root capability is the address space executor capability, then the callee will receive the entry capability of that enclave.

[0178] -If the root ability is a linear physical ability, the callee will receive that ability.

[0179] In a system with a similar trustzone abstraction, this would be done by the boot firmware, which would then create address space execution for the hypervisor and TEE.

[0180] The MMU is responsible for enforcing all of these guarantees, but the root capabilities are stored in a system register that is not usually considered part of the MMU. Logically, it is intended to be read by the MMU. Physically, it can be stored in the MMU, and a write to this architectural register is an implicit message to the MMU.

[0181] In operation, a capability is owned by a software module 401 if the capability is in a register or in memory reachable by the software module when the software module runs. Memory reachable by a software component is the transitive closure of the capabilities reachable from the root capability register.

[0182] Root capabilities exist to provide root access. For example, in a system with a hardware-managed TLB, a single level of translation managed by the address space executive is used:

[0183] i) Isolate software to read virtual address X;

[0184] ii) The TLB has no mapping from address X;

[0185] iii) The page table walker checks the root capabilities to discover the location of the enclave execution program;

[0186] iv) A page table walker traverses down the page table (usually a tree), checking that each entry is within the region identified by the root capability;

[0187] v) At the leaf node, the page table walker finds the capability;

[0188] vi) the page table walker inserts a TLB entry from the virtual page containing address X into the physical page identified by the capability, and with the permissions identified in the capability; and then

[0189] vii) Load instruction successful.

[0190] If any capability check fails, the CPU will deliver an exception to the address space executive, which can then forward it to another executive.

[0191] This is slightly more complicated when there are page tables in the enclave. In this case, each page table access requires a more complex capability check. For example, in a fully nested paging approach, each entry in the page table is in the pseudo-physical address space, and this sequence of operations will need to be run to check the access (this is how nested paging works on current CPUs, and adds capability checks as a final layer).

[0192] Root capabilities are used by the current address space executor. During a domain transfer, they are replaced by the target executor's capabilities. They cannot be extracted except through enclave teardown (see below). Once an entry capability is created, any code with a copy of that capability can call into the enclave. The address space executor will explicitly convert its enclave capabilities into normal linear physical capabilities and pass them to another executor during enclave destruction.

[0193] Each software module 401 runs its own partition (e.g., enclave) 400, which is a memory address subspace consisting of a base area 402 and a non-executable area 404. The base area contains at least the executable for the corresponding software component. The software component itself (e.g., application) is stored in the non-executable area 404.

[0194] Initially, only the hypervisor is running and owns all address space. To allow another isolated component to run, the hypervisor creates a corresponding base region in memory for it and populates it with the corresponding executive. The base region is specially protected from modification. This is roughly analogous to the privileged / non-privileged mode separation in current CPUs. The region identified by the root capability can only be modified by code running in executive mode, which is contained within the region and can only be entered from non-executive code via an explicit entry point.

[0195] To set up and run a partition (e.g., an enclave), this involves the operating system or hypervisor executing the enclave creation instruction. The enclave creation instruction converts linear physical capabilities into entry capabilities. This is a destructive operation that consumes linear capabilities (and requires that the capability be unsharded—i.e., it has exclusive ownership of all permissions and memory). Initially, only the entity that created the enclave will hold a copy of the entry capability, and therefore only that entity can call it. Copies of the entry capability can be delegated elsewhere. The right to create an enclave is granted if any of the following conditions occur:

[0196] -The root ability is a linear physical ability, or

[0197] - Root capability is the address space executive capability, and the currently executing software is in executive mode.

[0198] This pair of restrictions allows the first executor to enforce the policy on all subsequent executors.

[0199] Later, another non-contiguous address space can be added to the enclave / partition. To do this, another software component (a hypervisor or another component, such as an operating system or another application) provides one of its capabilities to the partition / enclave in question. This is a simple enclave call, passing the delegated capability in the general capability register. This involves a swap operation to load them from the owning enclave's execution program. If the caller wishes to share memory, the caller will slice the capability before passing it to the other enclave.

[0200] The clean separation between simple hardware mechanisms and (potentially) complex software strategies is another noteworthy part of the design.

[0201] The target's entry capability is the operand of the enclave call instruction. This causes execution to branch to a predetermined address within the destination enclave / partition's executable. In some embodiments, this will always jump to a specific fixed address within the executable. In other embodiments, as a performance optimization, it may take an integer operand and jump to the entry point identified by that index. Either way, the executable may then decide to build a thread-like abstraction on top, simply acquire a mutex, or fail to acquire a mutex and return.

[0202] The executable code is now running. It can then jump to the non-executable area, including any non-contiguous space, to run the corresponding software component (e.g., operating system or application). In some implementations, it may be beneficial to have explicit instructions for jumping out of the executable.

[0203] Destroying an enclave is called a "teardown". Enclave teardown relies on a trusted entry point in the enclave's executable. This can only be invoked by one of a small set of entry capabilities provided during enclave creation (usually only the hypervisor).

[0204] As mentioned, once entry capabilities exist, some mechanism is needed to invalidate (revoke) them so that when an executor is destroyed, the original linear memory capabilities can be reconstructed without violating the linearity invariant. This can be built on top of the linearity mechanism, so that the entry capabilities are linear and shardable, but this is not necessarily ideal for two reasons. First, because it limits the number of things that can invoke an executor to the number of shards supported by the system. If every VM wants to be able to invoke the hypervisor, then every VM will need entry capabilities on the hypervisor. With an 8-bit shard count, this limits you to 256 VMs. The second problem is that when an executor is torn down, the only way to invalidate linear capabilities is to collect them all. This requires a lot of communication to identify all the places where linear capabilities ended up and hand them back.

[0205] Therefore, in the preferred design, revocation is implemented using a unique number stored in memory at the start of the execution program and in the entry capability. The entry capability is valid only if this number matches, so all entry capabilities can be invalidated (revoked) by changing the stored number. There is also a tag check. Without the tag check, it is possible to construct a memory area that the system believes is an execution program and reuse existing entry capabilities, in the process constructing duplicate linear capabilities and violating the system's invariants. The start of the enclave has a coarse-grained (e.g., one per page) tag that indicates that it is the start of an execution program.

[0206] Therefore, the executive can be disassembled by incrementing the counter value, which invalidates all entry capabilities, forces all other cores running in that executive to terminate, and then clears the enclave call and enclave bits in the registers (which passes the current root capabilities in the capability link registers as normal physical capabilities).

[0207] To destroy an enclave in this design, the flag bit is cleared, preventing any existing entry capability from being invoked, while ensuring that exactly one thread is active. This is accomplished by invoking the teardown entry point in the enclave. This invokes the enclave executive code, which first clears the flag, ensuring that no cores already running enclave code can do so. It then sends an IPI to all other cores running enclave code, requesting that they invoke the hypervisor. Once all other running threads have notified the teardown thread of their exit, the teardown thread zeroes all physical memory associated with the enclave, clears the enclave bits in its underlying physical capability, and finally invokes the hypervisor.

[0208] Embodiments may also employ an attestation mechanism. When the hypervisor populates the executive area 402 with the enclave executive code, this code is trusted by both the hypervisor and the enclave. After the enclave is created, no code other than the code in this section can modify anything in the enclave base area. The hypervisor's trust comes from the fact that it provides this code. The enclave owner trusts this code because it is part of the attestation offer and can therefore be verified as the agreed-upon enclave executive image. This code replaces a large amount of unverified secret microcode in SGX.

[0209] The system can perform attestation as a two-stage process. The hardware (microcode or a small coprocessor) will generate an attestation quote for each enclave executive image, specifically stating that it has created an enclave with a specific version at a specific address and that it is running an executive with a specific hash. For remote attestation, this will also include a signature using the public key generated by the enclave executive. This is not required for local attestation, as the enclave's base address and version are embedded in the entry capability.

[0210] The enclave executes program code, and because it runs with interrupts disabled and inserts all entry and exit events, it can generate subsequent attestation quotes for the software running inside the enclave.

[0211] It should be understood that the above embodiments are described by way of example only.

[0212] More generally, the present disclosure relates to a system comprising: execution logic comprising one or more execution units; a memory comprising one or more memory units; and memory access logic for locating a mapping between a physical address space and a virtual address space of the memory. The execution logic is arranged to run a plurality of software modules, each in a respective partition of the physical address space, each software module running in a respective partition of the physical address space, including for executing a memory access operation performed by a currently executing software module, the memory access operation specifying a virtual address within a virtual address range as a target of the memory access operation. The memory access logic is configured to perform the following operations: locate a physical address in the physical address space that is mapped to a virtual address, check whether the ability to authorize access to the physical address is found in a memory location to which the currently executing software module has access, and, conditionally, authorize access to the physical address for performing the memory access operation.

[0213] The storage location to which the currently executing software module has access may be a capability register accessible to the currently executing code, or an area in a partition of memory corresponding to the currently executing module.

[0214] Each capability specifies a corresponding region of the physical address space to which the capability is authorized to access. In an embodiment, at least one of the capabilities authorizes exclusive access to its specified address range.

[0215] The memory access logic may be implemented in dedicated hardware circuitry, in firmware, or in low-level software running in the executive space, or any combination of these.

[0216] In an embodiment, if access is not authorized, the execution logic may trigger an exception.

[0217] The memory access operation may be, for example, a load operation to load a value from a target address, a store operation to store a value to a target address, or an instruction fetch operation to fetch an instruction from a target address to be executed by execution logic.

[0218] According to the first aspect of the present disclosure, the execution logic is further configured to perform a linear capability transfer operation that transfers one of the capabilities from the first partition of the software module to the second partition of the software module without retaining it in the first partition.

[0219] According to a second, alternative or additional aspect of the present disclosure, the execution unit is configured to perform a sharding operation, whereby one of the capabilities is divided into at least two instances, and the execution unit is further configured to perform a shard reassembly operation, whereby the instances are reassembled.

[0220] To achieve this, in an embodiment, at least one of the capabilities may include a corresponding split count value; wherein in a sharding operation, the partitioning is recorded in the corresponding split count value of each instance; and wherein the reorganization is based on the corresponding split count value of the instance, and the reduction in the number of instances is recorded in the corresponding split count value of the reorganization capability.

[0221] In an embodiment, the execution logic is configured to not allow any capability to be partitioned more than a maximum predetermined number of times.

[0222] In an embodiment, a source software module of one of the software modules may transfer one of the shard instances from a partition of the source software module to a partition of a destination software module of the software module. This transfer may be linear. Another instance may remain in the partition of the source module or be transferred to a partition of another software module. This transfer may also be linear. To enable reassembly, all instances may be transferred back to a partition of the same software module. In an embodiment, all transfers of shard instances may be linear.

[0223] In an embodiment, the capability conveyed by the linear capability operation may be one of the shard instances.

[0224] In an embodiment, the destination module may check the split count value to determine whether it has exclusive access to the corresponding address range, and / or determine how many other instances of the corresponding capability there are in the loop.

[0225] Any one, multiple or all of the following embodiments may be applied to the first or second aspect.

[0226] In an embodiment, at least one of the software modules may include an application running on an operating system. In an embodiment, at least one of the software modules may include an operating system on which one or more applications run, such as one or more other software modules in the software modules. In an embodiment, at least one of the software modules may include a hypervisor on which at least one operating system runs, such as a hypervisor that may also be one of the software modules.

[0227] Note that in the case of a three-layer stack of application, operating system, and hypervisor (application(s) running on the OS and the OS running on the hypervisor), when the currently executing software module is one of the applications, the mapping of virtual addresses to physical addresses can be via pseudo-physical addresses. In other words, the currently executing application specifies a virtual address, the operating system converts to a pseudo-physical address, and the memory access logic performs the mapping by mapping from the pseudo-physical address to the (real) physical address.

[0228] Each corresponding software module can access the physical address range of its corresponding partition. Since these capabilities both authorize access to memory and are stored in memory, a mechanism can be provided to guide access. There are many possible mechanisms for this, which can be used individually or, more preferably, together.

[0229] For example, in an embodiment, each of the partitions may include a corresponding base region, and the memory access logic may be configured to perform the check at least by checking whether the capability authorized to access the physical address is found in the base region of the currently executing software module.

[0230] In an embodiment, the base region of each software module may be implemented in a protected executive area of ​​the memory, accessible only to executive-level code running in a privileged executive mode of the execution logic.

[0231] In an embodiment, each of the partitions may include, in addition to the base region, a respective further region of the physical address space, wherein capabilities in the respective base region authorize access to the respective further region.

[0232] In an embodiment, each of the software modules may include a corresponding address space executive program, which is a portion of executable executive program code stored in and retrieved from a corresponding base area of ​​the corresponding software module.

[0233] In an embodiment, each of the software modules may further include a corresponding program other than the address space execution program stored in and retrieved from a corresponding additional area of ​​the corresponding partition.

[0234] The program of each module may be, for example, an application, an operating system, or a hypervisor (or a portion thereof).

[0235] The capabilities in each of the base regions may be stored, for example, in the form of a memory access table. The checking of the base regions may include checking the memory access table of the currently executed software module.

[0236] In an embodiment, the system may include at least one root capability register for storing the root capability of the currently executed software component. The memory access logic may be configured to perform the check by at least checking whether a capability authorizing access to the physical memory address is found in the root capability register.

[0237] In an embodiment, the root capability may grant access to the base area of ​​the currently executing software module.

[0238] In an embodiment, the memory access logic may be configured to perform the check by checking whether a capability authorizing access to the physical memory address is found in either a root capability register or a base area of ​​the currently executed software module, and authorizing access if found in either one.

[0239] In an embodiment, a calling software module among the software modules may be configured to perform a calling operation to call another called software module among the software modules, and in doing so, perform a domain transfer that switches the root capability in the root capability register from the root capability of the calling software module to the root capability of the called software module.

[0240] Due to the disclosed capability system, neither the calling software module nor the called software module will be able to access the internal state of the other (ie, data or code in the other's partition).

[0241] The calling software module may be, for example, the first software module and the called software component may be the second software module.

[0242] In an embodiment, the call may be performed by the address space execution program of the calling software module. Alternatively, the call may include a jump to the address space execution program of the called software module. In some such embodiments, the jump may include a jump to a predetermined point in the address space execution program of the called module, such as a jump to a predetermined instruction address in the base area. Alternatively, the jump point may be specified.

[0243] Once called, the address space execution program of the callee module may then jump to a corresponding program in a corresponding further area of ​​the partition.

[0244] In an embodiment, prior to the call, the calling software module or another software module in the software component may be configured to initially create one of the partitions (e.g., an enclave) in which the called software component runs by setting the base area of ​​the called software component. This creation may be performed by the address space execution program of the calling software module or another software module.

[0245] In an embodiment, each capability may specify one or more types of permissions: read, write, and / or execute. If the memory access operation is a load operation, then authorization to access the physical address is further dependent on whether the permission type is read. If the memory access operation is a store operation, then authorization to access the physical address is further dependent on whether the permission type is write. If the memory access operation is an instruction fetch or branch operation, then authorization to access the physical address is further dependent on whether the permission type is execute.

[0246] As an alternative or additional feature to sharding, in further embodiments, the execution logic may be configured to perform a range split operation, whereby: a parent capability in a partition of one software module (e.g., the first or source module) that specifies a larger address range is divided into two child capabilities that specify a smaller address range, the smaller address range being an exclusive fragment of the larger address range. At least one child capability may be transferred to a partition of another recipient software module of the software module (e.g., the second or destination module). This transfer may be implemented in a linear or sharded manner. In some such embodiments, the execution logic may be configured to perform a range reorganization operation, whereby the child capabilities are reorganized back into a reorganized capability having a larger range. The reorganized capability may be placed in a partition of the original software module, the recipient software module, or another software module.

[0247] The execution logic may be configured to execute machine code instructions, each machine code instruction being an instance of a plurality of instruction types defined in an instruction set of the execution logic,

[0248] In an embodiment, an instruction set may include one or more memory access instruction types, and said memory access operations and said operation of the memory access logic may be evoked by a single instance of a single one of said memory access instructions.

[0249] Alternatively or additionally, the instruction set may include one or more capability manipulation instruction types.

[0250] In some such embodiments, the linear capability transfer operation may be invoked, at least in part, by one or more instances of one or more of the capability manipulation instruction types.

[0251] For example, the memory access instruction may be a single load instruction, a single store instruction, or a single instruction fetch.

[0252] In further alternative or additional embodiments, the slicing operation may be invoked at least in part by one or more instances of one or more of the capability manipulation instruction types.

[0253] In an embodiment, the shard reassembly operation may be invoked at least in part by one or more instances of one or more of the capability manipulation instruction types.

[0254] In an embodiment, the call may be elicited, at least in part, by one or more instances of one or more of the capability manipulation instruction types.

[0255] In an embodiment, the split scope operation may be invoked at least in part by one or more instances of one or more of the capability manipulation instruction types.

[0256] In an embodiment, the scope reorganization operation may be invoked at least in part by one or more instances of one or more of the capability manipulation instruction types.

[0257] In an embodiment, one or more capability manipulation instructions may take as operands an indication of one or more of the capability registers.

[0258] In further embodiments, the system may include a plurality of further capability registers for storing capabilities loaded from at least the base region of the currently executing software module. The address space execution program may be arranged to use the further capability registers to store capabilities during domain transfers and / or to use the further capability registers as operands for one or more capability manipulation instruction types.

[0259] In such an embodiment, a given capability may be loaded from the base region into one of the further capability registers and subsequently stored back to the base region, but not maintained in both the capability register and the base region simultaneously.

[0260] In another embodiment, the memory is divided into a plurality of words for storing data and includes a corresponding flag bit associated with each word. The flag bit is arranged to be enabled when the corresponding word is part of a capability and disabled when the word is instead available for other data. In such an embodiment, the check may include checking the flag bit, wherein each capability is only valid when the flag bit is enabled. And / or, in an embodiment, the flag bit is not addressable except by an executive code running in executive mode. And / or, if any of the words is loaded from the memory, the flag bit is propagated along with it.

[0261] According to another aspect of the present disclosure, there is provided a method of operating a system according to any of the statements above.

[0262] According to another aspect, there is provided software embodied on a computer-readable medium for execution on a system according to any of the statements above, the software comprising one or more of the software modules comprising instructions for performing at least one instance of a memory access operation and at least one instance of a linear capacity transfer operation.

[0263] Other variations or uses of the disclosed technology may become apparent to those skilled in the art once given the disclosure herein.The scope of the present disclosure is not limited by the described embodiments but only by the appended claims.

Claims

1. A system comprising: An execution module, including an execution unit; Memory, including memory cells; as well as A memory access module, configured to find a mapping between the physical address space and the virtual address space of the memory; wherein the execution module is arranged to run a plurality of software modules, each in a corresponding partition of the physical address space, including to execute a memory access operation performed by a currently executing software module of the plurality of software modules, the memory access operation specifying a virtual address within a virtual address range as a target of the memory access operation; The memory access module is configured to perform the following operations: finding the physical address in the physical address space that is mapped to the virtual address, confirming that the capability authorized to access the physical address is found in a memory location to which the currently executing software module has access, and authorizing access to the physical address for performing the memory access operation; The capabilities include corresponding split count values; and The execution unit is configured to perform: a sharding operation, wherein the capability is divided into at least two instances through the sharding operation, and the division is recorded in the corresponding split count value of each instance; as well as A shard reassembly operation is performed, by which the instances are reassembled into the capability based on the corresponding split count values, and a reduction in the number of instances is recorded in the corresponding split count values ​​of the reassembled capability.

2. The system of claim 1 , wherein the execution module is configured to, based on the corresponding split count value, not allow the capacity to be divided by the instance of the sharding operation more than a maximum number of times.

3. The system of claim 1 , wherein the execution module is further configured to perform a linear capability transfer operation that transfers one of the instances from a partition of a first software module among the plurality of software modules to a partition of a second software module among the plurality of software modules without retaining the transferred instance in the partition of the first software module.

4. The system of claim 1 , wherein each of the partitions includes a corresponding base area, and the memory access module is configured to perform the confirmation at least by confirming whether the capability authorized to access the physical address is found in the corresponding base area of ​​the currently executing software module.

5. The system of claim 4, wherein the corresponding base area of ​​each software module is implemented in a protected executive area of ​​the memory, accessible only to executive-level code running in a privileged executive mode of the execution module.

6. The system of claim 4, wherein each of the partitions includes a respective additional region of the physical address space in addition to the respective base region, wherein the capabilities in the respective base region authorize access to the respective additional region.

7. The system of claim 4 , wherein each of the plurality of software modules includes a corresponding address space executive, the corresponding address space executive being a portion of executable executive code stored in and retrieved from the corresponding base area of ​​the corresponding software module.

8. The system of claim 7 , wherein each of the partitions includes a corresponding additional area of ​​the physical address space in addition to the corresponding base area, wherein the capability in the corresponding base area authorizes access to the corresponding additional area, and wherein each of the plurality of software modules further includes a corresponding program in addition to the corresponding address space execution program that is stored in and retrieved from the corresponding additional area of ​​the corresponding partition.

9. The system according to claim 1, comprising: a root capability register, configured to store the root capability of the currently executed software module; as well as The memory access module is configured to perform the confirmation at least in the following manner: confirming whether the capability authorized to access the physical address is found in the root capability register.

10. The system of claim 9, wherein each of the partitions includes a corresponding base area, and the memory access module is configured to perform the confirmation by at least confirming whether the capability authorizing access to the physical address is found in the corresponding base area of ​​the currently executing software module, wherein the root capability authorizes access to the corresponding base area of ​​the currently executing software module.

11. The system of claim 9 , wherein each of the partitions includes a corresponding base area, and the memory access module is configured to perform the confirmation by at least confirming whether the capability authorizing access to the physical address is found in the corresponding base area of ​​the currently executed software module, wherein the memory access module is configured to perform the confirmation by confirming whether the capability authorizing access to the physical address is found in either the root capability register or the corresponding base area of ​​the currently executed software module, and granting access if the capability is found in either one.

12. The system of claim 9 , wherein a calling software module among the plurality of software modules is configured to perform a calling operation to call another called software module among the plurality of software modules, and in doing so, perform a domain transfer, the domain transfer switching the root capability in the root capability register from the root capability of the calling software module to the root capability of the called software module.

13. The system of claim 12 , wherein each of the plurality of software modules comprises a corresponding address space executive, the corresponding address space executive being a portion of executable executive program code stored in and fetched from a corresponding base area of ​​the corresponding software module, the system further comprising an additional capability register for storing capabilities loaded from at least the corresponding base area of ​​the currently executing software module; The address space execution program is capable of using the further capability register to store capabilities during a domain transfer and / or using the further capability register as an operand of at least one capability manipulation instruction type.

14. The system of claim 1 , wherein the execution module is configured to execute machine code instructions, each machine code instruction being an instance of a plurality of instruction types defined in an instruction set of the execution module, wherein: the instruction set includes memory access instruction types, and the memory access operation and the operation of the memory access module are invoked by a single instance of a single one of the memory access instruction types; and / or The instruction set includes a capability manipulation instruction type, and the sharding operation and / or the shard reassembly operation is at least partially evoked by instances of one or more of the capability manipulation instruction types.

15. The system of claim 1, wherein the plurality of software modules include any one, more than one, or all of the following: application; at least one operating system, the application being arranged to run on the at least one operating system; and / or A hypervisor, the at least one operating system being arranged to run on the hypervisor.

16. A computer-implemented method comprising: running, using an execution module, a plurality of software modules each in a corresponding partition of a physical address space of a memory, including executing a memory access operation performed by a currently executing software module of the plurality of software modules, the memory access operation specifying a virtual address within a virtual address range as a target of the memory access operation; Use the memory access module to: finding the physical address in the physical address space that is mapped to the virtual address, confirming that the capability authorized to access the physical address is found in a memory location to which the currently executing software module has access, and granting access to the physical address for performing the memory access operation; and The capability includes a corresponding split count, and the execution unit of the execution module is configured to perform: a sharding operation, wherein the capability is divided into at least two instances by the sharding operation, and the division is recorded in a corresponding split count value of each instance; as well as A shard reassembly operation is performed, by which the instances are reassembled into the capability based on the corresponding split count values, and a reduction in the number of instances is recorded in the corresponding split count values ​​of the reassembled capability.

17. The computer-implemented method of claim 16, further comprising: The capability is not allowed to be split more than a maximum number of times by instances of the sharding operation based on the corresponding split count value.

18. The computer-implemented method of claim 16, further comprising: A linear capability transfer operation is performed to transfer one of the instances from a partition of a first software module of the plurality of software modules to a partition of a second software module of the plurality of software modules without retaining the transferred instance in the partition of the first software module.

19. A computer hardware memory device comprising executable instructions that, when executed by a processor, cause the processor to perform a plurality of operations comprising: running, using an execution module, a plurality of software modules each in a corresponding partition of a physical address space of a memory, including executing a memory access operation performed by a currently executing software module of the plurality of software modules, the memory access operation specifying a virtual address within a virtual address range as a target of the memory access operation; Use the memory access module to: finding the physical address in the physical address space that is mapped to the virtual address, confirming that the capability authorized to access the physical address is found in a memory location to which the currently executing software module has access, and authorizing access to the physical address for performing the memory access operation; and and The capability includes a corresponding split count, and the execution unit of the execution module is configured to perform: a sharding operation, by which the capability is divided into at least two instances, and the division is recorded in a corresponding split count value of each instance; and A shard reassembly operation is performed, by which the instances are reassembled into the capability based on the corresponding split count values, and a reduction in the number of instances is recorded in the corresponding split count values ​​of the reassembled capability.

20. The computer hardware memory device of claim 19, wherein the plurality of operations further comprises: The capability is not allowed to be split more than a maximum number of times by instances of the sharding operation based on the corresponding split count value.

Images