Integrated circuit, method in integrated circuit, computer system, device and product for enabling secure communication between a device protected container module and an input / output device

Abstract

Integrated circuit comprising the following: Logic designed to control protected container access, to perform a set of access control checks and determine that a Device Protected Container Module (DPCM) and an input and / or output device (I / O device) are allowed to communicate securely via Direct Memory Access (DMA) or Memory Mapped Input / Output (MMIO), after determining that at least: the DPCM and the I / O device are assigned to each other; an access address associated with the communication is resolved into a protected container storage; and a page of the protected container storage into which the access address is resolved, which DMA or MMIO allows.

Description

GENERAL STATE OF THE TECHNOLOGY Field of Technology

[0001] The embodiments described herein generally relate to the securing of information. In particular, the embodiments described herein relate to enabling secure communication between a Device Protected Container Module and an input / output device. General state of the art

[0002] Desktop computers, laptops, smartphones, servers, and various other types of computer systems are often used to process secret or confidential information. Examples of such secret or confidential information include, but are not limited to, passwords, account information, financial information, information relating to financial transactions, confidential company data, enterprise rights management information, private calendars, private contacts, health information, other personal information, and the like. It is generally desirable to protect such secret or confidential information against unauthorized access, fraudulent alteration, theft, and similar threats.

[0003] Document US 2014 / 0 068 704 A1 concerns a technique for limiting unauthorized access to data traffic. SUMMARY OF THE INVENTION

[0004] According to the invention, an integrated circuit, a method in an integrated circuit, a computer system, a device and a product are provided as defined in the patent claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The invention is best understood with reference to the following description and the accompanying drawings, which are used to illustrate embodiments. In the drawings is Fig. 1 a block diagram of an embodiment of a computer system in which embodiments can be implemented. Fig. Figure 2 is a block diagram of a detailed embodiment of a computer system suitable for implementing embodiments of the invention. Fig. Figure 3 is a block diagram of an embodiment of a computer system with an exemplary embodiment for an I / O-protected container module. Fig. Figure 4 is a block flowchart of an exemplary implementation for configuring a secure DMA. Fig. Figure 5 is a block diagram of an exemplary implementation of a computer system, which shows how to configure a secure DMA. Fig. Figure 6 is a block diagram of an embodiment of a processor used to execute an embodiment of an instruction relating to the configuration of DMA-protected container pages. Fig. Figure 7 is a block diagram of an exemplary implementation of a computer system, which shows the specification of a DMA operation. Fig. Figure 8 is a block diagram of an exemplary implementation of a computer system, which shows security checks and the execution of a secure DMA. Fig. Figure 9 is a block flowchart of an embodiment of a method for performing safety checks to determine whether a safe DMA should be permitted or not. Fig. Figure 10 is a block flowchart of an exemplary implementation for configuring a secure MMIO. Fig. Figure 11 is a block diagram of an exemplary implementation of a computer system, which shows the configuration of a secure MMIO. Fig. Figure 12 is a block flow diagram of a detailed embodiment of a method in which a given DPCM performs a safe MMIO. Fig. Figure 13 is a block diagram of an exemplary implementation of a computer system, which shows the configuration of a secure MMIO. Fig. Figure 14A is a block diagram illustrating an embodiment of an in-order pipeline and an embodiment of a register renaming, out-of-order allocation / execution pipeline. Fig. 14B is a block scheme of an embodiment of a processor core containing a front-end unit coupled to an execution engine unit, both of which are coupled to a memory unit. Fig. 15A is a block diagram of an embodiment of a single processor core, together with its connection to the interconnection network housed on a chip and with its local subset of the Level-2(L2) cache. Fig. Figure 15B is a block diagram of an embodiment of an extended view of a part of the processor core according to Fig. 15A. Fig. Figure 16 is a block scheme of an embodiment of a processor which may have more than one core, may have an integrated memory controller and may have integrated graphics. Fig. Figure 17 is a block diagram of a first embodiment of a computer architecture. Fig. Figure 18 is a block diagram of a second embodiment of a computer architecture. Fig. Figure 19 is a block diagram of a third embodiment of a computer architecture. Fig. Figure 20 is a block diagram of a fourth embodiment of a computer architecture. Fig. Figure 21 is a block diagram for the use of a software instruction converter for converting binary instructions in a source instruction set into binary instructions in a target instruction set according to embodiments of the invention. DETAILED DESCRIPTION OF EXECUTION FORMS

[0006] This document discloses processors, methods, systems, and instructions for enabling secure communication between a protected container memory and an input and / or output device. Numerous specific details are detailed in the following description (e.g., specific processor configurations, microarchitecture details, instruction operations, process flows, etc.). However, embodiments can also be implemented practically without these specific details. In other cases, well-known circuits, structures, and techniques have not been described in detail to maintain clarity.

[0007] Fig. Figure 1 is a block diagram of an embodiment of a computer system 100, in which embodiments can be implemented. In various embodiments, the computer system can be a desktop computer system, a laptop computer system, a tablet computer system, a smartphone, a server, a network device, or the like, or computer systems of various other types, commonly used for processing secret or confidential information.

[0008] The computer system includes a protected container memory 101, a processor 104, and an input and / or output device (I / O device) 107. The protected container memory, the processor, and the I / O device are coupled together. As shown, the processor is coupled to the protected container memory via a first optional coupling mechanism 108, the protected container memory is coupled to the I / O device via a second optional coupling mechanism 110, and the processor is coupled to the I / O device via a third optional coupling mechanism 109. Examples of suitable coupling mechanisms include one or more buses or other interconnections, one or more chipset components, other mechanisms for coupling the processor, the memory, and the I / O device, and various combinations thereof.

[0009] The processor features a protected container architecture 105. The protected container architecture includes logic 106 for controlling protected container access. In some embodiments, the protected container architecture and / or the logic for controlling protected container access can serve to support and protect the protected container memory and / or one or more protected container modules thereof (e.g., one or more Secure Enclaves).In some embodiments, the protected container architecture and / or the logic provided for controlling protected container access may serve to support and / or protect and / or control access to the protected container storage and / or one or more protected container modules thereof, using any or any number of the different methods used for Intel® Software Guard Extensions (Intel® SGX) to support and / or protect and / or control access to an Enclave Page Cache (EPC) and / or one or more Secure Enclaves thereof, but this does not limit the scope of protection of the invention.In some embodiments, the protected container architecture and / or the logic provided for controlling protected container access can serve to support and / or protect the protected container storage and / or one or more protected container modules thereof and / or to control access to it, using any one or more of the different methods described below in conjunction with . Fig. 2 described, but the scope of protection of the invention is not thereby limited. In some embodiments, one or more other methods for supporting and / or protecting the protected container storage and / or one or more protected container modules thereof and / or for controlling access thereto may also be used optionally and / or alternatively.

[0010] In some embodiments, the processor may be a general-purpose processor (e.g., a general-purpose microprocessor or a central processing unit (CPU) of the type commonly used in desktop, laptop, smartphone, and other computers), but this does not limit the scope of the invention. The processor may have any of the following architectures: Complex Instruction Set Computing (CISC), Reduced Instruction Set Computing (RISC), Very Long Instruction Word (VLIW), hybrid, other types, or a combination of different architectures (e.g., different cores may have different architectures). To avoid complicating the description, a simplified processor example is shown; however, it is understood that the processor may optionally include any of the components of the other processors shown and described herein.

[0011] The I / O device 107 can be of various different types. In some embodiments, the I / O device 107 may be a Direct Memory Access (DMA) device that the processor can configure to perform DMA. In some embodiments, the I / O device 107 may be a Memory Mapped I / O (MMIO) device that the processor can configure through MMIO. In some embodiments, the I / O device 107 may be both a DMA device and an MMIO device.Specific examples of suitable different types of I / O device 107 include, but are not limited to, DMA controllers, DMA engines and various types of devices with at least one DMA controller and / or DMA engine, keyboards, touchscreens, fingerprint sensors or readers, iris scanners and other biometric devices, disk drives and other storage controllers, devices connected via Universal Serial Bus (USB), portable storage devices, flash drives, network cards, network controllers and other network and communication devices, sound cards and other audio devices, cameras, video devices and graphics cards and other graphics devices, GPS sensors (GPS = Geographic Positioning System) and other location sensors, and the like.

[0012] As shown, in some embodiments, the protected container memory 101 may include an embodiment of an input- and / or output-protected (I / O-protected) container module 102. In some embodiments, the protected container memory may also include one or more protected container pages configured for I / O access by the I / O device and / or otherwise used to permit I / O access by the I / O device. In some embodiments, the I / O-protected container module 102 and the I / O device 107 may perform I / O operations through the one or more protected container pages configured for I / O 103 and / or otherwise used for I / O operations. As shown, the I / O-protected container module 102 may access the one or more protected container pages 103 (e.g., read and / or write to them).Similarly, the I / O device 107 can access one or more protected container pages 103 112 (e.g., read and / or write them). In some embodiments, these accesses can be performed by the protected container architecture 105 and / or the logic 106 provided for controlling protected container accesses, which can be used to permit these accesses. For example, in some embodiments, the protected container architecture 105 and / or the logic 106 provided for controlling protected container accesses can be used to allow the I / O-protected container module 102 and the I / O device 107 to perform a DMA through the one or more protected container pages 103.In another example, the protected container architecture 105 and / or the logic 106 provided for controlling protected container accesses can, in some embodiments, serve to allow the I / O-protected container module 102 and the I / O device 107 to perform an MMIO through one or more protected container sides 103.

[0013] Fig. Figure 2 is a block diagram of a detailed embodiment of a computer system 200 suitable for implementing embodiments of the invention. The computer system comprises a processor 204, a memory 225, and an input and / or output device (I / O device) 207. The processor, the memory, and the I / O device are interconnected. As shown, the processor is interconnected to the memory via a first interconnection mechanism 208, the processor is interconnected to the I / O device via a second optional interconnection mechanism 209, and the I / O device is interconnected to the memory via a third optional interconnection mechanism 210. Examples of suitable interconnection mechanisms include, but are not limited to, one or more buses or other interconnections, one or more chipset components, other mechanisms for interconnecting the processor, the memory, and the I / O device, and various combinations thereof.

[0014] The Processor 200 can be any of the various different types described above as suitable for the Processor 100. In some embodiments, the Processor 200 may include a protected container architecture 205 designed to provide and / or support one or more of a protected container module 230 and an I / O-protected container module 202. Examples of suitable protected container modules include, but are not limited to, secure enclaves, isolated execution environments, isolated execution spaces, and the like. By way of example, in some embodiments, the protected container architecture may include Intel® Software Guard Extensions (Intel® SGX), an extension or future version of Intel® SGX, a protected container architecture with at least some features similar to those of Intel® SGX, and other protected container architectures.

[0015] As shown, the protected container architecture 205 can include one or more protected container support instructions 218. When these instructions are executed, they can trigger the processor to support various aspects associated with the protected container modules. For example, some embodiments may optionally include instructions for creating protected container modules, permanently deleting protected container modules, starting protected container modules, terminating protected container modules, handling paging for protected container modules, performing security operations on protected container modules, measuring protected container modules, otherwise supporting operations associated with protected container modules, or various combinations thereof.Some of these instructions may be privileged instructions, which can be executed by privileged software but not by unprivileged user-level software. Other instructions, however, may be unprivileged user-level instructions. These instructions may be from a processor instruction set (e.g., from at least one of its cores).

[0016] The processor's protected container architecture 205 can also include logic 206 designed to control protected container access. This logic can be used to control access to the protected container modules (e.g., module 230 and / or 202).In various embodiments, the logic provided for controlling protected container access can be distributed across various components of the processor, for example, across one or more caches 222, a memory management unit (MMU) 223, one or more translation lookaside buffers (TLBs) 224, architecture registers (not shown), one or more out-of-order execution buffers (not shown), execution units (not shown), and various other logics integrated on a chip that are used to access the protected container memory, store contents of the protected container memory, process the contents of the protected container memory, etc. The logic provided for controlling protected container access can be implemented in a circuit or other hardware, firmware (e.g., instructions stored in read-only memory), software, or a combination thereof (e.g.,(in at least one piece of hardware, possibly in combination with firmware and optionally with software). The following sections discuss different ways in which the logic intended to control protected container access can control access to the protected container modules.

[0017] Memory 225 can represent main system memory. Physically, the memory can contain one or more types of physical memory. Logically, the memory can be configured as either normal memory 226 or protected container memory 201. In some embodiments, the protected container memory can represent a dedicated or static portion of the total memory configured to implement the protected container memory. For example, in some embodiments, the protected container memory can represent an Intel® SGX Enclave Page Cache (EPC), but this does not limit the scope of the invention. In other embodiments, pages or other portions of the total memory can be dynamically configured (e.g., during runtime) or converted into pages or portions of either normal memory or protected container memory.For example, in some embodiments, the protected container memory can be an Intel® SGX Flexible Enclave Page Cache (Flexible EPC) in which pages can be converted between normal and protected container memory; however, this does not limit the scope of protection of the invention. In some embodiments, the processor may have one or more area registers that can be used to store one or more areas for configuring the portion of total memory used for the protected container memory. Typically, the areas in the area registers can be stored in a Basic Input / Output System (BIOS) during boot.

[0018] Normal memory 226 and protected container memory 201 can have different levels of protection or security, as provided by the processor's protected container architecture 205. Specifically, normal memory can have a lower level of protection than protected container memory. For example, normal memory may have a level of protection similar to that previously used for memory used to store one or more privileged system software modules 227 (e.g., a virtual machine monitor module, one or more operating system modules, etc.) and one or more user-level application modules 228 (e.g., a word processor, a spreadsheet application, an email application, a web browser, etc.).In contrast, protected container storage can have a higher level of protection than that previously used to store such privileged system software modules, user-level application modules, user-level data, and the like. This higher level of protection can be enforced, controlled, or otherwise provided, at least in part, by the processor's logic 206, which is designed to control protected container access.

[0019] During operation, one or more protected container modules 230 can be stored in the protected container memory 201. Each protected container module can, for example, contain one or more pages of the protected container memory. Examples of suitable protected container modules according to various embodiments include, but are not limited to, Secure Enclaves, isolated execution environments, isolated execution areas, and the like. For example, in some embodiments, the protected container modules can represent Intel® SGX Secure Enclaves; however, this does not limit the scope of protection of the invention.Each of the protected container modules may contain code and / or data and / or a stack and / or other content, the protection of which the protected container architecture 205 and / or the logic 206 of the processor intended to control protected container access may contribute, even from the most privileged system-level software.

