Segmented non-contiguous reverse map table

Abstract

The computing device (200) comprises a processor (202), a table walker (230), and a memory (204) that stores a reverse map table (242) segmented into multiple non-contiguous portions of memory. The table walker is configured to translate a virtual memory address specified by a memory access request into a physical memory address associated with the virtual memory address, and to provide a requestor associated with the memory access request with access to the associated physical memory address in response to an indication in the reverse map table that the requestor is authorized to access the associated physical memory address.

Description

[Background technology]

[0001] Some computing devices run virtual machines (VMs), which are software entities that emulate or otherwise interface with the hardware of the computing device to provide support for running software programs. For example, a virtual machine may use hardware elements (processor, memory, network interfaces, etc.) within the computing device to provide support for running one or more instances of an operating system (OS), called a guest operating system. The guest operating system, in turn, provides support for running other software programs, such as applications and databases.

[0002] Some computing devices run two or more virtual machines simultaneously (e.g., in parallel on one or more processing cores in corresponding time slices). In such computing devices, each virtual machine may have access to hardware resources allocated exclusively for the virtual machine's use. For example, each virtual machine may be allocated a corresponding region of memory within the computing device for the virtual machine's exclusive use. In these computing devices, a first virtual machine may be prevented from accessing a region of memory allocated to a second virtual machine, and vice versa. In some of these computing devices, a hypervisor (also called a VMM, virtual machine monitor, or virtual machine manager) enforces access control for each virtual machine. A hypervisor is a software entity that runs / executes on a computing device and acts as a manager or controller for virtual machines running on the computing device. For example, the hypervisor may start or initialize virtual machines, control access of computing device hardware by virtual machines, terminate or close virtual machines, etc. Summary of the Invention [Means for solving the problem]

[0003] In one embodiment, a method for processing memory accesses in a computing system includes receiving a memory access request that specifies a virtual memory address; identifying a physical memory address associated with the virtual memory address; determining whether a requestor associated with the memory access request is authorized to access the associated physical memory address based on a segmented reverse map table stored in a non-contiguous portion of physical memory of the computing system; and, in response to determining that the requestor is authorized to access the physical memory address, providing the requestor access to the identified physical memory address; and otherwise preventing access to the identified physical memory address.

[0004] The segmented reverse map table may include an RMT segment index that includes multiple index entries, each corresponding to one of multiple segments of the RMT stored in non-contiguous portions of physical memory.

[0005] Each segment of the multiple segments includes multiple segment entries, each corresponding to a distinct physical address.

[0006] A computing system may run one or more virtual machines each assigned a portion of physical memory such that a segment entry for a plurality of segments includes the entirety of the physical memory assigned to the one or more virtual machines.

[0007] The physical memory of the computing system may include a plurality of non-uniform memory access (NUMA) memory nodes such that each segment of the plurality of segments maps to a respective NUMA memory node, and at least one segment of the plurality of segments may be stored on a respective NUMA memory node mapped by the at least one segment.

[0008] The RMT segment index may further include an RMT counter table that includes one or more counters each associated with one or more encryption keys.

[0009] Identifying the physical memory address may be performed by a table walker of the computing system. The requestor may be an input / output (I / O) device communicatively coupled to the computing system, and the table walker is a hardware table walker associated with an I / O memory management unit (IOMMU) of the computing system.

[0010] The requestor may be any of one or more VMs executing on a computing system each assigned a respective plurality of physical memory addresses.

[0011] In one embodiment, a computing device may include a processor, a table walker, and a memory that stores a reverse map table (RMT) segmented into multiple non-contiguous portions of memory. The table walker is configured to receive a memory access request specifying a virtual memory address, identify a physical memory address associated with the virtual memory address, determine whether a requestor associated with the memory access request is authorized to access the associated physical memory address based on the segmented reverse map table, and, in response to determining that the requestor is authorized to access the physical memory address, provide the requestor access to the identified physical memory address, and otherwise prevent access to the identified physical memory address.

[0012] The segmented reverse map table may include an RMT segment index including a plurality of index entries each corresponding to one of a plurality of segments of the RMT stored in non-contiguous portions of memory, and each of the plurality of segments may include a plurality of segment entries each corresponding to a distinct physical address in memory.

[0013] A computing device may run one or more virtual machines, each allocated a portion of memory, and a segment entry for a plurality of segments includes the entirety of the memory allocated to one or more virtual machines.

[0014] The memory may include a plurality of non-uniform memory access (NUMA) memory nodes such that each segment of the plurality of segments maps to a respective NUMA memory node, and at least one segment of the plurality of segments may be stored on a respective NUMA memory node mapped by the at least one segment.

[0015] The RMT segment index further includes an RMT counter table that includes one or more counters, such that each of the one or more counters is associated with one or more encryption keys.

[0016] The computing device further includes an input / output (I / O) memory management unit (IOMMU), the requestor is an I / O device communicatively coupled to the computing device, and the table walker is a hardware table walker associated with the IOMMU.

[0017] The computing device further includes one or more virtual machines executing on the computing device, each assigned a respective plurality of physical memory addresses, such that the requestor is any of the one or more virtual machines.

[0018] In one embodiment, a computing device is configured to store a reverse map table (RMT) segmented into multiple non-contiguous portions of a memory having multiple physical memory addresses, the segmented RMT including RMT segment indexes each including a plurality of index entries corresponding to one of the multiple segments of the segmented RMT stored in the non-contiguous portions of the memory; translate a virtual memory address specified by a memory access request into a physical memory address associated with the virtual memory address; and provide access to the physical memory address associated with the requestor in response to an indication in the segmented RMT that a requestor associated with the memory access request is authorized to access the associated physical memory address.

[0019] The present disclosure may be better understood, and its numerous features and advantages made apparent to those skilled in the art by referencing the accompanying drawings, in which: The use of the same reference numbers in different drawings indicates similar or identical items. [Brief explanation of the drawings]

[0020] [Figure 1] FIG. 1 is a block diagram illustrating a virtual machine and a hypervisor, according to some embodiments. [Figure 2] FIG. 1 is a block diagram illustrating a computing device according to some embodiments. [Figure 3] FIG. 10 illustrates a reverse map table RMT including an RMT segment index and n RMT segments according to some embodiments. [Figure 4] FIG. 10 is a block diagram illustrating an expanded view of an exemplary RMT segment, according to some embodiments. [Figure 5] FIG. 1 is a flow diagram of an operational routine suitable for processing memory access requests in a secure computing system, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0021] Although the hypervisor is supposed to provide access control to virtual machines, the hypervisor does not always properly enforce the access control. For example, the hypervisor's program code may be replaced with malicious program code, may be corrupted, or may contain errors. In such cases, the hypervisor may intentionally or unintentionally allow a virtual machine to access computing hardware allocated to another virtual machine. For example, in some computing devices, the hypervisor is responsible for providing address information to enable a virtual machine to access data in a corresponding region of memory. In these computing devices, the hypervisor provides translation between the local and / or virtual addresses used by the virtual machine (or software running thereon) and the physical address where the data is actually located in memory. If the hypervisor is not functioning correctly, the hypervisor may provide incorrect address information, thereby instructing the virtual machine to access data in an unexpected or unwanted region of memory (e.g., a region of memory allocated to another virtual machine). As described, by providing incorrect address information, the hypervisor may cause data to be accessed in violation of one or more access controls or rules.

