Patent ID: 12259824

DETAILED DESCRIPTION

In a computer system, a memory management units (MMU) can be positioned between a central processing unit (CPU) and a storage device. The MMU can help facilitate memory operations requested by the CPU. The MMU can also help prevent exploitations of memory corruption vulnerabilities. Input/Output memory management units (IOMMUs) can provide similar functionality for IO devices. For example, an IOMMU can be positioned between IO devices and the storage device to facilitate memory operations. But the protections afforded by IOMMUs may be weaker than those provided by MMUs for a variety of reasons. For example, an IOMMU may assign IOVAs sequentially, which can allow attackers to easily predict target address spaces on the physical memory. And due to the high computational cost of periodically invalidating large numbers of translation entries from a translation table of the IOMMU, IOVAs may remain valid after they are no longer in use. The net effect of these two problems is that an attacker may be able to successfully guess a valid IOVA and take advantage of it for malicious purposes.

Some examples of the present disclosure can overcome one or more of the abovementioned problems by determining the IOVAs using a pre-defined randomness algorithm, which may reduce memory errors or reduce opportunities for malicious attacks. For example, if a malicious attacker attempts to access the storage device by impersonating an IO device, the malicious attacker may have to guess a randomly assigned IOVA in the translation table, which may be extremely difficult.

In some examples, the IOMMU can also check the translation table to determine if a particular IOVA is still in use. If not, the IOMMU may invalidate that IOVA from the translation table. As a result, if an IO device attempts to access the IOVA, the IOMMU will block the IO device from access.

The IOMMU may detect behavior indicative of a malicious attacker. Given that IOVAs may be assigned by a pre-defined randomness algorithm, the IOMMU may have a threshold for sequentially ordered IOVAs. Exceeding the threshold may indicate illegitimate access attempts by a malicious attacker. In the event the threshold is exceeded, the IOMMU may execute certain functions to block the perceived malicious access attempts and future access attempts. For instance, the IOMMU may invalidate sequentially ordered IOVAs beyond the threshold, interrogating an IO device associated with the sequentially ordered IOVAs, or notify an administrator.

Illustrative examples are given to introduce the reader to the general subject matter discussed herein and are not intended to limit the scope of the disclosed concepts. The following sections describe various additional features and examples with reference to the drawings in which like numerals indicate like elements, and directional descriptions are used to describe the illustrative aspects, but, like the illustrative aspects, should not be used to limit the present disclosure.

FIG.1is a block diagram of an example of a system for assigning input/output virtual addresses (IOVAs) non-sequentially according to some aspects of the present disclosure. The system can include a computing device100, such as a laptop, desktop, server, tablet, mobile phone, or embedded computing board.

The computing device100includes a main memory102, an input/output (IO) device112, and a central processing unit (CPU)118. Examples of the main memory102can include a hard drive or hard disk. Examples of the IO device112include a graphics card, sound card, network card, wireless network card, video capture card, SATA Expansion card, M.2 NVMe Expansion card, port expansion card, CPU expansion card, RAM expansion card, keyboard, mouse, gamepad, printer, display, touchscreen, or external storage device.

The path between the IO device112and the main memory102includes an input/output memory management unit (IOMMU)108. The IOMMU108can translate an input/output virtual address (IOVA)106to a physical address in the main memory102. The IOVA106may be passed from the IO device112to the IOMMU for translation using a translation table120. This IOVA106may be “visible” to the IO device112, while the physical address may be “hidden” from the IO device112.

Similarly, the path between the CPU118and the main memory102includes a memory management unit (MMU)114. The MMU114can translate a virtual address116from the CPU118to a physical address in the main memory102. The virtual address116may be “visible” to the CPU118, while the physical address may be “hidden” from the CPU118.

The IOMMU108may determine the IOVA106using a predefined randomness algorithm. The predefined randomness algorithm can be configured to generate an IOVA in at least a substantially random manner. The IOMMU108can then store the randomized IOVA106in a translation entry122of the translation table120. The translation entry122can be an entry that maps the IOVA106to a corresponding physical memory address in the main memory102.