[0020] In some embodiments, a Protected Container Page Metadata Structure (PCPMS) 231 may be used to store metadata for pages of the protected container storage 201. In one embodiment, the PCPMS may be structured to have different entries or sections for different corresponding pages in the protected container storage; however, the PCPMS may also be structured in other ways. Each entry can be used to store metadata for a corresponding page of the protected container storage. Examples of suitable metadata types include, but are not limited to, security-related metadata, access control metadata, and the like.Specific examples of suitable metadata, depending on the implementation, include information indicating whether pages are valid or invalid, information specifying protected container modules to which the protected container pages belong, information specifying the virtual addresses through which the protected container pages may be accessed, information specifying access permissions for the protected container pages (e.g., indicating whether the pages are readable and / or writable and / or executable), and similar information, as well as various combinations thereof. Alternatively, less metadata, more metadata, or other metadata may be used optionally. Furthermore, in other implementations, metadata may optionally be stored in two or more different data structures.An example of a suitable PCPMS is an Intel® SGX Enclave Page Cache Map (EPCM), but this does not limit the scope of the invention. In other embodiments, the PCPMS can also contain less data, more data, or data of a different type than is typically stored in an EPCM. At least some of the metadata stored in the PCPMS can represent controls that can be used by processor access control logic to control access to protected container memory pages.

[0021] As in Fig. As shown in Figure 2, the protected container module(s) 230, 202, and the PCPMS 231 can optionally be stored in the protected container memory 201 (e.g., as one or more pages thereof). Furthermore, or alternatively, the contents of the protected container module(s) and / or the PCPMS can optionally be stored in an on-chip data memory of the processor 204. For example, one or more caches 222 of the processor can be used to store the protected container pages and / or the PCPMS. Either dedicated sections of one or more existing caches can be used, or one or more dedicated caches can be used, or a combination of these methods can be employed.As another option, in addition to caches, the processor can optionally also have a data storage device of a different type, for example a dedicated data storage device integrated into a chip, in which the contents of the protected container module and / or the PCPMS can be stored.

[0022] To protect the protected container module(s) (e.g., module 230 and / or 202), various types of security features can be used in different embodiments. In some embodiments, the protected container architecture 205 can provide confidentiality protection for the contents (e.g., code and / or data and / or a stack) of the protected container modules. Maintaining confidentiality generally means preventing disclosure of the contents. In some embodiments, the logic 206 provided for controlling protected container access can be used to control access to the protected container memory 201.In some embodiments, the logic provided for controlling protected container access can be used to control access to the contents of the protected container memory, not only when such contents are stored in the protected container memory, but also when these contents temporarily reside on the chip within the processor at runtime (e.g., stored in caches, registers, buffers, or other memory elements, or transmitted via buses, or processed by various other structures or units, etc.). Generally, these contents may be in unencrypted form when they reside on the chip, which would typically make them more easily accessible if such access controls were not integrated into the chip.

[0023] In some embodiments, the logic 206 provided for controlling protected container access can be used to allow only authorized access to the contents of a given protected container module from code that is located within the same given protected container module, and can be used to prevent unauthorized access to the contents of the given protected container module from code that is not located within the same given protected container module (e.g., code belonging to another protected container module, code belonging to normal memory (e.g., code belonging to the privileged system software module(s) 227), etc.).In some embodiments, the contents of such protected container modules can be protected in this way both when they are stored in the protected container memory and when they are temporarily located, possibly in unencrypted form, in caches, registers, or structures of various other types within the processor. In some embodiments, such contents can even be protected in this way when the code attempting to access the contents of the protected container module belongs to highly privileged system-level software (e.g., an operating system, a virtual machine manager, a BIOS, etc.).In some implementations, a module of privileged system-level software can be used to manage various aspects of the protected container storage and / or protected container modules, for example, to allocate pages to the protected container storage and / or protected container modules and / or to manage virtual storage for the protected container storage and / or protected container modules. However, the protected container modules may be unreadable even to the modules of the most highly privileged system-level software. That is, even if the modules of privileged system software can manage certain aspects of the protected container storage and / or protected container modules, they may still not be able to read and / or write to the contents of the protected container modules.This can be advantageous in maintaining confidentiality and data integrity, even in the presence of malware with extensive privileges.

[0024] In some embodiments, to provide enhanced confidentiality, the processor 204 can inherently, autonomously, and / or transparently store software-protected container module contents encrypted by the processor in the protected container memory 201. However, in contrast, the processor cannot inherently, autonomously, and / or transparently store contents encrypted by the processor in normal memory 226 (e.g., without having to execute an encryption routine). For example, in some embodiments, all operations performed by the processor to store contents in the protected container memory (e.g., due to the execution of instructions to store contents in memory, where addresses are assigned to the protected container memory, due to the removal of cache lines containing contents of the protected container memory from the cache, etc.) may be) automatically by a memory encryption / decryption unit 221 of the processor. The memory encryption / decryption unit can be used to inherently, autonomously, and / or transparently to software encrypt the data before it is stored in the protected container memory, which can help ensure data confidentiality. Furthermore, in some embodiments, all operations performed from the protected container memory to read data into the processor (e.g., due to the execution of instructions to load from memory, where addresses are assigned to the protected container memory) may be inherently, automatically, and / or transparently to software decrypted by the memory encryption / decryption unit.However, access to data in normal storage cannot be performed via the storage encryption / decryption unit and cannot be performed via such automatic encryption / decryption.

[0025] In some embodiments, the protected container architecture 205 may optionally provide integrity protection for the contents of the protected container modules (e.g., module 230 and / or module 202 and / or the one or more pages 203). Maintaining integrity generally involves preventing fraudulent modification of the contents. Integrity protection is sometimes also referred to as authentication. In some embodiments, the processor may optionally provide inherent, automatic, and / or software-transparent cryptographic integrity protection for the contents of the protected container memory. However, in contrast, the processor may not inherently, automatically, and / or transparently provide such software-transparent cryptographic integrity protection for the contents of normal memory (e.g., without having to execute an encryption routine).For example, in some embodiments, the memory encryption / decryption unit 221 may optionally be used to calculate a Message Authentication Code (MAC), another authentication code, or other integrity check data for the contents of the protected container memory before the contents are stored in memory from the processor. Once the contents of the protected container memory have been received in the processor, the memory encryption / decryption unit may then optionally be used to authenticate or verify the integrity of the contents using the integrity check data before the contents may be used. The processor may optionally include logic to prevent access to the contents if the authentication or integrity checks fail.

