Confidential computing mechanism

Abstract

According to a first aspect, the 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 partition of a second software module without retaining it in the partition of the first software module. According to an alternative or additional second aspect, the execution logic is configured to perform a sharding operation whereby the physical capability is divided into at least two instances that can subsequently be combined.

Description

Background Art

[0001] Traditionally, an operating system (OS) has the ability to view all data of all applications running on the OS. "View" here means being able to inspect and modify applications can inspect and modify all the same application data from the same (multiple) areas of memory. Similarly, if the OS runs on a management program ("hypervisor"), the hypervisor can view all data of the OS and the applications. This represents a hierarchical trust system, whereby the applications trust the OS, and the OS trusts the hypervisor.

[0002] Recently, the concept of "enclaves" has been introduced, whereby applications can run in confidential environments, which make the application's data inaccessible to the operating system or hypervisor. This eliminates the idea 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 tenants of a data center to keep their data private from the operators of the data center.

[0003] Access to memory may be restricted by a capability system. "Capability" is a field term that refers to an unforgeable digital institutional token that, for example, grants access to a specified memory address range. It is known to provide a capability system implemented 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 a corresponding capability that grants 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 dedicated additions to the processor's instruction set architecture. For example, the source operand of a traditional load instruction would 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 grants access to the target address, thereby adding that capability to the pointer. The capabilities in the register can only be manipulated through dedicated 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 by restricting where capabilities can be stored in memory. Capabilities can only be stored in specific areas, and everything in those areas is either capabilities or explicitly invalid capability values ​​(usually zero). For example, the CAP computer uses this model. The second is to use some form of tag memory where the not-addressable 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) use this model.

[0006] In the existing CHERI system, the capability grants access to a specified range of virtual addresses on the virtual address side of the address translation. As is familiar to those skilled in the art, almost all general-purpose computer systems now use virtual memory. That is, the system includes a page table (usually actually implemented as a tree) that maps between the virtual address space and the physical address space of (multiple) actual physical memory devices. The reason for this is to abstract the address space used by the software from the actual underlying physical memory resources. The target address is specified by the software in terms of the virtual address, and the system automatically uses the page table to convert it into the corresponding physical address. Typically, the conversion is automatically done in hardware by the memory management unit (MMU). The page table can be filled and managed by low-level system code, such as a hypervisor or the kernel of an OS. A translation lookaside buffer (TLB) can also be used to cache page table entries. In a software-managed TLB, the TLB is filled by software traversing the page table (or an equivalent data structure), while in a hardware-managed TLB, the hardware checks the page table to fill the TLB.

[0007] The CHERI capability also provides access to physical memory in 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: an execution logic including one or more execution units, a memory including one or more memory units, and a 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 in respective partitions of the physical address space, including executing a memory access operation performed by a currently executing software module in the software modules. The memory access operation specifies a virtual address in 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 in the physical address space that is mapped to a virtual address, check whether a capability granting access to the physical address is found in a storage location to which the currently executing software module has access, and if the capability is found in the storage location, grant access to the physical address for performing the memory access operation.

[0009] According to one aspect disclosed herein, the execution logic is further configured to perform a linear capability transfer operation that transfers one of the capabilities from a partition of a first software module in the software modules to a partition of a second software module in the software modules without retaining the capability 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 also configured to perform a sharding recombining operation, whereby the instances are recombined.

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

[0012] This summary is provided to introduce a selection of concepts in a simplified form that are 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 to the accompanying drawings, by way of example only, in which:

[0014] Figure 1 This is a diagram of the program stack.

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

[0016] Figure 2It is a schematic diagram of memory address conversion between virtual address and physical address.

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

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

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

[0020] Figure 5 is a schematic block diagram of executing a program in a specified address space according to an embodiment disclosed herein,

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

[0022] Figure 7 is a flow chart of a method of partitioning a memory according to embodiments disclosed herein. DETAILED DESCRIPTION

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

[0024] In the absence of capabilities, specifying the address space is implemented via reverse lookup. After the address translation, the MMU looks up who owns the page. There is usually a flat table with an entry for each physical page, which defines the owner of the page. Sometimes this is done via a mix of hardware and software, where the hardware checks the bit indicating that "the page is secret" and the software implements the invariant that the secret page is owned by a single owner. Alternatively, sometimes it is done entirely in software, with a small portion of trusted software implementing invariants. This gives the same thing that can be expressed with pure linear capabilities: running software can verify that it is the only owner of a given page and that it is not exposed to other things. Compared with table-based methods or hardware-based access control methods, the advantage of linear capabilities is that the lookup only runs in one way, and delegation from one isolated area to another does not need to go through a single trusted entity. Through a hybrid approach, it simplifies verification at the software layer. Another benefit is that it can easily implement pages that are writable by one party and readable by one or more other parties (e.g., a ring buffer of a virtual device).

[0025] According to a second aspect, a system for slicing capabilities that can be split a known number of times is provided. The ability to slice capabilities provides greater flexibility than strictly linear capabilities, but does not allow capabilities to proliferate uncontrollably. Because the system keeps track of the proportion of the original (exclusive) capability of the current slice, the slices can be reconstructed later to restore exclusivity. Preferably, the capability is also only allowed to be divided a limited number of times, so that a given area of ​​physical memory can be shared only between a limited number of applications or other such software modules.

[0026] Sharding can be used advantageously with the concept of linear capabilities. For example, using an 8-bit split field, a page can be shared between up to 256 entities (specified address spaces, isolated VMs, etc.), and each entity can cheaply check the maximum number of other entities that own it. This makes it easy to enforce guarantees such as sharing a page between two specified address spaces or between an isolated VM and a specified address space, but hiding it from the hypervisor. Doing this with a table-based scheme means that each table entry needs to be able to identify all the entities that may have access to the page, which gives you a very large table (and a large lookup cost). Doing this with capabilities allows for simple forward checking.

[0027] The disclosed mechanism makes it possible to build isolated virtual machines (VMs), hardware specified address spaces, etc. It can be used as a standalone mechanism, or 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). On the one hand, linear capabilities are provided that involve adding access to physical memory. Another alternative or additional aspect involves slicing of physical capabilities (limited, recorded partitioning of physical capabilities). Traditional CHERI capabilities use 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 permissions granted by a capability may 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 hypervisors). This makes it possible to implement complex confidential computing designs.

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

