Segmented discontinuous reverse mapping table

Abstract

A computing device (200) includes a processor (202), a table traversal device (230), and a memory (204) that stores a segmented reverse mapping table (242) in a plurality of non-contiguous portions of the memory. The table traverser is configured to translate a virtual memory address specified by a memory access request to a physical memory address associated with the virtual memory address; and providing access to the associated physical memory address to a requester associated with the memory access request in response to an indication at the reverse mapping table that the requester is authorized to access the associated physical memory address.

Description

Background Art

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

[0002] Some computing devices execute two or more virtual machines concurrently (e.g., executing in corresponding time slices, executing in parallel on one or more processing cores, etc.). In such computing devices, each virtual machine can access hardware resources allocated specifically for the use of the virtual machine. For example, each virtual machine can be allocated a corresponding area of ​​memory in the computing device that is dedicated to the virtual machine. In these computing devices, a first virtual machine can be prevented from accessing a memory area allocated to a second virtual machine, and vice versa. In some of these computing devices, a hypervisor (also known as a VMM, virtual machine monitor, or virtual machine manager) implements access control for each virtual machine. A hypervisor is a software entity that operates / executes on a computing device and serves as a manager or controller for the virtual machines executing on the computing device. For example, a hypervisor can start or initialize a virtual machine, control a virtual machine's access to the computing device hardware, terminate or shut down a virtual machine, etc. Summary of the Invention

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

[0004] The segment reverse mapping table may include an RMT segment index including a plurality of index entries, each of the plurality of index entries corresponding to a segment of a plurality of segments of the RMT stored in the non-contiguous portion of the physical memory.

[0005] Each segment of the plurality of segments may include a plurality of segment entries, each segment entry corresponding to a different physical address.

[0006] The computing system may execute one or more virtual machines that are each allocated a portion of physical memory such that the segment entry of the plurality of segments includes all of the physical memory allocated 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 of the plurality of segments is mapped to a corresponding NUMA memory node. At least one segment of the plurality of segments may be stored on the corresponding NUMA memory node mapped by the at least one segment.

[0008] The RMT segment index may also include an RMT counter table including one or more counters, each of the one or more counters being 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 requester may be an input / output (I / O) device communicatively coupled to the computing system, such that 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 one of one or more VMs executing on the computing system, each of which is assigned a corresponding 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 segment reverse mapping table (RMT) in a plurality of non-contiguous portions of the 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, based on the segment reverse mapping table, whether a requestor associated with the memory access request is authorized to access the associated physical memory address; and, in response to determining that the requestor is authorized to access the physical memory address, provide the requestor with access to the identified physical memory address, and otherwise prevent the requestor from accessing the identified physical memory address.

[0012] The segment reverse mapping table may include an RMT segment index, the RMT segment index including a plurality of index entries, each of the plurality of index entries corresponding to a segment of a plurality of segments of the RMT stored in the non-contiguous portion of the memory. Each segment of the plurality of segments may include a plurality of segment entries each corresponding to a different physical address of the memory.

[0013] The computing device may execute one or more virtual machines that are each allocated a portion of the memory such that the segment entry of the plurality of segments includes all of the memory allocated to the one or more virtual machines.

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

[0015] The RMT segment index may also include an RMT counter table including 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 may further include an input / output (I / O) memory management unit (IOMMU), such that the requestor is an I / O device communicatively coupled to the computing device, and wherein the table walker is a hardware table walker associated with the IOMMU.

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

[0018] In one embodiment, a computing device is configured to: store a segmented reverse mapping table (RMT) in multiple non-contiguous portions of a memory having multiple physical memory addresses, the segmented RMT including an RMT segment index, the RMT segment index including multiple index entries, each of the multiple index entries corresponding to one of the multiple segments of the segmented RMT stored in the non-contiguous portion of the memory; convert 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 associated physical memory address to the requester in response to an indication at the segmented RMT that the requester associated with the memory access request is authorized to access the associated physical memory address. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0020] Figure 1 A block diagram illustrating a virtual machine and hypervisor according to some embodiments is presented.

[0021] Figure 2 A block diagram illustrating a computing device according to some embodiments is presented.

[0022] Figure 3A reverse mapping table (RMT) including an RMT segment index and n RMT segments according to some embodiments is illustrated.

[0023] Figure 4 A block diagram illustrating an expanded view of an example RMT segment according to some embodiments is presented.

[0024] Figure 5 A flow diagram illustrating an operational routine suitable for handling memory access requests in a secure computing system, according to some embodiments. DETAILED DESCRIPTION

[0025] Although it is assumed that the hypervisor provides access control for virtual machines, the hypervisor may not always implement access control correctly. For example, the hypervisor's program code may be replaced by malicious program code, the hypervisor's program code may be damaged or include errors, etc. In such cases, the hypervisor may intentionally or unintentionally allow a virtual machine to access computing hardware assigned to another virtual machine. For example, in some computing devices, the hypervisor is responsible for providing address information to enable the virtual machine to access data in a corresponding area of ​​memory. In these computing devices, the hypervisor provides conversion between local and / or virtual addresses used by the virtual machine (or software executed thereon) and the physical address where the data is actually located in the memory. When the hypervisor is not operating correctly, the hypervisor may provide incorrect address information, thereby directing the virtual machine to access data in an unexpected or unwanted area of ​​memory (e.g., a memory area assigned to another virtual machine). By providing incorrect address information as described, the hypervisor may enable access to data in violation of one or more access controls or rules.