[0026] In some embodiments, the protected container architecture 205 may optionally include logic to generate and use version information associated with the contents of the protected container memory 201 (e.g., one or more pages of the module 230, one or more pages of the module 202, the one or more pages 203, etc.). For example, pages of the protected container memory may optionally be assigned version information (e.g., a unique version counter value) when they are stored in the protected container memory from the processor. Once the contents of the protected container memory have been received back into the processor, the processor may then optionally check this version information. In some embodiments, the processor may only allow protected container memory contents that meet the version information (e.g.,Only versions that are listed as allowed or valid (only the latest version after removal from the cache) can be loaded. This can optionally help prevent the rendering of protected container code and / or protected container data.

[0027] To further illustrate certain inventive concepts, examples of possible types of protection have been described that can optionally be used in some embodiments to protect or secure protected container modules. It is understood, however, that depending on the specific implementation, the required level of security, the costs, the complexity of security compromises, and the like, the types and levels of protection may vary from implementation to implementation. The embodiments disclosed herein can be used with protected container modules of different types and with different levels of protection.Accordingly, the scope of protection of the invention is not limited to known types of protection mechanisms and / or protection levels used for I / O protection as described herein, even though the aforementioned protection mechanisms and various combinations thereof are suitable for embodiments and may optionally be used in some embodiments.

[0028] In Fig. 2, to which reference is made again, the computer system also includes the I / O device 207. In some embodiments, the I / O device may be a DMA device. In some embodiments, the I / O device may be an MMIO device. In some embodiments, the I / O device may be both a DMA device and an MMIO device. All of the various device types listed above are suitable as I / O device 107.

[0029] Up to now, protected container architectures (e.g., the protected container architecture 205) generally do not allow secure communication between the protected container storage 201 and the I / O device 207. Consequently, the protected container storage and / or one or more of its protected container modules may not be able to exchange secure I / O data between the protected container storage and the I / O device (e.g., write contents from the protected container storage to the I / O device and / or read data from the I / O device to the protected container storage) without such data exchanges potentially being easily viewed and / or fraudulently altered.

[0030] In Fig. 2, to which reference is made again, the protected container memory 201 can comprise an embodiment of an I / O-protected container module 202. As shown, in some embodiments, the I / O-protected container module can be stored in the protected container memory. As further shown, in some embodiments, the I / O-protected container module can comprise or at least access one or more protected container pages 203, wherein the one or more container pages are configured for secure I / O operations and / or serve another related purpose.

[0031] In some embodiments, the processor logic 206, which is provided for controlling protected container access, may be used to allow the I / O-protected container module and the I / O device to perform safe I / O operations. In some embodiments, the safe I / O operations may be safe DMA operations. In some embodiments, the safe I / O operations may be safe MMIO operations. In some embodiments, such safe I / O operations may be performed by one or more pages 203, or at least one or more pages of another section of the protected container memory 201, which is configured for such safe I / O operations between the I / O-protected container module and the I / O device, or which serves another related purpose.In some embodiments, the logic 206 of the processor, intended for controlling protected container accesses, may, by performing the secure I / O operations through one or more pages 203 or at least through a section of the protected container memory, take advantage of and / or extend at least some existing protection mechanisms associated with protecting the protected container memory in order to contribute to securing or protecting such I / O operations by means of the I / O device.

[0032] Fig. Figure 3 is a block diagram of an embodiment of a computer system 300 with an embodiment of an I / O-protected container module 302. As shown, in some embodiments the I / O-protected container module may be logically divided into a first module, referred to as the Trusted Management Protected Container Module (TMPCM) 334, and a second module, referred to as the Device Protected Container Module (DPCM) 336, although this is not a requirement.

[0033] The DPCM 336 can be used to communicate with the I / O device 307. Typically, in some embodiments, the DPCM may contain at least some type of code or other logic similar to that commonly found in a device driver module to allow the DPCM to communicate with the I / O device. However, the DPCM can be implemented at a user privilege level, rather than at a privilege level often used to implement device drivers. This makes it easier to allow user-level applications to perform safe I / O operations using the DPCM. In some embodiments, the DPCM may optionally be device-type specific, meaning it communicates only with one I / O device of a particular type. Alternatively, the DPCM may optionally be able to communicate with I / O devices of two or more different types.

[0034] However, a privileged module 338 may optionally also contain code or logic of other types associated with communicating with the I / O device 307. For example, code or logic of other types generally appropriate for a higher privilege level than user-level privileges may optionally be allocated to the privileged module. For example, the privileged module may contain code or logic used to handle interrupts, exceptions, or similar events that may occur during safe I / O operations. In some embodiments, the DPCM and a privileged module may interact or cooperate to implement a distributed hybrid user and privileged virtual device driver module 339.

[0035] In some embodiments, the TMPCM 334 may be equipped with more rights or privileges than the DPCM 336. For example, in an Intel® SGX implementation, the TMPCM may optionally be implemented as an Architectural Device Enclave (ADE), which may have special privileges beyond those available for normal Secure Enclaves; however, this does not limit the scope of protection of the invention. In some embodiments, the TMPCM may serve to mediate or connect via an interface between the I / O device 307 and logic 306 of a processor intended for controlling protected container access.

[0036] In some embodiments, the TMPCM 334 can be used to selectively assign and / or revoke ownership of the I / O device 307 or other rights to use it to the DPCM 336. For example, in some embodiments, the TMPCM can maintain a structure 335 for assigning a DPCM to an I / O device, such as a table or other data structure, that assigns or otherwise allocates ownership of the I / O device or other rights to use it to the DPCM. In implementations where more than one I / O device is to be used for safe I / O operations and / or where more than one DPCM is to be used for safe I / O operations, the structure provided for assigning a DPCM to an I / O device can similarly assign these other DPCMs to these other I / O devices.

[0037] In some embodiments, one or more pages 303 configured for safe I / O, or serving another related purpose, can be used by the DPCM and the I / O device to implement the safe I / O operations. In some embodiments, this page(s) may reside in a linear, virtual, or other logical address space 337 of the DPCM. This may allow the monitoring and control of certain access rights by the logic 306 provided for controlling protected container access to be used more effectively, although this is not a requirement.

[0038] In some embodiments, one or more pages may be of a new page type reserved for I / O and / or a specific type of I / O (e.g., DMA only, MMIO only, etc.). The use of a new page type may represent one or more bits in an EPCM or other protected container page metadata structure (PCPMS) that indicate the page(s) is / are of the new type, as well as any associated new or other access controls. Different examples of suitable types of access controls appropriate for these new page types are discussed in more detail below.

[0039] In some embodiments, only a single DPCM may possess the I / O device 307 or have another right to use it. In some embodiments, the processor logic 306, intended for controlling protected container accesses, may be used to determine, based on information representative of such possession of the I / O device or other right to use it by the DPCM, whether or not an I / O attempt is to be permitted by either the DPCM and / or the I / O device. That is, the ability to use the secure I / O operations may depend on one or more checks of whether the DPCM is authorized to perform secure I / O operations through the I / O device and / or whether the I / O device is authorized to perform secure I / O operations through the DPCM.

[0040] As shown, in some embodiments, attempted accesses by the I / O device to the one or more pages 303 configured for secure I / O operations or serving another related purpose may include or use an associated device identifier (e.g., a Security Attributes of Initiator (SAI)) 340. Likewise, in some embodiments, attempted accesses by the DPCM to the one or more pages 303 may include or use an associated DPCM identifier (e.g., a Secure Enclave identifier) ​​341. Alternatively, information in other forms sufficient to allow the processor logic intended to control protected container accesses to determine whether the attempted accesses should be permitted may be used instead.

[0041] As mentioned above, in some implementations, the safe I / O operations may include safe DMA operations. DMA is a method commonly used to send and receive data from the processor (e.g., a CPU) to memory (e.g., main system memory). Without DMA, the processor would generally have to be much more heavily involved in performing such data transfers. For example, without DMA, the processor might use programmed input or output by executing instructions to perform these data transfers. This would heavily burden the processor during the data transfers, making it generally less available to perform other tasks.

[0042] With DMA, however, the processor can delegate such data transfers to a DMA device (e.g., a DMA controller, a DMA engine, a device with a DMA controller or DMA engine, etc.). Initially, the processor can program the DMA device to perform the data transfers. For example, the processor can program one or more registers of the DMA-enabled device (e.g., using MMIO) to specify a memory address to be used for the transfer, a data volume to be transferred (e.g., the number of words to be transferred), a transfer direction (e.g., whether a read or a write operation is to be performed), and optionally other details of the data transfer (e.g., a port to be used, how much data to transfer in a burst, etc.).

[0043] The programmed DMA device can then directly access memory and perform read and / or write operations to execute the programmed data transfers essentially without further processor involvement. The data transfers can occur between memory and the DMA device and / or between different memory locations. Typically, once the data transfers have been programmed and initialized, the processor does not need to execute any additional instructions associated with carrying out the data transfers. This usually frees up the processor to perform other tasks while the data transfers take place. Once the DMA operations are complete, the DMA device can provide an interrupt to the processor or otherwise signal to the processor that the DMA transfers have finished.

[0044] In some embodiments, a protected container architecture of a processor and / or processor logic designed to control protected container access may permit secure DMA, in which secure or protected bidirectional communication takes place between a DPCM and a DMA device. Initially, a secure DMA configuration phase may be performed, in which the DPCM and the DMA device are mapped and configured to allow secure DMA operations. This is followed by a DMA specification phase, in which the specific secure DMA operations to be performed are defined. Finally, a secure DMA implementation phase may be performed, in which the specified secure DMA operations are carried out.

[0045] Fig. Figure 4 is a block flow diagram of a detailed embodiment of Method 444 for safe DMA configuration, in which a DPCM and a DMA device are associated and configured to allow safe DMA operations to be performed. Fig. Figure 5 is a block diagram of a detailed embodiment of a computer system 500, showing the phase of a safe DMA configuration in which a given DPCM 536 and a given DMA device 507 are associated with each other and configured to allow safe DMA operations. To streamline the description, procedure 444 is described in connection with computer system 500. However, it is understood that procedure 444 can optionally be performed by other computer systems and / or that computer system 500 can optionally perform other procedures.

[0046] In block 445 in Fig. 4, to which reference is made, a TMPCM can enumerate or otherwise identify one or more DMA devices that comprise a given DMA device in a computer system and can include the identified DMA devices in a device mapping table. As in Fig. As shown in Figure 5, a TMPCM 534 can identify a given DMA device 507 555 and access a device mapping table 535 556 to update it by listing the given DMA device in it or by otherwise including it in it.

[0047] There are different ways to identify DMA devices. In some embodiments, the identified DMA devices may be trusted DMA devices, and the TPMCM uses a set of platform configuration information. In one embodiment, the platform configuration information may represent trusted platform configuration information about the computer system, provided or possibly authenticated by a platform vendor or other trusted entity, and may possibly be updated after use by a network. For example, the platform configuration information may partially describe which devices of the computer system (e.g., possibly which types of devices and from which vendors) are considered trusted and support trusted DMA operations.

[0048] Although for simplicity the device mapping table is referred to as a "table," this term is used broadly here and refers to various different types of tables, linked lists, tuples, or other data structures that may be used to assign or otherwise associate the given DMA device with the given DPCM. In some embodiments, each of the identified DMA devices may have a corresponding device identifier and be identifiable by that identifier. Examples of suitable device identifiers include a Security Attributes of Initiator (SAI). The SAI or other device identifier can be used by hardware or other logic of the processor (e.g., processor 104, 204, or a processor with logic 306) to identify the associated I / O device (in this case, for example, the DPCM).to identify a DMA device when that device attempts to perform a memory access, sends a request, etc. A potential advantage of the SAI is that, generally, its generation is usually difficult to forge, which can be beneficial because untrusted devices have difficulty imitating its generation. As in . Fig. As shown in Figure 5, a SAI No. 1 (or a device identifier of another type) corresponding to the identified given DMA device 507 in the device assignment table 535 can be stored in the TMPCM.

[0049] In block 446 in Fig. 4, to which reference is made again, a given DPCM may request the TMPCM to take possession of a given DMA device from the identified DMA devices or to otherwise assign such a DMA device. The DPCM may, for example, send a message to the TMPCM or otherwise signal this request to the TMPCM. Fig. 5, to which reference is now made, the given DPCM can send a message, signal or other request 557 to the TMPCM 534 to request that the given DMA device 507 be assigned to the given DPCM 536.

[0050] In block 447 in Fig. 4, to which reference is made again, the TMPCM can assign the given DMA device to the given DPCM in the device mapping table or assign it in some other way. As in Fig. As shown in Figure 5, the TMPCM 534 can map the given DMA device 507 to the given DPCM 536 in the device mapping table 535 558. For example, the TMPCM may store a Device Protected Container Identifier (DPCMID No. 1) that corresponds to the given DPCM in an entry of the device mapping table 535, which has a SAI No. 1 or other device identifier that corresponds to the given DMA device. An example of a suitable DPCID in an Intel® SGX implementation is an Enclave Identifier (EID), but this does not limit the scope of the invention. This allows the given DPCM to be effectively mapped to the given DMA device.

[0051] In block 448 in Fig. 4, to which reference is made again, the TMPCM can provide information on the assignment or mapping of the given DMA device to the given DPCM for an I / O Memory Management Unit (MMU). As in Fig. As shown in Figure 5, the TMPCM 534 can signal or provide to an I / O MMU 550 an indication of the assignment of the given DMA device 507 to the given DPCM 536. For example, the TMPCM and / or the I / O MMU may update an entry in an I / O MMU assignment table 560 belonging to or at least accessible to the I / O MMU, which contains the SAI No. 1 or other identifier of the given DMA device, to include the DPCID No. 1 or other DPCM identifier of the given DPCM, thus indicating the assignment or mapping. This effectively informs the I / O MMU that the given DPCM corresponds to the given DMA device and is permitted to perform safe DMA operations with the given DMA device. In some embodiments, all memory accesses can be performed by the given DMA device as part of the mechanism for translating from a virtual to a physical address.This allows the I / O MMU to potentially detect a secure DMA, enabling it to selectively allow properly configured pairs of DMA devices and DPCMs to perform secure DMA without allowing other DMA devices and protected containers to perform secure DMA, and / or without allowing other improperly configured DMA devices to access the protected container memory. In some embodiments, the I / O MMU may reside within the processor (e.g., the 104 and / or 204 processor) or at least on the same chip or die as the processor to ensure trustworthiness. Examples of suitable I / O MMUs for embodiments include a general-purpose I / O MMU such as those commonly used for access control of peripheral devices (e.g.,devices connected via a Southbridge) are used, as well as a GT-MMU such as those commonly used for access control of graphical devices.

[0052] In block 449 in Fig. 4, which is referred to again, are one or more pages in a protected container store, which are optionally located within the logical address space (e.g., a linear, virtual, or other logical address space) of the given DPCM or are at least accessible to the given DPCM and which translate to a given physical address (e.g., the Guest Physical Address) and are configured to allow secure DMA. Because the protected container page(s) are located within the logical address space of the given DPCM and / or are at least accessible to the given DPCM, policies and logic for controlling access to protected container store, which are also used for other access to the protected container store, can potentially be exploited to control access to the protected container page(s) for secure DMA (e.g.,to ensure that the attempted access takes place in a protected container mode, originates from the correct DPCM, occurs with the correct access permissions, etc.).

[0053] In some embodiments, the protected container page(s) can optionally be allocated exclusively to the given DPCM and can therefore optionally be used to assign or map the given DMA device exclusively to the given DPCM. Alternatively, in other embodiments, an exclusive allocation criterion may optionally not be enforced. Instead, some I / O devices may be assigned to other device-protected container modules. For example, a Universal Serial Bus (USB) controller may have different functions that may be assigned to different DPCMs for either an MMIO or a DMA. In another example, under certain conditions, a given function of an I / O device may be assigned to different DPCMs based on an additional identifier, such as a VLAN for a network controller. As in Fig. As shown in Figure 5, the DPCM 536 can at least partially configure one or more protected container pages 503 for secure DMA.

[0054] The protected container page(s) can be configured for secure DMA in different ways depending on the embodiment. In some embodiments, the given DPCM might require a module of privileged system-level software to allocate a protected container memory page to a given logical address (e.g., a given linear address), which may optionally be located in the logical address space of the given DPCM or otherwise accessible to the given DPCM. The privileged system-level software module might, for example, be generally responsible for storage virtualization management. The privileged system-level software module can allocate and assign the protected container memory page to the given logical address and can return a corresponding physical address (e.g., a Guest Physical Address (GPA)) to the DPCM. As shown below (e.g., in conjunction with Fig. 7) As explained in more detail, the GPA can be used by the DPCM to configure DMA communication. The physical addresses (e.g., the GPA) can be used partially instead of a linear, virtual, or other logical address, since the DMA devices (e.g., the given DMA device) may not be sufficiently familiar with memory virtualization to readily use logical addresses. Alternatively, if an unused page accessible to the given DPCM and already assigned a suitable physical address is available, it may be repurposed for secure DMA without requiring the module of a privileged system-level software to allocate a new page. Other methods are also considered and will be apparent to the person skilled in the art from the present disclosure.

[0055] In some embodiments, one or more security checks or determinations may optionally be performed before the protected container page(s) is / are configured for secure DMA. For example, in one embodiment, it may be checked or determined whether the protected container page(s) to be configured for secure DMA resolves to a protected container storage page(s) accessible to the given DPCM. Alternatively, one or more additional and / or other security checks or determinations may optionally be performed before the protected container page(s) is / are configured for secure DMA. If any such checks or determinations fail, the protected container page(s) cannot be configured for secure DMA.Conversely, if such checks or provisions are successful, the protected container page(s) can be configured for secure DMA.

[0056] The protected container page(s) can be configured for safe DMA in different ways depending on the implementation. To configure the protected container page(s) for safe DMA, in some implementations, one type of protected container page(s) can be changed to a new, dedicated page type for which safe DMA is permitted. In one implementation, this new page type can optionally be specifically designated for safe DMA. In some implementations, the type of protected container storage page can be changed by modifying metadata for the protected container page(s), for example, by changing a page type field of a corresponding entry in a PCPMS or other data structure. In an Intel® SGX implementation, this might involve, for example, specifying an EPCM.The PT field of an EPCM is modified to have a new value assigned to the secure, DMA-enabled, protected container memory page type. Unlike traditional types of protected container memory pages, this new page type may have access controls that allow secure DMA. For example, this new page type may be accessible to DMA from a properly mapped or assigned DMA device. Specifically, the processor and / or I / O MMU logic designed to control protected container access may allow the properly mapped or assigned DMA device to access (e.g., read and / or write) this page of the new type. Conversely, the processor and / or I / O MMU logic designed to control protected container access may prevent the DMA device from accessing pages of other types within the protected container memory.

[0057] To configure the protected container page(s) for secure DMA, some implementations may configure a physical address (e.g., a Guest Physical Address) that is permitted for accessing the protected container page(s) via secure DMA. This physical address (e.g., the Guest Physical Address) may have been previously determined by a module of privileged system-level software for the protected container page(s). In some implementations, the permitted physical address may be configured by modifying metadata for the protected container page(s), for example, by changing a field for access via a permitted physical address in a corresponding entry in a PCPMS or other data structure.

[0058] To configure the protected container page(s) for secure DMA, some implementations allow one or more permitted access types to be optionally configured for the one or more protected container storage pages. Examples of different access types that may or may not be configured for the one or more protected container storage pages include, but are not limited to, a read-only (R) access type, a write-only (W) access type, and a read-only (RW) access type. Configuring such access types is optional and not a requirement. In other implementations, only certain access types may be permitted by default, or all access types may be permitted by default.

[0059] In Fig. 5, which is referred to again as shown in 561, the given DPCM 536 can configure the protected container page(s) 503 for secure DMA or at least initiate the configuration of the protected container page(s) by modifying metadata for each page in a corresponding PCPMS entry 531. This can include, for example, configuring a page type field 552 to have a page type that allows secure DMA, configuring a valid physical address field 553 to have a physical address (e.g., a Guest Physical Address) through which the page can be accessed, and configuring a valid access type field to allow one or more different access types (e.g., read, write, read and write, etc.).Alternatively, the page does not necessarily need to have a new type for storage in the page type field; an existing page type and / or a page used for other purposes can optionally be suitable as a page that allows safe DMA. For example, the same page type already stored in the page type field can be used for both pages that allow safe DMA and pages that do not, and other metadata can be stored elsewhere (e.g., another "suitability" field in the PCPMS record confirming or indicating that safe DMA is allowed for the page, without requiring the page to have a page type that allows safe DMA or be specifically designed to allow safe DMA). The allowed physical address can be checked later before safe DMA is performed (e.g., as in conjunction with the...). Fig. (described in sections 8-9). Instead of making such a configuration only in the PCPMS, alternatively two or more structures can be used to store this and / or additional and / or other metadata or configuration information for the protected 503 container page(s).

[0060] Fig. Figure 6 is a block diagram of an embodiment of a processor 604, which serves to implement an embodiment of an instruction 619 relating to the configuration of DMA-protected container pages. In some embodiments, the processor can be the processor 104 of Fig. 1 and / or the 204 processor from Fig. 2 or be included in one of these processors. The components, features, and special optional details described herein for Processors 104 and 204 also apply optionally to Processor 604. Alternatively, Processor 604 may optionally be included in similar or other processors instead of Processors 104 and 204. Furthermore, Processors 104 and 204 may also contain similar or other processors besides Processor 604.

[0061] The processor 604 includes a decoding unit 664 that can receive and decode the instruction 619 relating to the configuration of DMA-protected container pages. In some embodiments, the instruction relating to the configuration of DMA-protected container pages can specify or otherwise indicate protected container access to the associated protected container page to be configured for secure DMA, can specify or otherwise indicate a permissible physical access address 653 (e.g., a guest physical address) for the associated protected container page to be configured for secure DMA, and can specify or otherwise indicate one or more permissible access types or permissions for the associated protected container page to be configured for secure DMA.The command may, for example, include fields that provide such information and / or specify or indicate registers in which such information is stored. In some embodiments, the specified protected container access may be a signal or indication that access is being made from a protected container module to a permitted address (e.g., a linear or other logical address permitted for the protected container module), thereby making it easier to ensure that configuration is performed only from within the protected container and that the protected container configures only a page permitted for that protected container. In a particular example, the specified protected container access in an Intel® SGX implementation may be an enclave access (EA) indication, but this does not limit the scope of protection of the invention.The instruction relating to the configuration of DMA-protected container pages can represent a macro instruction, a machine code instruction, or an assembly language instruction from a processor instruction set. The decoding unit can output one or more instructions or one or more control signals at a relatively low level (e.g., one or more micro-instructions, one or more micro-operations, one or more microcode entry points, one or more decoded instructions, or one or more control signals, etc.) that reflect, represent, and / or are derived from the received instruction relating to the configuration of DMA-protected container pages at a relatively higher level. In some embodiments, the decoding unit may include one or more input structures (e.g.,A decoding unit consists of a port(s), interconnection(s), or interface through which a command can be received; logic coupled to this for command recognition and decoding, through which the received command can be recognized and decoded; and one or more output structures coupled to this (e.g., port(s), interconnection(s), or interface) through which the command(s) or control signal(s) can be output. The decoding unit can be implemented using various different mechanisms, including, but not limited to, microcode read-only memories (ROMs), lookup tables, hardware implementations, programmable logic arrays (PLAs), and other mechanisms suitable for implementing decoding units.

[0062] An execution unit 665 is coupled to the decoding unit 664. Although only one execution unit is shown, it is understood that this single execution unit can represent one or more execution units and / or logics distributed across one or more units, which together constitute an execution unit for carrying out the instruction. The execution unit can receive one or more decoded or otherwise converted instructions, or one or more decoded or otherwise converted control signals, which represent and / or are derived from the instruction relating to the configuration of DMA-protected container pages. The execution unit serves to act upon and / or as a consequence of the decoding of the instruction relating to the configuration of DMA-protected container pages (e.g.,(in response to the fact that one or more commands or control signals have been decoded from the command), to perform one or more operations associated with the command.

[0063] As shown, in some embodiments, the execution unit may include optional security check logic 667. The security check logic and / or the execution unit may perform one or more security checks to determine whether or not to allow one or more subsequent command operations to configure the associated protected container page for secure DMA. For example, in one embodiment, it may be checked or determined whether the specified or otherwise indicated protected container access resolves to a protected container page accessible to the DPCM currently executing the command. Alternatively, one or more additional and / or other security checks or determinations may be optionally performed before the protected container page(s) are configured for secure DMA.If any such checks or determinations fail, the associated protected container page cannot be configured for safe DMA. For example, the execution unit may optionally signal error 669 and terminate the command execution.

[0064] Conversely, if all such checks or determinations are successful, the execution unit 665 can proceed to configure the associated protected container pages for secure DMA. As shown, the execution unit may include logic 668 for configuring protected container pages. In some embodiments, the logic for configuring protected container pages and / or the execution unit may access one or more structures 631, such as a PCPMS, and configure one or more sets of information therein to configure the associated protected container page for secure DMA. In some embodiments, for example, a type of page 652 may be configured as a new, dedicated page type that is configured for secure DMA.To give another example, in some embodiments, a permitted physical access address (e.g., a guest physical address previously determined by the privileged system-level software) may be configured for the page. To give yet another example, in some embodiments, one or more permitted access types (e.g., read, write, read and write, etc.) may be configured for the associated protected container page. In other embodiments, additional configurations, other configurations, or a combination of both may be optionally implemented.

[0065] The execution unit and / or processor may contain special or specific logic (e.g., transistors, an integrated circuit, or other hardware, possibly combined with firmware (e.g., instructions stored in non-volatile memory) and / or software) designed to perform such operations in response to and / or as a consequence of the instructions (e.g., in response to one or more instructions or control signals being decoded from the instructions). In some embodiments, the execution unit may include one or more input structures (e.g., port(s), interconnect(s), an interface) for receiving source data, circuitry or logic coupled to it for receiving and processing the source data, and one or more output structures coupled to it (e.g., port(s), interconnect(s), an interface) for executing the operations.

[0066] Fig. Figure 7 is a block diagram of a detailed embodiment of a computer system 700, showing a phase of a secure DMA specification in which a given DPCM 736 specifies secure DMA operations to be performed by a given DMA device 707. As shown in Figure 771, the DPCM 736 can access or configure DMA buffers 772 in one or more protected container pages 703 that are configured for secure DMA or serve another related purpose. In some embodiments, physical addresses (e.g., guest physical addresses), for example, based on those initially used to configure the one or more protected container pages 703, may be used as pointers.

[0067] As shown in Figure 773, the DPCM 736 can access or configure one or more protected container pages 770, configured for secure MMIO or serving another related purpose, to program device registers for the given DMA device 707 and thereby specify and initiate the DMA operations. In some embodiments, these device registers may be programmed using secure MMIO, as disclosed elsewhere herein. In some embodiments, physical addresses (e.g., guest physical addresses), for example, based on those initially used to configure the one or more protected container pages 703, may be used as pointers. Alternatively, a method other than secure MMIO may optionally be used to specify and initiate the DMA operations.

[0068] Fig. Figure 8 is a block diagram of a detailed embodiment of a computer system 800, showing that a given DMA device 807 attempts a DMA access 875 and an I / O MMU 850 is used to perform security checks to determine whether or not to allow the attempted DMA access. As shown, the given DMA device attempts a DMA access 875. In some embodiments, the given DMA device may attempt the DMA access using a physical address and a device identifier. In some embodiments, the physical address may be a guest physical address previously programmed by a DPCM in one or more pages configured for or used for DMA purposes (e.g., as above in conjunction with Fig. (described in section 7). In some embodiments, the device identifier may be a SAI, but this does not limit the scope of protection of the invention. In some embodiments, the DMA device may have both a secure SAI and an unsecure SAI, and when performing a secure DMA, may perform the access using the secure SAI.

[0069] As further shown, the attempted DMA access can be performed by an I / O MMU 850. The I / O MMU can be used for memory access by devices. The I / O MMU can be used to perform one or more security checks to determine whether the attempted DMA access should be allowed or not. A few typical examples of security check types that can be optionally performed in some embodiments are described in more detail below; however, it is understood that subsets, supersets, and other security checks can also be performed as options.

[0070] As shown in section 876, the I / O MMU (850) can determine whether the physical address of the attempted DMA access resolves to protected container storage and / or to one or more protected container pages (803) configured for secure DMA or serving another related purpose. For example, this might involve translating the physical address (e.g., the Guest Physical Address) of the attempted access to a Host Physical Address, if necessary, and verifying whether the Host Physical Address resolves to the protected container storage and / or the protected container page(s) (803). The I / O MMU can signal or otherwise trigger a DMA termination event (878), such as an error, if the physical address does not resolve to the protected container storage and / or one or more protected container pages (803).This may represent a conflict, insofar as a secure DMA is attempted (e.g., as specified by the secure SAI), but the attempted access does not reach the protected container storage.

[0071] As shown in Figure 877, the I / O MMU can attempt to look up a DPCM identifier in an I / O MMU mapping table (Figure 860) using the device identifier associated with the attempted DMA access. For example, if the device identifier is a SAI, the I / O MMU might attempt to find an entry in the table that maps the SAI to a corresponding assigned or allocated DPCM identifier. For instance, an entry in the table, as shown, might contain an SAI No. 1 corresponding to the given DMA device, as well as a DPCMID No. 1 corresponding to the given DPCM module configured to perform safe DMA with the given DMA device. In such a case, the I / O MMU can retrieve the corresponding assigned or allocated DPCM identifier (e.g., DPCMID No. 1) from the table. This can be used, in part, to determine that the given DMA device is assigned to the given DPCM.If the SAI or other device identifier is not validly mapped to a DPCM identifier in the table, the I / O MMU can alternatively be used to signal or otherwise trigger the error or other DMA termination event 878.

[0072] As shown in Figure 879, the I / O MMU can access metadata associated with the attempted access. For example, in some embodiments, the I / O MMU can access a PCPMS entry 831 corresponding to a page being attempted to access during the DMA access. For example, the page might be an entry for the host physical address. In some embodiments, the I / O MMU can access a page type field 852 to determine whether the specified page type is configured for safe DMA. If not, the I / O MMU can raise the DMA termination event 878. In some embodiments, the I / O MMU can access a field 853 designated for the allowed page type to determine whether the specified allowed physical address matches and / or is compatible with a physical address of the attempted DMA access.This can be used, in part, to determine whether the DMA device is currently attempting to access memory that has been configured or authorized for safe DMA. If not, the I / O MMU can be used to trigger the DMA termination event 878. In some embodiments, the I / O MMU can access a field designated for allowed access types, 854, to determine whether the specified allowed access type(s) match or are compatible with the access type of the attempted DMA access. If not, the I / O MMU can be used to trigger the DMA termination event 878. In some embodiments, the I / O MMU can access a DPCMID field, 899, to determine whether the DPCMID matches the DPCMID obtained from the I / O MMU mapping table. For example, in an Intel® SGX implementation, an Enclave ID (EID) can be created using an EPCM.The SID can be obtained from the SECS, and it can be checked whether an EID obtained from the I / O MMU mapping table matches the EID from a SECS.EID field. If no match is detected, the I / O MMU can be used to trigger the DMA termination event 878.

[0073] These are merely a few examples for illustration. In other embodiments, the I / O MMU may perform fewer, more, or different security checks. If all implemented security checks required for the particular implementation are successful, the I / O MMU may, as shown in Figure 880, allow the attempted DMA access to proceed. Conversely, if any of the implemented security checks fail, the I / O MMU may trigger the DMA termination event 878.

[0074] Fig. Figure 9 is a block flowchart of a detailed embodiment of a method 982 for secure DMA, in which a DMA device attempts DMA access and several security checks determine whether the attempted DMA access may be carried out or not. In block 983, the DMA device attempts DMA access using a physical address and a device identifier. In some embodiments, the physical address may be a Guest Physical Address, but this does not limit the scope of protection of the invention. In some embodiments, the device identifier may be a SAI, but this does not limit the scope of protection of the invention.

[0075] Block 984 determines whether the access is to a protected container storage and / or one or more pages thereof configured for secure DMA. If so, the procedure proceeds to block 985. If not, the procedure proceeds to block 991.

[0076] Block 985 determines whether a DPCM is assigned to the DMA device attempting access in an I / O MMU mapping table. If so, the process proceeds to block 986. If not, the process proceeds to block 991. In block 986, a DPCM identifier corresponding to the device identifier is retrieved from the I / O MMU mapping table. For example, in an Intel® SGX implementation, the DPCM identifier is a Secure Enclave ID; however, this does not limit the scope of protection of the invention.

[0077] Block 987 determines whether a page type corresponding to the access attempt is configured for secure DMA. This might involve, for example, determining whether the page type is a specific new, dedicated page type configured for secure DMA. Typically, this includes looking up the type of page being accessed in an EPCM, PCPMS, or other metadata structure. If so, the procedure proceeds to block 988. If not, the procedure proceeds to block 991.

[0078] Block 988 determines whether the physical address associated with the attempted access (e.g., the Guest Physical Address associated with a read or write operation) matches or is at least compatible with a valid physical access address for the page being accessed. This valid physical access address can typically be stored in an EPCM, PCPMS, or other metadata structure. If so, the procedure proceeds to block 989. If not, the procedure proceeds to block 991.

[0079] Block 989 determines whether the attempted access method, such as a read or write operation, matches or is at least compatible with a permitted access method(s) for the page being accessed. Typically, the permitted access method(s) can be stored in an EPCM, PCPMS, or other metadata structure. If so, the procedure proceeds to block 990. If not, the procedure proceeds to block 991.

[0080] Block 990 allows attempted DMA access. For example, secure DMA access allows the DMA device to access data within a section of protected container storage (e.g., a new page that permits secure DMA). This advantageously provides a secure, low-latency, and generally high-bandwidth, bidirectional communication data channel between the DPCM and DMA devices of various types. In a specific illustrative example, the DMA device might be a USB-connected device, and secure DMA might be used to place data directly from the USB-connected device into a new type of page that permits secure DMA within the protected container storage.This allows data from the USB-connected device to be securely stored in the protected container memory accessible to the DPCM, thus protecting it from access by other elements in the system, even highly privileged system software and various protected container modules. Conversely, if any access checks fail, attempted DMA access in block 991 can be blocked or prevented.

[0081] In some embodiments, a processor's protected container architecture and / or processor logic designed to control protected container access may allow for secure MMIO, where a processor can communicate information (e.g., control information, configuration information, etc.) to an MMIO device via secure MMIO. For example, secure MMIO can be used to write control registers of the MMIO device, which is mapped to an MMIO space in such a way that other software (e.g., other protected containers, privileged software, etc.) cannot access the same MMIO space. Initially, a secure MMIO configuration phase may be performed, in which a given DPCM and a given MMIO device are mapped to each other, and the secure MMIO is configured.Afterwards, an MMIO implementation phase can be carried out, in which the given DPCM can perform a secure MMIO to communicate information (e.g. control information, configuration information, etc.) to the given MMIO device.

[0082] Fig. Figure 10 is a block flow diagram of a detailed embodiment of a method 1092 in which a given DPCM and a given MMIO device are mapped to each other and a secure MMIO is configured. Fig. Figure 11 is a block diagram of a detailed embodiment of a computer system 1100, showing a phase of a secure MMIO configuration in which a given DPCM 1136 and a given MMIO device 1107 are mapped to each other and a secure MMIO is configured. To streamline the description, method 1092 is described in connection with computer system 1100. However, it is understood that method 1092 can optionally be performed by other computer systems and / or that computer system 1100 can optionally perform other methods.

[0083] In block 1093 in Fig. 10, to which reference is made, a TMPCM can enumerate or otherwise identify one or more MMIO devices that contain a given MMIO device in a computer system and can include the identified MMIO devices in a device mapping table. In some embodiments, the TMPCM can also identify resources of the MMIO devices, for example, their respective MIMO ranges. As in Fig. As shown in Figure 11, a TMPCM 1134 can identify a given MMIO device 1107 1155 and access a device mapping table 1135 1156 so that the given MMIO device is included in it. In some embodiments, the TMPCM may use platform configuration information 1151 to identify the MMIO devices, for example, in a manner analogous to that shown above (e.g., in conjunction with block 445 of Figure 11). Fig. 4) described for the DMA devices.

[0084] In block 1094 in Fig. 10, to which reference is made again, a given DPCM may request the TMPCM to take possession of a given of the identified MMIO devices or to otherwise assign such an MMIO device. The DPCM may, for example, send a message to the TMPCM or otherwise signal this request to the TMPCM. Fig. 11, to which reference is now made, the given DPCM can send a message, signal or other request 1157 to the TMPCM 1134 to request that the given MMIO device 1107 be assigned to the given DPCM 1136.

[0085] In block 1095 in Fig. 10, to which reference is made again, the TMPCM can assign the given MMIO device to the given DPCM in the device mapping table or map it in some other way. This mapping can be, but need not be, an exclusive mapping, as discussed elsewhere herein. For example, some I / O devices may be mapped to other protected container modules of a device. For instance, a Universal Serial Bus (USB) controller may have different functions that may be mapped to different DPCMs for either an MMIO or a DMA. In another example, under certain conditions, a given function of an I / O device may be mapped to different DPCMs based on an additional identifier, such as a VLAN for a network controller. As discussed in Fig. As shown in Figure 11, the TMPCM 1134 can map the given MMIO device 1107 to the given DPCM 1136 in the device mapping table 1135. For example, the TMPCM may store a Device Protected Container Identifier (DPCMID No. 1) that corresponds to the given DPCM in an entry of the device mapping table 1135 that corresponds to the given MMIO device. An example of a suitable DPCID in an Intel® SGX implementation is an Enclave Identifier (EID), but this does not limit the scope of the invention. In this example, the given MMIO device has a device identifier (ID), namely ID No. 1, and an MMIO range of "A to B". This creates an association or mapping between the given MMIO device and the given DPCM.

[0086] In block 1096 in Fig. 10, to which reference is made again, the TMPCM can provide a device identifier (ID) of the given associated MMIO device and an MMIO range of the given associated MMIO device to the DPCM. For example, this information may be provided in a message from the TMPCM to the DPCM and is available in platform configuration information for the computer system. As in Fig. As shown in Figure 11, the TMPCM 1134 can send a message 1198 to provide a device identifier of the given associated MMIO device 1107 (e.g. ID No. 1) and an MMIO range of the given associated MMIO device (e.g. from A to B) for the given DPCM 1136.

[0087] Different types of device identifiers are possible for the assigned MMIO devices in different embodiments. In some embodiments, each MMIO device can have a unique row number, a unique entry, or another unique index in the device mapping table. In some embodiments, such an index can serve as the device identifier for the MMIO device. For example, ID No. 1 of the given MMIO device might be the row number where the MMIO range "A to B" for the given MMIO device is located. In other embodiments, each MMIO device can have a Security Attributes of Initiator (SAI) as its device ID. Alternatively, other large and / or unique numbers can optionally be used as device identifiers.

[0088] In block 1097 in Fig. 10, to which reference is made again, are one or more pages in a protected container memory, which are optionally located within the logical address space (e.g., a linear, virtual, or other logical address space) of the given DPCM or are at least accessible to the given DPCM, configured to allow secure MMIO with the identified given MMIO device and its MMIO space. As in Fig. As shown in Figure 11, the given DPCM 1136 can configure one or more protected container storage pages 1103 accessible to the given DPCM, at least partially, to allow secure MMIO by means of the identified given MMIO device (e.g., ID No. 1) and its MMIO range (e.g., from A to B).

[0089] The protected container page(s) can be configured for secure MMIO in different ways depending on the implementation. If no protected container page is currently available for configuration for secure MIMO, the DPCM can allocate a new protected container page in some implementations. In some implementations, one or more security checks or determinations can optionally be performed before the protected container page(s) are configured for secure MMIO. For example, in some implementations, it can optionally be checked or determined whether the device identifier of the given MMIO device is correctly mapped to the given DPCM. This might involve, for example, communicating with the TMPCM to verify the mapping between the given DPCM and the given MMIO device.For example, the given DPCM can provide the MMIO device identifier previously obtained from the TMPCM (e.g., as discussed for block 1096) to the TMPCM as a query, and in order to configure the one or more pages for a secure MMIO, it can be checked whether the TMPCM returns a DPCMID that matches the DPCMID that is currently attempting to configure the one or more pages for a secure MMIO.

[0090] In another example, some embodiments may optionally check or determine whether the MMIO offset is page-aligned (e.g., aligned to a 4-kilobyte page or to other implemented page-sized boundaries), because memory can generally be managed in page-sized sections. In yet another example, some embodiments may optionally check or determine whether the requested offset and the offset plus a page size (e.g., a 4-kilobyte page or another implemented page size) are within the MMIO area. Such checks or determinations can optionally provide better assurance that an access attempt will not target a different MMIO area, which might be allocated to a different DPCM.Alternatively, one or more additional and / or other security checks or provisions can optionally be performed before the protected container side(s) is / are configured for secure MMIO. If any such implemented checks or provisions fail, the protected container side(s) cannot be configured for secure MMIO. Conversely, if such checks or provisions are successful, the protected container side(s) can be configured for secure MMIO.

[0091] In Fig. Reference 11 to which is made, it is assumed that if any such optional checks or determinations are successful, as shown in 1161, the given DPCM 1136 can configure the protected container storage page(s) 1103 for secure MMIO. The protected container page(s) can be configured for secure MMIO in different ways in different embodiments. In some embodiments, this can involve modifying metadata in a PCPMS. For example, for each page configured for secure MMIO, metadata 1152, 1154, 1199 can be modified in a corresponding PCPMS entry 1131. Instead of having the metadata in the PCPMS or another single structure, alternatively two or more structures can be used to store this and / or additional and / or other metadata for the protected container page(s) 1103.

[0092] As shown, in some embodiments, the given DPCM 1136 can configure a page type field 1152 to have a page type that permits secure MMIO. In some embodiments, a new, dedicated page type for which secure MMIO is permitted may exist. In an Intel® SGX implementation, for example, this may involve modifying an EPCM.PT field of an EPCM to have a new value assigned to a page type that permits secure MMIO. In contrast, other types of protected container storage pages may not permit secure MMIO.

[0093] As shown, in some embodiments, the given DPCM 1136 can configure an MMIO range field 1199 to specify a valid MMIO range for use in safe MMIO. In an Intel® SGX implementation, for example, this might involve modifying a new EPCM.IOADDR field of an EPCM to specify a valid MMIO range for use in safe MMIO, such as a base plus offset.

[0094] As shown, in some embodiments, the given DPCM 1136 can optionally configure a field designated for allowed access type(s) to configure the access type(s) permitted for the protected container page(s) for use in secure MMIO. In an Intel® SGX implementation, this might involve, for example, modifying an EPCM.RW field of an EPCM to specify the allowed access type permissions. Examples of different access types that may or may not be configured for the one or more protected container storage pages include, but are not limited to, a write (W) access type and a read / write (RW) access type. Configuring such access types is optional and not a requirement.In other embodiments, only certain access types may be permitted by default, or all access types may be permitted by default.

[0095] In some embodiments, a new instruction relating to the configuration of MMIO-protected container pages may optionally be included in a processor's instruction set to allow a protected container page to be configured for secure MMIO. In some embodiments, the instruction may be a user-level instruction, and a DPCM may use the instruction to configure a page in its linear or other logical address space, or a page that is at least accessible to the DPCM, for secure MMIO. In some embodiments, the instruction relating to the configuration of MMIO-protected container pages may specify or otherwise indicate a linear or other logical address of the protected container memory page, may specify or otherwise indicate an MMIO device identifier, and may specify or otherwise indicate MMIO address information (such as an MMIO space offset).In some embodiments, the command can optionally specify or otherwise indicate one or more permitted access modes, such as read, write, or read and write. For example, the command can include fields that provide such information and / or specify registers in which such information is stored. The command relating to the configuration of MMIO-protected container pages can be decoded by a decoding unit, and the decoded commands or control signals can be executed by an execution unit. The decoding unit can be the decoding unit 664 of . Fig. 6 be the same or similar.

[0096] In response to the command, the execution unit can perform any of the optional security checks or provisions mentioned above, and / or others that may be required for the specific implementation. For example, the execution unit can perform a check to ensure that the MMIO device is associated with the DPCM executing the command, and it can perform a check to ensure that the offset is page-aligned and that the requested offset and the offset plus the page size are within the MMIO range. If such security checks or provisions are successful, the execution unit can configure the page for secure MMIO in response to the command. This can be done by performing any of the configuration operations mentioned above, and / or others that may be required for the specific implementation.For example, in some embodiments, the execution of the command might configure a page type to allow secure MMIO (e.g., by configuring the page type field 1152), configure an MMIO range (e.g., by configuring the MMIO range field 1199), and optionally configure one or more allowed access types (e.g., by configuring the field designated for allowed access type(s) 1154). Alternatively, such operations can optionally be split into two or more separate commands, if desired.

[0097] Fig. Figure 12 is a block flow diagram of a detailed embodiment of a method 1202 in which a given DPCM performs a safe MMIO. Fig. Figure 13 is a block diagram of a detailed embodiment for a computer system 1300, showing how a given DPCM performs a secure MMIO. To streamline the description, method 1202 is described in conjunction with computer system 1300. However, it is understood that method 1202 can optionally be performed by other computer systems and / or that computer system 1300 can optionally perform other methods.

[0098] In block 1203 in Fig. 12, to which reference is made, a given DPCM may attempt to access one or more pages configured for secure MMIO (e.g., by means of a read or write operation). As in Fig. As shown in Figure 13, a given DPCM 1336 may attempt to access one or more protected container pages 1302 configured for secure MMIO 1316. In some embodiments, the access attempt may be made using a linear or other logical access address that is in the logical address space of the given DPCM or is at least accessible to the DPCM in a protected container memory.

[0099] In block 1204 in Fig. In accordance with section 13, it can be determined whether one or more access control checks for the one or more pages configured for secure MMIO are successful. If the check(s) is / are unsuccessful, the procedure can proceed to block 1205, where the attempted access can be denied. For example, an error message might be displayed. If, however, the check(s) is / are successful, the procedure can proceed to block 1206. As described in Fig. As shown in Figure 13, the attempted access 1316 can be performed by logic 1306 designed to control protected container access, which includes a Memory Management Unit (MMU) 1311. The logic designed to control protected container access and / or the MMU can perform one or more access control checks to determine whether or not to allow the attempted access and / or secure MMIO.

[0100] Different types of access checks are suitable for different embodiments. In some embodiments, one or more conventional checks can optionally be performed to access protected container storage. For example, in some embodiments, access checks might require that attempted access be allowed based on the fact that it is made in a protected container mode, is made to the protected container storage, is made only from the protected container module to which the pages of the protected container storage are assigned, and is made using a permitted access method. In other embodiments, fewer, more, or different access control checks can optionally be used.In some embodiments, the protected container memory page(s) intended for secure MMIO may be allocated either exclusively or non-exclusively for use by the single given DPCM. In the case of exclusive allocation, which may provide even greater protection but is not a requirement, no other protected container modules, no other DPCMs, and no modules of the most privileged system-level software may access this one or more protected container memory pages intended for secure MMIO solely through the given allocated DPCM.

[0101] In block 1206 in Fig. In step 12, it can be determined whether a page type corresponding to the attempted access is configured for secure MMIO or not. If the page is not configured for secure MMIO, the procedure can switch to block 1207, where the attempted access can be performed based on the original access address for a page in protected container storage. If the page is configured for secure MMIO, the procedure can alternatively switch to block 1208. As in Fig. As shown in Figure 13, the MMU 1311 and / or the logic 1306, which is intended for controlling protected container access, can check a page type field 1152 to determine whether a page type of the page being accessed is configured for secure MMIO. If not, the MMU can allow the attempted access to the page. If so, in some embodiments, the MMU can be used to redirect the attempted access to a different physical address.

[0102] In block 1208 in Fig. 12, to which reference is made, the access address of the original attempted access (e.g., for block 1203) can be redirected to a corresponding MMIO address in some embodiments. As in Fig. As shown in Figure 13, the MMU 1311 can contain redirection logic to redirect the address of the attempted access, associated with the attempted access 1316, from the protected container page(s) 1303, configured for secure MMIO, to one or more pages 1315 in an MMIO area for the associated MMIO device. In some embodiments, the MMU may, for example, convert the original address of the attempted access into a corresponding MMIO address by replacing a page frame (e.g., the upper portion of the physical address) of the original address of the attempted access with a page frame for the MMIO address. For example, the page frame for the MMIO address may optionally be stored in the PCPMS or another metadata structure. This can be done, for example, using information from the MMIO area field 1199 of Figure 1311. Fig. 11. Initially, access is directed to the protected container storage page, which may allow existing checks to control access to protected container pages to be effectively used or otherwise utilized, after which access may be redirected to a location outside the protected container storage.

[0103] In block 1209 in Fig. In section 12, to which reference is made, the storage type of the redirected MMIO page(s) may optionally be configured as non-cacheable in some embodiments. In other embodiments, this may be optionally omitted.

[0104] In block 1210 in Fig. 12, to which reference is made, optionally a redirected access can be carried out at the corresponding MMIO address with an accompanying Secure Identifier. As in Fig. As shown in Figure 13, redirected access to page(s) 1315 in the MMIO area can be achieved via Secure Identifier Logic 1314. The Secure Identifier Logic can be used to add a Secure Identifier to the redirected access to the MMIO area. In one example, in some embodiments, the Secure Identifier Logic might apply a Secure Identifier Identity (SAI) applicable to a protected container to the access, indicating that the access is a secure access made by a protected container. However, it might not apply such a protected container SAI if the access is not made by a properly mapped DPCM.In some embodiments, the SAI applicable to a protected container or other secure identifier can confirm to the MMIO device that the attempted access by the processor was verified as having been made not only by the processor but also by a verified DPCM associated with the MMIO device. Alternatively, other secure identifiers can optionally be used. In some embodiments, the MMIO device may support a secure mode and, more generally, but optionally, an insecure mode. In secure mode, the MMIO device can be used to distinguish between SAIs applicable to a protected container and other secure identifiers, and can also be used to accept or recognize only MMIO accesses with such secure identifiers (e.g., the SAI applicable to a protected container).In some embodiments, the MMIO device may only serve to switch from safe mode to unsafe mode as a result of a check performed in safe mode (e.g., by specifying a SAI applicable to a protected container). In some embodiments, it may be possible to prevent access from being affected by a Basic Input / Output System (BIOS) misconfiguration of the MMIO address space.

[0105] Advantageously, the DPCM correctly assigned to the corresponding MMIO device can potentially access the MMIO space of the MMIO device without other, unassigned, protected container modules or software (e.g., even privileged system software) being able to access this MMIO space. This allows one or more correctly assigned DPCMs to exclusively and securely control or configure the MMIO device at the processor level. This can provide a control or configuration path for the MMIO device, or potentially a low-bandwidth data path for it. Various processes and procedures have been described. Some of these processes are described in a relatively simple form in the flowcharts; however, additional processes can be optionally added to and / or omitted.Furthermore, while the flowcharts show the processes according to the embodiments in a specific sequence, this sequence is merely exemplary. The processes can also be carried out in a different order in alternative embodiments, certain processes can be combined, certain processes can overlap, etc. Exemplary core architectures, processors and computer architectures

[0106] Processor cores can be implemented in different ways, for different purposes, and in different processors. For example, implementations of such cores might include: 1) a general-purpose in-order core intended for general-purpose computing; 2) a high-performance general-purpose out-of-order core intended for general-purpose computing; 3) a specialized core intended primarily for graphics and / or scientific (throughput) computing.The implementations of the different processors may include: 1) a CPU containing one or more universal in-order cores intended for general-purpose computing and / or one or more universal out-of-order cores intended for general-purpose computing; and 2) a coprocessor containing one or more specialized cores primarily intended for graphics and / or scientific (throughput) computing.Such different processors lead to different computer system architectures, which may include: 1) the coprocessor on a chip separate from the CPU; 2) the coprocessor on a separate die in the same package as a CPU; 3) the coprocessor on the same die as a CPU (such a coprocessor is sometimes referred to as special logic, such as integrated graphics logic and / or scientific (throughput) logic, or as special cores); and 4) a system-on-a-chip that may contain the same die as the CPU described (sometimes referred to as application core(s) or application processor(s)), the coprocessor described above, and additional functionality. Exemplary core architectures are described next, followed by descriptions of exemplary processors and computer architectures. Exemplary core architectures: In-order and out-of-order core block diagram