[0031] Figure 1 An example program stack 100 of an example application according to the currently disclosed technology is shown. The stack 100 includes multiple 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 (multiple) applications 102AP together form a virtual machine (VM) 103. A hypervisor (also called 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 run 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 to allow an OS to run such that a hypervisor cannot forcefully relinquish resources.

[0033] Figure 2A memory mapping scheme that can be used to facilitate access to memory is shown. The memory 104 includes a physical address space 202 across one or more memory devices, i.e., the actual hardware addresses by which physical memory regions 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. Note that Figure 2 is schematic. In practice, page tables may be implemented in physical memory. Page tables are a protocol for system software to communicate with a memory management unit (MMU). The MMU performs lookups with the help of page tables managed by system software or a trusted trap handler that performs cacheable address translations.

[0035] When a program 102, such as an application 102AP, wants to access memory, such as to perform a load, store, or instruction 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 a hypervisor 102HV or a kernel of an 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 misses is the page table or address translation error handler queried directly. Either way, address translation is performed through some mechanism provided by the MMU, and there is some policy controlling address translation, which is provided by one or more layers of privileged software (as code or data).

[0037] Note: In a scenario with three layers in the stack 100 - the hypervisor 102HV, the operating system 102OS, and the application layer 102AP - in some such embodiments, the operating system may issue a target address in a second-layer virtual address, which is converted to a first-layer virtual address, sometimes also referred to as a pseudo-physical address, and the hypervisor 102HV or MMU converts it to a (real) physical address. That is, the virtual machine 103 may need to perform two address translations. In this case, if the article says that the application specifies a virtual address, etc., this can be considered to mean that the application specifies a first-layer virtual address (pseudo-physical address) instead via the operating system. The physical address refers to the real physical address in the actual physical address space 202.

[0038] More generally, the present application may be applied to any program stack, for example in scenarios involving only an OS 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 a designated address space so that the operating system 102OS and the hypervisor 102HV cannot view the data of an application 102AP, even if the application is running on the operating system. Alternatively, it may be desirable to prevent an application 102APi of one party from accessing the data of an application 102APii of another party, without trusting the OS or hypervisor to prevent this.

[0040] In the traditional model, the hypervisor 102HV partitions out an area of ​​the virtual address space for use by the operating system, and then the operating system 102OS partitions out an area from that memory area for each of the applications 102AP running on the 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 the ability to access all data of the applications 102AP in all memory address spaces allocated to them, and the hypervisor 102HV has the ability to access all data in all address spaces it has allocated to the operating system 102OS. The hypervisor 102HV can also limit what the operating system 102OS has access to, and the operating system 102OS can limit what its applications 102AP have access to. Therefore, there must be a hierarchical trust system between the different layers of the stack 100: the operating system 102OS must trust the hypervisor 102HV, and the application 102AP must trust the operating system 102OS. For example, the hypervisor 102HV may be cracked and snoop on the data of one of the operating system 102OS or the application 102AP, or may be malicious from the beginning.

[0041] It is desirable to change this "nested" model so that each level or layer in the stack 100 can access the memory address space assigned to the next layer, for example, so that the operating system 102OS does not have to fully trust the hypervisor 102HV, and / or the application 102AP that specifies the address space does not have to fully trust the operating system 102OS. Therefore, the concept that a more trusted component always has access to the memory of a less trusted component running on it is no longer necessary, and for example, even if the hypervisor 102HV or the operating system 102OS is compromised, the confidentiality and integrity of the data owned by the application 102AP can be guaranteed. In an embodiment, the hypervisor and OS can still remain in the TCB (trusted computing base) for availability, rather than for confidentiality or integrity. In this case, a malicious hypervisor can still simply choose not to run a particular VM ever, and the VM cannot prevent this from happening. But despite this, using the disclosed mechanism, it is guaranteed that the hypervisor cannot inspect or tamper with the memory owned by the VM.

[0042] The hypervisor 102HV may still be responsible for partitioning out memory for the operating system 102OS, and the operating system may still be responsible for partitioning out memory for its applications 102AP. However, once the partitioning is complete, the hypervisor 102HV does not necessarily have to access the memory it has allocated to the operating system 102OS, and / or the operating system does not necessarily have to access the memory it has allocated to one or more of its applications 102AP. And 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 implemented in hardware. A "capability" is a token that a software module needs 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, access to that memory area is not allowed. This can be achieved by providing only tokens (i.e., "capabilities") to one or more (but not all) software modules running on the system to achieve isolation.

[0044] Physical capabilities are capabilities that operate at the physical memory address level rather than the virtual address level. Only software modules that can present the relevant token (i.e., capability) are allowed to access the corresponding physical memory area. Hardware-implemented capabilities are capabilities for which the check for the capability is implemented 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 the first software module to the second, the first module does not keep a copy. For example, the operating system starts with a capability and then passes the capability to the application. The application now has that capability, but the operating system cannot keep a copy, so the operating system gives up access to the corresponding memory area. With a non-linear capability, the operating system can choose to pass the capability and keep a copy for itself.

[0047] The inventors are unaware of no previous disclosures that provide a capable system having both physical and linear properties.

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

[0049] A "sharded" capability can be divided and therefore shared between different modules of the software (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 therefore be reassembled with each other to reduce the number in circulation. In an embodiment, a capability can also only be divided up to a maximum number of times. Limits on the number of times a capability can be divided are not required. The split count enables the owner of a shard to identify the maximum number of other shard owners. For example, a specified address space may wish to verify that the OS can access a shared area, but the hypervisor cannot. This is possible with a finite split count, and the specified address space has all but one of the shares. If there was an infinitely divisible split count, the two-party case would be the same as the multi-party case (a protocol would be needed to ensure that the cooperating groups all share ratios that sum to 1).

[0050] The inventors are not aware of a system that has been previously disclosed to provide the ability to be 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 slicing, thereby limiting the communication boundaries between different software modules.

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

[0053] Figure 1A An example computer system 150 is shown for implementing embodiments disclosed herein. System 150 includes execution logic 104, memory 106, memory access logic 108, page tables 112, and optional translation lookaside buffers 114. System 150 may also include a capability register set 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 special-purpose processor (e.g., 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 decoding stage, an execution stage, an arithmetic logic unit (ALU), a floating point logic unit (FPU), a load / store unit (LSU), etc. Execution logic 104 is configured to execute an instance of an instruction from a specific instruction set, which is a basic set of machine code types identified by 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] The memory 106 includes one or more physical memory devices 106. The / these may include one or more memory devices on the same die as the execution logic 104, one or more memory devices on different dies in the same IC package, and / or one or more units external to the die and IC package of the execution logic 104. In the case of an execution unit external to the device, the MMU will be used for DMA or the logical MMU will be implemented as multiple physical MMUs to control 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 one or more storage 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 memory; 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 will typically be 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 above. It may be implemented in an area of ​​the memory 106 (e.g., in a special execution program or reserved area of ​​the memory 106) and / or in a separate dedicated memory unit. In an embodiment, the page table 112 also provides a mapping for finding corresponding capabilities for various physical address ranges. Note that although, as a convention in the art, a page table may be referred to as a page "table", it is now more often implemented 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 data structure form for matching between virtual memory addresses and physical memory addresses. The page table may be a completely software structure that forms an implementation detail of the firmware or software that provides the policy to the MMU. More generally, the page table 112 may represent any logic or data structure that implements the memory protection and conversion policies defined in the software and may optionally cache these conversions.

[0058] Execution logic 104 is configured to execute machine code instructions from a predetermined instruction set, which defines a predetermined instruction type set, 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, that is, the source address in the case of loading or the destination address in the case of storage. Typically, the instruction specifies the target address alternatively by indicating the operand of the instruction of the general register in the register file of the execution logic 104, wherein the register then stores the pointer (target address). The target address or pointer will be a virtual address within the virtual address range. Other types of operations will also implicitly operate on the target address in the memory 106, such as fetching instructions from the current program counter (PC) value. PC will specify a virtual address in the virtual address space. Alternatively, in a CISC type architecture, 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 convert a virtual target address to a physical address in the memory 106 when the execution logic 104 executes a memory access instruction. This is done 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 to the physical address in the memory 106. The same is true 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 may be implemented in the form of a dedicated cache unit, such as an associative cache, which may 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 special system register. System registers (also called "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 instructions in a special capability manipulation instruction set, which will be discussed in more detail later. Capability registers 116 can be implemented in execution logic, or as part of an MMU that implements part of memory access logic 108, or as a separate special 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 used explicitly as operands for capability instructions. For example, in a system with a complete CHERI implementation, these registers may be the same as the registers exposed for virtual capabilities.

[0063] The general capability register is tightly coupled to the CPU's pipeline(s), and must therefore be implemented as part of the CPU.A system register typically has write-through behavior, so 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 shown. Note that Figure 2A This is merely illustrative and is not necessarily intended to imply that the physical address space 202 consists of a single range of contiguous addresses. For example, it may represent the address space of more than one physical memory device, and / or a fragmented range of a given device having unusable regions.

[0065] The physical memory 106 / 202 is in the form of a tagged memory. That is, it includes a plurality of words for storing data (i.e., actual data content or payload data), and also includes a corresponding tag bit cascaded with each word. When the corresponding word is part of the capability, the tag bit is asserted (e.g., set to 1), and when the word is available for other data (payload), the tag bit is deasserted (e.g., set to 0). In such an embodiment, checking the capability by the hardware enforcement mechanism implicitly includes checking the tag bit, wherein each capability is valid only when the tag bit is asserted. In an embodiment, the tag bit is not addressable except by the executive program code running in the executive program mode. In addition, if any of the above words is loaded from the memory, the tag bit is propagated with it. Such a feature helps to ensure that these capabilities act as unforgeable authorization tokens to grant access to their corresponding specified memory address ranges. This creates a strict provenance chain and makes the physical capabilities unforgeable.

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

[0067] However, marked memory is not required. As described in the Background section, capabilities are protected in memory, and a hardware memory capability system can do this in at least two ways. The first approach is to restrict the locations where capabilities can be stored in memory. Capabilities can only be stored in specific areas, and everything in those areas is either capabilities or explicitly invalid capability values ​​(usually zero). For example, CAP computers use this model. The second approach is to use some form of marked 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 M-Machine and some other systems) use this model. The system disclosed in this article can support the former approach if specific areas are marked within the address space execution program as storing capability tables (although this would be a slightly weaker model since access to capabilities would be forgeable).

[0068] Figure 3 Capability registers 116 are shown. They may include a single root capability register 302 and an additional set of capability registers 304, also referred to herein as "universal" capability registers. Note that Figure 3 It is a schematic, and does not rule out the possibility of a merged register file (where there is overlap between general-purpose and power 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 to which it grants access. It may also include other parameters, such as one or more types of permissions it grants (e.g., read, write, and / or execute).

[0070] Figure 6 An example form that a data structure 600 of capabilities according to embodiments disclosed herein may take is shown. Capabilities 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 in physical address space 202. In the example shown, the address field specifies the range in terms of a low address and a high address of the address range. However, for example, the range may alternatively be specified in terms of a low address and an additive offset, or a high address and a subtractive offset. Regardless of how this is represented, this is the corresponding address range in physical address space 202 to which the corresponding capability grants 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 permission 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, which is used to record the number of times the corresponding capability has been fragmented. This will be discussed in more detail later.

[0073] Capabilities act like tokens or "bearer bonds" that are used to gain access to a program. Only software modules that possess a given capability can access the physical address range specified by that capability. For a given software module, "having" a capability for the present purpose means that the capability is stored in a storage location that the software module can access. This storage location can be a register, or another memory area, or both. This will be discussed in more detail later.

[0074] With linear capabilities, tokens or "tickets" are moved around without copying operations. The sharding operation can be thought of as an extension of the linear concept, allowing for access to partial capabilities. This is similar to sharding capabilities by range or into different permission sets.

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

[0076] In an embodiment, each partition 400 may include a corresponding base area 402 and a corresponding non-executable program 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 program area 404 may include a single range of continuous addresses or multiple ranges that are not continuous with each other. Corresponding capabilities grant access to each range.

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

[0078] The executive area 402 is implemented in a memory area 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 presented 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 the capability has only one owner and the owner has exclusive access to the address range of the capability). This ensures that no other part of the system can access the memory. The capability is then used and a (copyable) entry capability is created. When the executive is called, the root capability register will include a capability with the same permissions 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 user space / supervisor / manager privilege levels.

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

[0080] Many existing architectures have a privileged mode, called supervisor mode (or ring 0 for x86). In an embodiment, an address space executes a program mode that is different from an existing privilege level such as supervisor mode, and is used to manage code for memory regions containing software that will use one or more of the privilege levels. For example, a specified address space will only use user mode, an isolated VM 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" simply refers 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. The 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 certain proportion of the hypervisor or OS (i.e., providing memory isolation and sharing, and a set of interfaces for secure configuration sharing, which is very small). Non-executable program 102 can refer to any non-executable program that does not run in executive mode. This can be an application 102AP, an operating system 102OS, or a hypervisor 102HV.

[0082] The non-executable program data 405, non-executable program 102 and address space executable program 403 of each partition 400 together form a partitioned module of software 401. Module 401 includes different programs 102APi, 102APii, 102OS, 102HV, etc. which can be kept secure from each other by 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 memory of the process. Similarly, an isolated VM may have exclusive access to its own memory, and shared access to the portion it uses for communication. Typically, the system supports a single entity with memory, where portions are completely private, shared with a single other party, or shared with multiple other parties but not shared with all. A partition that includes at least some exclusive memory may be referred to as a "designated address space," but note that this term is not always used consistently in the art.

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

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

[0086] Also note, Figure 4 A partition 400 is shown which may refer to an address space, 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 may also be employed in the embodiments disclosed herein. This mechanism is orthogonal to the existing privilege mechanism in the CPU and therefore will allow an isolated region to have only user space, user space + supervisor, or even user space + supervisor + hypervisor privilege levels.

[0087] Figure 5 An example data structure of an address space executive 403 is shown. This includes multiple fields, including at least a memory access table 508 and a portion of an executable executive code 510. One or more capabilities of the non-executable program area 404 of the corresponding partition 400 are stored in the memory access table 508. 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 the program state of the address space executive, and / or a key field 506 for storing one or more keys required when 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 represent the user space concept of a thread, and may be closer to the VM abstraction of a virtual CPU, on which the system (e.g., OS) in 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 functions, such as revocation policy, e.g., specifying whether a capability may be revoked by the hypervisor 102HV or the operating system 102OS.

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

[0090] Access is allowed if one of the following conditions is met: 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 that there is a direct correspondence between root capabilities and code running with the privileges of the address space executor, but this is not required (it simply simplifies certain aspects of the implementation). Similarly, the requirement that linear capabilities never leave the memory allocated to the address space executor is intended to simplify verification of the code and prevent capabilities from being accidentally corrupted, rather than being a core part of the model.

[0091] The check for capabilities is performed by the memory access logic 108 (and the results of the check are implemented). The check may be implemented, for example, by dedicated hardware circuitry in the MMU or by low-level trusted firmware or executive software, or a combination thereof (e.g., the hardware may 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 instruction set of the execution logic, such as a single load or single store instruction. For efficiency, in an embodiment, the results of the check will also be cached in hardware (e.g., TLB 114), regardless of how it actually occurs.

[0092] The root capabilities in the root capabilities register 302 grant access to the base address area 402 including the address space executor 403. The memory access table 508 in the address space executor 403 includes zero or more additional capabilities that grant access to one or more additional address ranges that make up the corresponding non-executor area 404 (it may be that the isolated area consists only of software running in the base area 402 and running with the address space executor privileges - unlikely to be common, but it may be useful for some lightweight trusted agents running in this mode). When the address space executor 403 of one module of software 401 calls another module of software 401, a domain transition is performed to transition from one partition 400 to another (for example, the hypervisor calls the OS or the OS calls the application). At the time of the domain transition, the root capabilities in the root capabilities register 302 are replaced with the root capabilities of the address space executor 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 execution program 403 of the called module 401, so that the new address space execution program starts running. The address space execution program 402 can then jump to any location in the non-executable program area 404 in the corresponding program 102 based on having one or more corresponding capabilities for the area in its corresponding memory access table 508. The address space execution program 403 or the non-executable program 102 can also access data 405 from anywhere in the non-executable program area 404 based on having one or more corresponding capabilities for the area in the corresponding memory access table 508.

[0093] Preferably, the instruction set of execution logic 104 includes one or more special purpose capability manipulation instructions, i.e., special purpose 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 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, some or all of the instructions may be non-privileged instructions, but can only be used with valid capabilities, so that 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 manipulation instructions may include any, multiple, or all of the following: a partition creation instruction (e.g., EnclaveCreate) for creating a partition; a partition call instruction (e.g., EnclaveCall) for calling an address space executor 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 split 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 split, or permission split capabilities (this may be the same instruction type for all of these, or different types for different types of recombinations). Alternatively, for some architectures, such as those that wish to avoid microcode, 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 the partition 400 of both. Linear transfer means that the capabilities are transferred from the partition 400 of one software module 401 to the partition 400 of the second software module 401 without being retained in the partition of the first software module. In the illustrated embodiment, this means that the capabilities are transferred 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 being retained in the memory access table of the first software module.

[0096] Capabilities can also be sharded. Linearity is a property of how a capability can be transferred (i.e., movement is allowed without copying), sharding is a property of the things that are moved. Sharding defines additional ways to split up linear capabilities. A capability can be split (sharded) into two parts (shards), and then potentially 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 full capability. The linearity property of the sharded parts guarantees that no other entity retains a copy of the capability. Any number of split and combine operations can be performed between the initial split and the final recombination, but the linearity property of all of them must be respected.

[0097] One of the shards 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 partition 400 and the second partition 400 (source and destination) have one of the shards. 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 be shared but only between a limited number of modules 401 that have one of the capability shards in the capability shards.

[0098] According to one aspect disclosed herein, the sharding operation also implicitly modifies the split count value 606 to record the proportion of each resulting sharded capacity that is the original unsharded (i.e., exclusive) capacity, and the proportion of the original exclusive capacity that it is. This split count allows the sharded capacity to be reassembled again later so that exclusivity can be restored, and memory sharing does not have to be indefinite or unlimited.

[0099] For example, in one possible encoding, consider an 8-bit split count field, which can be represented using a 1 bias. That is, so the representable values ​​are 1 to 256 (having a 0 scale of capability does not make sense because that would not make sense), a value of 256 represents full ownership (no sharding at all), a value of 128 represents half of the original capability, and so on, with a value of 1 representing 1 / 256 of the original capability. In this encoding, reassembly requires only addition (splitting requires subtraction).

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

[0101] The split operation performs a split based on scope or permission to give two capabilities that are disjoint subsets of the rights of an initial capability. Slicing provides two capabilities with the same permissions as the original but with a smaller split ratio (the sum of the split ratios is the same as the original). Combining provides a single capability that has the sum of the rights held by both parties. Atomic exchange moves a pair of capabilities between registers and memory locations (if one is an empty capability, this is equivalent to performing a load or store of linear attributes). EnclaveCreate consumes the full capability (full split ratio, all permissions) and provides entry capabilities, which then allows the system to reconstruct the full capability using the execution program bit set in the root register. The execution program bit prevents any software from moving the capability out of the root capability register until it is destroyed for the specified address space. The specified address space destruction implicitly invalidates all entry capabilities of the specified address space and reconstructs the full capability into memory. There is a revocation mechanism for entry capabilities, which will be discussed in more detail later.

[0102] When reassembling a shard or splitting a capability, the reassembled parts can be equal, but it is also possible to reassemble two unequal parts. Any split operation (whether by shard, permission, or range) 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 the capabilities of the memory access table base area 508 in the base area 402 of at least the current execution module 400 can be stored in the general capability register 304. (Multiple) root capability registers 302 are used for basic lookups. The additional (general) capability registers 304 are used as a place to manipulate capabilities for the execution program code and to store capabilities when capabilities are transferred between domains. Capabilities from the basic area are not stored in these registers and memory at the same time. Instead, software can move capabilities between the basic area (or, if software policy allows, other memory) and these registers. The additional capability registers 304 can therefore maintain the capabilities of loading and storing from memory to memory for manipulation by the execution logic 104. However, they do not maintain a copy at the same time as the memory, because the copy will violate the linear property.

[0104] In an embodiment, general purpose 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 an embodiment, the EnclaveCall instruction (or, more precisely, the storage of capabilities in registers 304 during an EnclaveCall) is a mechanism for transferring capabilities linearly between partitions, but each load, store, split, or combination is also linear. EnclaveCall swaps the root capabilities and provides the entry 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 EnclaveCall. If it is desired to send more than one different non-contiguous capability to a specified address space or partition before the call; if the system has enough capability registers, these capabilities can all be placed as register parameters and then the EnclaveCall is executed to call the target. If there are not enough registers, multiple calls may be required to pass all capabilities.

[0106] As an alternative or in addition to using EnclaveCall, other implementations may provide other mechanisms for performing linear transfers of capabilities, such as dedicated linear transfer instructions for transferring linear capabilities from one specified address space / partition to another specified address space / partition. Performing this operation 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 may also be done asynchronously (without any dedicated hardware support) by providing capabilities to a buffer shared between the two executors and using it as a ring buffer to store other capabilities.

[0107] Figure 7 4 is a flow chart showing a method of booting the system 100, partitioning the physical address space 202, and allocating corresponding capabilities between different software modules 401 running in different partitions 400. This will be based on Figure 1 The illustrated scenario is illustrated in which 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, for example, without a 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 (at least the entire protected address space if only part of the address space is protected by the capability 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 to cover 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 by jumping to an address within the hypervisor 102HV's address space executive 403. The hypervisor's executive 403 may then jump to its non-executable program code 102HV, and / or create and call a partition for 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 address space executive 403 for the operating system 102OS, and allocates corresponding capabilities covering the 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 including the operating system 102OS. This includes: switching the root capability in the root capability register 302 to the root capability of the basic area 402 of the operating system, and jumping to an address within the address space executive 403 of the operating system 102OS. The executive 403 of the OS can then jump to its non-executable program code 102OS, and / or create and call partitions for one or more applications 102AP.

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

[0114] At step 740, the operating system 102OS or its executive program 403 calls the software module 401 including the application 102AP. This includes: switching the root capability in the root capability register 302 to the root capability of the basic area 402 of the application, and switching by jumping to an address within the address space executive program 403 of the application 102AP. The executive program 403 of the application 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 an embodiment, the capability register 304).

[0116] Notice, Figure 7 It is not implied that all of these steps are required in all possible situations. They are only required if each level in the system (hypervisor, OS, and applications) requires isolation. For example, an executor can be launched for the OS and run isolated from the hypervisor, but the application is not forced to be isolated from the OS. This may be a common use case (e.g., a cloud customer trusts the OS it deploys, but does not trust the hypervisor provided by the cloud operator). The address space executor 403 is only required for components that do not want to rely on a hierarchical trust relationship in which they are strictly less trusted than the components that allocate resources to them.

[0117] Some examples of operations that can be performed on capabilities are 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 described above, the root capability is used for the current address space executive. At the time of domain transition, it is replaced with the capability of the target executive in the root capability register 302. A domain transition is a call between two isolated address spaces. In an embodiment, it is the result of the EnclaveCall instruction. Note that a trusted hypervisor can call the OS (and the OS can call a trusted hypervisor), and a trusted OS can call an application, and vice versa, without going through an executive. Cross-domain calls are only required between mutually untrusted parties (e.g., a hypervisor and an isolated VM, an OS, and a user space specified address space).

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

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

[0121] ii) using one or more capability splitting instructions in a series of capability splitting instructions to refer to the physical capability of the region from the root capability,

[0122] iii) Issue an EnclaveCreate instruction with the capability to give the "entry capability", then

[0123] iv) Issue EnclaveCall instruction.