[0026] In addition to the address translations provided by the hypervisor being used by virtual machines, in some of these computing devices, address translations are used by input-output (IO) devices to access memory pages allocated to a particular virtual machine. For example, when interacting with a virtual machine, an input / output (I / O) device (such as a disk controller, a network interface device, a peripheral component interface express or PCIe bus device, a graphics processing unit (GPU), etc.) performs direct memory access (DMA) operations to write data to one or more memory pages allocated to the virtual machine. Similar to the operations involving virtual machines described above, operations performed by the I / O device may be maliciously or erroneously misdirected when the hypervisor provides incorrect address information.

[0027] As discussed herein, computing devices use virtual memory to handle data access by programs executed in the computing device or by input / output (IO) devices interacting with the computing device. For example, the executed programs may include applications, operating systems, device drivers, virtual machines, firmware, etc. Generally speaking, when data is accessed by a program or I / O device in a computing device, a memory block or memory page of a given size (e.g., 4kB, 2MB, etc.) of data is copied from a large-capacity storage device (e.g., a disk drive or semiconductor memory) to an available physical location in the memory of the computing device or is newly created in the memory. In order to avoid programs and I / O devices being required to track the physical location of pages in memory, the computing device tracks the physical location of pages for the programs and I / O devices. Programs and I / O devices use virtual addresses in a virtual address space to access memory, rather than using addresses based on the physical location (or physical address) of the page to access memory. The virtual address space is a local address space dedicated to the corresponding program or I / O device. From the perspective of a program or I / O device, a virtual address indicates the actual physical location of data stored in memory, and the program or I / O device uses the virtual address accordingly to perform memory accesses. However, the virtual address may not directly map to the physical address of the physical location of the page in memory where the data is stored. As part of tracking the physical location of the page, the computing device converts the virtual address used by the program or I / O device in the memory access request into the physical address where the data is actually located. The computing device then uses the physical address to perform memory accesses for the program or I / O device.

[0028] To implement virtual-to-physical address translation, a computing device includes a page table. A page table is a record stored in a memory of the computing device that includes entries, or page table entries, with virtual-to-physical address translation information for pages of data stored in the memory. In other words, the 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 retrieves 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 a 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.

[0029] Thus, a computing device includes a translation lookaside buffer (TLB), which is a local cache for storing a limited number of copies of address translation information (i.e., information based on page table entries) obtained during a page table traversal. 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, the processing core, IOMMU, or I / O device first attempts to obtain a cached page table entry from the corresponding TLB for performing virtual address to physical address translation. When a copy of the corresponding page table entry does not exist in the TLB (i.e., when a miss occurs), the processing core or IOMMU performs a page table traversal to obtain the desired page table entry—and caches the obtained copy of the page table entry in the TLB.

[0030] The secure virtual machine architecture provides hardware resources that allow 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 intercepting and emulating sensitive operations of guest VMs in a secure manner (such as modifying page tables, which can give guest VMs access to memory they are not allowed to access, or access to peripherals shared between multiple guest VMs). A page table is a data structure used by the virtual memory system to store the mapping between virtual memory addresses and physical memory addresses. The VMM provides each guest VM with the appearance of full control over the entire computer system (memory, central processing unit (CPU), and all peripherals). A guest VM can have one or more virtual CPUs (vCPUs) managed by the guest OS, just as on a non-virtualized system, and the VMM can run any mix of vCPUs from the same or different guests on different logical processors essentially simultaneously.

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

[0032] In the embodiments discussed herein, a reverse mapping table (RMT) is used to implement data integrity protection for encrypted VMs. The RMT is checked by both the CPU and the IOMMU during a page table walk to determine whether a page is accessible. In certain embodiments, the RMT is also used to ensure that the hypervisor (and / or another entity in the computing device) has not yet remapped the conversion from the guest physical address to the system physical address in the nested page table. The RMT includes information that is particularly useful for determining whether the system physical address obtained for the guest physical address during a table walk of the nested page table matches the system physical address previously used. In other words, the RMT is used to ensure that the system physical address of a given page in memory matches only one guest physical address at a time, and to control access by I / O devices and virtual machines to pages in memory allocated to the virtual machine.