[0022] In addition to the address translation provided by the hypervisor being used by virtual machines, in some of these computing devices, address translation is also used by input / output (IO) devices to access pages of memory assigned to a particular virtual machine. For example, when interacting with a virtual machine, input / output (I / O) devices (disk controllers, network interface devices, Peripheral Component Interface Express (i.e., PCIe) bus devices, graphics processing units (GPUs), etc.) perform direct memory access (DMA) operations to write data to one or more pages of memory assigned to the virtual machine. Similar to the operations involving the virtual machine described above, operations performed by I / O devices can be maliciously or accidentally misdirected if the hypervisor provides incorrect address information.

[0023] As described herein, a computing device uses virtual memory to handle data accesses by programs executing within the computing device or by input / output (IO) devices interacting with the computing device. For example, the programs being executed may include applications, operating systems, device drivers, virtual machines, firmware, etc. Generally, when data is accessed by a program or I / O device within a computing device, a block or page of memory of a predetermined size (e.g., 4 kB, 2 MB, etc.) containing the data is copied from mass storage (e.g., a disk drive or semiconductor memory) to an available physical location in memory within the computing device, or is newly created in memory. To avoid programs and I / O devices having to track the physical location of pages in memory, the computing device tracks the physical location of pages for the program or I / O device. Instead of accessing memory using an address based on the physical location (or physical address) of the page, the program and I / O device access memory using a virtual address within a virtual address space, which is a local address space specific to the corresponding program or I / O device. From the perspective of a program or an I / O device, a virtual address indicates the actual physical location where data is stored in memory, and memory accesses are performed by the program and I / O device accordingly using the virtual address. However, the virtual address may not directly map to the physical address of the physical location where the data is stored in a page in memory. As part of keeping track of the physical location of pages, the computing device translates the virtual addresses used by the program and I / O device in memory access requests into the physical address where the data is actually located. The computing device then performs memory accesses for the program and I / O device using the physical address.

[0024] To enable translation from virtual addresses to physical addresses, computing devices include page tables. A page table is a record stored in a computing device's memory that includes entries, or page table entries, having virtual-to-physical address translation information for pages of data stored in the memory. In other words, a page table includes a mapping of virtual addresses to corresponding physical addresses. Upon receiving a request from a program or an I / O device to access memory at a given virtual address, the computing device obtains the corresponding physical address information from the page table by performing a page table walk, during which the page table is searched for a page table entry that provides the physical address associated with the virtual address. Because such page table walks are relatively slow, it is desirable to avoid performing page table walks whenever possible.

[0025] Accordingly, a computing device includes a translation lookaside buffer (TLB), which is a local cache used to store a limited number of copies of address translation information (i.e., information based on page table entries) obtained during a page table walk. For example, a processing core, an input / output memory management unit (IOMMU) through which an I / O device accesses memory, or an I / O device may include a corresponding TLB for locally storing copies of information based on page table entries. During operation, a processing core, an IOMMU, or an I / O device first attempts to retrieve a cached page table entry from the corresponding TLB to perform a virtual-to-physical address translation. If a copy of the corresponding page table entry is not present in the TLB (i.e., a miss occurs), the processing core or IOMMU performs a page table walk to retrieve the desired page table entry and caches the retrieved copy of the page table entry in the TLB.

[0026] A secure virtual machine architecture provides hardware resources that enable a single physical machine to efficiently run multiple operating systems while maintaining secure, hardware-enforced isolation. A hypervisor or virtual machine manager (VMM) controls the execution of multiple guest operating systems on a single physical machine by securely intercepting and emulating sensitive guest VM actions, such as modifying page tables that could give a guest VM access to memory it is not authorized to access or accessing peripheral devices shared among multiple guest VMs. A page table is a data structure used by a virtual memory system to store mappings between virtual and physical memory addresses. The VMM provides each guest VM with the appearance of complete control over the complete computer system (memory, central processing unit (CPU), and all peripheral devices). A guest VM may have one or more virtual CPUs (vCPUs) managed by the guest OS, similar to a non-virtualized system, and the VMM may run any combination of vCPUs from the same or different guests on different logical processors substantially simultaneously.

[0027] In certain secure computing systems, code and data associated with an encrypted VM are secured such that decrypted versions of that code and data are only available within the VM itself. Each encrypted VM is associated with a unique encryption key, so that if the data is accessed by different entities using different keys, the encrypted VM's code and / or data may be decrypted with the wrong key, resulting in incomprehensible results. In such secure computing systems, the managing VMM can no longer inspect or modify all guest code or data. The VM may mark data memory pages as either private or shared, thus allowing selected pages to be shared outside the encrypted VM. Private memory is encrypted using a VM-specific key, and shared memory is accessible to the VMM. Such measures provide VM memory integrity protection to help prevent hypervisor-based attacks that rely on guest data corruption, aliasing, replay, and various other attack vectors.

[0028] In embodiments described herein, a Reverse Map Table (RMT) is used to enforce data integrity protection for encrypted VMs. The RMT is checked by both the CPU and IOMMU during a page table walk to determine whether a page can be accessed. In particular embodiments, the RMT is used to ensure that the hypervisor (and / or another entity within the computing device) does not remap the translation from guest physical addresses to system physical addresses in a nested page table. The RMT contains information that can be used to, among other things, determine whether a system physical address obtained during a table walk of a nested page table of guest physical addresses matches a previously used system physical address. In other words, the RMT ensures that the system physical address of a given page in memory matches only one guest physical address at a time and is used to control access by I / O devices and virtual machines to pages in memory allocated to the virtual machine.

[0029] By using RMT, the described embodiments enable detection of potentially malicious or erroneous modifications of nested page tables. Preventing such modifications of nested page tables can improve the security of virtual machine data within a computing device by preventing the hypervisor (and / or another entity) from improperly remapping guest physical addresses to system physical addresses to instruct a virtual machine to access (e.g., read, overwrite, execute, etc.) data in unknown, unwanted, or incorrect regions of memory (including regions of memory allocated to other virtual machines). Thus, the use of RMT improves data security by enforcing rules such as: each page in memory is only allowed to be associated with a single / unique guest physical address (guest physical address aliasing is not allowed); and: in-use private guest pages cannot be remapped without involving / informing the corresponding virtual machine, as described herein. Furthermore, alone or in combination with other techniques, such as encryption of virtual machine memory regions and protection of virtual machine processor state (e.g., registers, etc.), the described embodiments avoid the need for implicit trust in the hypervisor, which simplifies management of computing devices and improves security. The described embodiments therefore improve the security, operational stability, and value to consumers of computing devices.

[0030] In conventional implementations, a single RMT table occupies a single contiguous memory region for the entire system. Such implementations are associated with several drawbacks. For example, using a single contiguous memory region for RMT can result in over-allocation of RMT in certain memory configurations, such as when the system address space is non-contiguous. Thus, if a computing system with 512 GB of RAM in each of two partitions contains non-contiguous DRAM addresses (e.g., 0 to 512 GB and 1 TB to 1.5 TB), a relatively large RMT must be allocated to cover the entire non-contiguous address space (e.g., a 6 GB RMT allocation to cover addresses 0 to 1.5 TB), even though there may be sizable holes in that address space (e.g., a 512 GB hole between 0.5 and 1 TB). As another example, a single contiguous RMT region is virtually unaware of non-uniform memory access (NUMA), where memory access times depend on memory location relative to the processor. This can result in long latency RMT accesses during page table walks and uneven DRAM utilization, as RMT may consume only a portion of the memory on one NUMA node, resulting in correspondingly less memory available to that node.