[0107] Fig. Figure 14A is a block diagram illustrating both an exemplary in-order pipeline and an exemplary register renaming, out-of-order allocation / execution pipeline according to embodiments of the invention. Fig. Figure 14B is a block diagram illustrating both an embodiment of an in-order architecture kernel and an exemplary register renaming, out-of-order allocation / execution architecture kernel for inclusion in a processor according to embodiments of the invention. The boxes with the solid lines in the Fig. Figures 14A-B illustrate the in-order pipeline and the in-order kernel, while the optional addition of the boxes with the dashed lines illustrates the register renaming and out-of-order allocation / execution pipelines and kernels. Since the in-order aspect is a subset of the out-of-order aspect, the out-of-order aspect is described.

[0108] In Fig. 14A contains a processor pipeline 1400, a fetch stage 1402, a length decode stage 1404, a decode stage 1406, an allocation stage 1408, a rename stage 1410, a scheduling (also known as dispatch or issue) stage 1412, a register read / memory read stage 1414, an execution stage 1416, a write-back / memory write stage 1418, an exception handling stage 1422, and a write-in stage 1424.

[0109] Fig. Figure 14B shows a processor core 1490 containing a front-end unit 1430 coupled to an execution engine unit 1450, and both are coupled to a memory unit 1470. The core 1490 could be a reduced instruction set (RISC) core, a complex instruction set (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. Another possibility is that the core 1490 could be a special-purpose core, such as a network or communications core, a compression engine, a coprocessor core, a general-purpose computing graphics processing unit (GPGPU) core, a graphics core, or the like.

[0110] The front-end unit 1430 contains a branch prediction unit 1432, which is coupled to an instruction cache unit 1434, which is coupled to an instruction translation lookaside buffer (TLB) 1436, which is coupled to an instruction fetch unit 1438, which is coupled to a decoder unit 1440. The decoder unit 1440 (or decoder) can decode instructions and generate as output one or more microoperations, one or more microcode entry points, one or more microinstructions, one or more other instructions, or one or more other control signals that are decoded from the original instructions or that otherwise reflect or are derived from the original instructions. The decoder unit 1440 can be implemented using various different mechanisms.Examples of suitable mechanisms include lookup tables, hardware implementations, programmable logic arrays (PLAs), microcode read-only storage (ROMs), etc. In one embodiment, the core 1490 contains a microcode ROM or other medium in which microcode for specific macro instructions is stored (e.g., in the decoding unit 1440 or elsewhere within the front-end unit 1430). The decoding unit 1440 is coupled to a renaming / allocator unit 1452 in the execution engine unit 1450.

[0111] The execution engine unit 1450 contains the renaming / allocator unit 1452, which is coupled to a reordering unit 1454 and a set of one or more scheduler units 1456. The scheduler unit(s) 1456 represent any number of different schedulers, which contain reservation stations, a central instruction window, etc. The scheduler unit(s) 1456 is / are coupled to the physical register storage unit(s) 1458. Each of the physical register storage units 1458 represents one or more physical register memories, different of which store one or more different data types, such as scalar integer, scalar floating-point, packed integer, packed floating-point, vector integer, vector floating-point, status (e.g., an instruction pointer, that is, the address of the next instruction to be executed), etc.In one embodiment, the physical register storage unit 1458 comprises a vector register unit, a write mask register unit, and a scalar register unit. These register units can provide architectural vector registers, vector mask registers, and general-purpose registers. The physical register storage unit(s) 1458 is / are overlapped by the reorder unit 1454 to illustrate the various ways in which register renaming and out-of-order execution can be implemented (e.g., using a reorder buffer(s) and a retirement register file(s); using a future buffer(s), a past buffer(s), and a retirement register file(s); using register mappings and a pool of registers; etc.).The reorder unit 1454 and the physical register storage unit(s) 1458 are coupled to the execution cluster(s) 1460. The execution cluster(s) 1460 contains a set of one or more execution units 1462 and a set of one or more memory access units 1464. The execution units 1462 can perform various operations (e.g., shifts, addition, subtraction, multiplication) on various types of data (e.g., scalar floating-point, packed integer, packed floating-point, vector integer, vector floating-point). While some embodiments may contain a number of execution units dedicated to specific functions or sets of functions, other embodiments may contain only one execution unit or multiple execution units, each performing all functions.The scheduler unit(s) 1456, the physical register storage unit(s) 1458 and the execution cluster(s) 1460 are shown as if they were present multiple times, because certain embodiments generate separate pipelines for certain types of data / operations (e.g., a pipeline for scalar integers, a pipeline for scalar floating-point / packed integers / packed floating-point / vector integers / vector floating-points and / or a memory access pipeline, each having its own scheduler units, physical register storage units and / or execution clusters - and in the case of a separate memory access pipeline, certain embodiments are implemented in which only the execution cluster of that pipeline has the memory access unit(s) 1464).It is also understood that when using separate pipelines, one or more of these pipelines may be out-of-order allocation / execution pipelines and the rest of them may be in-order pipelines.

[0112] The set of memory access units 1464 is coupled to the memory unit 1470, which contains a data TLB unit 1472, which is coupled to a data cache unit 1474, which is coupled to a level 2 (L2) cache unit 1476. In one embodiment, the memory access units 1464 can contain a load unit, an address storage unit, and a data storage unit, each coupled to the data TLB unit 1472 in the memory unit 1470. The instruction cache unit 1434 is further coupled to a level 2 (L2) cache unit 1476 in the memory unit 1470. The L2 cache unit 1476 is coupled to one or more cache levels and finally to main memory.

[0113] In one example, the exemplary register renaming, out-of-order allocation / execution core architecture can implement pipeline 1400 as follows: 1) The instruction fetch unit 1438 performs fetch and length decode stages 1402 and 1404; 2) the decode unit 1440 performs decode stage 1406; 3) the rename / allocator unit 1452 performs allocation stage 1408 and rename stage 1410; 4) the scheduler unit(s) 1456 perform scheduling stage 1412; 5) the physical register storage unit(s) 1458 and the storage unit 1470 perform register read / memory read stage 1414; The execution cluster 1460 performs execution stage 1416; 6) the storage unit 1470 and the physical register storage unit(s) 1458 perform write-back / read-memory stage 1418; 7) different units can be involved in exception handling stage 1422;and 8) the reordering unit 1454 and the physical register storage unit(s) 1458 perform the storage stage 1424.;