[0124] For subsequent isolated regions, a similar sequence may be performed, but step ii) involves directly using one of the physical capabilities stored in the address space executive's memory access table 508. EnclaveCreate takes full linear capabilities for the region and constructs the entry capabilities. In an embodiment, it also generates an initial proof that can be used to verify that the initial state of the executive is running trusted code.

[0125] Entry capability is a term from the existing capability system. It is a capability that grants the right to call (enter) specific code, but cannot inspect it. Entry capability implements domain transition. Once an executive for an isolated address space is created, some mechanism is needed to call it. It needs to be able to grant the right to call the executive without granting the right to directly access any of its information. This is the entry capability. It can be used as an operand to EnclaveCall. The hardware will check if it is valid, and if so, construct the specified address space capability (a linear capability that sets bits to prevent it from being removed from the root capability register except during executive teardown ("teardown")). Once entry capabilities exist, some mechanism is needed to invalidate (revoke) them so that when the executive is destroyed, the initial linear memory capabilities can be reconstructed without violating linear invariants. In an embodiment, entry capabilities are not linear, they provide a mechanism to allow multiple isolated units to all call each other. In alternative embodiments, entry capabilities can be linear, but they can also have different revocation mechanisms. Either way, entry capabilities have some revocation mechanism. One possible revocation mechanism involves having additional pre-specified address space tag bits and a revocation counter at the beginning of the executive. If non-executable code is not allowed to maintain direct access capabilities, the same linear mechanism can be used, although this will complicate the disassembly process (to destroy an isolated region, all access capabilities to it must be restored).