[0031] The embodiments described herein provide a segmented RMT architecture such that the RMT table itself is partitioned in memory and does not need to reside in a single, physically contiguous location. In particular embodiments utilizing segmented RMT, a single segment index describes multiple RMT segments, each corresponding to a particular range of physical addresses. The size of the segments is configurable, allowing flexibility in various system configurations. Because the RMT table may be partitioned in memory and no longer needs to occupy a single, physically contiguous location, the segmented RMT architecture avoids the need to over-allocate RMT memory when non-contiguous address spaces exist, making RMT more efficient in the context of non-uniform memory access.

[0032] In certain embodiments, the segmented RMT is resized during runtime (i.e., during operation, without a system reinitialization process) when physical memory is added or removed "hot." In such embodiments, the segmented RMT is expanded to protect memory added to the system in this manner, such as by using unallocated RMT segment indexes. Furthermore, since existing memory (memory in the system before the addition of the new memory) may already be fully allocated, memory for the new RMT segment may be allocated within the newly added (and therefore unallocated) memory. When such memory is removed during operation, the segment is updated to be invalidated accordingly.

[0033] In a specific embodiment, the RMT contains two components: a first component contains a counter used to enforce security properties when changing encryption keys, and a second component contains an entry for each page of memory. All CPUs in the system point to the same RMT memory.

[0034] 1 shows a block diagram illustrating virtual machines and a hypervisor, according to some embodiments. In the illustrated embodiment, three virtual machines (VMs) 100 each run a guest OS 102 and one or more programs 104, such as a database, software applications, etc. The virtual machines 100 communicate with a hypervisor 106, which interfaces between a host OS 108 and the virtual machines 100. The host operating system 108 provides an interface between computing device hardware 110 and the hypervisor 106. Additionally, in some embodiments, an IOMMU 112 interfaces between I / O devices 114 and the virtual machines 100, such as for direct-mapped I / O devices.

[0035] 1, the invention is not so limited, and other arrangements of these and other elements are utilized in various embodiments. For example, in some embodiments, there is no host OS 108, and the hypervisor 106 communicates directly with the computing device hardware 110. As another example, there may be a different number of virtual machines 100, or the IOMMU 112 may interface between two or more virtual machines 100 and the I / O devices 114.

[0036] In the illustrated embodiment, guest operating system 102, IOMMU 112, I / O devices 114, and hypervisor process memory requests using virtual memory techniques. Accordingly, a hierarchy of page tables (not shown in FIG. 1 ) is maintained within the computing device. Within the hierarchy of page tables, guest operating system 102 and I / O devices are associated with local page tables (e.g., guest page tables or input / output page tables (IO page tables)), and hypervisor 106 is associated with nested page tables. During operation, using a virtual machine as an example, upon receiving a request from the processor for a translation from a virtual address used by a program executing under the guest operating system to a system physical address, a hardware table walker (e.g., circuitry configured to perform page table walks, not shown) performs the translation using the guest page table and the nested page table. More specifically, the table walker uses the guest page table to translate the virtual address used by the program to a guest physical address, which is an address local to the guest operating system. Because the guest physical address may not map directly to a location in memory where the data (or instructions, etc.) accessed by the program is stored, the table walker uses nested page tables to translate the guest physical address to a system physical address, which is an address that indicates the actual location in memory where the data is stored. Once the system physical address is obtained, the table walker provides the system physical address for use in accessing the data. The translation to the system physical address may be cached in a TLB.

[0037] In particular embodiments, operations similar to those described above with respect to the translation operations of a virtual machine are performed by a hardware IO table walker in an input / output memory management unit (IOMMU) to translate an I / O device virtual address into a system physical address for use in accessing data in pages of memory. For example, the IO table walker may obtain a system physical address to enable an I / O device to perform a direct memory access (DMA) operation to write data to one or more pages of memory allocated to the virtual machine. More specifically, for the translation operation, the IO table walker performs a walk in an IO page table to obtain a guest physical address associated with the I / O device virtual address. The IO table walker then uses nested page tables to translate the guest physical address into a system physical address, which is an address that indicates the actual location in memory where the data is stored. Upon obtaining the system physical address, the IO table walker uses the system physical address to access memory. The IOMMU may also cache the translation to the system physical address in a TLB in the IOMMU.

[0038] In described embodiments, the hypervisor may perform various operations on the information in the nested page tables. For example, the hypervisor may update (i.e., overwrite) the mapping of guest physical addresses to system physical addresses. As described below, the described embodiments perform operations to ensure that the information in the nested page tables is not modified by the hypervisor (maliciously, accidentally, etc.) in a way that would cause the hypervisor to provide incorrect mappings / translations.

[0039] In described embodiments, pages in a computing device's memory may be "private" pages allocated for the exclusive use of a given virtual machine among multiple virtual machines executed by the computing device. In these embodiments, I / O devices (e.g., disk controllers, network interface devices, PCIe bus devices, etc.) are permitted, in certain circumstances, to access private pages of memory to enable interaction with the virtual machine to which the pages are allocated. For example, a disk controller may access pages of memory to write data destined for the corresponding virtual machine or a software program running thereon. In described embodiments, various operations are performed by an input / output memory management unit (IOMMU) and other functional blocks within the computing device to ensure that pages allocated to a virtual machine are protected from unwanted access by I / O devices. For example, described embodiments include a reverse map table (RMT) used to control access by I / O devices and virtual machines to pages in memory allocated to a virtual machine. As another example, in described embodiments, data in a virtual machine's pages may be encrypted so that only I / O devices with a designated key can encrypt / decrypt the data to enable access.

[0040] In some embodiments, the one or more other checks of the information in the reverse map table include checking information in an entry in the reverse map table that indicates whether the I / O device, or a corresponding virtual machine having an identifier, such as that used by the I / O device when accessing the corresponding page, is authorized to perform the requested access in the page of memory. For example, in some embodiments, the entry in the reverse map table includes a recorded guest identifier (ID) that identifies the virtual machine to which the page is allocated. In some embodiments, the I / O device provides an identifier (e.g., a Peripheral Component Interface (PCI) bus / device / function or BDF identifier) ​​at boot time or another time, and the IO table walker, upon receiving an access request from the I / O device, uses the I / O device identifier to look up the guest ID in a mapping table in which the IOMMU maintains a mapping from I / O device identifiers to guest IDs. If the recorded guest ID and the guest ID associated with the I / O device from the mapping table do not match, the page is currently recorded as being assigned to a different virtual machine than the one associated with the I / O device, and the IO table walker determines that a system physical address should not be provided for use in performing the requested access of the I / O device. In this case, the IO table walker stops / fails the translation and signals an error message or failure to the I / O device. In some embodiments, there may be additional checks of the information in the reverse map table to determine whether the I / O device is authorized to perform the requested access. If all checks pass, e.g., if the recorded guest ID and the guest ID associated with the I / O device match, the IO table walker determines that a system physical address can be provided for use in performing the requested access of the I / O device.

[0041] 2 is a block diagram illustrating a computing device 200, according to some embodiments. In the illustrated embodiment, computing device 200 includes a processor 202, memory 204, mass storage 206, input / output (IO) devices 208 and 210, and an input / output (IO) hub 212.