[0114] The Core 1490 can support one or more instruction sets (e.g., the x86 instruction set (with some extensions added in newer versions); the MIPS instruction set from MIPS Technologies of Sunnyvale, CA; the ARM instruction set (with optional additional extensions such as NEON) from ARM Holdings of Sunnyvale, CA), including the instruction (or instructions) described herein. In one embodiment, the Core 1490 includes logic to support an instruction set extension for packed data (e.g., AVX1, AVX2), enabling the operations used by many multimedia applications to be performed using packed data.

[0115] It is understood that the core can support multithreading (when two or more parallel sets of operations or threads are executed) and this can be done in a variety of ways, including split-time multithreading, concurrent multithreading (where a single physical core provides a logical core for each of the threads that the physical core executes in concurrent multithreading), or a combination thereof (e.g., split-time fetching and decoding followed by concurrent multithreading, as in Intel® Hyperthreading Technology).

[0116] Although register renaming is described in the context of out-of-order execution, it is understood that register renaming can also be used in an in-order architecture. While the illustrated embodiment of the processor also includes separate instruction and data cache units 1434 / 1474 and a shared L2 cache unit 1476, alternative embodiments may have only a single primary cache for both instructions and data, for example, a Level 1 (L1) primary cache, or multiple primary cache levels. In some embodiments, the system may include a combination of a primary cache and a secondary cache located outside the core and / or the processor. Alternatively, the entire cache may be located outside the core and / or the processor. Special exemplary in-order core architecture