[0126] To call a partition (e.g., specify an address space) 400, the EnclaveCall instruction acts like a jump and link register instruction. The caller is responsible for placing any parameters (including capabilities) into registers. The callee executor will typically have a dispatcher check the caller and some equivalent vtable index and then jump to the correct location.

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

[0128] EnclaveCall has entry capability and:

[0129] i) Check whether the access capability is valid.

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

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

[0132] a. If it is an execution program capability, an entry capability is constructed from it and placed in the capability link register, but

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

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

[0135] In order to slice the capability, the capability slice instruction may take the following form, for example:

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

[0137] Where $cd is the capacity destination register, $cs is the capacity source register and $rs is the integer source register. This will deduct the value in $rs from the split ratio field in $cs and construct a capacity in $cd that is the same as the original value of $cs with the split ratio field set to the value in $rs. If $rs is greater than the split share in $cs, it will give an empty capacity in $cs and the original capacity in $cd (or vice versa - both are equivalent for the model).

[0138] Similarly, a command of this form:

[0139] CSplitRange$cd、$cs、$rs

[0140] Split $cs into two components, split based on the offset into the address range provided in the $rs register.

[0141] Another instruction of this form:

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

[0143] The same thing can be done to fetch the permission set from $cs into $cd.

[0144] To regroup the range splitting or license splitting capabilities, in an embodiment, there may be a single CCombine instruction of the form:

[0145] C combination $cd, $cs1, $cs2

[0146] This will check if $cs1 and $cs2 are adjacent and have the same permissions and split ratios, the same range and permissions but different split ratios, or the same range and split counts but different permissions, then the values ​​in $cs1 and $cs2 will be replaced with nothing and the combined capabilities will be placed in $cd.

[0147] To reassemble the sharded capabilities, this can also be done using a single CCombinine instruction or using separate instructions for combining permissions, split counts, and ranges.

[0148] Capability manipulation operations are atomic. That is, one thread cannot perform only a partial update to a capability before switching to another thread. That is, moving or modifying a capability is an indivisible operation. For example, interrupting in the middle of a capability operation should not allow partial state to be observed. Preferably, this is implemented in hardware.

[0149] A mechanism may also be provided for disassembling a partition (eg, a specified address space) 400. The policy to allow this may be specified in the address space executive 403.

[0150] Based on the various possibilities discussed above, there is therefore provided a set of extensions to an architecture that provides CHERI-like capabilities that would allow for partitioning of address spaces such as SGX-like specified addresses. Both SGX and CHERI facilitate partitioning, but the threat models are quite different. SGX assumes that trusted applications attempt to protect themselves from untrusted OS and / or hypervisors. CHERI assumes that mutually untrusted components of an application attempt to protect each other to run on a trusted OS. It is desirable that an application can be protected from both at the same time. The present disclosure provides various embodiments for achieving this.

[0151] Some additional exemplary implementation details are now set forth below, again by way of illustration only.

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

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

[0154] As a first possibility, the capabilities are stored by the address space executive in a structured form. The OS updates the traditional page table to reference the physical address and an additional phase at the end of the page table walk checks the structure and verifies if the capabilities of the represented address range are held by the address space executive of the currently executing component.

[0155] As a second possibility, the capabilities are stored in a flat table by the address space executive, and the leaf page table entry includes an index into that table and an offset within that capability. The page table walker then has the simpler additional step of checking that this is a valid capability and that the offset in 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 a single virtualization level in the current implementation.

[0156] The first possibility is more complex, but does not require modifying the OS to understand the mechanism. The second possibility does require modifying the OS to understand the mechanism, but has the advantage of less complexity.

[0157] An address space executive is code that is trusted for all privilege levels of code it directly manages. Malware running in an executive is unlikely to violate the isolation guarantees enforced by the hardware. Individual executives can decide whether to trust other executives based on their attestation offers ("quotes"). If an executive fails to disable interrupts, it may lose its own capabilities, but it cannot steal capabilities of others. If the executive receiving the capabilities does not perform proper TLB invalidations, the sending region may be able to access memory (temporarily), but again, a flawed designated address space can only compromise its own security. The hypervisor trusts any running designated address spaces for some availability guarantees (i.e., they will not accidentally destroy capabilities, making some memory inaccessible until the system is rebooted).

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

[0159] 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, broadcast TLB invalidations to ensure there are no stale references to owned capability sets in other parts of the system).

[0160] Sharding adds a controlled sharing mechanism to this. The page table walker performs the same capability checks when installing TLB entries, but now the two address space executors can communicate the fact that, between them, they can interpret all references to a page, and therefore it is shared by them but not by any other entity in the system. For example, a fenced VM and a userspace specified address space can share pages that the hypervisor cannot see.

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

[0162] The hardware enforces a strict provenance tree for all kinds of capabilities: capabilities cannot be created from scratch, they can only be constructed by allowing operations on existing capabilities. The set of operations for linear capabilities is slightly different, in that 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.

[0163] Steering Figure 1 In the possible implementation of the system diagram shown, 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 not be practical. There are a number of different possible implementations of the data structure of the page table 112, such as a flat table lookup, a tree, etc. Roughly speaking, the MMU uses two mechanisms (in which at least part of the memory access logic 108 can be implemented).