[0042] Processor 202 is a functional block that performs computational operations in computing device 200. In the illustrated embodiment, processor 202 includes two processing cores 214, 216, each of which includes one or more computing mechanisms, such as a central processing unit (CPU), a graphics processing unit (GPU), an embedded processor, an application-specific integrated circuit (ASIC), and / or other computing mechanisms. Processor 202 also includes cache memory (or cache) that is used to locally store data and instructions used by processing cores 214, 216 to perform computational operations. In the illustrated embodiment, the cache in processor 202 includes level 1 (L1) caches 218, 220 (L1 218 and L1 220) in each of processing cores 214, 216. Each L1 cache includes memory circuitry such as one or more of static random access memory (SRAM), dynamic random access memory (DRAM), double data rate synchronous DRAM (DDR SDRAM), and / or other types of memory circuitry for storing data and instructions used by the corresponding processing core 214, 216, and control circuitry for handling accesses of the data and instructions stored in the memory circuitry. Processor 202 further includes a shared level 2 (L2) cache 222 that includes memory circuitry such as one or more of SRAM, DRAM, DDR SDRAM, and / or other types of memory circuitry for storing data and instructions used by both processing cores 214, 216, and control circuitry for handling accesses of the data and instructions stored in the memory circuitry. Processor 202 further includes a shared level 3 (L3) cache 224 that includes memory circuitry, such as one or more of SRAM, DRAM, DDR SDRAM, and / or other types of memory circuitry for storing data and instructions used by both processing cores 214, 216, as well as control circuitry for handling accesses of data and instructions stored in the memory circuitry.

[0043] Processor 202 further includes a platform security processor (PSP) 226. Platform security processor 226 comprises processing cores, ASICs, and / or other functional blocks for performing security operations in computing device 200. Generally, platform security processor 226 is considered secure against malicious or erroneous behavior of hardware and software entities and may therefore be used within computing device 200 to secure operations that are susceptible to such behavior. For example, platform security processor 226 may perform operations related to enabling a trusted execution environment (TEE) within computing device 200, such as performing cryptographic operations (e.g., key generation, encryption / decryption of data, etc.), registration and / or authentication of hardware and software entities, etc. In some embodiments, platform security processor 226 performs at least some of the operations described herein to control access by virtual machines and I / O devices to pages in memory 204.

[0044] Memory 204 is memory within computing device 200 (e.g., “main” memory) and includes memory circuits such as one or more of DRAM, DDR SDRAM, non-volatile random access memory (NVRAM), and / or other types of memory circuits for storing data and instructions used by functional blocks within computing device 200, as well as control circuitry for handling access of data and instructions stored in the memory circuits.

[0045] In the illustrated embodiment, computing device 200 includes mass storage 206, which may include one or more of mass semiconductor memory (non-volatile semiconductor memory, such as flash memory or NVRAM), a disk drive (e.g., a hard drive), an optical drive, and / or other data storage hardware that stores data and instructions used by computing device 200. In various embodiments, mass storage 206 holds data and instructions that are retrieved and stored in memory 204 for later use by functional blocks within computing device 200. For example, data and / or instructions may be retrieved from mass storage 206 in blocks or pages of a predetermined size (e.g., 4 kB, 2 MB, 1 GB, etc.), and the pages may be stored in memory 204. Additionally, pages may be newly created in available physical locations within memory 204 (e.g., to store computation results, etc.). Pages retrieved from mass storage 206 and stored in memory 204 may be reserved for exclusive access by a particular virtual machine and / or may have other access requirements (e.g., restrictions on access types, etc.).

[0046] In the illustrated embodiment, memory management unit (MMU) 228 is a functional block that processes memory access requests. When data and instructions are to be accessed by a functional block within processor 202 (i.e., read, written, checked / verified, deleted, invalidated, etc., by processing core 214 or another functional block), the functional block sends the memory access request to memory management unit 228. Memory management unit 228 then sends a corresponding request to one or more of L2 cache 222, L3 cache 224, and memory 204 for fulfillment / resolution of the memory access request. For example, if data is to be retrieved based on the memory access request, memory management unit 228 may obtain the data from L2 cache 222, L3 cache 224, or memory 204 (or mass storage 206 if the data is not present in L2 cache 222, L3 cache 224, or memory 204) and transfer the data to the requesting functional block.

[0047] In the illustrated embodiment, memory management unit 228 includes a hardware table walker (TW) 230. Table walker 230 is a functional block that performs operations related to retrieving address translations from page tables (e.g., page table walks, etc.) and checking reverse map tables to ensure that access by a virtual machine is permitted, as described herein. More specifically, as described above, computing device 200 uses virtual memory to enable software programs (e.g., executed by processing cores 214, 216) to access memory using virtual addresses that are translated to physical addresses. Upon receiving a memory access request from a program with a virtual address, table walker 230 performs operations to translate the virtual address into the physical address of the page where the data is located in memory 204.

[0048] In some embodiments, table walker 230 (and, more generally, memory management unit 228) uses two mechanisms to perform virtual-to-physical address translations. The first mechanism is a hierarchy of page tables, including a page table associated with each virtual machine and a nested page table associated with the hypervisor. Examples of page tables are shown in FIG. 2 as guest page table 232 and nested page table 234 associated with a virtual machine (e.g., VM 100 of FIG. 1 ) and a hypervisor (e.g., hypervisor 106 of FIG. 1 ), respectively. Each page table is a data structure (e.g., one or more tables, arrays, lists, etc.) stored in memory 204. For example, guest page table 232 may be stored in reserved memory region 236 (shown using dashed lines) allocated for exclusive access of the corresponding virtual machine. In some embodiments, a given page table stores at least one translation for each page present in memory 204 that has been stored in memory 204 by a corresponding program, virtual machine, etc. Thus, in these embodiments, when a page is copied from mass storage 206 to memory 204 or newly created in memory 204 and remains available in memory 204, the associated virtual to physical address translation must be present in the corresponding page table. As described above, table walker 230 uses guest page table 232 and nested page table 234 to perform virtual to physical address translations.

[0049] In some embodiments, when translating a guest physical address to a system physical address based on an access request from an I / O device (e.g., I / O devices 208, 210) to access a page of memory, IO table walker 246 of IOMMU 244 performs a table walk of nested page table 234 to obtain the system physical address from the corresponding entry in nested page table 234. It is unknown whether the nested page table (and therefore the corresponding entry) has been modified, and therefore it is unknown whether the system physical address properly maps to the guest physical address in the corresponding entry. Therefore, IO table walker 246 performs various checks in RMT 242 to ensure that the system physical address specified in the corresponding entry properly maps to a guest physical address and that the requesting I / O device is permitted to access the corresponding page. For example, in particular embodiments, IO table walker 246 determines whether the entry in RMT 242 (corresponding to the system physical address) has a recorded guest physical address that matches the guest physical address from the request. If the recorded guest physical address from the RMT does not match the guest physical address from the request, the system physical address is improperly mapped to the guest physical address in the nested page table 234, in which case the IO table walker 246 stops or fails the translation and responds by signaling an error message or failure to the requesting I / O device 208, 210. On the other hand, if the guest physical addresses match, the system physical address is properly mapped to the guest physical address in the nested page table 234. Once the system physical address is properly mapped, the results of one or more other checks of the information in the RMT 242 are used to determine whether the system physical address should be used to perform the requested access to the I / O device.

[0050] A second mechanism for performing virtual to physical address translations is the translation lookaside buffers 238, 240 (TLBs 238, 240), which are caches in each of the processing cores 214, 216 configured to store / cache virtual to physical address translation information obtained during page table walks. The processing cores 214, 216 obtain virtual to physical address translation information from the corresponding TLBs 238, 240 to avoid performing page table walks when possible.

[0051] Computing device 200 includes multiple portions of memory 204 allocated for use as reverse map tables 242. In particular, in the illustrated embodiment, RMT 242 includes a single RMT segment index 241 and multiple RMT segments 243. Each allocated portion of RMT 242 is a data structure (e.g., a table, a list, etc.) that includes several entries, as described in more detail below. For ease of explanation, the description herein will generally refer to such data structures as tables, although it should be understood that any suitable data structure may be utilized.