[0033] By using RMT, the described embodiments enable detection of potentially malicious or erroneous modifications to nested page tables. Avoiding such modifications to nested page tables can improve the data security of virtual machines in a computing device by preventing the hypervisor (and / or another entity) from incorrectly remapping guest physical addresses to system physical addresses to direct virtual machines to access (e.g., read, overwrite, execute, etc.) data in unknown, unnecessary, or incorrect areas of memory (including memory areas allocated to other virtual machines). Thus, the use of RMT improves data security by enforcing rules such as: only allowing each page in memory to be associated with a single / unique guest physical address (guest physical address aliases are not allowed), and private guest pages in use cannot be remapped without involving / notifying the corresponding virtual machine as described herein. Furthermore, alone or in combination with other techniques (such as encryption of virtual machine memory areas 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 the computing device, improves the security of the computing device, etc. Therefore, the described embodiments improve the security, operational stability, and value to consumers of the computing device.

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

[0035] The embodiments discussed herein provide a segmented RMT architecture such that the RMT table itself is split in memory and does not need to reside in a single physically contiguous location. In certain embodiments utilizing a segmented RMT, a single segment index describes multiple RMT segments, each RMT segment corresponding to a specific physical address range. The size of the segments is configurable, thereby enabling flexibility in various system configurations. Because the RMT table can be split 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 in the presence of non-contiguous address spaces, and makes the RMT more efficient in the context of non-uniform memory access.

[0036] In some embodiments, the segmented RMT is resized during runtime if physical memory is added or removed "hot" (i.e., during operation and without a system reinitialization process). In such embodiments, the segmented RMT is expanded to protect the memory added to the system in this manner, such as by using unallocated RMT segment indexes. Additionally, since the existing memory (the memory in the system before the new memory was added) may have been fully allocated, memory for the new RMT segment may be allocated within the newly added (and therefore unallocated) memory. If such memory is removed during operation, the segment is updated accordingly to be invalidated.

[0037] In certain embodiments, the RMT comprises two components, a first component containing a counter for enforcing security properties when changing encryption keys, and a second component containing an entry for each memory page. All CPUs in the system point to the same RMT memory.

[0038] Figure 1 A block diagram illustrating virtual machines and hypervisors according to some embodiments is presented. In the depicted embodiment, each of three virtual machines (VMs) 100 executes a guest OS 102 and one or more programs 104, such as a database, software application, 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 the 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.

[0039] Despite Figure 1 Specific elements are presented in FIG, but in various embodiments, other arrangements of these and other elements are utilized. For example, in some embodiments, host OS 108 is not present, and hypervisor 106 communicates directly with computing device hardware 110. As another example, there may be a different number of virtual machines 100, or IOMMU 112 may interface between more than one virtual machine 100 and I / O device 114.

[0040] In the depicted embodiment, guest operating system 102, IOMMU 112, I / O devices 114, and hypervisor use virtual memory technology to handle memory requests. Thus, a hierarchy of page tables ( Figure 1). Within the hierarchy of page tables, the 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 the hypervisor 106 is associated with nested page tables. During operation, and using a virtual machine as an example, upon receiving a request from a processor for a translation from a virtual address used by a program executing under a guest operating system to a system physical address, a hardware table walker (e.g., circuitry configured to perform a page table walk, not shown) performs the translation using the guest page table and the nested page tables. More specifically, the table walker uses the guest page table to translate the virtual address used by the program into a guest physical address, which is an address local to the guest operating system. Because a guest physical address may not directly map to a location in memory where data (or instructions, etc.) to be accessed by the program is stored, the table walker uses the nested page tables to translate the guest physical address into a system physical address, which is an address indicating the actual location in memory where the data is stored. Upon obtaining the system physical address, the table walker provides the system physical address for accessing the data. Translations to system physical addresses may also be cached in the TLB.

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

[0042] In the described embodiments, the hypervisor can perform various operations on the information in the nested page tables. For example, the hypervisor can update (i.e., overwrite) mappings from guest physical addresses to system physical addresses, etc. As described below, the described embodiments perform operations to ensure that the information in the nested page tables has not been altered by the hypervisor (maliciously, mistakenly, etc.) in a manner that causes the hypervisor to provide incorrect mappings / translations.

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

[0044] In some embodiments, one or more other checks of the information in the reverse mapping table include checking information in an entry in the reverse mapping table that indicates whether the I / O device (or a corresponding virtual machine, an identifier of which the I / O device uses when accessing the corresponding page, etc.) is permitted to perform the requested access in the memory page. For example, in some embodiments, the entry in the reverse mapping table includes a recorded guest identifier (ID) that identifies the virtual machine to which the page is assigned. 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 at another time, and the IO table walker uses the I / O device identifier to look up the guest ID in a mapping table when receiving an access request from the I / O device, in which the IOMMU maintains a mapping from the I / O device identifier to the guest ID. When the recorded guest ID does not match the guest ID associated with the I / O device from the mapping table, the page is currently recorded as being assigned to a virtual machine different from the virtual machine associated with the I / O device, and the IO table walker determines that a system physical address will not be provided for performing the requested access to the I / O device. In this case, the IO table walker stops / does not perform the translation and signals an error message or failure to the I / O device. Depending on the implementation, there may be additional checks on the information in the reverse mapping table to determine whether the I / O device is permitted to perform the requested access. When all checks pass, for example, when the recorded client ID matches the client ID associated with the I / O device, etc., the IO table walker determines that the system physical address can be provided for performing the requested access to the I / O device.

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

[0046] The processor 202 is a functional block in the computing device 200 that performs computing operations. In the depicted embodiment, the 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. The processor 202 also includes a cache memory (or cache) for locally storing data and instructions used by the processing cores 214, 216 to perform computing operations. In the depicted embodiment, the cache in the processor 202 includes a level 1 (L1) cache 218, 220 (L1 218 and L1 220) in each of the processing cores 214, 216. Each L1 cache includes one or more memory circuits, such as static random access memory (SRAM), dynamic random access memory (DRAM), double data rate synchronous DRAM (DDR SDRAM), and / or other types of memory circuits, for storing data and instructions for use by the corresponding processing core 214, 216, and control circuitry for handling access to the data and instructions stored in the memory circuits. Processor 202 also includes a shared second-level (L2) cache 222, which includes one or more memory circuits, such as SRAM, DRAM, DDR SDRAM, and / or other types of memory circuits, for storing data and instructions for use by both processing cores 214, 216, and control circuitry for handling access to the data and instructions stored in the memory circuits. Processor 202 also includes a shared third-level (L3) cache 224, which includes one or more memory circuits, such as SRAM, DRAM, DDR SDRAM, and / or other types of memory circuits, for storing data and instructions for use by both processing cores 214, 216, and control circuitry for handling access to the data and instructions stored in the memory circuits.

[0047] The processor 202 further includes a platform security processor (PSP) 226. The platform security processor 226 includes processing cores, ASICs, and / or other functional blocks in the computing device 200 for performing security operations. Generally speaking, the platform security processor 226 is considered secure against malicious or erroneous behavior of hardware and software entities, and therefore can be used within the computing device 200 to protect operations that are susceptible to such behavior. For example, the platform security processor 226 can perform operations associated with implementing a trusted execution environment (TEE) in the 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, the platform security processor 226 performs at least some of the operations described herein for controlling access of virtual machines and I / O devices to pages in the memory 204.

[0048] Memory 204 is memory in 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 for use by functional blocks in computing device 200, and control circuitry for handling access to the data and instructions stored in the memory circuits.

[0049] In the depicted embodiment, computing device 200 includes mass storage 206, which may include one or more of high-capacity semiconductor memory (non-volatile semiconductor memory such as flash memory, NVRAM, etc.), a disk drive (hard drive, etc.), an optical drive, and / or other data storage hardware that stores data and instructions for use by computing device 200. In various embodiments, mass storage 206 saves data and instructions retrieved and stored in memory 204 for subsequent use by functional blocks in computing device 200. For example, data and / or instructions may be retrieved from mass storage 206 in blocks or pages of a given size (e.g., 4kB, 2MB, 1GB, etc.), and the pages may be stored in memory 204. In addition, new pages may be created at available physical locations in memory 204 (e.g., for storing computational 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 (restrictions on access types, etc.).

[0050] In the depicted embodiment, the memory management unit (MMU) 228 is a functional block that handles memory access requests. When data and instructions are to be accessed by a functional block in the processor 202 (i.e., read, written, checked / verified, deleted, invalidated, etc. by the processing core 214 or another functional block), the functional block transmits the memory access request to the memory management unit 228. The memory management unit 228 then transmits the corresponding request to one or more of the L2 cache 222, the L3 cache 224, and the memory 204 to satisfy / resolve the memory access request. For example, if data is to be retrieved based on a memory access request, the memory management unit 228 may obtain the data from the L2 cache 222, the L3 cache 224, or the memory 204 (or the mass storage device 206 if the data is not present in one of the L2 cache 222, the L3 cache 224, or the memory 204) and forward the data to the requesting functional block.

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

[0052] In some embodiments, table walker 230 (and more generally, memory management unit 228) uses two mechanisms to perform virtual to physical address translation. The first mechanism is a hierarchy of page tables that includes a page table associated with each virtual machine and a nested page table associated with the hypervisor. An example of a page table is shown in Figure 2 232 and nested page tables 234, which are respectively associated with a virtual machine (e.g., Figure 1 VM 100) and hypervisor (e.g., Figure 1204). Each page table is a data structure (e.g., one or more tables, arrays, lists, etc.) stored in memory 204. For example, a guest page table 232 may be stored in a reserved memory area 236 (shown using dashed lines) allocated for exclusive access by a corresponding virtual machine. In some embodiments, a given page table stores at least one translation for each page present in memory 204 that is stored in memory 204 by a corresponding program, virtual machine, etc. Thus, in these embodiments, if a page has been copied from mass storage device 206 to memory 204 or newly created in memory 204 and remains available in memory 204, the associated virtual address to physical address translation should 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 address to physical address translation.

[0053] In some embodiments, when converting 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 memory page, the IO table walker 246 of the IOMMU 244 performs a table walk of the nested page table 234 to obtain the system physical address from the corresponding entry in the 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 is correctly mapped to the guest physical address in the corresponding entry. Therefore, the IO table walker 246 performs various checks in the RMT 242 to ensure that the system physical address specified in the corresponding entry is correctly mapped to the guest physical address and that the requesting I / O device is permitted to access the corresponding page. For example, in some embodiments, the IO table walker 246 determines whether the entry in the 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, then the system physical address is incorrectly mapped to the guest physical address in the nested page table 234, in which case the IO table walker 246 responds by stalling or not performing the translation and signaling an error message or failure to the requesting I / O device 208, 210. On the other hand, when the guest physical addresses match, the system physical address is correctly mapped to the guest physical address in the nested page table 234. When the system physical address is correctly 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 will be used to perform the requested access to the I / O device.

[0054] The second mechanism for performing virtual-to-physical address translation is a translation lookaside buffer 238, 240 (TLB 238, 240), which is a cache within each of the processing cores 214, 216 configured to store / cache virtual-to-physical address translation information obtained during a page table walk. When possible, the processing cores 214, 216 obtain virtual-to-physical address translation information from the corresponding TLB 238, 240 to avoid performing a page table walk.

[0055] The computing device 200 includes multiple portions of the memory 204 that are allocated for use as reverse mapping tables 242. Specifically, in the depicted embodiment, the RMT 242 includes a single RMT segment index 241 and a plurality of RMT segments 243. Each allocated portion of the RMT 242 is a data structure (e.g., a table, a list, etc.) that includes a number of entries, as discussed in more detail below. For ease of illustration, the discussion herein generally refers to such data structures as tables, but it should be understood that any suitable data structure may be utilized.

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

[0057] In some embodiments, the hypervisor is prevented from directly accessing the reverse mapping table 242. For example, the reverse mapping table 242 may be stored in a memory area that the hypervisor cannot directly access, and / or may be marked as immutable in the reverse mapping table 242 (for example, so that the page in the memory storing the reverse mapping table 242 itself can be marked as immutable). As another example, the reverse mapping table 242 can be encrypted into a form that cannot be directly decrypted by the hypervisor. In some embodiments, the reverse mapping table 242 is stored in one or more areas of the memory that the hypervisor cannot directly access and is encrypted. Although the hypervisor is not allowed "direct" access to the reverse mapping table 242, the hypervisor can enable other elements or entities in the computing device 200 (such as a processor, etc.) to perform operations on the table and use the information in the table. For example, dedicated instructions that enable the hypervisor (and other entities) to enable the computing device 200 to update or adjust the entries in the reverse mapping table 242 can be supported.

[0058] Input-output (IO) devices 208 and 210 are devices or functional blocks that perform access (e.g., reading, writing, copying, invalidating, etc.) to data and / or instructions in memory 204 during the operation of the corresponding device. For example, I / O devices 208 and 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 Buses (USB), WiFi devices, etc.), GPUs, etc. The specific operations performed by each of I / O devices 208 and 210 depend on the nature of each I / O device. For example, assuming that I / O device 208 is a disk controller, I / O device 208 can retrieve data from a disk (such as mass storage device 206) and write data to memory 204, and vice versa. As another example, assuming that I / O device 210 is a network interface device, I / O device 210 may store data received via the network in memory 204 or retrieve data from memory 204 to be sent to a receiving device over the network in packets, data units, etc. As another example, assuming that I / O device 210 is a GPU, I / O device 210 may perform operations for rendering graphics or other information for display and / or may perform general computing operations (e.g., matrix processing operations, operations offloaded from one of processing cores 214, 216, etc.).

[0059] The IO hub 212 is an input-output hub that performs operations for interfacing between I / O devices (e.g., I / O devices 208, 210) and other functional blocks in the computing device 200 (e.g., processor 202). For example, in some embodiments, an input-output memory management unit (IOMMU) 244 in the IO hub 212 performs operations to enable the I / O devices to access the memory 204. In these embodiments, when data and instructions are to be accessed (i.e., read, written, checked / verified, deleted, invalidated, etc.) by an I / O device in the memory 204, the I / O device transmits a memory access request (e.g., a direct memory access request or DMA) to the IOMMU 244. The IOMMU 244 then transmits the corresponding request to the memory 204 to satisfy / resolve the memory access request. For example, if data is to be retrieved based on a memory access request, the IOMMU 244 may obtain the data from the memory 204 (or mass storage 206 if the data does not exist in the memory 204) and forward the data to the requesting I / O device.

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

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

[0062] In some embodiments, I / O devices 208, 210 may be provided with access to memory pages allocated to a virtual machine—i.e., access to memory pages reserved for use exclusively by a particular virtual machine, which may be referred to as "private" memory pages. For example—and continuing with the example where I / O device 208 is a disk controller—I / O device 208 may perform direct memory access (DMA) operations to write data to memory pages allocated to a particular virtual machine. In these embodiments, the IOMMU 244 and / or I / O devices 208, 210 perform operations to ensure that access to pages owned by the virtual machine is permitted and otherwise enable access. For example, as described herein, when translating virtual addresses to physical addresses, the IO table walker 246 checks the reverse mapping table 242 to ensure that access by the I / O device is permitted. As another example, in embodiments where pages owned by the virtual machine are encrypted, the IOMMU 244 and / or I / O devices 208, 210 use corresponding keys, etc., to encrypt and decrypt information retrieved from or to the pages.

[0063] In some embodiments, communication paths are coupled between various functional blocks (processing cores 214, 216, memory management unit 228, memory 204, etc.) in computing device 200, as shown by arrow lines between the elements. The communication paths include one or more buses, wires, leads, and / or other connections that may be associated with controllers, structural elements (switches, routers, etc.), circuit elements, etc. The communication paths can be used to route commands, data, control signals, and / or other information between functional blocks. For example, in some embodiments, a coherent bus structure is coupled between IO hub 212, processor 202 (e.g., MMU 228), and memory 204. It will be understood that for clarity, the communication paths are described in detail below. Figure 2 Various communication paths are omitted.

[0064] It will be understood that although the specific embodiments discussed herein include a particular arrangement of processing cores, 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 may use any arrangement of processing cores that can perform the operations described herein.

[0065] 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. Additionally, 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 in processor 202). As another example, some embodiments include different levels of caches, ranging from only one level of cache to multiple levels of cache, and these caches may be located within processor 202 and / or external to processor 202. Generally speaking, the described embodiments may use any arrangement of caches that can be used to perform the operations described herein.

