Techniques for providing access protection to shared virtual memory

Abstract

Various embodiments generally relate to techniques for shared virtual memory (SVM) access protection, e.g., such as by performing a security check whenever a write request arrives from a SVM device. Some embodiments particularly relate to an input / output memory management unit (IOMMU) that prevents a SVM device from modifying a code page as a result of a memory transaction request by generating an access request fault and / or a translation complete with read-only access in response to the memory transaction request.

Description

Background Technology

[0001] Shared memory can refer to memory that can be accessed simultaneously by multiple programs or processes to facilitate communication between them or to avoid redundant copies. Virtual memory can refer to memory management techniques that map memory addresses (called virtual addresses) used by programs or processes to physical addresses in computer memory. In various embodiments, the translation from physical address to virtual address and from virtual address to physical address can occur transparently to the program or process. Typically, the operating system (OS) manages the virtual address space and the allocation of physical memory to virtual memory. Attached Figure Description

[0002] Figure 1 An embodiment of the first operating environment is illustrated.

[0003] Figure 2A An embodiment of the second operating environment is illustrated.

[0004] Figure 2B An embodiment of the third operating environment is illustrated.

[0005] Figure 3 An embodiment of the fourth operating environment is illustrated.

[0006] Figure 4 An embodiment of the fifth operating environment is illustrated.

[0007] Figure 5A An embodiment of the first logic flow is illustrated.

[0008] Figure 5B An embodiment of the second logic flow is illustrated.

[0009] Figure 6A An example of the third logic flow is illustrated.

[0010] Figure 6B An example of the fourth logic flow is illustrated.

[0011] Figure 7 An example of a storage medium is illustrated.

[0012] Figure 8 An example of a computing architecture is illustrated.

[0013] Figure 9 An example of a communication architecture is illustrated. Detailed Implementation

[0014] For example, various embodiments generally relate to techniques for shared virtual memory (SVM) access protection, such as performing a security check whenever a write request arrives from the SVM device. Some embodiments particularly relate to an input / output memory management unit (IOMMU) that prevents the SVM device from modifying code pages due to a memory transaction request by generating an access request failure and / or a translation completion with read-only access in response to the memory transaction request. In various embodiments, a memory transaction request may include one or more of a memory access request and a memory translation request. In one embodiment, for example, means for memory access protection may include memory and logic for the IOMMU, at least a portion of which is implemented in circuitry coupled to the memory. In various embodiments, the logic may receive a memory access request, identify a cache translation entry associated with an address included in the memory access request, and determine whether to execute the memory access request based on the type of the memory transaction request and the set of permissions included in the cache translation entry. In some embodiments, the logic may receive a memory translation request and determine whether to generate a translation completion with read-write access or read-only access based on whether the memory page associated with the translation request is executable. These and other embodiments are described and claimed.

[0015] Some challenges faced by the IOMMU include the inability to perform security checks to prevent SVM devices from modifying code pages. These challenges can arise from the SVM device's ability to implicitly access the entire process memory space. In some cases, these challenges can provide attack vectors for malicious users. For example, a malicious user could manipulate the SVM device's workload to compromise the CPU's process memory and hijack its control flow. Adding further complexity, many applications can choose their own read, write, and execute permissions for memory pages. For example, sometimes both write and execute permissions can be granted simultaneously, such as in Just-In-Time (JIT) code, packagers, self-modifying code, and kernel scenarios. These and other factors can lead to poor security and limited functionality for the IOMMU. Such limitations can significantly reduce the IOMMU's usability and applicability, resulting in ineffective systems with security vulnerabilities and limited functionality.

[0016] The various embodiments described herein include an IOMMU that can prevent SVM devices (such as hardware accelerators, e.g., graphics processing units (GPUs)) from modifying CPU code pages by performing one or more security checks. In one or more embodiments, the security checks can operate to restrict write access to CPU code pages originating from the SVM device. This and other features described herein prevent the SVM device from being used to attack and manipulate the behavior of the CPU. For example, in some embodiments, the IOMMU can perform security checks such that whenever a write request arrives from the SVM device, an access violation fault is generated and... The request is then terminated. In another example, the IOMMU can perform a security check such that whenever a memory translation request corresponding to a write operation arrives from the SVM device, a translation completion with read-only access is generated if the memory page associated with the translation request is executable. This prevents malicious or vulnerable devices from corrupting the CPU's process memory and causing arbitrary code execution with the privileges of the CPU process. Additionally, in various embodiments, efficiency can be achieved by performing security checks based on one or more bits in cache entries, such as in a translation backstop (TLB) cache. In various such embodiments, this prevents overhead such as additional page traversal.

[0017] In these and other ways, IOMMU enables reliable and efficient security checks to achieve improved shared virtual memory access protection from SVM devices, while reducing attack vectors for malicious users, resulting in several technical effects and advantages.

[0018] Referring generally to the notation and nomenclature used herein, one or more parts of the following detailed description are presented in relation to program procedures that can be executed on a computer or a network of such computers. These process descriptions and representations are used by those skilled in the art to most effectively convey the nature of their work to others skilled in the art. A process herein and generally is conceived as a self-consistent sequence of operations that lead to a desired result. These operations are those that require the physical manipulation of physical quantities. Typically, though not always, these quantities take the form of electrical, magnetic, or optical signals that can be stored, transferred, combined, compared, and otherwise manipulated. Sometimes, primarily for reasons of common usage, these signals are referred to as bits, values, elements, symbols, characters, items, numbers, etc., as is convenient. However, it should be noted that all these and similar terms will be associated with the appropriate physical quantities and are merely convenient labels applied to those quantities.

[0019] Furthermore, these manipulations are often referred to using terms such as addition or comparison that are typically associated with mental operations performed by a human operator. However, in any of the operations described herein that form part of one or more embodiments, such an ability of a human operator is not required, or in most cases desired. Instead, these operations are machine operations. Useful machines for performing the operations of the various embodiments include general-purpose digital computers, such as those selectively activated or configured by computer programs stored internally and written in accordance with the teachings herein, and / or include means specifically constructed for the desired purpose. The various embodiments also relate to means or systems for performing these operations. These means may be specifically constructed for the desired purpose or may include general-purpose computers. The desired structures for the various such machines will be apparent from the given description.

[0020] Referring now to the accompanying drawings, in which similar reference numerals are used throughout to denote similar elements. In the following description, numerous specific details are set forth for illustrative purposes to provide a thorough understanding. However, it may be apparent, however, that novel embodiments may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form for ease of description. It is intended to cover all modifications, equivalents, and substitutions within the scope of the claims.

[0021] Figure 1 An example of an operating environment 100, which may represent various embodiments, is illustrated. Operating environment 100 may include shared virtual memory (SVM) devices 102-1, 102-2, 102-n, an input / output memory management unit (IOMMU) 104, shared virtual memory (SVM) 106, and a CPU 108. In operating environment 100, IOMMU 104 may support memory operations between SVM devices 102-1, 102-2, 102-n and SVM 106. For example, IOMMU 104 may restrict write access to CPU code pages (e.g., CPU 108) originating from SVM devices (e.g., SVM devices 102-1, 102-2, or 102-n), preventing the SVM devices from being used to attack and manipulate CPU behavior. Embodiments are not limited in this context.

[0022] In various embodiments, IOMMU 104 can facilitate and control memory operations between SVM devices 102-1, 102-2, 102-n and SVM 106. In various such embodiments, IOMMU 104 can be a memory management unit that connects an input / output (I / O) bus supporting direct memory access (DMA) to main memory. In one or more embodiments, SVM device 102 can issue memory transaction requests to IOMMU 104. In one or more such embodiments, memory transaction requests can include one or more of memory access requests and memory translation requests. In various embodiments, memory access requests can include read and / or write operations. In many embodiments, memory translation requests can include translation of memory addresses between various mappings (e.g., virtual, linear, physical, etc.). In many such embodiments, memory translation requests can utilize the Address Translation Service (ATS) protocol. In some embodiments, main memory can be any memory directly accessible to CPU 108. For example, main memory can include random access memory (RAM). In various embodiments, main memory can be communicatively coupled to CPU 108 via a memory bus. In various such embodiments, the IOMMU 104 may receive the memory transaction request before it travels across the memory bus. In other such embodiments, the IOMMU 104 may receive the memory transaction request after it has traveled across the memory bus. In the same or similar manner, the IOMMU 104 may receive the memory transaction request from the SVM device.

[0023] In one or more embodiments, the operating environment 100 may include a set of one or more IOMMUs. For example, SVM device 102-1 may have a dedicated IOMMU, while SVM devices 102-2, 102-n share a second IOMMU. Various embodiments described herein may include one or more IOMMUs that perform security checks internally. In various such embodiments, security checks may be implemented in dedicated hardware and / or circuitry. In one or more embodiments, CPU 108 may have or utilize an MMU. In some embodiments, security checks may be performed without modifying any existing control flow (e.g., that of CPU 108). In various embodiments, security checks may be performed without additional page traversal. In one or more embodiments, these capabilities enable global and high-impact remediation of security vulnerabilities with minimal hardware changes.

[0024] In some embodiments, IOMMU 104 enables processes of CPU 108 to directly share the resources of SVM 106 with one or more SVM devices (e.g., SVM devices 102-1, 102-2, 102-n). From a software application perspective, this allows for seamless pointer-based data structure sharing, while from a system perspective, it allows for process memory page table sharing and device page faults. However, by using SVM 106, SVM devices can implicitly access the entire 64-bit process memory, and without IOMMU 104 performing security checks to restrict write access to CPU code pages originating from SVM devices, SVM devices can be used as components to attack and manipulate CPU behavior.

[0025] Therefore, in one or more embodiments described herein, the IOMMU 104 may perform security checks to determine whether or how to execute a memory transaction request (e.g., a memory translation request and / or a memory access request) based on one or more attributes of the request (such as source or type) and an associated set of permissions. For example, the determination of whether to execute a memory transaction request may be based on one or more of the following: whether the source of the memory transaction request is an SVM device; whether the memory transaction request is a memory translation request; whether the memory transaction request includes or is associated with a write request; whether the associated set of permissions allows or restricts the memory transaction request; whether the memory page associated with the memory transaction request exists in main memory; and whether the memory page associated with the memory transaction request is executable. In some embodiments, the associated set of permissions may be included in translation entries stored in a cache.

[0026] In some embodiments, when IOMMU 104 receives a memory transaction request for SVM 106, it can determine whether the source of the memory transaction request is an SVM device (e.g., SVM device 102-1, 102-2, or 102-N). In some such embodiments, when IOMMU 104 determines that a memory transaction request has been received from an SVM device, it can determine whether the memory transaction request is a write request. However, if the memory transaction request is not from an SVM device and / or is not a write request, IOMMU 104 can service the memory transaction request by transferring data from SVM 106 to / from the source of the memory transaction request to SVM 106. For example, when a memory transaction request including a read request is received from SVM device 102-2, IOMMU 104 can service the read request by transferring data from SVM 106 to SVM device 102-2.