[0052] In particular embodiments, RMT 242 includes a single RMT segment index 241 that maps all of multiple RMT segments 243 (e.g., up to 512 such segments), which collectively include one entry for each page of memory in memory 204 that may be allocated for use by one or more virtual machines. For example, if memory 204 includes 32 GB of memory that may be allocated to virtual machines in 4 kB pages, then reverse map table 242 includes a total of 8,388,608 entries stored across RMT segments 243. Reverse map table 242 is used by a hypervisor (e.g., hypervisor 106 of FIG. 1 ) and other entities to maintain records that, at least in the illustrated embodiment, include information indicating the guest physical address associated with the system physical address, the permission level for accessing the virtual machine, the validation of the page by the virtual machine, the immutable page, and / or other information associated with the corresponding page. In this way, computing device 200 maintains records that can be used to detect when changes are made to nested page tables 234 and otherwise protect pages of memory from unauthorized access by virtual machines and / or I / O devices. Reverse map table 242 is described in more detail below.

[0053] In some embodiments, the hypervisor is prevented from directly accessing reverse map table 242. For example, reverse map table 242 may be stored in a memory region that is not directly accessible by the hypervisor and / or may be marked as immutable in reverse map table 242 (e.g., the page in which reverse map table 242 is stored in memory may itself be marked as immutable). As another example, reverse map table 242 may be encrypted in a format that cannot be directly decrypted by the hypervisor. In some embodiments, reverse map table 242 is stored in one or more regions of memory that are not directly accessible to the hypervisor and are unencrypted. Although “direct” access to reverse map table 242 is not permitted by the hypervisor, the hypervisor may cause other elements or entities (such as a processor) within computing device 200 to perform operations on the table and use the information in the table. For example, dedicated instructions may be supported that allow the hypervisor (and other entities) to cause computing device 200 to update or adjust entries in reverse map table 242.

[0054] Input / output (IO) devices 208, 210 are devices or functional blocks that access (e.g., read, write, copy, invalidate, etc.) data and / or instructions in memory 204 in the course of corresponding device operations. For example, I / O devices 208, 210 may include network interface devices, disk controllers, devices coupled to corresponding wired or wireless buses or interfaces (e.g., Peripheral Controller Interface Express (PCIe) buses, Universal Serial Bus (USB), Wi-Fi devices, etc.), GPUs, etc. The specific operations performed by each of I / O devices 208, 210 depend on the nature of each I / O device. For example, assuming I / O device 208 is a disk controller, I / O device 208 can retrieve data from a disk (e.g., mass storage 206) and write the data to memory 204, or vice versa. As another example, assuming I / O device 210 is a network interface device, I / O device 210 may store data received over a network in memory 204 or retrieve data from memory 204 that is transmitted over the network to a receiving device in packets, data units, etc. As another example, assuming I / O device 210 is a GPU, I / O device 210 may perform operations to render graphics or other information for display and / or perform general-purpose computing operations (e.g., matrix processing operations, operations offloaded from either of processing cores 214, 216, etc.).

[0055] IO hub 212 is an input / output hub that performs operations to interface between I / O devices (e.g., I / O devices 208, 210) and other functional blocks (e.g., processor 202) in computing device 200. For example, in some embodiments, input / output memory management unit (IOMMU) 244 in IO hub 212 performs operations to allow I / O devices to access memory 204. In these embodiments, when data and instructions are to be accessed (i.e., read, write, check / verify, delete, invalidate, etc.) by an I / O device in memory 204, the I / O device sends a memory access request (e.g., a direct memory access request or DMA) to IOMMU 244. IOMMU 244 then sends a corresponding request to memory 204 for fulfillment / resolution of the memory access request. For example, if data is to be retrieved based on a memory access request, IOMMU 244 may obtain the data from memory 204 (or mass storage 206 if the data is not resident in memory 204) and transfer the data to the requesting I / O device.

[0056] In some embodiments, as described above, I / O devices use virtual memory techniques to address memory. Accordingly, IOMMU 244 includes mechanisms for enabling I / O devices to access memory using virtual memory operations. IO table walker 246 is one such mechanism. IO table walker 246 is a functional block that performs operations related to retrieving address translations from page tables (e.g., page table walks, etc.). IO table walker 246 uses a hierarchy of page tables, including a page table associated with IOMMU 244 and a nested page table associated with the hypervisor. Examples of page tables are shown in FIG. 2 as input / output (IO) page table 248 and nested page table 234 associated with IOMMU 244 and the hypervisor, respectively. IO page table 248 is a data structure (e.g., one or more tables, arrays, lists, etc.) stored in memory 204. For example, IO page table 248 may be stored in a protected / encrypted area of ​​memory that is inaccessible to the hypervisor (and other entities within computing device 200). In some embodiments, IO page table 248 stores at least one translation for each page present in memory 204 that is stored in or otherwise accessed by an I / O device in memory 204. As described above, IO table walker 246 uses IO page table 248 and nested page tables 234 to perform virtual to physical address translations.

[0057] IOMMU 244 also includes translation lookaside buffer 250 (TLB 250), which is a cache within IOMMU 244 configured to store / cache virtual-to-physical address translation information obtained during page table walks. IOMMU 244 obtains virtual-to-physical address translation information from a corresponding TLB to avoid performing page table walks when possible. In some embodiments, an I / O device (e.g., I / O device 208) may include a local TLB, such as IOTLB 252, which can be used by the I / O device alone or in combination with TLB 250 within IOMMU 244 to store virtual-to-physical address translation information.

[0058] In some embodiments, I / O devices 208, 210 are provided with access to pages of memory allocated to a virtual machine, i.e., pages of memory reserved for the exclusive use of a particular virtual machine, which may be referred to as “private” pages of memory. For example, continuing with the example in which I / O device 208 is a disk controller, I / O device 208 may perform direct memory access (DMA) operations to write data to pages of memory allocated to a particular virtual machine. In these embodiments, IOMMU 244 and / or I / O devices 208, 210 ensure that access of pages owned by the virtual machine is permitted, or perform operations to enable access if not. For example, when IO table walker 246 translates a virtual address to a physical address, it checks reverse map table 242, as described herein, to ensure that access by the I / O device is permitted. As another example, in embodiments in which pages owned by a virtual machine are encrypted, IOMMU 244 and / or I / O devices 208, 210 encrypt and decrypt information retrieved from or addressed to the pages, using a corresponding key, or the like.

[0059] In some embodiments, communication paths are coupled between various functional blocks (e.g., processing cores 214, 216, memory management unit 228, memory 204) within computing device 200, as indicated by arrowed lines between the elements. The communication paths include one or more buses, wires, guides, and / or other connections, possibly involving controllers, fabric elements (e.g., switches, routers), circuit elements, etc. The communication paths are used to route commands, data, control signals, and / or other information between the functional blocks. For example, in some embodiments, a coherent bus fabric is coupled between IO hub 212, processor 202 (e.g., MMU 228), and memory 204. It should be understood that various communication paths have been omitted from FIG. 2 for clarity.

[0060] While certain embodiments described herein include particular arrangements of processing cores, it should be understood that various embodiments include different numbers and / or arrangements of processing cores. For example, some embodiments have only one processing core, while other embodiments have five, eight, or another number of processing cores. In general, the described embodiments can use any arrangement of processing cores capable of performing the operations described herein.