[0164] The first mechanism uses a software managed TLB 114. These are used on MIPS and early SPARCs (newer SPARCs are a mix). When the CPU encounters a TLB miss, it passes an exception and some system code installs a new TLB entry. Implementing the idea with a software TLB would pass the exception to the address space executive, which would issue a TLB fill instruction to represent the (physical) address in memory in linear capabilities. The CPU would then check if the physical address is within the executive (by checking the bounds in the address space executive capabilities register), load the capabilities, and then install the TLB entry.

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

[0166] In the first option of a hardware-managed TLB, software running within the isolated region is aware of the isolation mechanism. In this case, the address space executive manages a simple indexed data structure (e.g., an array) of physical capabilities, and the software within the region maintains a set of page tables (or equivalent). In a traditional page table, the last hop provides the physical address of the start of the page and the set of permissions. In this model; however, the last step is an index into a data structure managed by the translation. From a security model perspective, the page table is untrusted: only the last check (of the 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 a specified address space executive that are used during page table walks.

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

[0168] The third option is a slight variation of the second option for the userspace specified address space model. This variation has a single level of page tables managed by the executive for the specified address space and provides some interfaces for the OS to add mappings of untrusted memory. From a hardware perspective, this is the same as the second option, the only difference is that the software running in the specified address space executive has some interfaces to allow delegating certain pages exclusively and delegating certain pages as shared regions and external APIs to allow the OS to update the page tables for shared regions.

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

[0170] The registers are an architectural abstraction, while the TLB 114 is (mostly) 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 that capability"). For a hardware managed TLB, it is populated implicitly by the page table walker (in a software managed TLB, it is populated explicitly in response to an interrupt).

[0171] In principle, this model could be implemented without utilizing 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.

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

[0173] At system startup, before entering the first address space execution program, disable any second level translation and simply check all memory accesses against this capability. There are mechanisms that can guide the first address space execution program to manage these capabilities. This includes:

[0174] 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,

[0175] ii) carve out the area from the initial capabilities, and

[0176] iii) Start the address space to execute the program and provide it with access to the rest of the memory.

[0177] The EnclaveCall instruction will provide the root capabilities (in the system registers or the general capabilities registers) of the caller to the callee in one of two cases:

[0178] - If the root capability is an address space executive capability, the callee will receive the entry capability for the specified address space.

[0179] - If the root capability is a linear physics capability, the callee will receive that capability.

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

[0181] The MMU is responsible for enforcing all of these guarantees, although 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 may be stored in the MMU, and a write to this architectural register is an implicit message to the MMU.

[0182] 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 ("closure") of the capabilities reachable from the root capability register.

[0183] 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:

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

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

[0186] iii) The page table walker checks the root capability to find the location of the program executing in the specified address space;

[0187] iv) A page table walker traverses down the page table (usually a tree) to check if each entry is within the region identified by the root capability;

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

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

[0190] vii) Load instruction successful.

[0191] If any capability check fails, the CPU will pass an exception to the address space executor, which can then forward it to another executor.

[0192] This is slightly more complicated in the case where there are page tables in the specified address space. 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 needs to be run to check the access (this is how nested paging works on current CPUs, with capability checks added at the last level).

[0193] The root capability is for the current address space executive. On domain transition, it is replaced with the target executive's capability. It cannot be fetched except through a specified address space teardown (see below). Once an entry capability is created, any code that has a copy of the capability can call into the specified address space. The address space executive will explicitly convert its specified address space capabilities to normal linear physical capabilities and pass them to another executive during a specified address space teardown.

[0194] Each software module 401 runs its own partition (e.g., specified address space) 400, which is a memory address subspace including a basic area 402 and a non-executable program area 404. The basic area includes at least the executable program of the corresponding software component. The software component itself (e.g., application) is stored in the non-executable program area 404.

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

[0196] To set up and run a partition (e.g., a specified address space), this involves the hypervisor or OS executing the EnclaveCreate instruction. The EnclaveCreate instruction converts a linear physical capability into an entry capability. This is a destructive operation, consuming a linear capability (and requires the capability to be unsharded - i.e. it has exclusive ownership of the memory and all permissions). Initially, only the entity that creates the specified address space will have a copy of the entry capability, so only that entity can call it. Copies of the entry capability may be delegated elsewhere. Permission to create a specified address space is granted if any of the following occurs:

[0197] The root power is a linear physical power, or

[0198] Root capability is the executive capability of the address space and the currently executing software is in executive mode.

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

[0200] Another non-contiguous address space can be added to the specified address space / partition later. To do this, another software component (hypervisor or another component, such as OS or another application) provides one of its capabilities to the partition / specified address space in question. This is a simple EnclaveCall, passing the delegated capabilities in the general capability register. This involves a swap operation to load them from the specified address space that owns them. If the caller wants to share memory, the caller will slice the capabilities before passing it to another specified address space.

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

[0202] The target's entry capability is the operand of the EnclaveCall instruction. This causes a branch to be executed to a predetermined address of the executing program in the address space / partition specified by the destination. In an embodiment, it will always jump to a specific fixed address in the executing program. In some other embodiments, it may take an integer operand and jump to the entry point identified by that index, as a performance optimization. Either way, the executing program may decide to build a thread-like abstraction on top, or just acquire the mutex, or fail to acquire the mutex and return.

[0203] 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., OS or application). In some implementations, it may be beneficial to have explicit instructions for jumping out of the executable.

[0204] Corrupting a specific address space is called a "teardown". A specific address space teardown relies on a trusted entry point in the specific address space executable. This can only be called by one of a small set of entry capabilities provided during the creation of the specific address space, usually only the hypervisor.

[0205] As mentioned above, once entry capabilities exist, some mechanism is needed to invalidate (revoke) them so that when the executor is destroyed, the original linear memory capabilities can be reconstructed without violating linear invariants. This can be built on top of the linear 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 call into the executor to the number of shards supported by the system. If every VM wants to be able to call into the hypervisor, then every VM needs the ability to enter the hypervisor. With an 8-bit split count, this limits you to 256 VMs. The second problem is that when the executor is torn down, the only way to invalidate linear capabilities is to collect them. This requires a lot of communication to identify all the places where linear capabilities end up and hand them back.

[0206] Therefore, in the preferred design, revocation is achieved by a unique number stored in the entry capability and the start of the execution program in memory. The entry capability is only valid if this number matches, so all entry capabilities can be invalidated (revoked) by changing this number in memory. There is also a tag check. Without the tag check, it is possible to build memory areas that the system thinks are execution programs and reuse existing entry capabilities, building duplicate linear capabilities in the process and violating the invariants of the system. The start of the designated address space has a coarse-grained (e.g., one per page) tag to indicate that it is the start of the execution program.

[0207] Therefore, the executive can be disassembled by increasing the counter value, which invalidates all entry capabilities, forces all other kernels running in that executive to terminate, and then clears the specified address space bits in the register and the EnclaveCall (which passes the current root capability in the capability link register as a normal physical capability).

[0208] To destroy the specified address space in this design, the tag bit is cleared to invalidate any existing entry capability from being called, while ensuring that exactly one thread is active. This is sequenced by calling the teardown entry point in the specified address space. This calls the specified address space executor code, which will first clear the tag to ensure that no core that is not already running specified address space code can do so. It will then send an IPI to all other cores running specified address space code to ask them to call the hypervisor. Once all other running threads have notified the teardown thread that they have exited, the teardown thread will zero all physical memory associated with the specified address space, clear the specified address space bit in its base physical capability, and finally call the hypervisor.