[0027] In various embodiments, when IOMMU 104 receives a memory transaction request including a write request from an SVM device, IOMMU 104 can identify the memory page associated with the write request in SVM 106 and determine whether the associated memory page exists and is executable. In various such embodiments, when the memory page associated with the write request exists and is executable, IOMMU 104 can generate an access violation fault and can terminate the request. However, if the memory page associated with the write request does not exist and / or is not executable, IOMMU 104 can service the write request. For example, when a write request is associated with a memory page that is not executable in SVM 106, IOMMU 104 can service the write request by transferring data from the requesting SVM device (e.g., SVM device 102-1, 102-2, or 102-n) to SVM 106 for storage.

[0028] In some embodiments, IOMMU 104 can map device-visible virtual addresses to physical addresses according to a paging architecture. In some such embodiments, IOMMU 104 can utilize one or more of a memory transaction request, cache entry, page table, page directory, or page directory pointer table supported by a paging architecture to translate the device-visible virtual address to a physical address, identify the memory page associated with the memory transaction request, determine whether the memory page associated with the memory transaction request exists in main memory, and / or determine whether the memory page associated with the memory transaction request is executable. For example, SVM device 102-1 can send a memory transaction request including a device-visible virtual address to IOMMU 104. IOMMU 104 can then identify or determine one or more of a cache entry, page directory pointer, page directory entry, page table entry, memory page, and physical address associated with the memory transaction request based on the virtual address.

[0029] In various embodiments, the paging architecture may support one or more information bits in one or more of cache entries, page directory entries, page table entries, memory pages, physical addresses, or other locations. In various such embodiments, these information bits may be used by the IOMMU 104 to determine one or more characteristics or attributes of a memory transaction request, such as whether the memory page associated with the memory transaction request is present, readable, writable, or executable. For example, a page table entry associated with a memory transaction request may include information bits used by the IOMMU 104 to determine whether the memory page associated with the memory transaction request exists and whether the memory page associated with the memory transaction request is executable. In one or more embodiments, the paging architecture may support Physical Address Extension (PAE).

[0030] In some embodiments, a paging architecture can be used that supports information bits for indicating the presence of a memory page in main memory. In some such embodiments, this information bit may be referred to as a present bit. In various embodiments, the IOMMU 104 may determine whether a memory page associated with a memory transaction request exists in main memory based on the present bit. For example, a memory page associated with a memory transaction request may exist in main memory if the present bit is 1, and not exist in main memory if the present bit is 0. In various embodiments, the present bit may be a PAE bit. In some embodiments, the present bit may be part of each page table entry. In some such embodiments, the present bit may be the least significant bit of each page table entry.

[0031] In various embodiments, a paging architecture may be used that supports information bits for indicating whether a memory page is executable. In various such embodiments, this information bit may be referred to as an execution bit. In some embodiments, the execution bit can separate areas of memory used for storage of processor instructions (e.g., executable code) from areas used for data storage. In other words, the execution bit can define whether an associated memory page is available for use by a CPU (e.g., CPU 108) to execute code therefrom. In various embodiments, the execution bit may be used by the IOMMU 104 to determine whether a memory page associated with a memory transaction request is executable (i.e., whether the memory page is used for storage of processor instructions). For example, a memory page associated with a memory transaction request may be executable if the execution bit is 0, and not executable if the execution bit is 1. In some embodiments, the execution bit may be a PAE bit. In various embodiments, the execution bit may be part of each page table entry. In various such embodiments, the execution bit may be the most significant bit of each page table entry. In some embodiments, the execution bit may include a No-eXecute (NX) bit of the Intel® 64 and Intel® Architecture (IA) 32 paging architectures. In some such embodiments, the IOMMU 104 may determine whether a memory page associated with a memory transaction request is executable based on the NX bit.

[0032] In some embodiments, IOMMU 104 can be used to access physical memory or SVM 106. IOMMU 104 can translate addresses associated with memory transaction requests from client virtual addresses to client physical addresses via x86 page tables, and from client physical addresses to host physical addresses via extended page tables (EPTs). In various embodiments, the page table structure of all MMUs can be identical, enabling seamless sharing of physical memory between CPU 108 and SVM devices 102-1, 102-2, 102-n.

[0033] In one or more embodiments, security checks may utilize a page table structure. For example, the page table structure may include information about whether a particular page is executable (e.g., one or more sets of bits). In some such embodiments, this information may be included in one or more of the following: an NX bit, an execute disabled (XD) bit, an EPT SLEE bit, an EPT X bit, etc. In various embodiments, the IOMMU 104 may perform security checks. In various such embodiments, security checks may ensure that whenever a write request arrives from the SVM device, if the requested page exists (existence bit is 1) and the page is executable (accumulated X bit is 1), an address translation fault (ATF) is generated and the request is terminated. In one or more embodiments described herein, cache entries reflecting data about a memory transaction request may be generated in response to the memory transaction request. For example, a cache entry may reflect that the page associated with the memory transaction request is not writable (write access bit is 0). In some such examples, this may be reflected by a set of permissions included in the cache entry. The use of these cache entries can minimize performance overhead by preventing full page traversal.

[0034] As illustrated in the embodiments, IOMMU 104 can be communicatively coupled to SVM devices 102-1, 102-2, 102-n, and SVM 106. It should be understood that any number of SVM devices, as indicated by the 102-n notation, can be included in various embodiments. Therefore, the embodiments described herein can include one or more SVM devices. In some embodiments, an SVM device can include any device or component that utilizes shared virtual memory to enable a CPU process to directly share resources with that device or component. For example, the CPU and SVM device can share resources via a unified virtual address space. In various embodiments, an SVM device can include one or more of the following: a hardware accelerator, a graphics processing unit (GPU), a field-programmable gate array (FPGA), a system-on-a-chip (SoC), a speech processing unit (SPU), an input / output (I / O) device, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), etc.

[0035] Figure 2A Examples of operating environments 200, representing various embodiments, are illustrated. In addition to SVM device 102, IOMMU 104, and SVM 106, operating environment 200 may also include an exception handler 210. In operating environment 200, IOMMU 104 may perform a security check to determine whether a memory transaction request received from SVM device 102 should be serviced. In various embodiments, the security check may determine one or more of the following: whether the source of the memory transaction request is an SVM device, whether the memory transaction request is a write request, and whether the memory page associated with the memory transaction request exists in main memory and is executable. In various such embodiments, IOMMU 104 may determine that the memory transaction request passes the security check and is serviced unless the source of the memory transaction request is an SVM device, the memory transaction request is a write request, and the memory page associated with the memory transaction request exists in main memory and is executable. On the other hand, if IOMMU 104 determines that the memory transaction request fails the security check and should not be serviced, an access request failure may be generated and passed to exception handler 210. In one or more embodiments, security checks may be performed based on one or more entries in the IOMMU cache 206. Embodiments are not limited in this context.

[0036] In the illustrated embodiment, IOMMU 104 may include a request manager 202, a page manager 204, an IOMMU cache 206, and one or more IOMMU registers 208. In some embodiments, components of IOMMU 104 are operable to determine how to process memory transaction requests received from SVM device 102. For example, components of IOMMU 104 may be operable to restrict memory transaction requests that include write requests to code pages of CPU 108 originating from SVM device 102, so that SVM device 102 cannot be used to attack and manipulate the behavior of CPU 108. It should be understood that although the IOMMU 104 embodiment illustrated in FIG2 includes the request manager 202, page manager 204, IOMMU cache 206, and one or more IOMMU registers 208 components, the functionality of IOMMU 104 described herein can be implemented using any type, number, or combination of components.

[0037] In various embodiments, when IOMMU 104 receives a memory transaction request (such as a memory access request), request manager 202 can determine the source of the memory transaction request. For example, request manager 202 can determine that SVM device 102 is the source of the memory transaction request. In some embodiments, when the source of the memory transaction request is not an SVM device (e.g., SVM device 102-1), request manager 202 can determine that the memory transaction request passes a security check.

[0038] In some embodiments, if the request manager 202 determines that the source of the memory transaction request is an SVM device and the memory transaction request includes a write request, the page manager 204 or the IOMMU cache 206 can be used by the request manager 202 to identify the memory page associated with the memory transaction request. In various embodiments, the page manager 204 may use one or more of the memory transaction request, page table, page directory, or page directory pointer table to identify the memory page associated with the memory transaction request. Once the memory page associated with the memory transaction request is identified, the request manager 202 can use the page manager 204 and / or the IOMMU cache 206 to determine whether the memory page exists in main memory and whether the memory page is executable.

[0039] In various embodiments, the existence and / or executableness of a memory page associated with a memory transaction request can be determined based on one or more information bits (such as in a page table entry or cache entry). For example, page manager 204 can identify a page table entry associated with a memory transaction request. In such an instance, page manager 204 can determine the existence of a memory page associated with a memory transaction request based on the first bit in the page table entry and determine whether the memory page associated with the memory transaction request is executable based on the second bit in the page table entry. In some embodiments, page manager 204 can pass an indication of the existence and / or executableness of a memory page associated with a memory transaction request in main memory to request manager 202. In one or more embodiments, request manager 202 can make one or more of these determinations based on one or more entries in IOMMU cache 206. In one or more such embodiments, this can prevent page manager 204 from performing additional page traversal. In some embodiments, the existence and / or executableness of a memory page associated with IOMMU cache 206 or device cache 220 can be determined based on one or more entries in IOMMU cache 206 or device cache 220 (see [link to documentation]). Figure 2BThe CPU cache 214 is used in a manner that allows for the use of the memory. In various embodiments, the request manager 202 can determine whether a memory transaction request passes a security check based on the determination that the memory page associated with the memory transaction request exists in main memory and is executable. For example, if the memory page associated with the memory transaction request does not exist in main memory or is not executable, the request manager 202 can determine that the memory transaction request passes a security check. However, if the memory page associated with the memory transaction request exists in main memory and is executable, an access request failure can be generated, such as by the request manager 202 or the page manager 204. In various embodiments, the access request failure can then be passed to an exception handler 210. In various such embodiments, the exception handler 210 can terminate the memory transaction request in response to the access request failure. In one or more embodiments, the exception handler 210 can be implemented via the CPU 108. In some embodiments, the exception handler 210 can be part of an operating system (OS) or a virtual machine monitor (VMM) executed by the CPU 108.

[0040] In various embodiments, CPU 108 may include processing circuitry 212, CPU cache 214, and one or more CPU registers 216. In one or more embodiments, CPU 108 may implement one or more of an operating system (OS) or a virtual machine monitor (VMM). In some embodiments, this may be achieved via one or more registers (e.g., one or more IOMMU registers 208, one or more CPU registers 216, and device registers 222, see [link to documentation]). Figure 2B This enables or activates one or more security checks described herein. In various embodiments, IOMMU register 208 may include a bit indicating whether a particular version of the IOMMU is capable of performing one or more of these security checks. For example, a bit may be allocated in an extension capability register included in IOMMU register 208 to indicate the capability of IOMMU 104. In another instance, a bit may be allocated in a global command register included in CPU register 216. In other such instances, the bit may be used by software to activate or deactivate one or more security checks. In various embodiments, one or more of the registers described herein may be memory-mapped. In various such embodiments, memory-mapped registers may be set by hardware, and software may have read-only access.