[0061] Similarly, although embodiments are described herein as having a particular arrangement of caches, various embodiments include different numbers and / or arrangements of caches. For example, some or all of the caches (e.g., L1 caches 218, 220, etc.) may be divided into separate instruction and data caches. Furthermore, L2 cache 222 may not be shared and therefore may be used only by a single processing core (i.e., there may be two L2 caches within processor 202). As another example, some embodiments include different levels of cache, from only one level of cache to multiple levels of cache, which may be located within processor 202 and / or external to processor 202. In general, the described embodiments may use any arrangement of caches capable of performing the operations described herein.

[0062] 1, computing device 200 and processor 202 are simplified for purposes of illustration, although the disclosure is not limited in this respect. As shown in FIG. 2, in some embodiments, computing device 200 and / or processor 202 include additional or different elements and mechanisms for performing the operations described herein and other operations. For example, computing device 200 and / or processor 202 may include one or more power controllers, batteries, media processors, input / output mechanisms, communication mechanisms, networking mechanisms, display mechanisms, etc.

[0063] Processor 202, memory 204, mass storage 206, and I / O devices 208, 210 are some examples of “hardware” that may be represented by computing device hardware 110 and I / O devices 114 of FIG. 1. Thus, in some embodiments, host operating system 108, IOMMU 112, and / or hypervisor 106 interface between processor 202, memory 204, mass storage 206, and I / O devices 208, 210 and virtual machine 100, guest operating system 102, and programs 104. In these embodiments, computing device 200 (e.g., processing cores 214, 216, etc.) executes host operating system 108 in embodiments in which hypervisor 106, virtual machine 100, guest operating system 102, programs 104, and host operating system 108 are present. Additionally, references in this description to a “computing device” and elements within a computing device may refer to computing device 200 and related elements.

[0064] 2 are implemented together, such as in a "system-on-chip" embodiment, where IO hub 212 and some or all of I / O devices 208, 210 are integrated with processor 202, such as fabricated on the same integrated circuit chip. In other words, in such an embodiment, IO hub 212 and I / O devices 208, 210 may be integrated with or located within other functional blocks.

[0065] Computing device 200 may be or may be included in any electronic device that performs computational operations. For example, computing device 200 may be or may be included in an electronic device such as a desktop computer, a laptop computer, a wearable computing device, a tablet computer, a smartphone, a server, an artificial intelligence device, a virtual or augmented reality device, a network device, a toy, an audiovisual device, a home appliance, a controller, a vehicle, and / or combinations thereof.

[0066] 3 shows an RMT 342 that includes an RMT segment index 341 and n RMT segments 343. While the specific configuration of the RMT 342 may vary and be flexible across multiple embodiments, various memory and storage parameters are provided in the following description as an example configuration for illustration purposes.

[0067] In the illustrated embodiment, each RMT segment entry is 16B in size and corresponds to a particular 4kB page of system memory. The size and location of the RMT segment index 341 is configurable via software, such as by specifying the RMT_BASE and RMT_END parameters (which indicate the addresses that point to the start and end of the RMT segment index 341, respectively) as part of system and / or memory initialization. All CPUs in the system point to the same RMT segment index 341.

[0068] The RMT segment index 341 includes an RMT counter table 344, which in the illustrated embodiment is 16 kB in size, contains counters used to enforce security properties when changing encryption keys, and specifies up to n (e.g., n=512) RMT segments 343. Each RMT segment 343 corresponds to a range of physical addresses. The size of each RMT segment 343 is configurable (and, at least in the illustrated embodiment, is substantially identical), allowing flexibility in various system configurations. To access an RMT entry for a target virtual memory page address (virtual page address), a processor (e.g., processor 202 in FIG. 2) first identifies the virtual page address's associated RMT segment index entry using a subset of the virtual page address's bits. The processor then identifies the RMT entry corresponding to the physical page address based on the base memory address specified by the RMT segment index (e.g., the SGMNT_BASE parameter of RMT segment 2) and additional bits of the virtual page address.

[0069] As described in more detail below with respect to FIG. 4, within each RMT segment 343, each system physical address corresponds to a single RMT entry. The illustrated embodiment allows for a maximum of n=512 RMT segments 343, although the actual number of NUMA nodes in a typical system is much smaller. To improve RMT lookup performance, hardware may cache information about some RMT segments so that the RMT segment index does not need to be examined on each lookup. Under an exemplary system configuration, valid entries in the RMT segment index are fully cached by hardware, resulting in substantially negligible impact on overall performance. In a particular embodiment, each individual RMT segment 343 is mapped to a single NUMA node, and for best performance, the RMT segment 343 resides on the same NUMA node as the memory page entry it describes.

[0070] In an exemplary configuration, the 1TB system described above is configured so that each RMT segment is allocated a size of 2GB, mapping 512GB of memory. Thus, entries in the first segment (e.g., RMT segment 1) describe memory from 0 to 512GB (with a 2GB RMT table). The second segment, describing memory from 512GB to 1TB, is invalid (because no memory exists at those system addresses). And the third and final segment describes memory from 1TB to 1.5TB (with a 2GB RMT).

[0071] In the illustrated embodiment, the configuration of the segmented RMT 342 is provided via various specified, non-exclusive, exemplary parameters. In particular, such parameters here include the minimum supported RMT segment size, the maximum supported RMT segment size, the number of RMT segment definitions that the CPU can cache, and whether the number of cached segments is a hard limit. Typically, the minimum and maximum sizes of RMT segments are expressed as powers of two. For example, a minimum segment size of 4 GB may be stored as 32 (as 2^32 = 4 GB). The segment size refers to the amount of system physical addresses covered by one entry in the RMT segment index 341. It is understood that the maximum segment size is greater than or equal to the minimum segment size; furthermore, if they are equal, only a single segment size is supported.

[0072] Continuing with the exemplary configuration of FIG. 3, an exemplary lookup operation of a system physical page address X within segmented RMT 342 is performed as follows: Calculate RMTIndex=X[RMTSegmentSize+8:RMTSegmentSize]. Read the 8B RMT segment index entry at RMT_BASE+0x4000+RMTIndex*8. ·If X[RMTSegmentSize-1:30]>=MappedSize, there is no RMT entry associated with this address. · If SGMNT_BASE is not a valid physical address, terminate the table walk (e.g., has a reserved bit fault). ·Access the 16B RMT entry at {RmtSegmentBase,20'b0}+{X[RMTSegmentSize-1:12],4'b0}.

[0073] In a particular embodiment, if there is no RMT entry associated with physical address X, then that physical address X is considered to be part of a hypervisor-owned page.

[0074] 4 is a block diagram illustrating an expanded view of an exemplary RMT segment 443 (which may, in various aspects, be substantially similar to one or more of RMT segment 243 of FIG. 2 and / or RMT segment 343 of FIG. 3), according to some embodiments. While the illustrated embodiment shows RMT segment 443 as including certain specified information, various embodiments may include one or more different arrangements or types of information. Generally, entry 400 within RMT segment 443 includes sufficient information to perform the operations described herein.

[0075] In the illustrated embodiment, RMT segment 443 includes several entries 400 (entries 400 are highlighted using dashed lines in FIG. 4 ). Each entry in RMT segment 443 contains information about a corresponding page in memory 204 (e.g., each 4 kB or 2 MB page in memory that can be allocated for use by one or more virtual machines). The entries in RMT segment 443 are indexed using the system physical address associated with each page, such that each entry is associated with a particular system physical address. For example, for a 4 kB page, the first entry in RMT segment 443 is associated with the first or lowest allocable system physical address (address A), the second entry is associated with the second allocable system physical address (address A+4 kB), and so on. In this way, when a particular system physical address is looked up in RMT segment 443, the entry at the corresponding offset in RMT segment 443 is looked up. In some embodiments, the base address of the RMT segment 443 is recorded in a designated, possibly secure, location within the computing device 200 to enable offset-based lookup.