[0209] Embodiments may also employ a certification mechanism. When the hypervisor fills the executive program area 402 with the code of the designated address space executive program, the code is trusted by both the hypervisor and the designated address space. After the designated address space is created, no code other than the code in this section can modify anything in the basic area of ​​the designated address space. The trust of the hypervisor comes from the fact that it provides the code. The designated address space owner trusts the code because it is part of the certification offer and can therefore be verified as the agreed designated address space executive program image. This code replaces a large amount of unverified secret microcode in SGX.

[0210] The system can perform attestation as a two-stage process. The hardware (microcode or small coprocessor) will generate an attestation quote for each SAM executable image to specifically state that it has created a SAM with a specific version at a specific address, and that it is running an executable with a specific hash. For remote attestation, this will also include a signature of a public key generated by the SAM executable. This is not necessary for local attestation because the SAM base address and its version are embedded in the entry capabilities.

[0211] Because it runs with interrupts disabled and all entry and exit events are instrumented, the specified address space execution program code can generate subsequent certification quotes for software running in the specified address space.

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

[0213] More generally, the present disclosure relates to a system comprising: execution logic including one or more execution units; a memory including 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 executing a memory access operation performed by a currently executed software module among the above software modules, the memory access operation specifying a virtual address in 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 in the physical address space that is mapped to a virtual address, check whether a capability granting access to the above physical address is found in a storage location to which the currently executed software module has access, and if the capability is found in the storage location, grant access to the above physical address for performing the above memory access operation.

[0214] 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 corresponding memory partition of the currently executing module.

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

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

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

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

[0219] According to the first aspect of the present disclosure, the execution logic is also configured to perform a linear capability transfer operation, which transfers one of the capabilities from a partition of a first software module in the above-mentioned software modules to a partition of a second software module in the above-mentioned software modules without retaining the capability in the partition of the first software module.

[0220] According to an alternative or additional second 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 also configured to perform a sharding reassembly operation, whereby the instances are reassembled.

[0221] 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 division is recorded in the corresponding split count value of each instance; and wherein the recombination 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 recombination capability.

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

[0223] In an embodiment, a source software module in 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 in the software modules. 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. In order to enable reassembly, the instances may all be transferred back to the partition of the same software module. In an embodiment, all transfers of shard instances may be linear.

[0224] In an embodiment, the capacity transferred by the above-mentioned linear capacity operation can be an instance of the above-mentioned sharding instance.

[0225] 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 are in the loop.

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

[0227] 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, for example, one or more other software modules of the above software modules. In an embodiment, at least one of the software modules may include a hypervisor on which at least one operating system runs, for example, which may also be one of the above software modules.