[0041] Figure 2BExamples of operating environments 250, which may represent various embodiments, are illustrated. In one or more embodiments described herein, the operating environment 250 may be configured to utilize the ATS protocol. For this purpose, the SVM device 102 of the operating environment 250 may include a transaction manager 218, a device cache 220, and a device register 222. In various embodiments, the ATS protocol may provide mechanisms that allow the SVM device 102 to participate in memory translation processes, such as by providing its own cache (e.g., device cache 220) for its own memory transactions. In the operating environment 250, the IOMMU 104 may perform a security check to determine whether to service a memory transaction request received from the SVM device 102. In various embodiments, the security check may determine one or more of the following: whether the source of the memory transaction request is an SVM device, whether the memory transaction request is a translation request requiring write permissions, and whether the destination address associated with the memory transaction request is executable. In some embodiments, the IOMMU 104 may generate a translation completion with read-write access when the destination address is not executable, and generate a translation completion with read-only access when the destination address is executable. The embodiments are not limited in this context.

[0042] In one or more embodiments, integrating the cache with the SVM device 102 can prevent excessive demand on the IOMMU cache 206 by distributing address translation cache responsibilities. In one or more such embodiments, distributing address translation cache responsibilities can allow the SVM device utilizing the integrated cache to have less performance dependence on the size of the IOMMU cache 206. Furthermore, the integrated cache can ensure optimal access latency by enabling pre-translated memory transaction requests to be sent to the MMU.

[0043] In some embodiments, the ATS protocol can classify memory transaction requests into two types: memory access requests and memory translation requests. In various embodiments, the SVM device uses memory access requests to send memory read / write requests to a translation agent (such as IOMMU 104). In various such embodiments, the memory access request may include an Address Type (AT) field, such as in the request header, indicating the type of address present (e.g., translated or untranslated). In some embodiments, the translation request is used by the SVM device to translate between different address mappings, such as from a virtual address to a physical address.

[0044] In various embodiments, memory transaction requests in operating environment 250 can be performed as follows. The ATS and SVM access control mechanisms can be initialized, for example, by the OS or VMM according to configuration. In some embodiments, the ATS and SVM access control mechanisms can be initialized by setting the ATS extended capability structure, SVM access control capability register, and page table in one or more IOMMUs. Once initialized, when a memory transaction is received via IOMMU 104, one or more checks can be performed to determine whether the request is a type-transformed request (e.g., the AT bit is 01b), whether the request was initiated by an SVM device, or whether the device is requesting write permission (e.g., the no-write (NW) bit is 0).

[0045] In one or more embodiments, if any of those requirements are not met, the IOMMU 104 performs conventional memory access and applies existing SVM access control mechanisms. However, if all those requirements are met, the IOMMU 104 may perform a page traversal on the requested page and check if the page's cumulative execution permissions are set (e.g., by considering one or more of the NXE, SLEE, EX, and / or X bits). If the requested page is executable, the IOMMU 104 responds to the SVM device with a translation completion message granting read-only permissions (e.g., RW bit set to 10b); however, if the requested page is not executable, it responds to the SVM device with a translation completion message granting read-write permissions (e.g., RW bit set to 11b). If the SVM device then requests translations for multiple pages, the next requested page is processed similarly until all memory translation requests have been served. Therefore, in various embodiments, if the target page is marked as executable by CPU 108, a translation request originating from SVM device 102 with write permissions will be rejected by IOMMU 104. In various such embodiments, existing write permissions may be ignored. In one or more embodiments, SVM device 102 may be prevented from modifying code pages (e.g., CPU 108 code pages) to ensure code integrity.

[0046] Figure 3Examples of operating environments 300 that may represent various embodiments are illustrated. In one or more embodiments described herein, the operating environment 300 may include a cache 302 having one or more translation entries 304-1, 304-2, 304-n. In the various embodiments described herein, translation entries 304 may be used to perform security checks on memory transaction requests. In various such embodiments, the performance of security checks using cache 302 can improve the efficiency of security checks by reducing the number of page traversals. In one or more embodiments, cache 302 may be the same as or similar to IOMMU cache 206, CPU cache 214, and / or device cache 220. In some embodiments, cache 302 may be a translation back buffer (TLB). Embodiments are not limited in this context.

[0047] Figure 4 Examples of operating environments 400 that may represent various embodiments are illustrated. In one or more embodiments described herein, the operating environment 400 may include a translation entry 452 having address translation 454 and translation metadata 458. In various embodiments, the translation entry 452 may be the same as or similar to one or more of translation entries 404-1, 404-2, 404-n. In some embodiments, the address translation 454 may include one or more corresponding addresses 456-1, 456-2, 456-n. In some such embodiments, each of the addresses 456 may correspond to a different address mapping, thereby enabling translation between different address mappings. For example, address 456-1 may correspond to a virtual address, address 456-2 may correspond to a linear address, and address 456-n may correspond to a physical address. Embodiments are not limited in this context.

[0048] In one or more embodiments, an address translation 454 may be used, for example, by request manager 202, to identify a translation entry associated with a memory transaction request. For example, a memory transaction request may include address 456-1. In some embodiments, translation entry 452 may also include translation metadata 458. In the various embodiments described herein, translation metadata 458 may be used to perform security checks on the memory transaction request. For example, a security check may include determining whether a permission set 460 allows or permits the requested memory transaction. In some embodiments, permission set 460 may refer to how the contents of an associated memory location can be manipulated. In the illustrated embodiments, permission set 460 may include permissions such as read 464, write 466, and execute 468. In one or more embodiments, each permission may include a bit, and if the bit is set, the associated permission is allowed, but if the bit is not set, the associated permission is disallowed. For example, if read permission 464 and execute permission 468 are set, but write permission 466 is not set, the associated memory location can be read (e.g., by IOMMU 104) and executed (e.g., by CPU 108); however, the associated memory location cannot be written to. Additionally, in some embodiments, translation metadata 458 may include additional data 462. In some such embodiments, additional data 462 may provide more information about the block of memory associated with translation entry 452, such as the length of the block. In one or more embodiments, translation entry 452 may include a set of bits. In one or more such embodiments, translation metadata 458 may include one or more subsets of that set of bits.

[0049] Figure 5A The illustration depicts one embodiment of a logical flow 500 that can represent operations performed in conjunction with providing shared virtual memory (SVM) access protection in various embodiments. The logical flow 500 can represent operations that can be performed by… Figure 1-2B Some or all of the operations are performed by one or more components (such as IOMMU 104) of the operating environment 100, 200, or 250. Implementations are not limited to this context.

[0050] exist Figure 5AIn the illustrated embodiment, logic flow 500 may begin at block 502. The IOMMU may be initialized at block 502, under the "Initialization" section. For example, initialization may be part of the Basic Input / Output System (BIOS) boot process. In some embodiments, initialization may include the BIOS boot process and additional functionality required by the BIOS to perform security checks, such as setting the page table, page directory, page directory pointer, information bits, etc. In various embodiments, initialization may prepare IOMMU 104 to monitor the memory path between SVM devices 102-1, 102-2, 102-n and SVM 106. In some embodiments, initialization may prepare multiple MMUs to monitor each of multiple memory paths. In one or more embodiments, initialization may include setting or evaluating one or more register values, such as one or more of IOMMU register 208, one or more of CPU register 216, and / or one or more of device register 222. In one or more such embodiments, the registers may include one or more of extension capability registers, global command registers, or SVM access control capability registers.

[0051] Proceeding to block 504, "Waiting for Access Request," may involve waiting for the receipt of a memory transaction request. In various embodiments, monitoring the memory path between the SVM device and the shared virtual memory may include waiting for the receipt of a memory transaction request. For example, IOMMU 104 may wait for the receipt of a memory transaction request by monitoring the memory path between SVM devices 102-1, 102-2, 102-n and SVM 106. In some embodiments, block 504 may be the first block in a continuous loop in which the device sends access requests to memory through IOMMU 104.

[0052] Access requests can be received at block 506, “Receive Access Request”. For example, IOMMU 104 can receive memory transaction requests from SVM devices 102-1, 102-2, or 102-n. In various embodiments, the access request may be aimed at reading data from or writing data to SVM 106. In some embodiments, request manager 202 may receive memory transaction requests from SVM device 102-1.

[0053] Continue to block 508 "Is the source an SVM device?" The IOMMU 104 can determine whether the source of a received memory transaction request is an SVM device. For example, the IOMMU 104 can determine whether the source of the memory transaction request is an SVM device 102-1, 102-2, or 102-n, or a non-SVM device. In some embodiments, the request manager 202 can determine the source of the memory transaction request. In various embodiments, the source of the memory transaction request can be determined based on one or more bits in the memory transaction request. For example, the memory transaction request may include a unique identifier used by the IOMMU 104 to determine the source of the memory transaction request.

[0054] Returning to reference block 508, if the source is not an SVM device, logic flow 500 can proceed to block 510, "Serving the Access Request". For example, IOMMU 104 can read from or write to SVM 106 in response to a memory transaction request originating from an SVM device (e.g., not SVM device 102-1, 102-2, or 102-n). In some embodiments, when the source of the memory transaction request is not an SVM device, IOMMU 104 can determine that the memory transaction request passes a security check. In various embodiments, serving the access request can be performed as it would in a conventional system. In some embodiments, once the memory transaction request has been served, logic flow 500 can return to block 504, "Waiting for Access Request," as part of a continuous loop. In some such embodiments, the continuous loop can exit only upon a power state change or a system setting change.

[0055] In some embodiments, serving a memory transaction request may include using IOMMU 104 (e.g., request manager 202, page manager 204, and / or IOMMU cache 206) to map a device-visible virtual address included in the memory transaction request to a corresponding physical address according to the paging architecture. In some such embodiments, IOMMU 104 may use one or more of the memory transaction request, page table, page directory, or page directory pointer table to translate the device-visible virtual address into a physical address and / or identify the memory page associated with the memory transaction request. For example, SVM device 102-1 may send a memory transaction request including a device-visible virtual address to IOMMU 104. IOMMU 104 may then identify or determine one or more of the cache entry (e.g., translation entry 452), page directory pointer, page directory entry, page table entry, memory page, and physical address associated with the memory transaction request based on the virtual address. In various embodiments, IOMMU 104 may retrieve and / or store data in SVM 106 as part of serving the memory transaction request.

[0056] Referring again to block 508, if the source is an SVM device, then logic flow 500 can proceed to block 512, "Write Request". For example, IOMMU 104 can determine whether a memory transaction request from SVM 102-1 includes a write request. In various embodiments, request manager 202 can determine whether a memory transaction request is a write request. In some embodiments, when a memory transaction request is not a write request, IOMMU 104 (e.g., request manager 202) can determine that the memory transaction request passes a security check. In various embodiments, when a memory transaction request is not a write request, logic flow 500 can proceed to block 510 "Serving the Access Request" and continue as described above. However, if the memory transaction request is a write request, logic flow 500 can proceed to block 514.