[0076] In the RMT segment 443, each entry 400 is configured to store a global shared page indicator (GSP) 402, a guest identifier (guest ID) 404, a guest physical address (guest PHY ADDR) 406, a subpage count 408, a size indicator 410, an allocated indicator 412, a locked indicator 414, an immutable indicator (IMMT) 416, a verified indicator 418, and a virtual machine permission level (VMPL) block 420.

[0077] Global shared page indicator 402 is an indicator of whether the corresponding page is shared by two or more virtual machines. Generally, if a page is shared, it can be accessed (typically in a read-only manner) by two or more virtual machines.

[0078] Guest identifier 404 is an identifier associated with the virtual machine to which the corresponding page is allocated. For example, if the corresponding page is allocated for use by a particular virtual machine, the identifier of the particular virtual machine is recorded in guest identifier 404. Guest identifier 404 may hold an address space identifier (ASID), an ID string, a name, and / or another value that identifies the virtual machine or identifies the page as hypervisor-allocated, shared among multiple virtual machines, or otherwise allocated.

[0079] Guest physical address 406 is a value representing the guest physical address associated with the entry's system physical address. For example, when a page at a given system physical address is allocated for use by a virtual machine, assigned to a virtual machine, etc., the guest physical address used by the virtual machine to address the page is recorded in the corresponding entry 400 in RMT segment 443. In this way, a record is created of the specific guest physical address used by the virtual machine to which each page is allocated. By recording this information, when a table walker (e.g., table walker 230 or IO table walker 246) checks a system physical address obtained during a walk of a nested page table, it can determine whether the system physical address maps to an expected guest physical address, i.e., whether the system physical address was simultaneously mapped to two different guest physical addresses. This can make it possible to detect whether the mapping has been maliciously or accidentally changed by the hypervisor or another entity.

[0080] Subpage count 408 is a count of smaller-sized pages allocated to a virtual machine within larger-sized pages. For example, in a system that supports 2MB pages and 4kB pages, pages on a 2MB boundary (e.g., pages at addresses A, A+2MB, A+4MB, etc.) may have a count of 4kB pages within the 2MB page allocated for use by the virtual machine. The subpage count value is used to determine whether access to the larger-sized page is disallowed, given that a smaller page has been allocated within the larger-sized page. In other words, subpage count 408 is used to prevent unauthorized access to the corresponding page using an inappropriate page size.

[0081] The size indicator 410 is the expected size for accesses of the corresponding page. For example, assuming that 4 kB pages and 2 MB pages are used in the computing device 200, the size indicator 410 indicates which size access is associated with the corresponding page. The size indicator 410 enables detection of accesses of impermissible sizes, such as a 2 MB access of what is actually a 4 kB page, or vice versa.

[0082] Allocated indicator 412 is an indicator of whether entry 400 is currently allocated to one or more virtual machines. Allocated indicator 412 is used to prevent use of information from entries 400 in RMT segment 443 that are not currently allocated but may still contain stale information (undeleted information, random bit patterns, etc.), are initialized but contain no actual information, etc. In some embodiments, allocated indicator 412 is set when the page is currently allocated to a virtual machine and is unset / cleared when the page is deallocated from the virtual machine.

[0083] Lock indicator 414 is an indicator of whether entry 400 is locked. When lock indicator 414 is set, entry 400 is considered locked, and when lock indicator 414 is unset / cleared, entry 400 is considered free or available. When entry 400 is locked by a given hardware or software entity, other hardware and software entities within computing device 200 are prevented from accessing entry 400 (e.g., reading, writing / updating, etc.) entry 400. In contrast, any hardware and software entity may be permitted to access a free / available entry (possibly after setting lock indicator 414). For example, in one embodiment where lock indicator 414 is a single bit and is initially clear (e.g., set to zero), an entity may set lock indicator 414 (e.g., to one), access entry 400 one or more times, and then clear lock indicator 414 when it is finished accessing entry 400. Using lock indicator 414, the described embodiments can avoid race conditions and other conditions that may occur with simultaneous reads and / or writes to entry 400.

[0084] The immutable indicator 416 is an indicator of whether the corresponding page is immutable. When a page is marked as immutable using the corresponding immutable indicator 416, the page cannot be written to by a software entity (e.g., a hypervisor, a guest operating system, an application program, etc.) executing on a core (e.g., cores 214-216). In other words, an immutable page is prevented from being rewritten, updated, modified, added, removed, etc., in whole or in part, by any of the software entities. Furthermore, an immutable page will be deallocated by a platform security processor (e.g., platform security processor 226) and cannot be deallocated by any core, including cores operating on behalf of or under the control of a software entity (e.g., a hypervisor, etc.) executing thereon. Immutable pages are described in detail in U.S. patent application Ser. No. 15 / 417,632, which is incorporated herein by reference, as noted above.

[0085] Verified indicator 418 is an indicator of whether entry 400 has been verified by a virtual machine (i.e., the virtual machine that allocated the corresponding page). The virtual machine updates verified indicator 418 (e.g., sets one or more bits in verified indicator 418 to a specified value, such as 1) to indicate that entry 400 has been verified, thereby “marking” entry 400 as verified. For example, the virtual machine may immediately verify the corresponding entry in RMT segment 443 when a page is allocated, or may delay verification, such as verifying the entry when the page is first accessed or upon receiving a page verification failure. In some embodiments, the virtual machine executes a dedicated instruction to verify / update verified indicator 418. When entry 400 is updated, such as when a hypervisor changes information in entry 400, verified indicator 418 is cleared. During operation, the table walker determines whether the virtual machine has verified entry 400 based on the set / clear state of verified indicator 418.

[0086] Virtual machine permission level (VMPL) block 420 includes a set of permissions for several permission levels for the page associated with entry 400. In some embodiments, computing device 200 supports two or more permission levels, with each permission level associated with permissions (e.g., enabled / disabled, allowed / disallowed, etc.) for a specified set of operation types for a page in memory. An operation type may include any operation that can be performed on or with data in a page, such as reading data, writing data, executing program code in a page, etc. For a given page, the set of permissions for each of the permission levels may differ, such that a given operation type at a first permission level may have different permissions than the same operation type at a second permission level. For example, writing data may be allowed for a page at a first permission level but not at a second permission level. In some embodiments, the permission levels are organized into a hierarchy, with "higher" permission levels having more permissions than "lower" permission levels.

[0087] FIG. 5 is a flow diagram of an operational routine 500 suitable for processing memory access requests in a secure computing system, according to some embodiments.

[0088] The routine begins at block 505, where a memory access request specifying a virtual memory address is received. The routine proceeds to block 510.

[0089] The physical memory address associated with the specified virtual memory address is identified at block 510. The routine proceeds to block 515.

[0090] A segmented reverse map table stored in a non-contiguous portion of physical memory is accessed at block 515. The routine proceeds to block 520.

[0091] In block 520, the routine determines whether the requestor associated with the memory access request received in block 505 is permitted to access the physical memory address identified in block 510. If so, the routine proceeds to block 525, where the requestor is provided access to the identified physical memory address. If not, the routine proceeds to block 530, where the requestor is prevented from accessing the identified physical memory address.