[0066] Although for illustrative purposes Figure 2 The computing device 200 and processor 202 are simplified in FIG. 1 , but in some embodiments, the 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, the 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.

[0067] The processor 202, memory 204, mass storage device 206 and I / O devices 208, 210 are operable by Figure 1 10 and I / O devices 114 in the embodiment of the present invention. Thus, in some embodiments, the host operating system 108, IOMMU 112, and / or hypervisor 106 interface between the processor 202, memory 204, mass storage 206, and I / O devices 208, 210 and the virtual machine 100, guest operating system 102, and program 104. In these embodiments, the computing device 200 (e.g., processing cores 214, 216, etc.) executes the hypervisor 106, the virtual machine 100, the guest operating system 102, and program 104, as well as the host operating system 108 (in embodiments in which the host operating system 108 is present). Furthermore, references in this specification to a "computing device" and elements within a computing device may refer to the computing device 200 and associated elements.

[0068] In some embodiments, Figure 2 208 , 210 are implemented together. For example, in a "system on a chip" embodiment, the IO hub 212 and some or all of the I / O devices 208 and 210 are combined with the processor 202, such as being manufactured on the same integrated circuit chip. In other words, for such embodiments, the IO hub 212 and the I / O devices 208 and 210 can be integrated with other functional blocks or located in other functional blocks.