[0057] Does the page exist in block 514? At this point, it can be determined whether the memory page associated with the memory transaction request exists in main memory. For example, IOMMU 104 can utilize page manager 204 or cache 302 to determine whether the memory page associated with the memory transaction request exists in main memory. In some such examples, cache 302 may include one or more of IOMMU cache 206, SPU cache 214, or device cache 220. In various embodiments, main memory may refer to random access memory (RAM). In some embodiments, IOMMU 104 can utilize one or more of the following: a memory transaction request supported by a paging and / or caching architecture, a cache entry (e.g., translation entry 452), a page table, a page directory, or a page directory pointer table to determine whether the memory page associated with the memory transaction request exists in main memory. In various embodiments, a paging and / or caching architecture supporting information bits (e.g., presence bits) for indicating the presence of a memory page in main memory can be used. For example, the memory page associated with the memory transaction request may exist in main memory if the presence bit is 1, and not exist in main memory if the presence bit is 0. In some embodiments, the presence bit may be part of each page table entry. In some such embodiments, the presence bit may be the least significant bit of each page table entry. In various embodiments, the presence bit may be a PAE bit. In one or more embodiments, the presence bit may be included in a cache entry (such as translation entry 452).

[0058] Returning to reference block 514, if the page does not exist, logic flow 500 can proceed to block 510 "Serving the Access Request" and continue as described above. In some embodiments, when the memory page associated with the memory transaction request does not exist in main memory, block 510 may include paging the memory page associated with the memory transaction request into main memory. In various embodiments, when the memory page associated with the memory transaction request does not exist in main memory, IOMMU 104 may determine that the memory transaction request passes the security check. On the other hand, if the memory page associated with the memory transaction request exists in main memory, logic flow 500 can proceed to block 516.

[0059] At block 516, “Is the page executable?”, it can be determined whether the memory page associated with the memory transaction request is executable. For example, IOMMU 104 can utilize page manager 204 or cache 302 to determine whether the memory page associated with the memory transaction request is executable. In some such examples, cache 302 may include one or more of IOMMU cache 206, SPU cache 214, or device cache 220. In various embodiments, IOMMU 104 may utilize one or more of the memory transaction request supported by a paging and / or caching architecture, cache entries (e.g., translation entry 452), page tables, page directories, or page directory pointer tables to determine whether the memory page associated with the memory transaction request is executable. In some embodiments, a paging and / or caching architecture supporting information bits (e.g., execution bits) for indicating whether a memory page is executable can be used. In some such embodiments, the information bits may be one or more bits in a cache entry (such as translation entry 452). In various embodiments, the execution bit can define whether the associated memory page is available for use by the CPU (e.g., CPU 108) to execute code therefrom. In one or more embodiments, the execution bit may include one or more of NXE, SLEE, XD, or X bits.

[0060] In some embodiments, the execution bit may be used by the IOMMU 104 to determine whether a memory page associated with a memory transaction request is executable (i.e., whether the memory page is used for storing processor instructions). For example, a memory page associated with a memory transaction request may be executable when the execution bit is 0, and not executable when the execution bit is 1. In various embodiments, the execution bit may be a PAE bit. In some embodiments, the execution bit may be part of each page table entry. In various such embodiments, the execution bit may be the most significant bit of each page table entry. In some embodiments, the execution bit may include the No-eXecute (NX) bit of the Intel® 64 and IA-32 paging architectures.

[0061] Returning to reference block 516, if the page is not executable, logic flow 500 can proceed to block 510 "Serving the Access Request" and continue as described above. In various embodiments, when the memory page associated with the memory transaction request is not executable, IOMMU 104 can determine that the memory transaction request passes the security check. On the other hand, if the memory page associated with the memory transaction request is executable, logic flow 500 can proceed to block 518.

[0062] An access request failure can be generated at block 518, “Generate Access Request Failure.” For example, the IOMMU 104 can generate an access request failure when: at block 508 the source is identified as an SVM device (e.g., SVM devices 102-1, 102-2, 102-n); at block 512 the memory transaction request is determined to include a write request; at block 514 the memory page associated with the memory transaction request exists in main memory; and at block 516 the memory page associated with the memory transaction request is executable. In various embodiments, the generation of an access request failure may be in response to the IOMMU 104 determining that the memory transaction request has failed a security check. In some embodiments, the request manager 202 may generate an access request failure. In one or more embodiments, the page manager 204 may generate an access request failure.

[0063] Proceeding to block 520, “Signaling an Exception,” can inform the exception handler of an access request failure. For example, IOMMU 104 (e.g., request manager 202 and / or page manager 204) can generate an access request failure that includes an interrupt signal to inform exception handler 210 of the access request failure. In some embodiments, exception handler 210 may be part of the OS. In various embodiments, exception handler 210 may terminate the memory transaction request in response to an access request failure. In some embodiments, once the access request failure has been signaled to the exception handler, logic flow 500 may return to block 504, “Waiting for Access Request,” as part of a continuous loop.

[0064] Figure 5B The illustration depicts one embodiment of a logical flow 550 that can represent operations performed in conjunction with providing shared virtual memory (SVM) access protection in various embodiments. The logical flow 550 can represent operations that can be performed by… Figure 1-2B Some or all of the operations are performed by one or more components (such as IOMMU 104) of the operating environment 100, 200, or 250. Implementations are not limited to this context.

[0065] exist Figure 5B In the illustrated embodiment, logic flow 550 may begin at block 552. The IOMMU may be initialized at block 552, under the "Initialization" section. For example, initialization may be part of the Basic Input / Output System (BIOS) boot process. In some embodiments, initialization may include the BIOS boot process, as well as additional functionality required by the BIOS to perform security checks, such as setting the page table, page directory, page directory pointer, information bits, etc. In various embodiments, initialization may prepare IOMMU 104 to monitor the memory path between SVM devices 102-1, 102-2, 102-n and SVM 106. In some embodiments, initialization may prepare multiple MMUs to monitor each of multiple memory paths. In one or more embodiments, initialization may include setting or evaluating one or more register values, such as one or more of IOMMU register 208, one or more of CPU register 216, and / or one or more of device register 222. In one or more such embodiments, the registers may include one or more of extension capability registers, global command registers, or SVM access control capability registers.

[0066] Proceeding to block 554, "Waiting for Transaction Request," can involve waiting for the receipt of a memory transaction request. In various embodiments, monitoring the memory path between the SVM devices and the shared virtual memory can include waiting for the receipt of a memory transaction request. For example, IOMMU 104 can wait for the receipt of a memory transaction request by monitoring the memory path between SVM devices 102-1, 102-2, 102-n and SVM 106. In some embodiments, block 554 may be the first block in a continuous loop in which devices send access requests to memory via IOMMU 104.

[0067] A transaction request can be received at block 556, “Receive Transaction Request”. For example, IOMMU 104 can receive a memory transaction request from SVM devices 102-1, 102-2, or 102-n. In various embodiments, the transaction request may be for reading data from or writing data to SVM 106, or for converting between different address mappings. In one or more embodiments, the transaction request may conform to the ATS protocol. In some embodiments, request manager 202 may receive a memory transaction request from SVM device 102-1.

[0068] Continue to block 558 "Is the source an SVM device?" The IOMMU 104 can determine whether the source of the received memory transaction request is an SVM device. For example, the IOMMU 104 can determine whether the source of the memory transaction request is an SVM device 102-1, 102-2, or 102-n, or a non-SVM device. In some embodiments, the request manager 202 can determine the source of the memory transaction request. In various embodiments, the source of the memory transaction request can be determined based on one or more bits in the memory transaction request. For example, the memory transaction request may include a unique identifier used by the IOMMU 104 to determine the source of the memory transaction request. Returning to reference block 558, if the source is not an SVM device, the logic flow 550 can proceed to block 560 "Serving the Transaction Request". For example, the IOMMU 104 can read content from or write content to the SVM 106 in response to the memory transaction request not originating from an SVM device (e.g., not SVM device 102-1, 102-2, or 102-n). In some embodiments, when the source of the memory transaction request is not an SVM device, the IOMMU 104 can determine that the memory transaction request has passed the security check. In various embodiments, servicing the access request can be performed as it would in a conventional system. In some embodiments, once the memory transaction request has been served, logic flow 550 can return to block 554 "Waiting for Transaction Request" as part of a continuous loop. In some such embodiments, the continuous loop can exit only upon a change in power state or system settings.

[0069] In some embodiments, serving a memory transaction request may include utilizing IOMMU 104 (e.g., request manager 202, page manager 204, and / or IOMMU cache 206) to map a device-visible virtual address included in the memory transaction request to a corresponding physical address according to the paging and / or caching architecture. In some such embodiments, IOMMU 104 may utilize one or more of the memory transaction request, page table, page directory, or page directory pointer table to translate the device-visible virtual address into a physical address and / or identify the memory page associated with the memory transaction request. For example, SVM device 102-1 may send a memory transaction request including a device-visible virtual address to IOMMU 104. IOMMU 104 may then identify or determine one or more of the cache entry (e.g., translation entry 452), page directory pointer, page directory entry, page table entry, memory page, and physical address associated with the memory transaction request based on the virtual address. In various embodiments, IOMMU 104 may retrieve and / or store data in SVM 106 as part of serving the memory transaction request.

[0070] Referring again to block 558, if the source is an SVM device, then logic flow 550 can proceed to block 562 "Conversion Request". For example, IOMMU 104 can determine whether a memory transaction request from SVM 102-1 is a transformation request. In various embodiments, request manager 202 can determine whether a memory transaction request is a transformation request. In some embodiments, when a memory transaction request is not a transformation request, IOMMU 104 (e.g., request manager 202) can determine that the memory transaction request passes a security check. In various embodiments, when a memory transaction request is not a transformation request, logic flow 550 can proceed to block 560 "Serving the Transaction Request" and continue as described above. However, if the memory transaction request is a transformation request, logic flow 550 can proceed to block 564.

[0071] Block 564 "Write permission required" The logic flow 550 can determine whether a memory conversion request is associated with a write request or requires write permissions. For example, IOMMU 104 can determine whether a memory conversion request from SVM 102-1 requires write permissions or is associated with a write request. In various embodiments, request manager 202 can determine whether a memory conversion request requires write permissions or is associated with a write request. In some embodiments, when a memory conversion request does not require write permissions or is not associated with a write request, IOMMU 104 (e.g., request manager 202) can determine that the memory transaction request passes the security check. In various embodiments, when a memory transaction request does not require write permissions or is not associated with a write request, logic flow 550 can proceed to block 560 "Serving the Transaction Request" and continue as described above. However, if the memory transaction request requires write permissions or is associated with a write request, logic flow 550 can proceed to block 566.

[0072] In block 566, is the associated page executable? The IOMMU 104 can determine whether a memory page associated with a memory translation request is executable. For example, the IOMMU 104 can utilize one or more of the request manager 202, page manager 204, or cache 302 to determine whether a memory page associated with a memory transaction request is executable. In some such examples, cache 302 may include one or more of the IOMMU cache 206, SPU cache 214, or device cache 220. In various embodiments, the IOMMU 104 can utilize one or more of a memory transaction request supported by a paging and / or caching architecture, a cache entry (e.g., translation entry 452), a page table, a page directory, or a page directory pointer table to determine whether a memory page associated with a memory transaction request is executable. In some embodiments, a paging and / or caching architecture supporting information bits (e.g., execution bits) for indicating whether a memory page is executable can be used. In some such embodiments, the information bits may be one or more bits in a cache entry (such as translation entry 452). In various embodiments, the execution bit may define whether the associated memory page is executable by the CPU (e.g., CPU...). 108) Used to execute code therefrom. In one or more embodiments, the execution bit may include one or more of NXE, SLEE, XD, or X bits.