[0228] Note that in the case of a three-layer stack of application, operating system, and hypervisor ((multiple) applications 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 through 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 above-mentioned determination of the mapping through mapping from the pseudo-physical address to the (real) physical address.

[0229] Each respective software module has access to the physical address range of its respective partition. Since these capabilities both grant access to memory and are stored in memory, mechanisms can be provided to direct access. There are many possible mechanisms for this, which can be used individually or, more preferably, together.

[0230] For example, in an embodiment, each of the partitions may include a corresponding basic area, and the memory access logic is configured to perform the above check at least by checking whether the ability to grant access to the above physical address is found in the basic area of ​​the currently executing software module.

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

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

[0233] In an embodiment, each of the software modules may include a corresponding address space executive program, which is a part of the executable executive program code for managing the corresponding partition, and the corresponding address space executive program is stored in the corresponding basic area of ​​the corresponding software module and is fetched from the corresponding basic area.

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

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

[0236] The capability of each of the above basic areas may be stored, for example, in the form of a memory access table. The above checking of the basic areas may include checking the memory access table of the currently executing software module.

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

[0238] In an embodiment, root capabilities may grant access to base areas of the currently executing software module.

[0239] In an embodiment, the memory access logic may be configured to perform the above-mentioned check by checking whether the capability to grant access to the above-mentioned physical memory address is found in either the root capability register or the base area of ​​the currently executing software module, and granting access if the capability to grant access to the physical memory address is found in either the root capability register or the base area of ​​the currently executing software module.

[0240] In an embodiment, a calling software module in the above-mentioned software modules may be configured to: perform a calling operation to call another called software module in the above-mentioned software modules, and perform a domain transition when doing so, the domain transition switching the root capability in the above-mentioned root capability register from the root capability of the calling software module to the root capability of the called software module.

[0241] Due to the disclosed capability system, neither the calling software module nor the called software module can access the internal state of the other (ie, data or code in the partition of the other).

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

[0243] In an embodiment, the above call may be performed by the address space execution program of the calling software module; and / or, the above call may include a jump to the address space execution program of the called software module. In some such embodiments, the above jump may include a jump to a predetermined point in the address space execution program of the called module, for example, a jump to a predetermined instruction address in the base area. Alternatively, the point to jump to may be specified.

[0244] Once called, the address space execution program of the called module can then jump to the corresponding program in the corresponding other area of ​​the partition.

[0245] In an embodiment, before the above-mentioned call, the calling software module or another software component in the above-mentioned software components may be configured to initially create one of the above-mentioned partitions in which the called software component is running (e.g., specifying an address space) by setting a basic area of ​​the called software component. The creation may be performed by the address space execution program of the above-mentioned calling or other software module.

[0246] 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 the granting of access to the physical address is further conditioned on the permission type being read. If the memory access operation is a store operation, then the granting of access to the physical address is also conditioned on the permission type being write. If the memory access operation is an instruction fetch or branch operation, then the granting of access to the physical address is also conditioned on the permission type being execute.

[0247] As an alternative or additional feature to sharding, in another embodiment, the execution logic can be configured to perform a range splitting operation, whereby: a parent capability (which specifies a larger address range) in a partition of a software module (e.g., the first module described above or the source module described above) is divided into two sub-capabilities, which specify a smaller address range, which is an exclusive fragment of the larger address range. At least one of the sub-capabilities can be transferred to a partition of another recipient software module in the software module (e.g., the second module described above or the destination module described above). This transfer can be implemented in a linear or sharded manner. In some such embodiments, the execution logic can be configured to perform a range reassembly operation, whereby the sub-capabilities are reassembled into a reassembled capability with a larger range. The reassembled capability can be placed in a partition of the initial software module, the recipient, or another software module in the software module.

[0248] 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,

[0249] In an embodiment, the instruction set may include one or more memory access instruction types, and the above-mentioned memory access operations and the above-mentioned operations of the memory access logic may be invoked by a single instance of a single memory access instruction of the above-mentioned memory access instructions.

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

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

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

[0253] In further alternative or additional embodiments, the above-mentioned slicing operations may be at least partially invoked by one or more instances of one or more of the above-mentioned capability manipulation instruction types.

[0254] In an embodiment, the above-mentioned slice reassembly operation can be at least partially called by one or more instances of one or more capability manipulation instruction types among the above-mentioned capability manipulation instruction types.

[0255] In an embodiment, the above call may be at least partially invoked by one or more instances of one or more of the above capability manipulation instruction types.

[0256] In an embodiment, the above-mentioned split range operation may be at least partially invoked by one or more instances of one or more capability manipulation instruction types among the above-mentioned capability manipulation instruction types.

[0257] In an embodiment, the above-mentioned range regrouping operation may be at least partially invoked by one or more instances of one or more of the above-mentioned capability manipulation instruction types.

[0258] In an embodiment, one or more of the capability manipulation instructions may take as an operand an indication of one or more of the capability registers described above.

[0259] In a further embodiment, the system may include a plurality of further capability registers for holding capabilities loaded from at least a base region of a currently executing software module. The address space executive may be arranged to use the further capability registers to store capabilities upon domain transition, and / or to use the further capability registers as operands for one or more of the capability manipulation instruction types.

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

[0261] In a further embodiment, the memory is divided into a plurality of words for storing data and includes a respective tag bit connected to each word. The tag bit is arranged to be asserted when the respective word is part of a capability and to be deasserted when the word is available for other data. In such an embodiment, the above-mentioned check may include checking the tag bit, wherein each capability is only valid when the tag bit is asserted; and / or, in an embodiment, the tag bit is not addressable except by an executive program code running in an executive program mode; and / or, if any of the above-mentioned words is loaded from the memory, the tag bit is propagated therewith.

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

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

[0264] Other variations or use cases 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: A memory, comprising a memory unit; an execution module comprising an execution unit, wherein the execution module is arranged to run a plurality of software modules each in a respective partition of a physical address space of the memory, including performing a memory access operation specifying a virtual address in a virtual address space as a target of the memory access operation; wherein the execution module is further configured to perform a linear capability transfer operation that transfers a capability from the partition of a first software module of the plurality of software modules to the partition of a second software module of the plurality of software modules, the capability being a digital token that grants access to a physical address in the physical address space that is mapped to the virtual address, wherein the linear capability transfer operation removes the capability from the partition of the first software module; 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 memory access module is configured to perform the following operations: finding the physical address in the physical address space, confirming that the capability granting access to the physical address is found in a storage location to which a currently executing software module of the plurality of software modules has access, and Access to the physical address is granted for performing the memory access operation.

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

3. The system of claim 2, wherein the base area of ​​each software module is implemented in a protected executive area of ​​the memory, the protected executive area being accessible only by executive-level code running in a privileged executive mode of the execution module.

4. The system of claim 2, wherein each of the partitions includes a corresponding additional area of ​​the physical address space in addition to the corresponding base area, wherein capabilities in the corresponding base area grant access to the corresponding additional area.

5. The system of claim 2 , wherein each of the plurality of software modules comprises a corresponding address space executive, the corresponding address space executive being a portion of an executable executive code for managing the corresponding partition, the corresponding address space executive being stored in the corresponding base area of ​​the corresponding software module and being fetched from the corresponding base area.

6. The system of claim 5 , wherein each of the partitions includes a corresponding additional area of ​​the physical address space in addition to the corresponding base area, wherein capabilities in the corresponding base area grant access to the corresponding additional area, and wherein each of the plurality of software modules includes a corresponding program in addition to the address space execution program, the corresponding program being stored in the corresponding additional area of ​​the corresponding partition and being fetched from the corresponding additional area.

7. The system according to claim 1, comprising: A root capability register, used to store the root capability of the currently executed software module; as well as The memory access module is configured to perform the confirming by at least confirming that the capability granting access to the physical address is found in the root capabilities register.

8. The system of claim 7 , 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 that the capability granting access to the physical address is found in the base area of ​​the currently executing software module, wherein the root capability grants access to the base area of ​​the currently executing software module.

9. The system of claim 7 , wherein each of the partitions comprises a corresponding base region, and the memory access module is configured to perform the confirmation at least by: confirming that the capability granting access to the physical address is found in the base region of the currently executing software module, wherein the memory access module is configured to perform the confirmation by: confirming that the capability granting access to the physical address is found in either the root capability register or the base region of the currently executing software module, and granting access if the capability granting access to the physical address is found in either the root capability register or the base region of the currently executing software module.

10. The system of claim 7, 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 transition, the domain transition 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.

11. The system of claim 1 , wherein a capability specifies one or more types of permissions: read, write, and / or execute; At least one of the following: If the memory access operation is a load operation, the granting of access to the physical address is further conditioned on the permission type being a read, If the memory access operation is a store operation, the granting of access to the physical address is further conditioned on the permission type being a write, or If the memory access operation is an instruction fetch or a branch operation, the granting of access to the physical address is further conditioned on the permission type being execute.

12. The system of claim 1, wherein: The execution unit 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; as well as The execution unit is also configured to perform a shard reassembly operation, by which the instances are reassembled into a reassembled capability based on the corresponding split count values, and a reduction in the number of instances is recorded in the split count value of the reassembled capability.

13. 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 at least one of the following: The instruction set comprises memory access instruction types, and the memory access operations and the operations of the memory access module are invoked by a single instance of a single one of the memory access instructions; or The instruction set includes a capability manipulation instruction type, and the linear capability transfer operation is at least partially invoked by an instance of the capability manipulation instruction type.

14. The system of claim 10 , wherein each of the partitions comprises a corresponding base area, and the memory access module is configured to perform the confirmation by at least: confirming that the capability granting access to the physical address is found in the base area of ​​the currently executing software module, wherein each of the plurality of software modules comprises a corresponding address space executive, the corresponding address space executive being part of an executable executive code for managing the corresponding partition, the corresponding address space executive being stored in and fetched from the corresponding base area of ​​the corresponding software module, the system further comprising an additional capability register for storing the capabilities loaded from at least the base area of ​​the currently executing software module; Wherein the address space execution program can use at least one of the further capability registers to store capabilities upon domain transition, or can use the further capability register as an operand of at least one capability manipulation instruction type.

15. The system of claim 1, wherein the plurality of software modules comprises at least one of the following: application; an operating system on which the application is arranged to run; or Management program.

16. The system of claim 1, wherein the linear capability transfer operation prevents at least one of the first software module or a third software module of the plurality of software modules from accessing the physical address.

17. A computer-implemented method comprising: Using the execution module to execute a plurality of software modules each in a corresponding partition of a physical address space of a memory includes performing a memory access operation that specifies a virtual address in a virtual address space as a target of the memory access operation; performing, using the execution module, a linear capability transfer operation to transfer a capability from the partition of a first software module of the plurality of software modules to the partition of a second software module of the plurality of software modules, the capability being a digital token that grants access to a physical address in the physical address space that is mapped to the virtual address, wherein the linear capability transfer operation removes the capability from the partition of the first software module; and Use the memory access module to: finding the physical address in the physical address space, confirming that the capability granting access to the physical address is found in a storage location to which a currently executing software module of the plurality of software modules has access, and Access to the physical address is granted for performing the memory access operation.

18. The computer-implemented method of claim 17, wherein the capability to grant access to the physical address comprises a hardware-enforced capability.

19. The computer-implemented method of claim 17, wherein each of the partitions comprises a corresponding base area and a corresponding additional area of ​​the physical address space other than the corresponding base area, the base area of ​​each software module being implemented in a protected executive area of ​​the memory, the protected executive area being accessible only by executive-level code running in a privileged executive mode of the execution module.

20. A hardware memory device comprising software implemented on a computer readable medium and comprising code configured to, when executed on a processor, perform a method comprising: Using the execution module to execute a plurality of software modules each in a corresponding partition of a physical address space of a memory includes performing a memory access operation that specifies a virtual address in a virtual address space as a target of the memory access operation; performing, using the execution module, a linear capability transfer operation to transfer a capability from the partition of a first software module of the plurality of software modules to the partition of a second software module of the plurality of software modules, the capability being a digital token that grants access to a physical address in the physical address space that is mapped to the virtual address, wherein the linear capability transfer operation removes the capability from the partition of the first software module; and Use the memory access module to: finding the physical address in the physical address space, confirming that the capability granting access to the physical address is found in a storage location to which a currently executing software module of the plurality of software modules has access, and Access to the physical address is granted for performing the memory access operation.

Images