[0092] In some embodiments, the above-described apparatus and techniques are implemented in a system including one or more integrated circuit (IC) devices (also referred to as integrated circuit packages or microchips). Electronic design automation (EDA) and computer-aided design (CAD) software tools can be used to design and manufacture these IC devices. These design tools are typically represented as one or more software programs. The one or more software programs include code executable by a computer system to operate the computer system to operate on code representing the circuits of one or more IC devices to perform at least a portion of a process for designing or adapting a manufacturing system for manufacturing the circuits. This code may include instructions, data, or a combination of instructions and data. The software instructions representing the design or manufacturing tools are typically stored in a computer-readable storage medium accessible to the computing system. Similarly, code representing one or more stages of the design or manufacture of the IC devices is stored in and accessed from the same or a different computer-readable storage medium.

[0093] A computer-readable storage medium includes any non-transitory storage medium or combination of non-transitory storage media that can be accessed by a computer system during use to provide instructions and / or data to the computer system. Such storage media may include, but are not limited to, optical media (e.g., compact discs (CDs), digital versatile discs (DVDs), Blu-ray discs), magnetic media (e.g., floppy disks, magnetic tape, magnetic hard drives), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or flash memory), or micro-electromechanical systems (MEMS)-based storage media. The computer-readable storage medium (e.g., system RAM or ROM) may be internal to the computing system, the computer-readable storage medium (e.g., a magnetic hard drive) may be permanently attached to the computing system, the computer-readable storage medium (e.g., an optical disk or Universal Serial Bus (USB)-based flash memory) may be removably attached to the computing system, or the computer-readable storage medium (e.g., network-accessible storage (NAS)) may be coupled to the computer system via a wired or wireless network.

[0094] In some embodiments, certain aspects of the techniques described above are implemented by one or more processors of a processing system executing software. The software includes one or more sets of executable instructions stored or otherwise tangibly embodied in a non-transitory computer-readable storage medium. The software may include instructions and specific data that, when executed by one or more processors, operate the one or more processors to perform one or more aspects of the techniques described above. The non-transitory computer-readable storage medium may include, for example, a magnetic or optical disk storage device, a solid-state storage device such as flash memory, a cache, a random access memory (RAM), or other non-volatile memory device(s). The executable instructions stored on the non-transitory computer-readable storage medium may be implemented as source code, assembly language code, object code, or other form of instructions that can be interpreted or otherwise executed by one or more processors.

[0095] In addition to the above, it should be noted that not all activities or elements described in the summary description are required, that some of the particular activities or devices may not be required, that one or more additional activities may be performed, and that one or more additional elements may be included. Furthermore, the order in which the activities are listed is not necessarily the order in which they are performed. Also, the concepts have been described with reference to specific embodiments. However, those skilled in the art will recognize that various modifications and variations can be made without departing from the scope of the invention as set forth in the claims. Accordingly, the specification and drawings should be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present invention.

[0096] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and features from which any benefit, advantage, or solution may arise or be manifested are not construed as critical, essential, or essential features of any or all claims. Moreover, the specific embodiments described above are illustrative only, since the disclosed invention may be modified and practiced in different, but similar manners apparent to those skilled in the art having the benefit of the teachings herein. No limitations are intended to the details of construction or design herein shown, other than as described in the appended claims. It is therefore apparent that the specific embodiments described above may be altered or modified, and that all such variations are considered within the scope of the disclosed invention. Accordingly, the protection sought herein is set forth in the appended claims.

Claims

1. 1. A method for processing memory accesses in a computing system, comprising: translating a virtual memory address specified by a memory access request into a physical memory address associated with said virtual memory address; providing access to the physical memory address to a requestor associated with the memory access request in response to an indication in a segmented reverse map table (RMT) that the requestor is authorized to access the associated physical memory address; the segmented RMT is stored in non-contiguous portions of the computing system's physical memory; method.

2. the segmented RMT includes an RMT segment index including a plurality of index entries each corresponding to one of a plurality of segments of the segmented RMT stored in non-contiguous portions of the physical memory; 10. The method of claim 1.

3. each segment of the plurality of segments includes a plurality of segment entries, each segment entry corresponding to a distinct physical address; The method of claim 2.

4. the computing system runs one or more virtual machines that are allocated portions of physical memory, and a segment entry for the plurality of segments includes the entirety of the physical memory allocated to the one or more virtual machines; The method of claim 3.

5. the physical memory of the computing system includes a plurality of non-uniform memory access (NUMA) memory nodes, and each segment of the plurality of segments maps to a respective NUMA memory node; The method of claim 2.

6. At least one segment of the plurality of segments is stored in the NUMA memory node mapped by the at least one segment. The method of claim 5.

7. the RMT segment index comprises an RMT counter table containing one or more counters associated with one or more encryption keys; The method of claim 2.

8. identifying the physical memory address is performed by a table walker of the computing system; 10. The method of claim 1.

9. the requestor is an input / output (I / O) device communicatively coupled to the computing system, and the table walker is a hardware table walker associated with an I / O memory management unit (IOMMU) of the computing system.

9. The method of claim 8.

10. the requestor is one or more virtual machines running on the computing system, each of which is assigned a plurality of physical memory addresses; The method of any one of claims 1 to 8.

11. 1. A computing device comprising: a processor; Table walkers and a memory that stores a segmented reverse map table (RMT) that resides in multiple non-contiguous portions of the memory; The table walker translating a virtual memory address specified by a memory access request into a physical memory address associated with said virtual memory address; providing a requestor associated with the memory access request with access to the associated physical memory address in response to an indication in the RMT that the requestor is authorized to access the associated physical memory address; configured to: Computing devices.

12. the segmented RMT includes an RMT segment index including a plurality of index entries each corresponding to one of a plurality of segments of the segmented RMT stored in the non-contiguous portion of the memory; The computing device of claim 11.

13. each segment of the plurality of segments includes a plurality of segment entries each corresponding to a distinct physical address of the memory; The computing device of claim 12.

14. the computing device runs one or more virtual machines that are allocated portions of the memory, and a segment entry for the plurality of segments includes an entirety of the memory allocated to the one or more virtual machines; The computing device of claim 13.

15. the memory includes a plurality of non-uniform memory access (NUMA) memory nodes, and each segment of the plurality of segments maps to a respective NUMA memory node; The computing device of claim 12.

16. At least one segment of the plurality of segments is stored in the NUMA memory node mapped by the at least one segment.

16. The computing device of claim 15.

17. the RMT segment index comprises an RMT counter table including one or more counters, each of the one or more counters associated with one or more encryption keys; The computing device of claim 12.

18. an input / output (I / O) memory management unit (IOMMU); the requestor is an I / O device communicatively coupled to the computing device, and the table walker is a hardware table walker associated with the IOMMU. The computing device of claim 11.

19. one or more virtual machines executing on the computing device, each assigned a plurality of physical memory addresses; the request source is any one of the one or more virtual machines; A computing device according to any one of claims 11 to 17.

20. 1. A computing device comprising: Storing a segmented reverse map table (RMT) residing in multiple non-contiguous portions of a memory having multiple physical memory addresses, the segmented RMT including an RMT segment index including multiple index entries corresponding to any of multiple segments of the segmented RMT stored in the non-contiguous portions of the memory; translating a virtual memory address specified by a memory access request into a physical memory address associated with said virtual memory address; providing a requestor associated with the memory access request with access to the associated physical memory address in response to an indication in the segmented RMT that the requestor is authorized to access the associated physical memory address; configured to: Computing devices.

Images