[0073] In some embodiments, the execution bit may be used by the IOMMU 104 to determine whether a memory page associated with a memory transaction request is executable (i.e., whether the memory page is used for storing processor instructions). For example, a memory page associated with a memory transaction request may be executable when the execution bit is 0, and not executable when the execution bit is 1. In various embodiments, the execution bit may be a PAE bit. In some embodiments, the execution bit may be part of each page table entry. In various such embodiments, the execution bit may be the most significant bit of each page table entry. In some embodiments, the execution bit may include the No-eXecute (NX) bit of the Intel® 64 and IA-32 paging architectures.

[0074] Returning to reference block 566, if the page is not executable, logic flow 550 can proceed to block 568, "Sending conversion completion with read-write access." Conversely, if the page is executable, logic flow 550 can proceed to block 570, "Sending conversion completion with read-only access." In various embodiments, when the memory page associated with the memory transaction request is not executable, IOMMU 104 can determine that the memory transaction request passes a security check, resulting in read-write permissions being granted. In some embodiments, when the memory page associated with the memory transaction request is executable, IOMMU 104 can determine that the memory transaction request fails a security check, resulting in read-only permissions being granted. In either case, the granted permissions can be transmitted in the conversion completion. In one or more embodiments, the conversion completion may include an address in a first mapping that corresponds to an address included in a second mapping in the memory conversion request. For example, the address in the first mapping may include a physical address and the address in the second mapping may include a virtual address.

[0075] Proceeding to block 572: "Are all related pages being served?" This can determine whether all pages associated with the conversion request have been served. If all associated pages have not yet been served, logic flow 550 can proceed to block 574 "Proceed to the next requested page", and return to block 566 "Is the associated page executable?" ", and continue as described above. On the other hand, if all associated pages have been served, logic flow 550 can proceed to block 554 "Waiting for transaction request" and continue as described above.

[0076] Figure 6A The illustration depicts one embodiment of a logical flow 600 that can represent operations performed in conjunction with providing shared virtual memory (SVM) access protection in various embodiments. The logical flow 600 can represent operations that can be performed by… Figure 1-2B Some or all of the operations are performed by one or more components (such as IOMMU 104) of the operating environment 100, 200, or 250. Implementations are not limited to this context.

[0077] exist Figure 6AIn the illustrated embodiment, logic flow 600 may begin at block 602. At block 602, “Receive memory access requests from shared virtual memory (SVM) devices, the memory access requests including types of multiple types of memory access requests,” one or more types of memory access requests may be received from the SVM devices. For example, IOMMU 104 may receive memory access requests of read or write type. In some embodiments, memory access requests may be received from one of SVM devices 102-1, 102-2, and 102-n.

[0078] Continuing to block 604, “Identifying translation entries associated with memory access requests in a cache, the translation entries including permission sets,” translation entries including permission sets associated with memory access requests can be identified in a cache. For example, request manager 202 can identify translation entries (e.g., translation entry 452) with permission set 460 in IOMMU cache 206. In some embodiments, the associated translation entry can be identified by IOMMU 104 based on an address included in the memory access request. For example, the memory access request may include a virtual address for identifying the associated translation entry.

[0079] Proceeding to block 606, "Execute the memory access request when the permission set allows the type of memory access request," the memory access request can be executed when the permission set allows the type of memory access request. For example, if the memory access request is a read request and permission set 460 includes the set read 464 permission, the memory access request can be executed. At block 608, "Generate a fault when the permission set restricts the type of memory access request," a fault can be generated when the permission set restricts the type of memory access request. For example, if the memory access request is a write request and permission set 460 includes the set execute 468 permission, the memory access request can be denied. In other words, as described herein, the memory access request may prevent an executable memory location from being written to.

[0080] Figure 6B The illustration depicts one embodiment of a logical flow 650 that can represent operations performed in conjunction with providing shared virtual memory (SVM) access protection in various embodiments. The logical flow 650 can represent operations that can be performed by… Figure 1-2B Some or all of the operations are performed by one or more components (such as IOMMU 104) of the operating environment 100, 200, or 250. Implementations are not limited to this context.

[0081] exist Figure 6BIn the illustrated embodiment, logic flow 650 may begin at block 652. At block 652, “Receive a memory transaction request from a shared virtual memory (SVM) device, the memory access request including an address associated with a memory page in the SVM utilized by the SVM device,” a memory transaction request including an address associated with a memory page in the SVM utilized by the SVM device may be received. For example, the IOMMU may receive the memory transaction request from SVM device 102-n. Further, SVM device 102-n may utilize SVM 106. In some embodiments, the memory transaction request may conform to the ATS protocol. Proceeding to block 654, “Determine that the memory transaction request includes a translation request and is associated with a write request,” the memory transaction request may be determined to include a translation request and be associated with a write request. In various embodiments, the memory transaction request may include a memory access request or a memory translation request. In one or more embodiments, if the memory transaction request includes a translation request and is associated with a write request, logic flow 650 may proceed to block 656.

[0082] At block 656, “Identifying whether the memory page associated with the memory transaction request is executable,” it is possible to identify whether the memory page associated with the memory transaction request is executable. The determination of whether a memory page is executable can be done in a manner similar to, for example, relative to, Figure 5A Block 516 or Figure 5B Block 566 continues as described above. Continuing to block 658, “Generate a translation completion with read-write access when the memory page associated with the memory transaction request is not executable,” a translation completion with read-write access can be generated when the memory page associated with the memory transaction request is not executable. For example, IOMMU 104 can generate a translation completion with read-write access for SVM device 102-n in response to receiving a memory transaction request associated with a non-executable memory page from SVM device 102-n. At block 660, “Generate a translation completion with read-only access when the memory page associated with the memory transaction request is executable,” a translation completion with read-only access can be generated when the memory page associated with the memory transaction request is executable. For example, IOMMU 104 can generate a translation completion with read-only access for SVM device 102-2 in response to receiving a memory transaction request associated with an executable memory page from SVM device 102-2.

[0083] Figure 7An embodiment of storage medium 700 is illustrated. Storage medium 700 may include any non-transitory computer-readable or machine-readable storage medium, such as optical, magnetic, or semiconductor storage media. In various embodiments, storage medium 700 may include article of manufacture. In some embodiments, storage medium 700 may store computer-executable instructions, such as instructions for implementing, etc., relative to... Figure 5A Logic flow 500 Figure 5B Logic flow 550 Figure 6A Logic flow 600 and Figure 6B The logical flow 650 refers to one or more computer-executable instructions in the logical flow or operation described herein. Examples of computer-readable or machine-readable storage media may include any tangible medium capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, etc. Examples of computer-executable instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, etc. Embodiments are not limited in this context.

[0084] Figure 8 Embodiments of an exemplary computing architecture 800 that may be adapted to implement the various embodiments described above are illustrated. In various embodiments, the computing architecture 800 may include or be implemented as part of an electronic device. In some embodiments, the computing architecture 800 may, for example, represent an implementation or utilization of Figure 1 Operating environment 100 Figure 2A Operating environment 200 and / or Figure 2B The operating environment 250 is a computer system comprising one or more components. In some embodiments, computing architecture 800 may, for example, represent one or more portions of an IOMMU 104 or CPU 108 that implements or utilizes one or more embodiments described herein. For example, IOMMU 104 may be a GPU that operates in conjunction with computing architecture 800. Embodiments are not limited in this context.

[0085] As used herein, the terms “system,” “component,” and “module” are intended to refer to computer-related entities, hardware, combinations of hardware and software, software, or software in execution, examples of which are provided by exemplary computing architecture 800. For example, a component can be, but is not limited to, a process running on a processor, a processor, a hard disk drive, multiple storage drives (optical and / or magnetic storage media), an object, an executable file, an executing thread, a program, and / or a computer. As illustrated, both an application running on a server and the server itself can be components. One or more components may reside within a process and / or an executing thread, and components may reside on a single computer and / or be distributed across two or more computers. Furthermore, components may communicatively couple with each other to coordinate operation via various types of communication media. Coordination may involve one-way or two-way exchange of information. For example, components may transmit information in the form of signals transmitted via a communication medium. Information may be implemented as signals assigned to various signal lines. In such assignments, each message is a signal. However, alternative embodiments may employ data messages. Such data messages may be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0086] The computing architecture 800 includes various common computing elements, such as one or more processors, multi-core processors, coprocessors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timers, video cards, sound cards, multimedia input / output (I / O) components, power supplies, etc. However, embodiments are not limited to implementations using the computing architecture 800.

[0087] like Figure 8 As shown, the computing architecture 800 includes a processing unit 804, a system memory 806, and a system bus 808. The processing unit 804 can be any of a variety of commercially available processors, including, but not limited to, AMD® Athlon®, Duron®, and Opteron® processors; ARM® application, embedded, and security processors; IBM® and Motorola® DragonBall® and PowerPC® processors; IBM and Sony® Cell processors; Intel® Celeron®, Core(2) Duo®, Itanium®, Pentium®, Xeon®, and XScale® processors; and similar processors. Dual-microprocessors, multi-core processors, and other multiprocessor architectures can also be used as the processing unit 804.

[0088] System bus 808 provides an interface for system components, including but not limited to system memory 806, to processing unit 804. System bus 808 can be any of several types of bus structures that can use any of a variety of commercially available bus architectures to further interconnect to memory buses (with or without memory controllers), peripheral buses, and local buses. Interface adapters can be connected to system bus 808 via slot architectures. Example slot architectures may include, but are not limited to, Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, PCMCIA, etc.

[0089] System memory 806 may include various types of computer-readable storage media in the form of one or more higher-speed memory cells, such as read-only memory (ROM), random access memory (RAM), dynamic RAM (DRAM), dual data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory (e.g., one or more flash memory arrays), polymer memory such as ferroelectric polymer memory, austenite memory, phase-change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, arrays of devices such as redundant independent disk array (RAID) drives, solid-state memory devices (e.g., USB memory, solid-state drive (SSD)), and any other type of storage medium suitable for storing information. Figure 8 In the illustrated embodiment, system memory 806 may include non-volatile memory 810 and / or volatile memory 812. In some embodiments, system memory 806 may include main memory. The Basic Input / Output System (BIOS) may be stored in non-volatile memory 810.

[0090] Computer 802 may include various types of computer-readable storage media in the form of one or more low-speed memory cells, including internal (or external) hard disk drive (HDD) 814, floppy disk drive (FDD) 816 for reading from or writing to removable disk 818, and optical disc drive 820 for reading from or writing to removable optical disc 822 (e.g., CD-ROM or DVD). HDD 814, FDD 816, and optical disc drive 820 may be connected to system bus 808 via HDD interface 824, FDD interface 826, and optical disc drive interface 828, respectively. HDD interface 824 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and Institute of Electrical and Electronics Engineers (IEEE) 994 interface technologies. In various embodiments, these types of memory may not be included in main memory or system memory.

[0091] Drives and associated computer-readable media provide volatile and / or non-volatile storage for data, data structures, computer-executable instructions, etc. For example, numerous program modules may be stored in drive and memory units 810, 812, including an operating system 830, one or more applications 832, other program modules 834, and program data 836. In one embodiment, one or more applications 832, other program modules 834, and program data 836 may include various applications and / or components, such as IOMMU 104, such as one or more portions of request manager 202 and / or page manager 204.