After storing the translation entry122in the translation table120, the IOMMU108may receive a request from the IO device112. The request can request to access data at the IOVA106. In some such examples, the IOVA106may be transmitted to the IO device112by a device driver, which may be located in the main memory102or elsewhere in the system. The device driver may be configured to resolve an alignment restriction, in which the IOVA106selected by the IOMMU108is a different length of bits than the length of memory address expected by the IO device112. The device driver may resolve such an alignment restriction by combining bits of the IOVA106subjected to the predefined randomness algorithm with padding bits that can extend the IOVA106, making the IOVA106still valid for the IO device112.

In response to receiving the request, the IOMMU108can access the translation table120, determine a translation entry122associated with the IOVA106specified in the request, and use the translation entry122to identify a physical memory address of the main memory102that is mapped to the IOVA106. The IOMMU108may then allow the IO device112to access the data at the physical memory address on the main memory102.

In some examples, the IOMMU108may check if the IOVA106is still in use after overseeing the request from the IO device112. In response to determining the IOVA106is not in use, the IOMMU108may invalidate the translation entry122from the translation table120. This invalidation step may provide added security such that a malicious attacker or a malfunctioning IO device112is unable to corrupt entries on the main memory102through direct memory access.

Memory coherence issues can occur when multiple processors share the same memory space. For example, the IO device112may be a graphics card with a graphics processing unit (GPU). In such an example, the GPU of the IO device112may share the main memory102with the CPU118. For the GPU of the IO device112to avoid affecting the work of the CPU118present on the main memory102, a schema may be necessary to observe the main memory102use of both processing elements, the GPU of the IO device112and the CPU118. As part of such a schema, the IOMMU108may examine other physical memory addresses associated with other translation entries apart from the entries of the IO device112and assign the translation entry210such that memory coherence issues are less likely to occur. In such observations, the IOMMU may also assign the translation entry210to avoid bit flip issues, in which the electro-magnetic influence of bits in a physical address of the main memory102can cause the bits of an adjacent physical address to change unintentionally.

In some examples, the whole IOVA106may be randomized. For example, the IOVA106may be a completely randomized string of bits. In other examples, only a subpart of the IOVA106may be randomized. For example, the IOMMU108may subject less than a total number of addressable bits to the pre-defined randomness algorithm. As one such example, if the IOMMU supports 48-bit IOVAs when allocating a 4-kilobyte range of addresses, 32 bits of the IOVA106may be available for randomization. Other bits may include other information, such as read and write permissions, which may not be randomized. By preventing the randomization of some bits, functions such as read and write permissions can be maintained while still offering the security protection and error protection afforded by randomization.

In some examples, the translation table120may include a plurality of entries for mapping a plurality of IOVAs to a plurality of physical addresses of the memory102. In some such examples, the translation table120may be specific to the IO device112. For instance, the IOMMU108may store a separate translation table for each IO device, where a given translation table is specific to a given IO device and not used in relation to other IO devices. In other examples, a single translation table may be shared between multiple IO devices. This may help conserve memory if two translation tables would be substantially similar.

Also, the IOMMU108may detect behavior indicative of a malicious attacker. For example, the IOMMU108may track requests by an IO device112having sequentially ordered IOVAs. If the number of requests meets or exceeds a predefined threshold, it may indicate an attacker is attempting to guess a valid IOVA to access the memory102or another type of security threat. The IOMMU108can detect such a security threat based on the number of such requests meeting or exceeding the predefined threshold and, in response, perform one or more mitigation operations. The mitigation operations can be designed to thwart the attack or otherwise reduce the security risk. Examples of such mitigation operations may include blocking incoming requests for a predetermined period of time or alerting an administrator.