[0117] The Fig. Figures 15A-B illustrate a block diagram of a more specific example in-order core architecture, the core of which would be one of several logic devices (including other cores of the same type and / or of different types) on a single chip. The logic devices communicate through a high-bandwidth interconnection network (e.g., a ring network) with some fixed functional logic, memory I / O interfaces, and other necessary I / O logic, depending on the application.

[0118] Fig. Figure 15A is a block diagram of a single processor core, including its connection to the interconnection network housed on a chip and its local subset of the Level 2 (L2) cache 1504, according to embodiments of the invention. In one embodiment, an instruction decoder 1500 supports the x86 instruction set with an instruction set extension for packed data. An L1 cache 1506 allows low-latency access to the cache memory in the scalar and vector units. Although in one embodiment (to simplify the structure) a scalar unit 1508 and a vector unit 1510 use separate register sets (the scalar registers 1512 and the vector registers 1514, respectively), and data transferred between them is written to memory and then read back from a Level 1 (L1) cache 1506, alternative embodiments of the invention can employ a different method (e.g.,a single register set is used or a communication path is established so that data can be transferred between the two register stores without being written and read back in).

[0119] The local subset of the L2 cache 1504 is a part of a global L2 cache, which is divided into separate local subsets, one for each processor core. Each processor core has a direct access path to its own local subset of the L2 cache 1504. Data read by a processor core is stored in its L2 cache subset 1504 and can be accessed quickly, in parallel with operations where other processor cores access their own local L2 cache subsets. Data written by a processor core is stored in its own L2 cache subset 1504 and, if necessary, removed from other subsets. The ring network ensures coherence for shared data. The ring network is bidirectional, allowing agents such as processor cores, L2 caches, and other logic components within the chip to communicate with each other. Each ring data path is 1012 bits wide in each direction.

[0120] Fig. 15B is an extended view of a portion of the processor core in Fig. 15A according to embodiments of the invention. Fig. 15B contains an L1 data cache 1506A, which is part of the L1 cache 1504, as well as further details regarding the vector unit 1510 and the vector registers 1514. Specifically, the vector unit 1510 is a 16-bit wide vector processing unit (VPU) (see 16-bit wide ALU 1528) that executes one or more integer, single-precision float, and double-precision float instructions. The VPU supports register input swizzling with a swizzle unit 1520, numerical conversion with numerical conversion units 1522A-B, and replication with a replication unit 1524 at the memory input. Write mask registers 1526 allow the resulting vector writes to be represented as predicates. Processor with integrated memory controller and integrated graphics

[0121] Fig. Figure 16 is a block diagram of a 1600 processor, which may have more than one core, an integrated memory controller, and integrated graphics, according to embodiments of the invention. The boxes with the solid lines in Fig. Figure 16 illustrates a processor 1600 with a single core 1602A, a system agent 1610, a set of one or more bus controller units 1616, while the optionally added boxes with the dashed lines illustrate an alternative processor 1600 with multiple cores 1602A-N, a set of one or more integrated memory controller units 1614 in the system agent unit 1610 and special logic 1608.

[0122] Thus, different implementations of the 1600 processor can include: 1) a CPU whose special logic 1608 is integrated graphics and / or scientific (throughput) logic (which may contain one or more cores) and whose cores 1602A-N are one or more general-purpose cores (e.g., universal in-order cores, universal out-of-order cores, or a combination of both); 2) a coprocessor whose cores 1602A-N are a large number of special-purpose cores primarily intended for graphics and / or scientific (throughput) computing; and 3) a coprocessor whose cores 1602A-N are a large number of universal in-order cores.Thus, the 1600 processor can be a general-purpose processor, a coprocessor, or a specialized processor, such as a network or communications processor, a compression engine, a graphics processor, a GPGPU (General Purpose Graphics Processing Unit), a high-throughput many-integrated-core (MIC) coprocessor (containing 30 or more cores), an embedded processor, or the like. The processor can be implemented on one or more chips. The 1600 processor can be part of one or more substrates and / or can be implemented on them using various process technologies such as BiCMOS, CMOS, or NMOS.

[0123] The memory hierarchy includes one or more cache levels within the cores, a set of one or more shared cache units (1606), and external memory (not shown) coupled to the set of integrated memory controller units (1614). The set of shared cache units (1606) may contain one or more mid-level caches, such as Level 2 (L2), Level 3 (L3), Level 4 (L4), or other cache levels, a last-level cache (LLC), and / or combinations thereof.

[0124] Although in one embodiment a ring-based interconnection unit 1612 connects the integrated graphics logic 1608, the set of shared cache units 1606, and the system agent unit 1610 / the integrated memory controller unit(s) 1614, any number of well-known techniques for interconnecting such units can be used in alternative embodiments. In one embodiment, coherence is maintained between one or more cache units 1606 and the cores 1602A-N.

[0125] In some embodiments, one or more of the 1602A-N cores are multithreaded. The 1610 system agent contains the components that coordinate and operate the 1602A-N cores. For example, the 1610 system agent unit may contain a power control unit (PCU) and a display unit. The PCU may be or contain logic and components necessary for controlling the power of the 1602A-N cores and the integrated 1608 graphics logic. The display unit is used to drive one or more externally connected displays.

[0126] The 1602A-N cores can be homogeneous or heterogeneous with respect to the architectural instruction set; that is, two or more of the 1602A-N cores can be capable of executing the same instruction set, while others may only be capable of executing a subset of that instruction set or a different instruction set. Exemplary computer architectures

[0127] The Fig. Figures 17-21 are block diagrams of exemplary computer architectures. Other system layouts and configurations known from the prior art for laptops, desktops, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, video game consoles, set-top boxes, microcontrollers, mobile phones, portable media players, handheld devices, and various other electronic devices are also suitable. In general, a wide variety of systems or electronic devices capable of accommodating a processor and / or other execution logic as disclosed herein are generally suitable.