[0092] Users can type commands and information into computer 802 using one or more wired / wireless input devices (e.g., keyboard 838 and pointing devices such as mouse 840). Other input devices may include microphones, infrared (IR) remote controls, radio frequency (RF) remote controls, gamepads, styluses, card readers, dongles, fingerprint readers, gloves, graphics tablets, joysticks, keyboards, retinal readers, touchscreens (e.g., capacitive, resistive, etc.), trackballs, touchpads, sensors, styluses, etc. These and other input devices are typically connected to processing unit 804 via input device interface 842 coupled to system bus 808, but can be connected via other interfaces such as parallel ports, IEEE 994 serial ports, game ports, USB ports, IR interfaces, etc.

[0093] A monitor 844 or other type of display device is also connected to the system bus 808 via an interface (such as a video adapter 846). The monitor 844 can be inside or outside the computer 802. In addition to the monitor 844, the computer typically includes other peripheral output devices, such as speakers, printers, etc.

[0094] Computer 802 can operate in a networked environment using logical connections to one or more remote computers (such as remote computer 848) via wired and / or wireless communications. In various embodiments, one or more migrations may occur via the networked environment. Remote computer 848 may be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer-to-peer device, or other public network node, and typically includes many or all of the elements described relative to computer 802; however, for simplicity, only memory / storage device 850 is illustrated. The depicted logical connections include wired / wireless connections to a local area network (LAN) 852 and / or a larger network (e.g., a wide area network (WAN) 854). Such LAN and WAN networking environments are common in offices and companies and facilitate enterprise-wide computer networks, such as intranets, all of which can connect to global communication networks, such as the Internet.

[0095] When used in a LAN networking environment, computer 802 connects to LAN 852 via a wired and / or wireless communication network interface or adapter 856. Adapter 856 facilitates wired and / or wireless communication to LAN 852, which may also include a wireless access point configured thereon for communicating with the wireless functionality of adapter 856.

[0096] When used in a WAN networking environment, computer 802 may include modem 1358, or a communication server connected to WAN 854, or other components for establishing communication via WAN 854 (such as via the Internet). Modem 858, which can be internal or external and wired and / or wireless, is connected to system bus 808 via input device interface 842. In a networking environment, program modules or portions thereof described relative to computer 802 may be stored in remote memory / storage device 850. It should be understood that the network connections shown are exemplary, and other components for establishing communication links between computers may be used.

[0097] Computer 802 is operable to communicate with wired and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively configured in wireless communication (e.g., IEEE 802.16 air modulation technology). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth™. TMWireless technologies, etc. Therefore, communication can be a predefined structure like a regular network or simply dedicated communication between at least two devices. Wi-Fi networks use radio technology known as IEEE 802.11x (a, b, g, n, etc.) to provide secure, reliable, and fast wireless connections. Wi-Fi networks can be used to connect computers to each other, connect to the Internet, and connect to wired networks (which use IEEE 802.3 related media and functions).

[0098] Figure 9 A block diagram of an exemplary communication architecture 900 suitable for implementing various embodiments as previously described, such as virtual machine migration, is illustrated. Communication architecture 900 includes various common communication elements, such as transmitters, receivers, transceivers, wireless devices, network interfaces, baseband processors, antennas, amplifiers, filters, power supplies, etc. However, embodiments are not limited to implementations via communication architecture 900.

[0099] like Figure 9 As shown, the communication architecture 900 includes one or more clients 902 and servers 904. Clients 902 and servers 904 are operatively connected to one or more corresponding client data stores 908 and server data stores 910, which may be used to store local information for the respective client 902 and server 904, such as cookies and / or associated context information. In various embodiments, any of the servers 904 may implement one or more of the logical flows or operations described herein, and is implemented in conjunction with storing data received from any client 902 on any server data store 910. Figure 7 Storage medium 700. In one or more embodiments, one or more of the client data storage 908 or server data storage 910 may include SVM 106.

[0100] Client 902 and server 904 can use communication framework 906 to transmit information to each other. Communication framework 906 can implement any well-known communication technology and protocol. Communication framework 906 can be implemented as a packet-switched network (e.g., a public network such as the Internet, a private network such as a corporate intranet, etc.), a circuit-switched network (e.g., a public switched telephone network), or a combination of packet-switched and circuit-switched networks (with suitable gateways and converters).

[0101] The communication framework 906 can implement various network interfaces arranged to receive, transmit, and connect to a communication network. Network interfaces can be considered as dedicated forms of input / output interfaces. Network interfaces can employ connection protocols, including but not limited to direct connection, Ethernet (e.g., thick, thin, twisted pair 10 / 100 / 1900 Base T (Fast Ethernet)), Token Ring, wireless network interfaces, cellular network interfaces, IEEE 802.11ax network interfaces, IEEE 802.16 network interfaces, IEEE 802.20 network interfaces, etc. Furthermore, multiple network interfaces can be used to interface with various communication network types. For example, multiple network interfaces can be used to allow communication over broadcast, multicast, and unicast networks. If processing requirements specify a greater amount of speed and capacity, a similar distributed network controller architecture can be used to aggregate, load balance, and otherwise increase the communication bandwidth required by the client 902 and server 904. The communication network can be any and a combination of wired and / or wireless networks, including but not limited to direct interconnection, secure custom connections, private networks (e.g., corporate intranets), public networks (e.g., the Internet), personal area networks (PANs), local area networks (LANs), metropolitan area networks (MANs), operational tasks as nodes on the Internet (OMNIs), wide area networks (WANs), wireless networks, cellular networks, and other communication networks.

[0102] Various embodiments can be implemented using hardware components, software components, or a combination of both. Examples of hardware components may include processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field-programmable gate arrays (FPGAs), logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software may include software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application programming interfaces (APIs), instruction sets, computational code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether an embodiment is implemented using hardware components and / or software components can vary depending on any number of factors, such as desired computational speed, power level, thermal tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance constraints.

[0103] One or more aspects of at least one embodiment can be implemented by representative instructions stored on a machine-readable medium, which represent various logics within a processor that, when read by a machine, cause the machine to manufacture the logic to perform the techniques described herein. Such representations, referred to as “IP cores,” can be stored on tangible machine-readable media and supplied to various customers or manufacturing facilities for loading into manufacturing machines that actually manufacture the logic or processor. Some embodiments can be implemented, for example, using machine-readable media or articles that can store instructions or a set of instructions that, if executed by a machine, can cause the machine to perform the methods and / or operations according to the embodiments. Such a machine can include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and can be implemented using any suitable combination of hardware and / or software. Machine-readable media or articles may include, for example, any suitable type of memory cell, memory device, memory article, memory medium, storage device, storage article, storage medium and / or storage cell, such as memory, removable or non-removable media, erasable or non-erasable media, writable or rewritable media, digital or analog media, hard disk, floppy disk, compact disc read-only memory (CD-ROM), recordable compact disc (CD-R), rewritable compact disc (CD-RW), optical disc, magnetic media, magneto-optical media, removable memory cards or discs, various types of digital universal discs (DVDs), magnetic tape, magnetic tape cassettes, etc. Instructions may include any suitable type of code implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc.

[0104] The following examples relate to other embodiments from which many permutations and configurations will be apparent.

[0105] Example 1 is a device for control flow protection, the device comprising: a memory; logic for an input / output memory management unit (IOMMU), at least a portion of which is implemented in circuitry coupled to the memory, the logic being configured to: receive a memory access request from a shared virtual memory (SVM) device, the memory access request including a plurality of types of memory access request types; identify in a cache a translation entry associated with the memory access request, the translation entry including a set of permissions; execute the memory access request when the set of permissions allows the types of the memory access request; and generate an access request fault when the set of permissions restricts the types of the memory access request.

[0106] Example 2 includes the subject matter described in Example 1, wherein each permission in the permission set is used to allow or restrict the type of the plurality of types of memory access requests.

[0107] Example 3 includes the subject described in Example 1, wherein the permission set includes one or more of read permission, write permission, and execute permission.

[0108] Example 4 includes the topic described in Example 1, wherein the IOMMU includes the cache.

[0109] Example 5 includes the subject described in Example 1, wherein the cache includes a translation back buffer (TLB).

[0110] Example 6 includes the subject described in Example 1, wherein the transformation entry comprises a set of bits and each permission in the permission set comprises a subset of that set of bits.

[0111] Example 7 includes the subject described in Example 1, including one or more registers, the contents of which are used to activate the logic.

[0112] Example 8 includes the subject matter described in Example 1, wherein the SVM device includes one or more of a hardware accelerator, a graphics processing unit (GPU), a field-programmable gate array (FPGA), a system-on-a-chip (SoC), a speech processing unit (SPU), an input / output (I / O) device, a digital signal processor (DSP), or an application-specific integrated circuit (ASIC).

[0113] Example 9 includes the subject matter described in Example 1, wherein the memory access request includes a virtual address.

[0114] Example 10 includes the subject matter described in Example 9, wherein the logic is used to identify the translation entry associated with the memory access request in the cache based on the virtual address.

[0115] Example 11 includes the subject matter described in Example 9, wherein the logic is used to determine a linear address corresponding to the virtual address based on the translation entry.

[0116] Example 12 includes the subject matter described in Example 1, wherein the logic is used to signal an exception handler to notify that the access request has failed when the permission set restricts the type of the memory access request.

[0117] Example 13 includes the subject matter described in Example 12, wherein the exception handler is included in an operating system (OS) for terminating the memory access request.

[0118] Example 14 is an apparatus for control flow protection, the apparatus comprising: a memory; and logic for an input / output memory management unit (IOMMU), at least a portion of which is implemented in circuitry coupled to the memory, the logic being configured to: receive a memory transaction request from a shared virtual memory (SVM) device, the memory transaction request including an address associated with a memory page in an SVM utilized by the SVM device; determine that the memory transaction request includes a translation request and is associated with a write request; identify whether the memory page associated with the memory transaction request is executable; generate a translation completion with read-write access if the memory page associated with the memory transaction request is not executable; and generate a translation completion with read-only access if the memory page associated with the memory transaction request is executable.

[0119] Example 15 includes the subject matter described in Example 14, the logic being used to send the translation completion with read-write access to the SVM device when the memory page associated with the memory transaction request is not executable.

[0120] Example 16 includes the subject matter described in Example 14, the logic being used to send the translation completion with read-only access to the SVM device when the memory page associated with the memory transaction request is executable.

[0121] Example 17 includes the subject matter described in Example 14, wherein the IOMMU includes an IOMMU cache having at least one translation entry associated with a previous memory transaction between the IOMMU and the SVM device.

[0122] Example 18 includes the subject matter described in Example 17, wherein the logic is used to identify whether the memory page associated with the memory transaction request is executable based on the IOMMU cache.

[0123] Example 19 includes the subject matter described in Example 14, wherein the logic is used to identify whether the memory page associated with the memory transaction request is executable based on one or more page table traversals.

[0124] Example 20 includes the subject matter described in Example 14, including the SVM device, the SVM device including a device cache having at least one translation entry associated with a previous memory transaction between the IOMMU and the SVM device.

[0125] Example 21 includes the subject matter described in Example 14, wherein the memory transaction request includes an address type field to indicate whether the address associated with the memory page in the SVM has been translated or not.