Including an IOMMU108in the computing device100may be preferable to direct, unmediated physical addressing to the main memory102by the IO device112for several reasons. The IOMMU108can save computational resources that may otherwise be spent finding fragmented, available memory addresses within the main memory102. In some instances, certain IO devices may not be able to address the full span of available memory addresses within the main memory102. The IOVA106created by the IOMMU108can reach any address within the main memory102, without expending computational resources on techniques such as double buffering to provide physical address extension.

The IOMMU108may also serve as a layer of protection against direct memory access attacks or errant memory transfers attempted by the IO device112. The IOMMU108may provide this layer protection by not allowing the IO device112to read or write to an address of the main memory102that has not been explicitly allocated with an IOVA106.

In some examples, the IO device112may be a graphics card. In some such examples, the IOMMU108may be a graphics address remapping table (GART). The IOMMU108may load graphical data, such as textures and polygon meshes, from the main memory102to the IO device112. Textures and polygon meshes may have initially been loaded to the main memory102by the central processing unit118. The main memory102may buffer the textures and polygon meshes between the IO device112and any number of original data sources, such as a hard drive, a solid-state drive, a network card, etc.

FIG.2is a block diagram of an example of a system for assigning input/output virtual addresses to physical memory addresses using a pre-defined randomness algorithm according to some aspects of the present disclosure. The system includes an IOMMU216. The IOMMU216includes a processor224and a memory226including instructions228. The IOMMU216is positioned in a pathway between an input/output (IO) device214and a storage device204. The storage device204includes physical memory addresses, such as physical memory address212. Non-limiting examples of the storage device204include electrically erasable and programmable read-only memory (EEPROM), flash memory, or any other type of non-volatile memory.

The processor224can include one processing device or multiple processing devices. Non-limiting examples of the processor224include a Field-Programmable Gate Array (FPGA), an application-specific integrated circuit (ASIC), or a microprocessor. The processor224can execute instructions228stored in the memory226to perform operations. In some examples, the instructions228can include processor-specific instructions generated by a compiler or an interpreter from code written in a suitable computer-programming language, such as C, C++, C #, etc.

The memory226can include one memory device or multiple memory devices. The memory226can be non-volatile and may include any type of memory that retains stored information when powered off. Non-limiting examples of the memory226include electrically erasable and programmable read-only memory (EEPROM), flash memory, or any other type of non-volatile memory. At least some of the memory226can include a non-transitory computer-readable medium from which the processor224can read instructions228. A computer-readable medium can include electronic, optical, magnetic, or other storage devices capable of providing the processor224with computer-readable instructions or other program code. Non-limiting examples of a computer-readable medium include magnetic disk(s), memory chip(s), ROM, random-access memory (RAM), an ASIC, a configured processor, optical storage, or any other medium from which a computer process or can read the instructions228.

In some examples, the processor224of the IOMMU216can determine an input/output virtual address (IOVA)218using a pre-defined randomness algorithm220. The processor224can then store, in a translation table208, an entry210that maps the IOVA to a physical memory address212of a storage device204. Subsequent to storing the entry210in the translation table208, the processor224can receive a request222from an input/output (IO) device214. The request222can be to access data at the IOVA218. In response to receiving the request222, the processor224can identify the physical memory address212that is mapped to the IOVA218in the entry210. The processor224can then allow the IO device214to access the data at the physical memory address212.

FIG.3is a flowchart of an example of a process300for assigning input/output virtual addresses using a pre-defined randomness algorithm according to some aspects of the present disclosure. Some examples may include more steps, fewer steps, different steps, or a different combination of steps than is shown inFIG.3. The steps ofFIG.3are described below with reference to the components ofFIG.2described above.

In block302, the IOMMU216may determine an IOVA218using a pre-defined randomness algorithm220. Examples of the pre-defined randomness algorithm220may be a linear congruential generator, a generator related to linear-feedback shift registers, a Mersenne Twister random number generator, a shift-register generator, a well equi-distributed long-period linear pseudorandom number generator, or any other suitable pre-defined randomness algorithm. The IOMMU may alter which bits are randomized or exclude results from the pre-defined randomness algorithm220based on entries in the translation table208.