[0128] In Fig. Figure 17, to which reference is now made, shows a block diagram of a system 1700 according to an embodiment of the present invention. The system 1700 can include one or more processors 1710, 1715 coupled to a controller hub 1720. In one embodiment, the controller hub 1720 includes a graphics memory controller hub (GMCH) 1790 and an input / output hub (IOH) 1750 (which may be located on separate chips); the GMCH 1790 includes a memory and graphics controller to which a memory 1740 and a coprocessor 1745 are coupled; The IOH 1750 connects input / output (I / O) devices 1760 to the GMCH 1790. Alternatively, the memory and / or graphics controllers are integrated within the processor (as described herein), the memory 1740 and the coprocessor 1745 are directly connected to the processor 1710, and the controller hub 1720 is on a single chip with the IOH 1750.

[0129] The optional additional 1715 processors are in Fig. 17 are represented by dashed lines. Each 1710, 1715 processor may contain one or more of the processor cores described herein and may be any version of the 1600 processor.

[0130] The memory 1740, for example, may be a Dynamic Random Access Memory (DRAM), a Phase Change Memory (PCM), or a combination of both. In at least one embodiment, the Controller Hub 1720 communicates with the processor(s) 1710, 1715 via a multidrop bus such as a frontside bus (FSB), a point-to-point interface such as QuickPath Interconnect (QPI), or a similar connection 1795.

[0131] In one embodiment, the coprocessor 1745 is a specialized processor such as a high-throughput MIC processor, a network or communications processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, or the like. In another embodiment, the controller hub 1720 may include an integrated graphics accelerator.

[0132] There can be a wide range of differences between the physical resources 1710 and 1715 with respect to a spectrum of performance metrics, including architectural, microarchitectural, thermal, power consumption characteristics, and the like.

[0133] In one embodiment, the processor 1710 executes instructions for controlling data processing operations of a general type. Coprocessor instructions may be embedded within these instructions. The processor 1710 recognizes that these coprocessor instructions are of a type to be executed by the connected coprocessor 1745. Accordingly, the processor 1710 outputs these coprocessor instructions (or control signals representing coprocessor instructions) to the coprocessor 1745 on a coprocessor bus or via another intermediate connection. The coprocessor(s) 1745 accepts and executes the received coprocessor instructions.

[0134] In Fig. Figure 18, to which reference is now made, shows a block diagram of a first, more specific exemplary system 1800 according to an embodiment of the present invention. As in Fig. As shown in Figure 18, the multiprocessor system 1800 is a point-to-point interconnect system and includes a first processor 1870 and a second processor 1880, which are coupled via a point-to-point interconnect 1850. Each of the processors 1870 and 1880 can be any version of the processor 1600. In one embodiment of the invention, the processors 1870 and 1880 are processors 1710 and 1715, respectively, while the coprocessor 1838 is a coprocessor 1745. In another embodiment, the processors 1870 and 1880 are a processor 1710 and a coprocessor 1745, respectively.

[0135] The processors 1870 and 1880 are shown, containing integrated memory controller (IMC) units 1872 and 1882, respectively. The 1870 processor also includes point-to-point (PP) interfaces 1876 and 1878 as part of its bus controller units; similarly, the 1880 processor includes PP interfaces 1886 and 1888. The 1870 and 1880 processors can exchange information via a point-to-point (PP) interface 1850 using PP interface circuits 1878 and 1888. As shown in Fig. As shown in Figure 18, the IMCs 1872 and 1882 couple the processors to respective memories, namely a memory 1832 and a memory 1834, which may be sections of a main memory locally connected to the respective processors.

[0136] The 1870 and 1880 processors can each exchange information with a chipset 1890 via individual PP interfaces 1852 and 1854, using point-to-point interface circuits 1876, 1894, 1886, and 1898. The 1890 chipset can optionally exchange information with the coprocessor 1838 via a high-performance interface 1839. In one embodiment, the coprocessor 1838 is a specialized processor such as a high-throughput MIC processor, a network or communications processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, or the like.

[0137] A shared cache (not shown) can be contained within or outside of both processors and yet be connected to the processors via a PP intermediary, so that if one processor enters a low-power mode, information from the local cache of one or both processors can be stored in the shared cache.

[0138] The chipset 1890 can be coupled to a first bus 1816 via an interface 1896. In one embodiment, the first bus 1816 may be a Peripheral Component Interconnect (PCI) bus, a bus such as a PCI Express bus, or another third-generation I / O interconnect bus; however, this does not limit the scope of protection of the invention.

[0139] As in Fig. As shown in Figure 18, various I / O devices 1814 can be coupled to the first bus 1816, along with a bus bridge 1818 that couples the first bus 1816 to a second bus 1820. In one embodiment, one or more additional processors 1815, such as coprocessors, high-throughput MIC processors, GPGPUs, accelerators (such as graphics accelerators or digital signal processing (DSP) units), field-programmable gate arrays, or any other processors, are coupled to the first bus 1816. In one embodiment, the second bus 1820 may be a low-pin-count (LPC) bus. In one embodiment, various devices may be coupled to a second bus 1820 and may include, for example, a keyboard and / or mouse 1822, communication devices 1827 and a data storage unit 1828 such as a disk drive or other mass storage device that may contain commands / code and data 1830.Furthermore, an audio I / O module 1824 can be connected to the second bus 1820. It should be noted that other architectures are also possible. For example, a system can use a different architecture instead of the point-to-point architecture. Fig. 18. Implement a multidrop bus or other similar architecture.

[0140] In Fig. Figure 19, to which reference is now made, shows a block diagram of a second, more specific exemplary system 1900 according to an embodiment of the present invention. Identical elements in the Fig. 18 and Fig. 19 are marked with the same reference symbols, and certain aspects of Fig. 18 were in Fig. 19 omitted to improve the clarity of other aspects of Fig. 19 not to make things more difficult.

[0141] Fig. Figure 19 illustrates that the 1870 and 1880 processors can contain integrated memory and an I / O control logic ("CL") 1872 or 1882, respectively. Thus, the CL 1872 and 1882 contain integrated memory controller units and I / O control logic. Fig. Figure 19 illustrates that not only are the 1832 and 1834 memory modules coupled to the 1872 and 1882 control logic modules, but also that the 1914 I / O devices are coupled to the 1872 and 1882 control logic modules. Older 1915 I / O devices are coupled to the 1890 chipset.

[0142] In Fig. Figure 20, to which reference is now made, shows a block diagram of a SoC 2000 according to an embodiment of the present invention. Elements similar to elements in Fig. Sixteen are labeled with the same reference symbol. Additionally, boxes with dashed lines are optional features in more complex SoCs. Fig. 20 is (are) an interconnection unit(s) 2002 coupled to the following: an application processor 2010 containing a set of one or more cores 192A-N and (a) shared cache unit(s) 1606; a system agent unit 1610; (a) bus controller unit(s) 1616; (a) integrated memory controller unit(s) 1614; a set of one or more coprocessors 2020 containing integrated graphics logic, an image processor, an audio processor, and a video processor; a static random access memory (SRAM) unit 2030; a direct memory access (DMA) unit 2032; and a display unit 2040 for coupling to one or more external displays. In one embodiment, the coprocessor(s) 2020 includes a special processor such as a network or communications processor, a compression engine, a GPGPU, a high-throughput MIC processor, an embedded processor, or the like.

[0143] The embodiments of the mechanisms disclosed herein can be implemented in hardware, software, firmware, or a combination of such implementation methods. The embodiments of the invention can be implemented as computer programs or program code for execution in programmable systems comprising at least one processor, a memory system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0144] A program code like the one in Fig. The illustrated code 1830 can be applied to input commands to perform the functions described herein and to generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, a processing system includes any system comprising a processor such as a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.

[0145] The program code can be implemented in a higher-level procedural or object-oriented programming language for communication with a processing system. If desired, the program code can also be implemented in assembly language or machine language. In principle, the mechanisms described herein are not limited to any specific programming language with regard to their scope of protection. In any case, the language can be compiled or interpreted.

[0146] One or more aspects of at least one embodiment can be implemented by representative instructions stored in a machine-readable medium. This medium represents logic, which may be structured differently, within the processor and, when read by a machine, triggers the machine to produce logic for carrying out the techniques described herein. Such representations, known as "IP cores," can be stored in a physical, machine-readable medium and delivered to various customers or production facilities to supply manufacturing machines that ultimately produce the logic or the processor.

[0147] Machine-readable storage media include, but are not limited to, non-transient physical arrangements of products manufactured or formed by a machine or device, including storage media such as hard disks, any other disk types including floppy disks, optical storage disks, compact disk read-only storage (CD-ROMs), rewritable compact disks (CD-RWs) and magneto-optical storage disks, semiconductor devices such as read-only memory (ROMs), working memory (RAMs) such as dynamic random access memory (DRAMs), static random access memory (SRAMs), erasable programmable read-only memory (EPROMs), flash memory, electrically erasable programmable read-only memory (EEPROMs), phase-change memory (PCMs), magnetic or optical memory cards, or any other type of media suitable for storing electronic instructions.

[0148] Accordingly, embodiments of the invention also include non-transient, physical, machine-readable media containing instructions or design data, such as the Hardware Description Language (HDL), which defines structures, circuits, devices, processors, and / or system features described herein. Such embodiments may also be referred to as program products. Emulation (including binary translation, code conversion, etc.)

[0149] In some cases, an instruction converter may be used to convert an instruction from a source instruction set to a target instruction set. The instruction converter can, for example, translate, transform, emulate, or otherwise convert an instruction into one or more other instructions to be processed by the kernel (e.g., using static binary translation, dynamic binary translation which includes dynamic compilation). The instruction converter can be implemented in software, hardware, firmware, or a combination thereof. The instruction converter can reside inside the processor, outside the processor, or partly inside and partly outside the processor.

[0150] Fig. Figure 21 is a block diagram with a comparative overview of the use of a software instruction converter for converting binary instructions in a source instruction set to binary instructions in a target instruction set according to embodiments of the invention. In the illustrated embodiment, the instruction converter is a software instruction converter, although the instruction converter can alternatively be implemented in software, firmware, hardware, or various combinations thereof. Fig. Figure 21 shows how a program in a higher-level programming language 2102 can be compiled using an x86 compiler 2104 to generate x86 binary code 2106 that can be executed natively by a processor with at least one x86 instruction set core 2116. The processor with at least one x86 instruction set core 2116 represents any processor capable of performing substantially the same functions as an Intel processor with at least one x86 instruction set core by (1) executing a substantial portion of the Intel x86 instruction set core's instruction set, or (2) executing or otherwise processing object code versions of applications or other software compatible with execution on an Intel processor with at least one x86 instruction set core to achieve substantially the same result as an Intel processor with at least one x86 instruction set core.The x86 compiler 2104 refers to a compiler that can be used to generate x86 binary code 2106 (e.g., object code), which can be executed with or without additional program connector processing on a processor with at least one x86 instruction set core 2116. Likewise, . Fig.21, how the program can be compiled in the higher-level programming language 2102 using an alternative instruction set compiler 2108 to generate an alternative instruction set binary code 2110 that can be executed natively by a processor without at least one x86 instruction set core 2114 (e.g., a processor with cores executing the MIPS instruction set from MIPS Technologies of Sunnyvale, CA, and / or the ARM instruction set from ARM Holdings of Sunnyvale, CA). The instruction converter 2112 is used to convert the x86 binary code 2106 into code that can be executed natively by the processor without an x86 instruction set core 2114.This converted code is likely not the same as the alternative instruction set binary code 2110, because creating an instruction converter capable of doing so is difficult; however, the converted code is sufficient for general operation and is composed of instructions from the alternative instruction set. Thus, the instruction converter 2112 represents software, firmware, hardware, or a combination thereof that, through emulation, simulation, or any other process, allows a processor or other electronic device without an x86 instruction set processor or core to execute the x86 binary code 2106.

[0151] The components, features, and details described for any of the devices may optionally also apply to any of the methods that can be performed in embodiments by and / or with devices of this type. Any of the processors described herein may be included in any of the computer systems disclosed herein. In some embodiments, the computer system may include a dynamic random access memory (DRAM). Alternatively, the computer system may include volatile memory that does not require refreshing or flash memory. The instructions disclosed herein may be executed with any of the processors shown herein, which may have any of the microarchitectures shown herein, in any of the systems shown herein.

[0152] The terms "coupled" and / or "connected," along with their derivatives, may have been used in the description and claims. These terms are not intended to be synonymous. Rather, "connected" may be used in the embodiments to indicate that two or more elements are in direct physical and / or electrical contact with each other. "Coupled" may mean that two or more elements are in direct physical and / or electrical contact with each other. However, "coupled" may also mean that two or more elements are not in direct contact with each other but nevertheless work together or interact. For example, an execution unit may be coupled to a register and / or a decoding unit via one or more intermediate components. Arrows are used in the figures to show connections and couplings.

[0153] The terms "logic," "unit," "module," or "component" may have been used in the description and / or claims. Each of these terms may refer to hardware, firmware, or various combinations thereof. In exemplary embodiments, each of these terms may refer to integrated circuits, application-specific integrated circuits, analog circuits, digital circuits, programmed logic circuits, instruction storage devices, and the like, as well as various combinations thereof. In some embodiments, these may include at least some hardware (e.g., transistors, gates, other circuit elements, etc.).

[0154] The conjunction pair "and / or" may have been used. As used here, the conjunction pair "and / or" denotes either one or the other or both (for example, A and / or B denotes A or B or both A and B).

[0155] The above description presents specific details to facilitate a thorough understanding of the embodiments. However, other embodiments can also be practically implemented without some of these specific details. The scope of the invention is not defined by the specific examples given above, but only by the claims below. In other cases, well-known circuits, structures, devices, and processes are shown in block diagram form and / or not in detail, so as not to impede the clarity of the description. Where deemed appropriate, reference numerals or sections at the end of reference numerals in the figures have been repeated to indicate corresponding or analogous elements, which may optionally have similar or the same properties, unless otherwise stated or unless something else is clearly apparent.

[0156] Certain operations can be performed by hardware components or may be implemented as machine-executable or circuit-executable instructions that can be used to trigger and / or cause a machine, circuit, or hardware component (e.g., a processor, part of a processor, a circuit, etc.) to be programmed with the instructions to perform the operations. Optionally, the operations may also be performed by a combination of hardware and software. A processor, machine, circuit, or hardware component may contain a special or specific circuit or other logic (e.g., hardware that may be combined with firmware and / or software) that serves to execute and / or process the instruction and store a result in response to the instruction.

[0157] Some embodiments include a product (e.g., a computer program product) that contains a machine-readable medium. The medium may include a mechanism that provides, for example, stores, information in a form that can be read by the machine. The machine-readable medium may provide an instruction or sequence of instructions which, when and / or as soon as they are executed by a machine, serve to trigger or cause the machine to perform operations, procedures, or techniques disclosed herein, the instruction or sequence of instructions also being stored in the machine-readable medium.