[0126] Example 22 includes the subject matter described in Example 21, wherein the memory transaction request includes a header containing the address type field.

[0127] Example 23 includes the subject matter described in Example 14, including one or more registers, the contents of which are used to activate the logic.

[0128] Example 24 includes the subject matter described in Example 14, including a central processing unit (CPU) and the SVM device for utilizing the SVM.

[0129] Example 25 includes the subject matter described in Example 14, wherein the SVM device includes one or more of a hardware accelerator, a graphics processing unit (GPU), a field-programmable gate array (FPGA), a system-on-a-chip (SoC), a speech processing unit (SPU), an input / output (I / O) device, a digital signal processor (DSP), or an application-specific integrated circuit (ASIC).

[0130] Example 26 is at least one non-transitory computer-readable medium comprising a set of instructions that, in response to execution by processor circuitry, cause the processor circuitry to: receive a memory access request from a shared virtual memory (SVM) device at an input / output memory management unit (IOMMU), the memory access request including a plurality of types of memory access requests; identify a translation entry associated with the memory access request in a cache, the translation entry including a set of permissions; execute the memory access request when the set of permissions allows the type of the memory access request; and generate an access request fault when the set of permissions restricts the type of the memory access request.

[0131] Example 27 includes the subject matter described in Example 26, wherein each permission in the permission set is used to allow or restrict the type of the plurality of types of memory access requests.

[0132] Example 28 includes the subject matter described in Example 26, wherein the permission set includes one or more of read permission, write permission, and execute permission.

[0133] Example 29 includes the topic described in Example 26, wherein the IOMMU includes the cache.

[0134] Example 30 includes the subject matter described in Example 26, wherein the cache includes a translation back buffer (TLB).

[0135] Example 31 includes the subject described in Example 26, wherein the transformation entry comprises a set of bits and each permission in the permission set comprises a subset of that set of bits.

[0136] Example 32 includes the subject matter described in Example 26, including one or more registers, the contents of which are used to activate the logic.

[0137] Example 33 includes the subject matter described in Example 26, wherein the SVM device includes one or more of a hardware accelerator, a graphics processing unit (GPU), a field-programmable gate array (FPGA), a system-on-a-chip (SOC), a speech processing unit (SPU), an input / output (I / O) device, a digital signal processor (DSP), or an application-specific integrated circuit (ASIC).

[0138] Example 34 includes the subject matter described in Example 26, wherein the memory access request includes a virtual address.

[0139] Example 35 includes the subject matter described in Example 34, including instructions executed by the processor circuitry to cause the processor circuitry to identify the translation entry associated with the memory access request in the cache based on the virtual address.

[0140] Example 36 includes the subject matter described in Example 34, including instructions that, in response to being executed by the processor circuitry, cause the processor circuitry to determine a linear address corresponding to the virtual address based on the translation entry.

[0141] Example 37 includes the subject matter described in Example 26, including instructions that, in response to being executed by the processor circuitry, cause the processor circuitry to signal an access request failure to an exception handler when the type of the memory access request is restricted by the permission set.

[0142] Example 38 includes the subject matter described in Example 37, wherein the exception handler is included in an operating system (OS) for terminating the memory access request.

[0143] Example 39 is at least one non-transitory computer-readable medium comprising a set of instructions that, in response to execution by processor circuitry, cause the processor circuitry to: receive a memory transaction request at an input / output memory management unit (IOMMU) from a shared virtual memory (SVM) device, the memory transaction request including an address associated with a memory page in the SVM utilized by the SVM device; determine that the memory transaction request includes a translation request and is associated with a write request; identify whether the memory page associated with the memory transaction request is executable; generate a translation completion with read-write access if the memory page associated with the memory transaction request is not executable; and generate a translation completion with read-only access if the memory page associated with the memory transaction request is executable.

[0144] Example 40 includes the subject matter described in Example 39, including sending a translation completion instruction with read / write access to the SVM device in response to being executed by the processor circuitry when the memory page associated with the memory transaction request is not executable.

[0145] Example 41 includes the subject matter described in Example 39, including sending an instruction to the SVM device indicating that the conversion with read-only access is complete when the processor circuitry, in response to being executed by the processor circuitry, sends the memory page associated with the memory transaction request to the SVM device.

[0146] Example 42 includes the subject matter described in Example 39, wherein the IOMMU includes an IOMMU cache having at least one translation entry associated with a previous memory transaction between the IOMMU and the SVM device.

[0147] Example 43 includes the subject matter described in Example 42, including instructions that, in response to execution by the processor circuitry, cause the processor circuitry to identify, based on the IOMMU cache, whether the memory page associated with the memory transaction request is executable.

[0148] Example 44 includes the subject matter described in Example 39, including instructions that, in response to being executed by the processor circuitry, cause the processor circuitry to identify whether the memory page associated with the memory transaction request is executable based on one or more page table traversals.

[0149] Example 45 includes the subject matter described in Example 39, including the SVM device, the SVM device including a device cache having at least one translation entry associated with a previous memory transaction between the IOMMU and the SVM device.

[0150] Example 46 includes the subject matter described in Example 39, wherein the memory transaction request includes an address type field to indicate whether the address associated with the memory page in the SVM has been translated or not.

[0151] Example 47 includes the subject matter described in Example 46, wherein the memory transaction request includes a header containing the address type field.

[0152] Example 48 includes the subject matter described in Example 39, including one or more registers, the contents of which are used to activate the logic.

[0153] Example 49 includes the subject matter described in Example 39, including a central processing unit (CPU) and the SVM device for utilizing the SVM.

[0154] Example 50 includes the subject matter described in Example 39, wherein the SVM device includes one or more of a hardware accelerator, a graphics processing unit (GPU), a field-programmable gate array (FPGA), a system-on-a-chip (SOC), a speech processing unit (SPU), an input / output (I / O) device, a digital signal processor (DSP), or an application-specific integrated circuit (ASIC).

[0155] Example 51 is a computer-implemented method comprising: receiving a memory access request from a shared virtual memory (SVM) device at an input / output memory management unit (IOMMU), the memory access request including a plurality of types of memory access request types; identifying a translation entry associated with the memory access request in a cache, the translation entry including a set of permissions; executing the memory access request when the set of permissions allows the type of the memory access request; and generating an access request fault when the set of permissions restricts the type of the memory access request.

[0156] Example 52 includes the subject matter described in Example 51, wherein each permission in the permission set is used to allow or restrict the type of the plurality of types of memory access requests.

[0157] Example 53 includes the subject described in Example 51, wherein the permission set includes one or more of read permission, write permission, and execute permission.

[0158] Example 54 includes the topic described in Example 51, wherein the IOMMU includes the cache.

[0159] Example 55 includes the subject matter described in Example 51, wherein the cache includes a translation back buffer (TLB).

[0160] Example 56 includes the subject described in Example 51, wherein the transformation entry comprises a set of bits and each permission in the permission set comprises a subset of that set of bits.

[0161] Example 57 includes the subject matter described in Example 51, including one or more registers, the contents of which are used to activate the logic.

[0162] Example 58 includes the subject matter described in Example 51, wherein the SVM device includes one or more of a hardware accelerator, a graphics processing unit (GPU), a field-programmable gate array (FPGA), a system-on-a-chip (SoC), a speech processing unit (SPU), an input / output (I / O) device, a digital signal processor (DSP), or an application-specific integrated circuit (ASIC).

[0163] Example 59 includes the subject matter described in Example 51, wherein the memory access request includes a virtual address.

[0164] Example 60 includes the subject matter described in Example 59, including identifying the translation entry associated with the memory access request in the cache based on the virtual address.

[0165] Example 61 includes the subject matter described in Example 59, including determining a linear address corresponding to the virtual address based on the translation entry.

[0166] Example 62 includes the subject matter described in Example 51, including signaling an exception handler to a faulty access request when the type of the memory access request is restricted by the permission set.

[0167] Example 63 includes the subject matter described in Example 62, wherein the exception handler is included in an operating system (OS) for terminating the memory access request.

[0168] Example 64 is a computer-implemented method comprising: receiving a memory transaction request from a shared virtual memory (SVM) device at an input / output memory management unit (IOMMU), the memory transaction request including an address associated with a memory page in an SVM utilized by the SVM device; determining that the memory transaction request includes a translation request and is associated with a write request; identifying whether the memory page associated with the memory transaction request is executable; generating a translation completion with read-write access if the memory page associated with the memory transaction request is not executable; and generating a translation completion with read-only access if the memory page associated with the memory transaction request is executable.

[0169] Example 65 includes the subject matter described in Example 64, including sending the translation completion with read-write access to the SVM device when the memory page associated with the memory transaction request is not executable.

[0170] Example 66 includes the subject matter described in Example 64, including sending the translation completion with read-only access to the SVM device when the memory page associated with the memory transaction request is executable.

[0171] Example 67 includes the subject matter described in Example 64, wherein the IOMMU includes an IOMMU cache having at least one translation entry associated with a previous memory transaction between the IOMMU and the SVM device.

[0172] Example 68 includes the subject matter described in Example 67, including identifying whether the memory page associated with the memory transaction request is executable based on the IOMMU cache.

[0173] Example 69 includes the subject matter described in Example 64, including identifying whether the memory page associated with the memory transaction request is executable based on one or more page table traversals.

[0174] Example 70 includes the subject matter described in Example 64, including the SVM device, the SVM device including a device cache having at least one translation entry associated with a previous memory transaction between the IOMMU and the SVM device.

[0175] Example 71 includes the subject matter described in Example 64, wherein the memory transaction request includes an address type field to indicate whether the address associated with the memory page in the SVM has been translated or not.

[0176] Example 72 includes the subject matter described in Example 71, wherein the memory transaction request includes a header containing the address type field.

[0177] Example 73 includes the subject matter described in Example 64, including one or more registers, the contents of which are used to activate the logic.

[0178] Example 74 includes the subject matter described in Example 64, including a central processing unit (CPU) and the SVM device for utilizing the SVM.

[0179] Example 75 includes the subject matter described in Example 64, wherein the SVM device includes one or more of a hardware accelerator, a graphics processing unit (GPU), a field-programmable gate array (FPGA), a system-on-a-chip (SoC), a speech processing unit (SPU), an input / output (I / O) device, a digital signal processor (DSP), or an application-specific integrated circuit (ASIC).

[0180] Example 76 is an apparatus for control flow protection, the apparatus comprising: components for receiving a memory access request from a shared virtual memory (SVM) device at an input / output memory management unit (IOMMU), the memory access request including a plurality of types of memory access request types; components for identifying a translation entry associated with the memory access request in a cache, the translation entry including a set of permissions; components for executing the memory access request when the set of permissions allows the type of the memory access request; and components for generating an access request fault when the set of permissions restricts the type of the memory access request.

[0181] Example 77 includes the subject matter described in Example 76, wherein each permission in the permission set is used to allow or restrict the type of the plurality of types of memory access requests.

[0182] Example 78 includes the subject matter described in Example 76, wherein the permission set includes one or more of read permission, write permission, and execute permission.

[0183] Example 79 includes the topic described in Example 76, wherein the IOMMU includes the cache.

[0184] Example 80 includes the subject matter described in Example 76, wherein the cache includes a translation back buffer (TLB).