[0069] The computing device 200 may be or may be included in any electronic device that performs computing operations. For example, the 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, virtual or augmented reality equipment, a network device, a toy, an audio-visual device, a home appliance, a controller, a vehicle, and / or a combination thereof.

[0070] Figure 3 An RMT 342 is illustrated including an RMT segment index 341 and n RMT segments 343. While the specific configuration of the RMT 342 may vary across multiple implementations and is flexible, various memory and storage parameters are provided as example configurations in the following discussion for purposes of illustration.

[0071] In the depicted embodiment, each RMT segment entry is 16B in size and corresponds to a specific 4kB page of system memory. The size and location of the RMT segment index 341 can be configured via software, such as by specifying RMT_BASE and RMT_END parameters (which represent the addresses pointing 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.

[0072] The RMT segment index 341 includes an RMT counter table 344, which, in the depicted embodiment, is 16 kB in size and contains counters used to enforce security properties when changing encryption keys, and specifies up to n RMT segments 343 (e.g., n=512). Each RMT segment 343 corresponds to a specific range of physical addresses. The size of each RMT segment 343 is configurable (and, in at least the depicted embodiment, is substantially the same), thereby enabling flexibility for various system configurations. To access an RMT entry for a target virtual memory page address (virtual page address), a processor (e.g., Figure 2The processor 202) first uses a subset of bits in the virtual page address to identify the relevant RMT segment index entry of the virtual page address; 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.

[0073] As follows about Figure 4 Described in more detail, within each RMT segment 343, each system physical address corresponds to a single RMT entry. Although the depicted embodiment allows for a maximum of n=512 RMT segments 343, the actual number of NUMA nodes in a typical system is much smaller. To improve RMT lookup performance, the hardware can cache information about several RMT segments so that the RMT segment index does not need to be consulted on every lookup. Under the example system configuration, valid entries in the RMT segment index are fully cached by the hardware, resulting in a substantially negligible overall performance impact. In some embodiments, each individual RMT segment 343 is mapped to a single NUMA node; for optimal performance, the RMT segment 343 exists on the same NUMA node as the memory page entry it describes.

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

[0075] In the depicted embodiment, configuration of the segmented RMT 342 is provided via various specified non-exclusive example parameters. Specifically, 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 2. For example, a minimum segment size of 4GB can be stored as 32 (because 2^32=4GB). Segment size refers to the amount of system physical address covered by one entry in the RMT segment index 341. It will be understood that the maximum segment size will be greater than or equal to the minimum segment size; further, if they are equal, only a single segment size will be supported.

[0076] Relative to Figure 3 Continuing with the example configuration of , an example lookup operation for system physical page address X in segment RMT 342 is performed as follows:

[0077] ·Calculate RMTIndex=X[RMTSegmentSize+8:RMTSegmentSize]

[0078] Read the 8B RMT segment index entry at RMT_BASE+0x4000+RMTIndex*8

[0079] If X[RMTSegmentSize-1:30]>=MappedSize, then no RMT entry is associated with this address

[0080] If SGMNT_BASE is not a valid physical address, terminate the table walk (e.g., with a reserved bit fault)

[0081] Access the 16B RMT entry at {RmtSegmentBase,20'b0}+{X[RMTSegmentSize-1:12],4'b0}

[0082] In some embodiments, if no RMT entry is associated with physical address X, then physical address X is considered to be part of a hypervisor-owned page.

[0083] Figure 4 An example RMT segment 443 (which in various aspects may be used with Figure 2 RMT Section 243 and / or Figure 3 4. Although the depicted embodiment shows RMT segment 443 as including specific specified information, in various embodiments, one or more different arrangements or types of information may be included. Generally speaking, the entries 400 in RMT segment 443 include sufficient information to perform the operations described herein.

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

[0085] 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 sub-page count 408, a size indicator 410, an assigned indicator 412, a locked indicator 414, an immutable indicator (IMMT) 416, a verified indicator 418 and a virtual machine license level (VMPL) block 420.

[0086] The global shared page indicator 402 is an indicator of whether the corresponding page is shared by two or more virtual machines. Generally speaking, when a page is shared, the page can be accessed (usually in a read-only manner) by two or more virtual machines.

[0087] The client identifier 404 is an identifier associated with the virtual machine to which the corresponding page is allocated. For example, when the corresponding page is allocated for use by a specific virtual machine, the identifier of the specific virtual machine is recorded in the client identifier 404. The client identifier 404 may store an address space identifier (ASID), an ID string, a name, and / or another value that identifies the virtual machine—or identifies the page as allocated to a hypervisor, shared among multiple virtual machines, or otherwise distributed.

[0088] The guest physical address 406 is a value representing a guest physical address associated with the system physical address of the entry. 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 to be used by the virtual machine to address the page is recorded in the corresponding entry 400 in the RMT segment 443. In this way, one record consists of the specific guest physical address to be used by the virtual machine to which each page is allocated. Recording this information enables a table walker (e.g., table walker 230 or IO table walker 246) to determine whether the system physical address is mapped to the expected guest physical address when checking the system physical address obtained during a traversal of the nested page table, that is, whether the system physical address has been mapped to two different guest physical addresses at the same time. This makes it possible to detect whether the mapping has been maliciously or erroneously changed by the hypervisor or another entity.

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

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

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

[0092] 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 reset / cleared, entry 400 is considered free or available. Once entry 400 has been locked by a given hardware or software entity, other hardware and software entities in computing device 200 are prevented from accessing entry 400 (e.g., reading, writing / updating, etc.). 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 an embodiment where lock indicator 414 is a single bit and is initially cleared (e.g., set to zero), an entity may set lock indicator 414 (e.g., to 1), access entry 400 one or more times, and then clear lock indicator 414 when it has completed accessing entry 400. Using lock indicator 414, the described embodiments can avoid race conditions and other conditions that could cause simultaneous reading and / or writing of entry 400.

[0093] 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 by a software entity (e.g., a hypervisor, a client operating system, an application, etc.) executed on the kernel (e.g., kernel 214-216). In other words, the immutable page is prevented from being overwritten, updated or modified, added or removed, etc., in whole or in part, by any software entity. In addition, the immutable page will be deallocated by the platform security processor (e.g., platform security processor 226) and cannot be deallocated by the kernel, which includes a kernel acting on behalf of a software entity (e.g., a hypervisor, etc.) executed thereon or under the control of the software entity. Immutable pages are described in more detail in U.S. patent application serial number 15 / 417,632, which is incorporated herein by reference as described above.

[0094] Verified indicator 418 is an indicator of whether entry 400 has been verified by the virtual machine (i.e., the virtual machine to which the corresponding page is allocated). The virtual machine updates verified indicator 418 (e.g., sets one or more bits of verified indicator 418 to a specified value such as 1) to indicate that entry 400 is verified, thereby "marking" entry 400 as verified. For example, the virtual machine may verify the corresponding entry in RMT segment 443 immediately when the page is allocated, or may delay verification, such as verifying the entry when the page is initially accessed or when a verification failure for the page is received. In some embodiments, the virtual machine executes a dedicated instruction to perform verification / update of verified indicator 418. When entry 400 is updated, such as when the hypervisor changes the 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.

[0095] Virtual Machine Permission Level (VMPL) block 420 includes permission sets for several permission levels for the page associated with entry 400. In some embodiments, computing device 200 supports two or more permission levels, each permission level being associated with permissions for a specified set of operation types (e.g., enable / disable, allow / not allow, etc.) 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 permission set for each permission level may be different, such that a given operation type in a first permission level may have different permissions than the same operation type in a second permission level. For example, writing data may be allowed in a first permission level for a page, but not allowed in 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.

[0096] Figure 5 A flow diagram illustrating an operational routine 500 suitable for handling memory access requests in a secure computing system, according to some embodiments.

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

[0098] At block 510 , a physical memory address associated with the specified virtual memory address is identified. The routine proceeds to block 515 .

[0099] At block 515 , a segment reverse mapping table stored in a non-contiguous portion of physical memory is accessed. The routine proceeds to block 520 .

[0100] At block 520, the routine determines whether the requestor associated with the memory access request received in block 505 is authorized to access the physical memory address identified in block 510. If so, the routine proceeds to block 525, where access to the identified physical memory address is provided to the requestor. Otherwise, the routine proceeds to block 530, and the requestor is prevented from accessing the identified physical memory address.

[0101] In some embodiments, the above-mentioned 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 in the design and manufacture of these IC devices. These design tools are typically represented as one or more software programs. One or more software programs include code that can be executed by a computer system to manipulate the computer system to operate on the code representing the circuit of one or more IC devices in order to perform at least a portion of the process for designing or adjusting a manufacturing system to manufacture the circuit. The code may include instructions, data, or a combination of instructions and data. Software instructions representing a design tool or a manufacturing tool are typically stored in a computer-readable storage medium accessible to a computing system. Similarly, codes representing one or more stages of the design or manufacture of an IC device can be stored in and accessed from the same computer-readable storage medium or different computer-readable storage media.

[0102] Computer-readable storage media may include 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 tapes, or 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 microelectromechanical systems (MEMS)-based storage media. Computer-readable storage media may be embedded in a computing system (e.g., system RAM or ROM), fixedly attached to a computing system (e.g., a magnetic hard drive), removably attached to a computing system (e.g., an optical disc or flash memory based on a universal serial bus (USB)), or coupled to a computer system via a wired or wireless network (e.g., a network accessible storage device (NAS)).

[0103] In some embodiments, certain aspects of the above-mentioned technology can be implemented by one or more processors of a processing system that executes software. The software includes one or more sets of executable instructions that are stored or otherwise tangibly embodied on a non-transitory computer-readable storage medium. The software may include instructions and certain data that, when executed by one or more processors, manipulate the one or more processors to perform one or more aspects of the above-mentioned technology. 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 a flash memory, a cache, a random access memory (RAM), or other one or more non-volatile memory devices. The executable instructions stored on the non-transitory computer-readable storage medium may be source code, assembly language code, object code, or other instruction formats that are interpreted or otherwise executed by one or more processors.

[0104] It should be noted that not all activities or elements described above in the general description are required, a particular activity or part of the device may not be required, and one or more additional activities may be performed, or elements may be included in addition to those described. Furthermore, the order in which the activities are listed is not necessarily the order in which they are performed. In addition, these concepts have been described with reference to specific embodiments. However, it is understood by those skilled in the art that various modifications and changes may be made without departing from the scope of the present disclosure as set forth in the following claims. Accordingly, the specification and drawings are to be regarded as illustrative rather than restrictive, and all such modifications are intended to be included within the scope of the present disclosure.

[0105] Benefits, other advantages and solutions to problems have been described above with respect to specific embodiments. However, benefits, advantages, solutions to problems, and any features that may cause any benefit, advantage, or solution to appear or become more pronounced should not be construed as key, required, or essential features of any or all of the claims. Furthermore, the specific embodiments disclosed above are merely illustrative, as the disclosed subject matter may be modified and practiced in different but equivalent manners that will be apparent to those skilled in the art having the benefit of the teachings herein. No limitation is intended to the details of construction or design shown herein, except as described in the claims below. It is therefore apparent that the specific embodiments disclosed above may be changed or modified, and all such variations are considered to be within the scope of the disclosed subject matter. Accordingly, the protection sought herein is as set forth in the claims below.

Claims

1. A method for handling memory access in a computing system, the method comprising: converting a virtual memory address specified by a memory access request into a physical memory address associated with the virtual memory address; as well as In response to an indication at a segmented reverse mapping table (RMT) that a requester associated with the memory access request is authorized to access the associated physical memory address, access to the physical memory address is provided to the requester, the segmented RMT being stored in a non-contiguous portion of the physical memory of the computing system.

2. The method of claim 1 , wherein the segmented RMT comprises an RMT segment index comprising a plurality of index entries, each of the plurality of index entries corresponding to one of the plurality of segments of the segmented RMT stored in the non-contiguous portion of the physical memory. 3 . The method of claim 2 , wherein each of the plurality of segments comprises a plurality of segment entries, each segment entry corresponding to a different physical address.

4. The method of claim 3 , wherein the computing system executes one or more virtual machines, each of the one or more virtual machines being allocated a portion of physical memory, and wherein the segment entries of the plurality of segments include all of the physical memory allocated to the one or more virtual machines.

5. The method of any one of claims 2 to 4, wherein the physical memory of the computing system comprises a plurality of non-uniform memory access (NUMA) memory nodes, and wherein each segment of the plurality of segments is mapped to a respective NUMA memory node. 6 . The method of claim 5 , wherein at least one segment of the plurality of segments is stored on the corresponding NUMA memory node mapped by the at least one segment.

7. The method according to any one of claims 2 to 6, wherein the RMT segment index further comprises an RMT counter table, the RMT counter table comprising one or more counters, each of the one or more counters being associated with one or more encryption keys.

8. The method of any one of claims 1 to 7, wherein identifying the physical memory address is performed by a table walker of the computing system.

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

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

11. A computing device, comprising: processor; Table Walker; and a memory storing a segment reverse mapping table (RMT) in a plurality of non-contiguous portions of the memory; The table walker is configured as follows: converting a virtual memory address specified by a memory access request into a physical memory address associated with the virtual memory address; and In response to an indication at the RMT that a requestor associated with the memory access request is authorized to access the associated physical memory address, access to the associated physical memory address is provided to the requestor.

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

13. The computing device of claim 12, wherein each of the plurality of segments comprises a plurality of segment entries each corresponding to a different physical address of the memory.

14. The computing device of claim 13, wherein the computing device executes one or more virtual machines, each of the one or more virtual machines being allocated a portion of the memory, and wherein the segment entries of the plurality of segments include all of the memory allocated to the one or more virtual machines.

15. The computing device of any one of claims 12 to 14, wherein the memory comprises a plurality of non-uniform memory access (NUMA) memory nodes, and wherein each segment of the plurality of segments is mapped to a respective NUMA memory node.

16. The computing device of claim 15, wherein at least one segment of the plurality of segments is stored on the corresponding NUMA memory node mapped by the at least one segment.

17. A computing device according to any one of claims 12 to 16, wherein the RMT segment index further comprises an RMT counter table, the RMT counter table comprising one or more counters, and wherein each of the one or more counters is associated with one or more encryption keys.

18. The computing device of any one of claims 11 to 17, further comprising an input / output (I / O) memory management unit (IOMMU), wherein the requestor is an I / O device communicatively coupled to the computing device, and wherein the table walker is a hardware table walker associated with the IOMMU.

19. A computing device according to any one of claims 11 to 17, the computing device further comprising one or more virtual machines executing on the computing device, each of the one or more virtual machines being assigned a corresponding plurality of physical memory addresses, and wherein the requester is one of the one or more virtual machines.

20. A computing device, the computing device being configured to: storing a segmented reverse mapping table (RMT) in a plurality of non-contiguous portions of a memory having a plurality of physical memory addresses, the segmented RMT comprising an RMT segment index comprising a plurality of index entries, the plurality of index entries each corresponding to a segment of a plurality of segments of the segmented RMT stored in the non-contiguous portions of the memory; converting a virtual memory address specified by a memory access request into a physical memory address associated with the virtual memory address; and In response to an indication at the segment RMT that a requestor associated with the memory access request is authorized to access the associated physical memory address, access to the associated physical memory address is provided to the requestor.

Images