[0158] In some embodiments, the machine-readable medium may include a non-transient, machine-readable storage medium. The non-transient, machine-readable storage medium may include: a floppy disk, an optical storage medium, an optical storage disk, an optical data storage device, a CD-ROM, a magnetic disk, a magneto-optical storage disk, a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), a working memory (RAM), a static RAM (SRAM), a dynamic RAM (DRAM), a flash memory, a phase-change memory, a phase-change data storage material, a non-volatile memory, a non-volatile data storage device, a non-transient memory, a non-transient data storage device, or the like.The non-transient, machine-readable storage medium does not consist of a signal with a short propagation time. In some embodiments, the storage medium may include a physical medium containing a solid.

[0159] Examples of suitable machines include a general-purpose processor, a specialized processor, a digital logic circuit, an integrated circuit, or the like. Further examples of suitable machines include a computer system or other electronic devices containing a processor, a digital logic circuit, or an integrated circuit. Examples of such computer systems or electronic devices include desktop computers, laptop computers, notebook computers, tablet computers, netbooks, smartphones, mobile phones, servers, network devices (e.g., routers and switches), mobile internet devices (MIDs), media players, smart TVs, nettops, set-top boxes, and video game controllers.

[0160] Whenever this patent specification refers, for example, to "an embodiment," "one or more embodiments," or "some embodiments," it indicates that a particular feature may be included in the practical implementation of the invention, but is not necessarily required to be. Similarly, the description sometimes groups various features into one embodiment, figure, or description thereof to streamline the disclosure and facilitate understanding of different aspects of the invention. However, it should not be inferred from the present method as disclosed that the invention requires more features than are expressly defined in each claim. Rather, as the following claims reflect, aspects of the invention may also be based on fewer than all the features of a single disclosed embodiment.Therefore, the claims following the detailed description are hereby expressly included in this detailed description, with each claim representing a separate embodiment of the invention on its own. EXAMPLES OF EXECUTION

[0161] The following examples relate to further embodiments. Details in the examples can be used at any point in one or more embodiments.

[0162] Example 1 is an integrated circuit that includes logic for controlling protected container access to perform a set of access control checks and determine whether a Device Protected Container Module (DPCM) and an input and / or output device (I / O device) are allowed to communicate securely via Direct Memory Access (DMA) or Memory Mapped Input / Output (MMIO). This determination is made after it has been established that at least the DPCM and the I / O device are associated with each other, an access address associated with the communication resolves to protected container memory, and a page of the protected container memory into which the access address resolves allows DMA or MMIO.

[0163] Example 2 contains the integrated circuit from Example 1, in which the DMA is permitted.

[0164] Example 3 includes the integrated circuit from Example 2, in which the logic intended to control protected container access is implemented to determine that the I / O device is allowed to access the protected container memory side.

[0165] Example 4 includes the integrated circuit from Example 2, in which the access address is configured to originate from the I / O device and is accompanied by a Security Attribute of Initiator (SAI) corresponding to the I / O device. Furthermore, the logic designed to control protected container access is configured to determine that the DPCM and the I / O device are mapped to each other. This is achieved by using the I / O device's SAI to obtain a DPCM identifier associated with the I / O device's SAI in a device mapping table and determining that the DPCM identifier obtained from the table corresponds to the DPCM.

[0166] Example 5 includes the integrated circuit according to Example 2, in which the logic provided for controlling protected container access is configured to access a valid physical address, which is configured to have been previously stored in a protected container page metadata structure, and is configured to determine that the DPCM and the I / O device are allowed to communicate securely, after it has been determined that the access address is compatible with the valid physical address.

[0167] Example 6 includes the integrated circuit according to Example 5, which further includes a decoding unit for decoding an instruction and an execution unit coupled to the decoding unit, wherein the execution unit is configured to store the permissible physical address in the metadata structure for protected container pages in response to the instruction.

[0168] Example 7 includes the integrated circuit from Example 2, in which the logic intended to control protected container access is configured to determine that the DPCM and the I / O device are allowed to communicate securely, after it has been determined that the page is of a type specifically designed to allow secure DMA.

[0169] Example 8 contains the integrated circuit from Example 2, in which the logic intended to control protected container access includes an I / O memory management unit (MMU).

[0170] Example 9 contains the integrated circuit from Example 1, in which the MMIO is permitted.

[0171] Example 10 includes the integrated circuit according to Example 9, which further includes a Memory Management Unit (MMU) for converting an address resolved into the protected container memory page into an MMIO address for the I / O device.

[0172] Example 11 contains the integrated circuit from Example 9, in which the logic intended for controlling protected container access is configured to provide a security identifier that accompanies access from the DPCM to the I / O device. Furthermore, the security identifier is configured to confirm to the I / O device that the access originates from a DPCM associated with the I / O device.

[0173] Example 12 contains the integrated circuit according to Example 9, in which the logic intended to control protected container access is configured to determine that the DPCM and the I / O device are allowed to communicate securely, after it has been determined that the page is of a type specifically designed to allow secure MMIO.

[0174] Example 13 contains the integrated circuit from Example 9, in which the logic intended to control protected container access includes a Memory Management Unit (MMU).

[0175] Example 14 contains the integrated circuit according to one of Examples 1 to 13, in which the logic intended to control protected container access is implemented to determine that the DPCM and the I / O device are allowed to communicate securely after it has been determined that an access type is compatible with one or more permitted access types for the page, which are to be stored in a protected container page metadata structure.

[0176] Example 15 contains the integrated circuit according to one of Examples 1 to 13, in which the logic intended to control protected container access is configured to determine that other protected container modules are not allowed to access the protected container memory side and privileged system software modules are not allowed to access the protected container memory side.

[0177] Example 16 is a method in an integrated circuit that includes determining that a Device Protected Container Module (DPCM) and an input and / or output device (I / O device) are associated with each other. The method also includes determining that an access address associated with an attempted access by the DPCM or the I / O device is resolved to a protected container memory. The method also includes determining that a page of the protected container memory, to which the access address is resolved, allows DMA or MMIO. The method also includes determining that the DPCM and the I / O device can communicate securely with each other via the page of the protected container memory.

[0178] Example 17 contains the procedure according to Example 16, wherein the determining includes determining that it is determined that it is permitted that the DPCM and the I / O device perform a secure DMA, and further includes allowing that the I / O device to access data in the protected container storage side.

[0179] Example 18 contains the procedure according to Example 16, in which determining includes determining that the DPCM and the I / O device are permitted to perform a safe MMIP.

[0180] Example 19 is a computer system that includes an interconnect and a processor coupled to the interconnect. The processor is configured to perform a set of access control checks and determine that a Device Protected Container Module (DPCM) and an input and / or output (I / O) device are allowed to communicate securely via Direct Memory Access (DMA) or Memory Mapped Input / Output (MMIO). This determination is made after it has been established that at least the DPCM and the I / O device are associated with each other, an access address associated with the communication resolves to protected container memory, and a page of protected container memory into which the access address resolves permits DMA or MMIO. The computer system also includes a Dynamic Random Access Memory (DRAM) coupled to the interconnect.The DPCM can optionally be stored in the DRAM, containing device driver commands for communicating with the I / O device at a user privilege level.

[0181] Example 20 contains the computer system according to Example 19, in which the DMA is permitted.

[0182] Example 21 is a product that includes a non-transient, machine-readable storage medium. The non-transient, machine-readable storage medium contains instructions designed to cause a machine to perform operations that include: requesting a protected container module in protected container memory to map an input and / or output device (I / O device) to the protected container module; accessing a page in the protected container memory that allows either direct memory access (DMA) or memory-mapped input / output (MMIO); and performing the DMA or MMIO with the I / O device via the page in the protected container memory.

[0183] Example 22 contains the product according to Example 21, in which the instructions which, when executed, cause the machine to perform the DMA or the MMIO with the I / O device include instructions which, when executed, cause the machine to perform the DMA with the I / O device.

[0184] Example 23 contains the product according to one of Examples 21 to 22, in which the instructions include a single instruction designed such that, when executed by the machine, it triggers the machine to configure a page to be of a type specifically intended for safe DMA.

[0185] Example 24 contains the product according to Example 21, in which the instructions which, when executed, cause the machine to perform the DMA or the MMIO with the I / O device include instructions which, when executed, cause the machine to perform the MMIO with the I / O device.

[0186] Example 25 contains the product according to one of Examples 21 and 24, in which the instructions include a single instruction designed such that, when executed by the machine, it triggers the machine to configure a page to be of a type specifically intended for safe MMIO.

[0187] Example 26 includes the processor of any one of Examples 1 through 13, further comprising an optional branch prediction unit for predicting branches and an optional instruction prefetch unit coupled to the branch prediction unit, the instruction prefetch unit being configured for prefetching instructions. The processor may also optionally include an optional Level 1 (L1) instruction cache coupled to the instruction prefetch unit for storing instructions, an optional L1 data cache for storing data, and an optional Level 2 (L2) cache for storing both data and instructions. The processor may also optionally include an instruction retrieval unit coupled to the decode unit, the L1 instruction cache, and the L2 cache.The processor may optionally also include a register renaming unit for renaming registers, an optional scheduler for scheduling one or more operations for execution, and an optional storage unit for storing execution results.

[0188] Example 27 is a processor or other device designed or used to perform the method according to any of Examples 16 to 18.

[0189] Example 28 is a processor or other device containing the means to carry out the method according to any one of Examples 16 to 18.

[0190] Example 29 is a processor comprising any combination of modules and / or units and / or logics and / or circuits and / or means for carrying out the procedure according to any of Examples 16 to 18.

[0191] Example 30 is a product containing an optionally non-transient, machine-readable medium in which an instruction is optionally stored or which optionally provides an instruction which, when and / or when executed by a processor, computer system, electronic device or other machine, is intended to cause the machine to perform the procedure according to any one of Examples 16 to 18.

[0192] Example 31 is a processor or other device that is substantially designed as described herein.

[0193] Example 32 is a processor or other device designed to perform any procedure substantially as described herein.

Claims

[1] Integrated circuit comprising: logic for controlling protected container access to perform a set of access control checks and determine that a Device Protected Container Module (DPCM) and an input and / or output device (I / O device) are allowed to communicate securely via direct memory access (DMA) or memory mapped input / output (MMIO) after determining that at least: the DPCM and the I / O device are associated with each other; an access address associated with the communication is resolved into a protected container memory; and a page of the protected container memory into which the access address is resolved allows DMA or MMIO. [2] The integrated circuit of claim 1, wherein the DMA is permitted. [3] The integrated circuit of claim 2, wherein the logic provided for controlling protected container accesses is configured to determine that the I / O device is allowed to access the protected container memory page. [4] The integrated circuit of claim 2, wherein the access address is configured to originate from the I / O device and is accompanied by a Security Attributes of Initiator (SAI) corresponding to the I / O device, and wherein the logic provided for controlling protected container accesses is configured to determine that the DPCM and the I / O device are associated with each other by using the SAI of the I / O device to obtain a DPCM identifier associated with the SAI of the I / O device in a device association table and to determine that the DPCM identifier obtained from the table corresponds to the DPCM. [5] The integrated circuit of claim 2, wherein the logic provided for controlling protected container accesses is configured to access a legal physical address configured to be previously stored in a protected container page metadata structure, and is configured to determine that the DPCM and the I / O device are allowed to communicate securely after determining that the access address is compatible with the legal physical address. [6] The integrated circuit of claim 2, wherein the logic provided for controlling protected container accesses is configured to determine that the DPCM and the I / O device are allowed to communicate securely after determining that the page is of a type specifically intended to allow secure DMA. [7] The integrated circuit of claim 1, wherein the MMIO is permitted. [8] The integrated circuit of claim 7, further comprising a memory management unit (MMU) for converting an address resolved into the page of protected container memory into an MMIO address for the I / O device. [9] The integrated circuit of claim 7, wherein the logic provided for controlling protected container access is configured to provide a security identifier to accompany access from the DPCM to the I / O device, and wherein the security identifier is configured to confirm to the I / O device that the access is from a DPCM associated with the I / O device. [10] The integrated circuit of claim 7, wherein the logic provided for controlling protected container accesses is configured to determine that the DPCM and the I / O device are allowed to communicate securely after determining that the page is of a type specifically intended to allow secure MMIO. [11] The integrated circuit of claim 7, wherein the logic provided for controlling protected container accesses comprises a memory management unit (MMU). [12] The integrated circuit of any one of claims 1 to 11, wherein the logic provided for controlling protected container accesses is configured to determine that the DPCM and the I / O device are allowed to communicate securely after determining that an access type is compatible with one or more permitted access types for the page to be stored in a protected container page metadata structure. [13] Integrated circuit according to one of claims 1 to 11, wherein the logic provided for controlling protected container accesses is designed to determine that it is not permitted: that other protected container modules access the protected container storage page; and that privileged system software modules access the protected container storage page. [14] A method in an integrated circuit comprising: Determining that a Device Protected Container Module (DPCM) and an input and / or output device (I / O device) are associated with each other; Determining that an access address associated with an attempted access by the DPCM or the I / O device resolves to a protected container memory; and Determining that a page of the protected container memory to which the access address is resolved allows direct memory access (DMA) or memory mapped input / output (MMIO); and Determine that the DPCM and the I / O device are allowed to communicate securely with each other through the protected container storage side. [15] The method of claim 14, wherein determining comprises determining to allow the DPCM and the I / O device to perform secure DMA, and further comprising allowing the I / O device to access data in the protected container memory page. [16] The method of claim 14, wherein determining comprises determining to allow the DPCM and the I / O device to perform a secure MMIO. [17] Computer system comprising: an interconnection; a processor coupled to the interconnect, the processor configured to perform a set of access control checks and determine that a Device Protected Container Module (DPCM) and an input and / or output device (I / O device) are allowed to communicate securely via direct memory access (DMA) or memory mapped input / output (MMIO) after determining that at least: the DPCM and the I / O device are associated with each other; an access address associated with the communication is resolved into a protected container memory; and a page of protected container memory to which the access address is resolved allows DMA or MMIO; and a dynamic random access memory (DRAM) coupled to the interconnect, wherein the DRAM stores a DPCM, the DPCM containing device driver instructions for communicating with the I / O device at a user privilege level. [18] The computer system of claim 17, wherein the DMA or the MMIO is permitted. [19] Apparatus comprising means for carrying out the method according to any one of claims 14 to 16. [20] A product comprising a machine-readable medium in which an instruction is stored which, when executed by a machine, serves to cause the machine to carry out the method according to any one of claims 14 to 16.

Images