[0185] Example 81 includes the subject described in Example 76, wherein the transformation entry comprises a set of bits and each permission in the permission set comprises a subset of that set of bits.

[0186] Example 82 includes the subject matter described in Example 76, including one or more registers, the contents of which are used to activate the logic.

[0187] Example 83 includes the subject matter described in Example 76, wherein the SVM device includes one or more of a hardware accelerator, a graphics processing unit (GPU), a field-programmable gate array (FPGA), a system-on-a-chip (SoC), a speech processing unit (SPU), an input / output (I / O) device, a digital signal processor (DSP), or an application-specific integrated circuit (ASIC).

[0188] Example 84 includes the subject matter described in Example 76, wherein the memory access request includes a virtual address.

[0189] Example 85 includes the subject matter described in Example 84, including components for identifying the translation entry associated with the memory access request in the cache based on the virtual address.

[0190] Example 86 includes the subject matter described in Example 84, including components for determining a linear address corresponding to the virtual address based on the translation entry.

[0191] Example 87 includes the subject matter described in Example 76, including components for signaling an exception handler to notify of a failure of the access request when the type of the memory access request is restricted by the permission set.

[0192] Example 88 includes the subject matter described in Example 87, wherein the exception handler is included in an operating system (OS) for terminating the memory access request.

[0193] Example 89 is an apparatus for control flow protection, the apparatus comprising: components for receiving a memory transaction request from a shared virtual memory (SVM) device at an input / output memory management unit (IOMMU), the memory transaction request including an address associated with a memory page in an SVM utilized by the SVM device; components for determining that the memory transaction request includes a translation request and is associated with a write request; components for identifying whether the memory page associated with the memory transaction request is executable; components for generating a translation completion with read-write access when the memory page associated with the memory transaction request is not executable; and components for generating a translation completion with read-only access when the memory page associated with the memory transaction request is executable.

[0194] Example 90 includes the subject matter described in Example 89, including components for sending the translation completion with read-write access to the SVM device when the memory page associated with the memory transaction request is not executable.

[0195] Example 91 includes the subject matter described in Example 89, including components for sending the translation completion with read-only access to the SVM device when the memory page associated with the memory transaction request is executable.

[0196] Example 92 includes the subject matter described in Example 89, wherein the IOMMU includes an IOMMU cache having at least one translation entry associated with a previous memory transaction between the IOMMU and the SVM device.

[0197] Example 93 includes the subject matter described in Example 92, including a component for identifying whether the memory page associated with the memory transaction request is executable based on the IOMMU cache.

[0198] Example 94 includes the subject matter described in Example 89, including a component for identifying whether the memory page associated with the memory transaction request is executable based on one or more page table traversals.

[0199] Example 95 includes the subject matter described in Example 89, including the SVM device, the SVM device including a device cache having at least one translation entry associated with a previous memory transaction between the IOMMU and the SVM device.

[0200] Example 96 includes the subject matter described in Example 89, wherein the memory transaction request includes an address type field to indicate whether the address associated with the memory page in the SVM has been translated or not.

[0201] Example 97 includes the subject matter described in Example 96, wherein the memory transaction request includes a header containing the address type field.

[0202] Example 98 includes the subject matter described in Example 89, including one or more registers, the contents of which are used to activate the logic.

[0203] Example 99 includes the subject matter described in Example 89, including a central processing unit (CPU) and the SVM device for utilizing the SVM.

[0204] Example 100 includes the subject matter described in Example 89, wherein the SVM device includes one or more of a hardware accelerator, a graphics processing unit (GPU), a field-programmable gate array (FPGA), a system-on-a-chip (SOC), a speech processing unit (SPU), an input / output (I / O) device, a digital signal processor (DSP), or an application-specific integrated circuit (ASIC).

[0205] The foregoing description of exemplary embodiments has been presented for illustrative and descriptive purposes. It is not intended to be exhaustive or to limit this disclosure to the precise forms disclosed. Many modifications and variations are possible in light of this disclosure. It is intended that the scope of this disclosure be limited not by this detailed description, but rather by the appended claims. A future application claiming priority to this application may claim protection for the disclosed subject matter in different ways and may generally include any one or more of the limiting factors as disclosed herein or otherwise demonstrated.

[0206] Various embodiments generally relate to techniques for access protection of shared virtual memory (SVM), such as performing a security check whenever a write request arrives from the SVM device. Some embodiments particularly relate to an input / output memory management unit (IOMMU) that prevents the SVM device from modifying code pages due to a memory transaction request by generating an access request fault and / or a transition completion with read-only access in response to the memory transaction request.

Claims

1. A computer-implemented method, comprising: The input / output memory management unit (IOMMU) receives memory access requests from the shared virtual memory (SVM) device, and the memory access requests include multiple types of memory access request types. Determine whether the type of the memory access request is a write request; Identify in the cache a translation entry associated with the memory access request, the translation entry including a set of permissions, the translation entry including a set of bits and each permission in the set of permissions including a subset of the set of bits; Determine whether the memory page associated with the memory access request is based on the permission set; as well as; The memory access request is executed based on the determination that the type of the memory access request is a write request and the determination that the memory page associated with the memory access request is executable. or An access request failure is generated based on the determination that the type of the memory access request is not a write request and that the memory page associated with the memory access request is not executable.

2. The computer-implemented method according to claim 1, wherein each permission in the permission set is used to allow or restrict the type of the plurality of memory access requests.

3. The computer-implemented method according to claim 1, wherein the permission set includes one or more of read permission, write permission, and execute permission.

4. The computer-implemented method according to claim 1, wherein the IOMMU includes the cache.

5. The computer-implemented method according to claim 1, wherein the cache includes a translation back buffer (TLB).

6. The computer-implemented method according to claim 1, comprising one or more registers, the contents of which are used for activation logic.

7. The computer-implemented method according to claim 1, wherein the SVM device comprises one or more of a hardware accelerator, a graphics processing unit (GPU), a field-programmable gate array (FPGA), a system-on-a-chip (SoC), a speech processing unit (SPU), an input / output (I / O) device, a digital signal processor (DSP), or an application-specific integrated circuit (ASIC).

8. The computer-implemented method according to claim 1, wherein the memory access request includes a virtual address.

9. The computer-implemented method of claim 8, further comprising identifying the translation entry associated with the memory access request in the cache based on the virtual address.

10. The computer-implemented method of claim 8, comprising determining a linear address corresponding to the virtual address based on the translation entry.

11. The computer-implemented method of claim 1, further comprising signaling an exception handler to notify the access request of a failure when the permission set restricts the type of the memory access request.

12. The computer-implemented method of claim 11, wherein the exception handler is included in an operating system (OS), and the exception handler is used to terminate the memory access request.

13. A computer-readable medium comprising code, which, when executed, causes a machine to perform the method according to any one of claims 1 to 12.

14. An apparatus for controlling flow protection, the apparatus comprising: Memory; as well as Logic for an Input / Output Memory Management Unit (IOMMU), at least a portion of which is implemented in circuitry coupled to the memory, the logic being used for: Receive a memory transaction request from a shared virtual memory (SVM) device, the memory transaction request including an address associated with a memory page in the SVM utilized by the SVM device; The memory transaction request is determined to include a conversion request and be associated with a write request; Identify in the cache a translation entry associated with the memory access request, the translation entry including a set of permissions, the translation entry including a set of bits and each permission in the set of permissions including a subset of the set of bits; The permission set identifier determines whether the memory page associated with the memory transaction request is executable; A translation completion with read and write access is generated when the memory page associated with the memory transaction request is not executable. as well as A conversion completion with read-only access is generated when the memory page associated with the memory transaction request is executable.

15. The apparatus of claim 14, wherein the logic is configured to send the translation completion with read-write access to the SVM device when the memory page associated with the memory transaction request is not executable.

16. The apparatus of claim 14, wherein the logic is configured to send the translation completion with read-only access to the SVM device when the memory page associated with the memory transaction request is executable.

17. The apparatus of claim 14, wherein the IOMMU device includes an IOMMU cache having at least one translation entry associated with a previous memory transaction between the IOMMU and the SVM device.

18. The apparatus of claim 17, wherein the logic is configured to identify whether the memory page associated with the memory transaction request is executable based on the IOMMU cache.

19. The apparatus of claim 14, wherein the logic is configured to identify whether the memory page associated with the memory transaction request is executable based on one or more page table traversals.

20. The apparatus of claim 14, comprising the SVM device, the SVM device including a device cache having at least one translation entry associated with a previous memory transaction between the IOMMU and the SVM device.

21. The apparatus of claim 14, wherein the memory transaction request includes an address type field to indicate whether the address associated with the memory page in the SVM has been translated or not.

22. The apparatus of claim 21, wherein the memory transaction request includes a header containing the address type field.

23. The apparatus of claim 14, comprising one or more registers, the contents of which are used to activate the logic.

24. The apparatus according to any one of claims 14 to 23, wherein the SVM device comprises one or more of a hardware accelerator, a graphics processing unit (GPU), a field-programmable gate array (FPGA), a system-on-a-chip (SoC), a speech processing unit (SPU), an input / output (I / O) device, a digital signal processor (DSP), or an application-specific integrated circuit (ASIC).

25. A device for controlling flow protection, comprising: A means for receiving memory access requests from a shared virtual memory (SVM) device at an input / output memory management unit (IOMMU), the memory access requests including multiple types of memory access request types; A means for determining whether the type of the memory access request is a write request; A means for identifying a translation entry associated with the memory access request in a cache, the translation entry including a set of permissions, the translation entry including a set of bits and each permission in the set of permissions including a subset of the set of bits; A means for determining whether a memory page associated with the memory access request is based on the permission set; and ； A means for executing a memory access request based on determining that the type of the memory access request is a write request and determining that the memory page associated with the memory access request is executable. or A means for generating an access request failure based on determining that the type of the memory access request is not a write request and determining that the memory page associated with the memory access request is not executable.

26. The device of claim 25, wherein each permission in the permission set is used to allow or restrict the type of the plurality of memory access requests.

27. The device according to claim 25, wherein the permission set includes one or more of read permission, write permission and execute permission.

28. The device of claim 25, wherein the IOMMU includes the cache.

29. The device of claim 25, wherein the cache includes a translation back buffer (TLB).

30. The device of claim 25, wherein the conversion entry comprises a set of bits and each permission in the permission set comprises a subset of the set of bits.

31. The device of claim 25, comprising one or more registers, the contents of which are used for activation logic.

32. The device of claim 25, wherein the SVM device comprises one or more of a hardware accelerator, a graphics processing unit (GPU), a field-programmable gate array (FPGA), a system-on-a-chip (SoC), a speech processing unit (SPU), an input / output (I / O) device, a digital signal processor (DSP), or an application-specific integrated circuit (ASIC).

33. The device of claim 25, wherein the memory access request includes a virtual address.

34. The apparatus of claim 33, further comprising means for identifying, in the cache, the translation entry associated with the memory access request based on the virtual address.

35. The apparatus of claim 33, further comprising means for determining a linear address corresponding to the virtual address based on the translation entry.

36. The apparatus of claim 25, further comprising means for signaling an exception handler to notify of a failure of the access request when the permission set restricts the type of the memory access request.

37. The device of claim 36, wherein the exception handler is included in an operating system (OS), and the exception handler is used to terminate the memory access request.

Images