Security afforded by the pre-defined randomness algorithm220may depend on the breadth of IOVAs that may result from the pre-defined randomness algorithm. This breadth of possible IOVAs may be increased by maximizing entropy in the pre-defined randomness algorithm220. Entropy may be increased either by raising the amount of IOVA area space over which the pre-defined randomness occurs or reducing the time period over which the pre-defined randomness occurs.

In block304, the IOMMU216may store, in the translation table208, a translation entry210that maps the IOVA218to a physical memory address212of the storage device204. The translation table208may be dedicated to the IO device214or may be shared by several IO devices. In some examples, there may be multiple IOVAs, including said IOVA218, mapped to the same physical memory address212.

In block306, subsequent to storing the translation entry210to the translation table208, the IOMMU may receive a request222from the IO device214for the IO device214to access data at the IOVA218. In some examples, the IOMMU may evaluate such requests in case they are indicative of a security threat. For example, the IOMMU may be able to detect a predefined number of access requests that correspond to sequential IOVAs. In some such examples, requesting sequential IOVAs may indicate a malicious attacker that is operating under the assumption that the IOMMU216is conventionally assigning IOVAs in a sequential order. Because the IOMMU216assigns IOVAs non-sequentially by a pre-defined randomness algorithm220, repeated attempts at requesting sequential IOVAs can be assumed to be a sign of a malicious attacker.

In block308, in response to receiving the request222, the IOMMU216may identify the physical memory address212that is mapped to the IOVA218by the translation entry210. In some examples, the translation entry210may correspond to a range of physical memory addresses.

In block310the IOMMU216may allow the IO device214to access the data at the physical memory address212. Accessing the data may involve reading or writing data to the physical memory address212. In some examples, the IOVA218may be transmitted to the IOMMU216by a device driver.

After the IOMMU216allows the IO device214to access the data at the physical memory address212, the IOMMU may inspect the translation entry210associated with the IOVA218. If the IOVA218associated with the translation entry210is no longer in use, the IOMMU216may invalidate the translation entry210. By invalidating the translation entry210, the IOMMU216may block access to the storage device204, from the IO device214, by way of the IOVA218. This blocked access may prevent the IO device214from creating a memory corruption error. This may be beneficial because direct memory access could allow the IO device214to affect not only operations related to itself, but also effect any operations staged on the storage device204, such as an operating system.

Invalidating the translation entry210may also prevent a cascade of memory corruption errors. For example, the IO device214may be instructed to fill multiple addresses sequentially. With a conventional approach, the IOMMU216may create the IOVA218for the request222which provides access to the physical memory address212. Subsequent access requests may then, through subsequent, sequentially ordered IOVAs, fill a plurality of sequentially ordered physical memory addresses. If, under the conventional approach, the IOMMU216has created an initial memory corruption error by accessing a physical memory address under use, subsequent, sequentially ordered physical memory addresses which may be functionally related to the initial physical memory address may also experience memory corruption errors.

The IOMMU216and its pre-defined randomness algorithm220may differ from techniques such as address-space layout randomization because the IOMMU216may not randomize memory regions such as stacks, heaps, or libraries. And in some examples, the IOMMU216may apply the pre-defined randomness algorithm220to generate every IOVA. By subjecting every IOVA to the pre-defined randomness algorithm220, malicious techniques such as heap spraying may be useless to an attacker.

For example, in an application of address-space layout randomization, the location of a stack may be randomly assigned within storage device204, but the addresses comprising the stack may be reused. A heap spray attack may change the contents of these reused addresses to reveal which addresses are associated with a process targeted by the malicious attacker. With every IOVA randomized and routinely invalidated, there may be no pattern of reused addresses or collection of sequential addresses for the malicious attacker to discover.

The foregoing description of certain examples, including illustrated examples, has been presented only for the purpose of illustration and description and is not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. Numerous modifications, adaptations, and uses thereof will be apparent to those skilled in the art without departing from the scope of the disclosure. For instance, any example(s) described herein can be combined with any other example(s) to yield further examples.