Patent Application
20050283602
One or more embodiments of the invention relate generally to the field of protected execution. More particularly, one or more of the embodiments of the invention relates to a method and apparatus for execution of graphics application.
Today's personal computer (PC) is typically linked to the Internet or Intranet and is widely used for creation, storage, editing and sharing of personal, corporate/government information. This enables the PC to play a critical role in a PC user's ability to conduct business, collaborate, access confidential data and conduct electronic transactions with third parties. A key reason for the widespread use of current PCs is the open nature of PC platforms. The architecture's interfaces are well-documented and understood, allowing for a variety of powerful software and hardware capabilities that deliver value to corporations and end users.
The proliferation of the Internet has led to the creation of a new form of commerce, generally referred to as Internet or electronic commerce (E-commerce). E-commerce has led to the availability of media applications, playback of motion pictures, music and other like entertainment, which may be downloaded to a PC for one-time use or for use for a predetermined period of time. Such media applications may send display information to a graphics frame buffer, which is read by a display engine. The display engine combines a converted set of source images or surfaces within the frame buffer and delivers the information to an output interface connected eventually to a display device. Such media applications are referred to herein as “graphics applications”.
Conventionally, graphics applications may require a rendering engine to draw pixels to be displayed into the frame buffer, which is read out by the display engine and routed to a display. Conventionally, a render engine and display engine may be implemented within a graphics adapter or a graphics controller. In operation, such graphics applications may request allocation of a portion of main memory for the graphic adapter's use. Generally, such graphics applications issue a call to the operating system (OS), which manages main memory.
As an example, a graphics driver may request a 16 megabyte (MB) block of main memory. This presents a problem for the OS, which may manage main memory in blocks of 4 kilobytes (KB), referred to as “pages”. Accordingly, rather than allocate a continuous segment of main memory, in response to a request for a large block of memory, the OS locates a required number of memory pages that are not currently in use from, for example, a free memory pool (e.g., a request for 16 MB of memory requires 4096 pages). This memory management technique of simulating a large address space with a small amount of physical memory is generally referred to as “page demanded virtual memory”.
In response to the request, the OS returns a 32-bit linear memory start address above the top of main memory to the graphics application and sets up a series of page table entries that translate accesses within the example 16 MB linear address range (“virtual memory”) to the appropriate pages of main memory. Accordingly, whenever graphics application, while executing on the processor, attempts to access the assigned virtual memory, the processor paging mechanism automatically performs the required address translation from linear to graphics address. Software builds a translation table in memory for the graphics address to physical address translation and informs the graphics adapter of the base address of the translation table in memory. For example, for accelerated graphics port (AGP) adapters, a graphics address reallocation table (GART) is provided.
Unfortunately, the GART shared among the graphics application is accessible by a rogue agent and may be used to read physical memory pages used by a media application to duplicate media content, such as a motion picture. Hence, without some mechanism for protecting the content provided by such media applications from access by rogue agents, E-commerce involving such media applications may be prohibitive to the media providers. As a result, media or content providers may be reluctant to create high quality media or content providing applications since such content may be susceptible to rogue agents.
The various embodiments of the present invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which:
In the following description, numerous specific details such as logic implementations, sizes and names of signals and buses, types and interrelationships of system components, and logic partitioning/integration choices are set forth to provide a more thorough understanding. It will be appreciated, however, by one skilled in the art that the invention may be practiced without such specific details. In other instances, control structures and gate level circuits have not been shown in detail in order not to obscure the invention. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate logic circuits without undue experimentation.
In the following description, certain terminology is used to describe features of the invention. For example, the term “logic” is representative of hardware and/or software configured to perform one or more functions. For instance, examples of “hardware” include, but are not limited or restricted to, an integrated circuit, a finite state machine or even combinatorial logical. The integrated circuit may take the form of a processor such as a microprocessor, application specific integrated circuit, a digital signal processor, a micro-controller, or the like.
An example of “software” includes executable code in the form of an application, an applet, a routine or even a series of instructions. In one embodiment, an article of manufacture may include a machine or computer-readable medium having software stored thereon, which may be used to program a computer (or other electronic devices) to perform a process according to one embodiment. The computer or machine readable medium includes but is not limited to: a programmable electronic circuit, a semiconductor memory device inclusive of volatile memory (e.g., random access memory, etc.) and/or non-volatile memory (e.g., any type of read-only memory “ROM”, flash memory), a floppy diskette, an optical disk (e.g., compact disk or digital video disk “DVD”), a hard drive disk, tape, or the like.
System
Representatively, chipset 110 may include integrated graphics memory controller hub (GMCH) 200. In an alternative embodiment, a graphics controller is separate from a memory controller and may be implemented within graphics block 160, such that graphics block 160 is, in one embodiment, a graphics chipset coupled to MCH 200. Representatively, GMCH 200 is coupled to main memory 170. In one embodiment, main memory 170 may include, but is not limited to, random access memory (RAM), dynamic RAM (DRAM), static RAM (SRAM), synchronous DRAM (SDRAM), double data rate (DDR) SDRAM (DDR-SDRAM), Rambus DRAM (RDRAM) or any device capable of supporting high-speed buffering of data.
As further illustrated, chipset 110 includes an input/output (I/O) controller hub (ICH) 112. Representatively, ICH 112 may include a universal serial bus (USB) link or interconnect 140 to couple one or more USB slots 142 to ICH 112. In addition, a peripheral component interconnect (PCI) bus 130 may couple one or more PCI slots 132 to ICH 112. Likewise, a serial advance technology attachment (SATA)120 may couple hard disk drive devices (HDD) 122 to ICH 112. Likewise, ICH 112 may include PCI-Express links 150 (150-1, . . . 150-N) to couple add-in cards 152 (152-1, . . . , 152-N) to ICH 112. In one embodiment, system BIOS 106 initializes computer system 100.
As illustrated in
In other words, the use of a single GTT prohibits protected execution of trusted graphics applications. As described herein, protected execution provides applications with the ability to run in an isolated, protected execution environment. Hence, unauthorized software on the platform is unable to observe or compromise information being operated on within a protected execution environment, such as, for example, illustrated with reference to
As described herein, a trusted application, such as a trusted graphics application, refers to a specially protected (trusted) software module that may be used, for example, to perform specific sensitive activities, possibly in the presence of hostile software. Accordingly, in one embodiment, a trusted application, or trusted software, may refer to tamper-resistant software or an application which has been authenticated and attested by a trusted portion of the operation system (trusted OS). In one embodiment, a secure virtual machine monitor (SVMM) authenticates and attests that a graphics application is a trusted graphics application when launch of such an application is detected.
Accordingly, in one embodiment, GMCH 200 is configured to provide a secure protected execution environment for trusted graphics applications. In one embodiment, GMCH 200 provides address space isolation of the address space assigned to trusted graphics application so that a graphics application cannot generate an access into a trusted graphics application address space. In one embodiment, untrusted graphics applications use GTT 340 and trusted applications use trusted GTT 360. In one embodiment, trusted applications store their data in protected pages, for example, as illustrated with reference to
In one embodiment, system BIOS 106 allocates a 512 KB range above top of the memory 220 for the registers and writes the location to the TGRBAR register. Subsequently, system BIOS 106 steals another 1 MB of memory below the top of memory 222 and writes the location to trusted graphics graphics translation table (TGGTT) register. Trusted GTT 360 starts at offset zero and is 256 KB in size. In one embodiment, trusted GTT 360 handles translation of access into graphics aperture 230 to trusted physical addresses to further ensure protected execution of such trusted graphics applications. In one embodiment, memory pages that are assigned to trusted graphics applications, referred to herein as “protected pages”, are protected from non-CPU access.
As described herein, non-CPU access refers to direct memory access (DMA) by devices. In other words, rather than request that CPU 102 perform a memory access to provide requested data, the device directly accesses memory 170 via GMCH 200 (see
In one embodiment, trusted GTT 360 is maintained by the certified and secure, trusted OS. In one embodiment, each trusted GTT assigned to a respective trusted graphics application is stored within protected storage by GMCH 200. Accordingly, in one embodiment, after allocating a protected page, the trusted OS is responsible for updating the no-DMA table 212 to block DMA access to the assigned protected page. In one embodiment, untrusted applications share GTT 340. Hence, untrusted applications are not provided with address space isolation. As a result, sharing of GTT 340 between untrusted graphics applications enables one trusted graphics application to access another graphics application's address space, thus prohibiting protected execution.
Accordingly, in one embodiment, GMCH 200 is configured to assign each trusted graphics application its own unique, trusted GTT. In one embodiment, the trusted OS is responsible for creating each trusted GTT and ensuring that each trusted GTT does not have any pages that overlap with any other application's trusted GTT. Hence, graphics applications are prohibited from generating an access that falls outside their assigned physical address space. In one embodiment, GTT allocation and edits are managed by the trusted OS to ensure that the GTT address space isolation property is not violated. In one embodiment, before an application starts executing, the trusted OS loads the appropriate GTT into GMCH 200, for example as shown in
As illustrated in
Accordingly, as illustrated in
In one embodiment, a virtual address space of, for example, 128 MB is assigned to each application. Representatively, driver 190 generates all surface addresses in this virtual address space to form a command buffer. Accordingly, as illustrated with reference to
In one embodiment, driver 190 is responsible for generating command buffer 260. As illustrated in
In one embodiment, software uses the tail offset 256 to inform an instruction parser (IP) of the presence of valid instructions that require execution. Representatively, head offset 250 is incremented by the IP as those instructions are parsed and executed. Accordingly, as the head offset is incremented during execution of each of the instructions contained within command buffer, head offset 254 will eventually match tail offset 256 once execution of instructions 262 is complete. In one embodiment, command buffer 260 is terminated by inserting a pipeline flush command and a store double word (dword) command.
Accordingly, in one embodiment, prior to activating a new command buffer 260-1 and inserting GTT 360-1 associated with command buffer 260-1, trusted OS 190 waits for the store command of previously executing command buffer 260-2 to take affect. In one embodiment, the trusted OS then verifies that previous command buffer 260-2 has completed execution by reading the command buffer head offset 254 and tail offset 256 to verify that the offsets match. Accordingly, in one embodiment, when both the store command and head and tail equality have been verified, the trusted OS places the GTT 360-1 within ring-zero execution environment 280 and then programs command buffer registers (see Table 2) to activate the new command buffer. Procedural methods for implementing one or more embodiments are now described.
Operation
In other words, in one embodiment, the trusted OS is responsible for creating each unique GTT assigned to an application and ensuring that the GTT does not have any pages that overlap with any other protected pages assigned to any other application's GTT. At process block 430, a translation table is generated to map the virtual address space assigned to the trusted application to a physical address space within the protected pages assigned to the trusted application. At process block 440, prior to execution of the trusted application, the translation table or trusted GTT assigned to the trusted application is loaded within a secure (protected) execution environment.
For example, as illustrated in
In one embodiment, the command buffer is written within the one or more protected pages assigned to the trusted application. At process block 560, during execution of the command buffer, virtual addresses referenced by command buffer instructions are translated into physical addresses according to the translation table assigned to the trusted application. In one embodiment, the command buffer is used to permit video display software control of the parameters provided to motion picture expert group (MPEG) acceleration commands or other like video acceleration commands.
Hence, in one embodiment, in order to enable secure behavior, the trusted OS is responsible for swapping out the previous application's GTT only after the previously executing command buffer has finished execution. Otherwise, unsynchronized swapping will cause an application to use another application's GTT, thus gaining access to another application's memory space to prohibit the protected execution of trusted graphics applications. Accordingly, at process block 545, the trusted OS delays installation of the translation table until the prior command buffer has completed execution.
In one embodiment, command buffer completion indication is obtained by waiting for a store command to take affect to indicate command buffer completion. However, a rogue application may try to fool the trusted OS into swapping the GTT earlier by issuing an early store command into the ring-zero execution environment. In one embodiment, this situation is avoided by requiring that the trusted OS ensure that the complete command buffer is executed by verifying that the command buffer head and tail coincide and the store command has taken effect prior to inserting the new GTT. In one embodiment, head and tail equality can be verified by either reading a command buffer register (see Table 2) or issuing a report head instruction in the ring buffer before the final store command.
Accordingly, in one embodiment, each command buffer is terminated by a pipeline flush and store command. Hence, in one embodiment, the trusted OS ends a new command buffer with a flush (optionally report head) and store command. Accordingly, prior to activating a new command buffer, the trusted OS waits for the store command of the currently executing command buffer to take effect. Subsequently, the trusted OS verifies current completion of the command buffer by reading the command buffer head and tail register or examining the report head contents (see Table 2). When both store command and head tail equality have been verified, the trusted OS places a new GTT within the execution ring and then programs the command buffer register to activate the new buffer (see
Accordingly, by assigning each trusted application its own unique trusted GTT, each application is prohibited from generating an access into another trusted application's graphics address space. Accordingly, by using its own trusted GTT, a trusted graphics application can maintain data integrity. Accordingly, address space isolation is maintained by using or performing the assignment of a unique GTT to each trusted application in order to provide address space isolation for graphics adapters. Accordingly, by assigning a unique GTT to each application, rogue drivers are prohibited from generating access to an address space that is outside their assigned address space, thereby providing a secure execution environment for trusted graphics applications.
Additionally, a circuit level model with logic and/or transistor gates may be produced at some stages of the design process. The model may be similarly simulated some times by dedicated hardware simulators that form the model using programmable logic. This type of simulation taken a degree further may be an emulation technique. In any case, reconfigurable hardware is another embodiment that may involve a machine readable medium storing a model employing the disclosed techniques.
Furthermore, most designs at some stage reach a level of data representing the physical placements of various devices in the hardware model. In the case where conventional semiconductor fabrication techniques are used, the data representing the hardware model may be data specifying the presence or absence of various features on different mask layers or masks used to produce the integrated circuit. Again, this data representing the integrated circuit embodies the techniques disclosed in that the circuitry logic and the data can be simulated or fabricated to perform these techniques.
In any representation of the design, the data may be stored in any form of a machine readable medium. An optical or electrical wave 660 modulated or otherwise generated to transport such information, a memory 650 or a magnetic or optical storage 640, such as a disk, may be the machine readable medium. Any of these mediums may carry the design information. The term “carry” (e.g., a machine readable medium carrying information) thus covers information stored on a storage device or information encoded or modulated into or onto a carrier wave. The set of bits describing the design or a particular of the design are (when embodied in a machine readable medium, such as a carrier or storage medium) an article that may be sealed in and out of itself, or used by others for further design or fabrication.
Alternate Embodiments
It will be appreciated that, for other embodiments, a different system configuration may be used. For example, while the system 100 includes an integrated GMCH, for other embodiments, a separate graphics chipset may benefit from the secure execution of graphics applications of various embodiments. Further different type of system or different type of computer system such as, for example, a server, a workstation, a desktop computer system, a gaming system, an embedded computer system, a blade server, etc., may be used for other embodiments.
Having disclosed exemplary embodiments and the best mode, modifications and variations may be made to the disclosed embodiments while remaining within the scope of the embodiments of the invention as defined by the following claims.
