Identifier associated with memory locations for managing memory accesses

Field

Embodiments of the present invention relate generally to the field of computer architecture, and more particularly to managing memory accesses in said architectures through identifiers associated with memory locations.

Background

Software programs operating on a host system often interact with other software, firmware, or hardware components executing on the same host system. The software programs may be divided on the operating environment (hardware and/or software) of the host system based on levels of privilege. The software programs are traditionally protected only by the privileged levels associated with executing code. Each different level of privilege allows software executing within that level to perform a certain set of operations. Programs executing within a given privilege level typically have access to some or all of the resources used by other programs executing in that privilege level and/or lower privilege levels. Thus, there is no protection of software programs within privilege levels on the platform, making the software programs vulnerable to compromise if another software program of the same privilege level becomes compromised.

Summary of the Invention

The present invention is defined in the appended independent claims to which reference should be made. Advantageous features are set out in the appended dependent claims.

In the following there is disclosed a memory management system associating micro-context ID to memory pages so as to provide privileged and shared memory accesses in a platform comprising dual execution environments.

Reference is made, by way of comparison, to United States Patent <patcit id="pcit0001" dnum="US6823433B1"><text>US 6,823,433 B1 (Barnes, B.C., et al.</text></patcit>). Therein is disclosed a memory organisation and protection apparatus which associates a Security Context ID 'SCID' to memory pages and which decides whether to grant/deny access to memory pages depending on a comparison between the SCID of a currently executed instruction and the SCID of a selected page.

Brief Description of the Drawings

Embodiments of the invention are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which: <ul id="ul0001" list-style="none"><li><figref idref="f0001"><b>FIG. 1</b></figref> illustrates a platform having dual execution environments to secure memory accesses in accordance with an embodiment of the present invention;</li><li><figref idref="f0001"><b>FIG. 2</b></figref> illustrates data structures of an auxiliary memory in accordance with an embodiment of the present invention;</li><li><figref idref="f0002"><b>FIG. 3</b></figref> illustrates a platform having dual processors to provide dual execution environments in accordance with an embodiment of the present invention;</li><li><figref idref="f0002"><b>FIG. 4</b></figref> illustrates operational phases of the host environment in accordance with an embodiment of the present invention;</li><li><figref idref="f0002"><b>FIG. 5</b></figref> illustrates operational phases of the auxiliary environment in accordance with an embodiment of the present invention;</li><li><figref idref="f0003"><b>FIG. 6</b></figref> illustrates an access operation from the host environment in accordance with an embodiment of the present invention;</li><li><figref idref="f0003"><b>FIG. 7</b></figref> illustrates a context-switching operation from an exiting component in accordance with an embodiment of the present invention;</li><li><figref idref="f0003"><b>FIG. 8</b></figref> illustrates a context-switching operation from an entering component in accordance with an embodiment of the present invention; and</li><li><figref idref="f0004"><b>FIG. 9</b></figref> illustrates a platform utilizing virtualization to provide dual execution environments in accordance with an embodiment of the present invention.</li></ul>

Detailed Description

Embodiments of the present invention may provide a method, apparatus, and system for enabling a secure platform. More specifically, embodiments of the present invention may provide an architecture providing memory access policies based on associated identifiers.

<figref idref="f0001"><b>FIG. 1</b></figref> illustrates a platform <b>100</b> having dual execution environments to secure memory accesses, in accordance with an embodiment of the present invention. The platform <b>100</b> may have a host execution environment, e.g., host environment <b>104,</b> an auxiliary execution environment, e.g., auxiliary environment <b>108,</b> a main memory <b>112,</b> and an auxiliary memory <b>116,</b> coupled with each other as shown. The auxiliary memory <b>116</b> may have a number of access policies relating to the access of content stored in the main memory <b>112.</b> These access policies may be maintained/managed by one or more components of the auxiliary environment <b>108.</b>

The auxiliary environment <b>108</b> may be securely partitioned from the host environment <b>104,</b> and may include, e.g., a service processor, a virtual partition using a virtual machine manager, or an embedded microcontroller. In an embodiment, the auxiliary environment <b>108</b> may be configured to execute code independently and securely isolated from the host environment <b>104.</b> In some embodiments, the auxiliary environment <b>108</b> may be further configured to prevent components of the host environment <b>104</b> from performing operations that would alter, modify, read, or otherwise affect the components of the auxiliary environment <b>108.</b> In various embodiments, the auxiliary environment <b>108</b> may be partitioned from the host environment <b>104</b> via a variety of different types of partitions, including an entirely separate hardware partition (e.g., utilizing Active Management Technologies (AMT), "Manageability Engine" (ME), Platform Resource Layer (PRL) using sequestered platform resources, System Management Mode (SMM), and/or other comparable or similar technologies) and/or a virtualized partition (e.g., a virtual machine in a Virtualization Technology (VT) scheme). In various embodiments, a virtualized host may also be used to implement AMT, ME, and PRL technologies (as described in further detail below).

In an embodiment, the main memory <b>112</b> and the auxiliary memory <b>116</b> may be sequestered from one another in a manner to provide different levels of access to components operating in the host environment <b>104</b> and components operating in the auxiliary environment <b>108.</b> For example, in some embodiments components operating in the auxiliary environment <b>108</b> may have read-only access to the main memory <b>112</b> and may have read-write access to the auxiliary memory <b>116</b> to facilitate management of access policies. Furthermore, in some embodiments components operating in the host environment <b>104</b> may have read-write access to the main memory <b>112</b> and read-only access to the auxiliary memory <b>116.</b> This restriction of components operating in the host environment to modify the access policies found in the auxiliary memory <b>116</b> may facilitate maintenance of security on the platform <b>100.</b>

It may be noted that the above access levels may refer to generic environmental access levels with the potential of having more particular access policies being applied to particular components operating in each environment. For example, the host environment <b>104</b> may include an operating system (OS) <b>120</b> for control and/or management of other components including the mediation of information flow between higher-level components, e.g., user apps <b>124,</b> and lower-level components, e.g., a loader <b>128,</b> a subject component <b>132,</b> a memory manager <b>136,</b> and/or a target component <b>140.</b> In some embodiments, the subject component <b>132</b> and the target component <b>140</b> may be software components operating in the same privilege level, or architectural ring. In some embodiments the OS <b>120</b> may have no access to the auxiliary memory <b>116,</b> while certain other components of the host environment <b>104,</b> e.g., subject component <b>132,</b> may be provided limited access.

As used herein, the term "component" is intended to refer to programming logic that may be employed to obtain a desired outcome. The term component may be synonymous with "module" and may refer to programming logic that may be embodied in hardware or firmware, or in a collection of software instructions, possibly having entry and exit points, written in a programming language, such as, for example, C++.

A software component may be compiled and linked into an executable program, or installed in a dynamic link library, or may be written in an interpretive language such as BASIC. It will be appreciated that software components may be callable from other components/modules or from themselves, and/or may be invoked in response to detected events or interrupts. Software instructions may be embedded in firmware, such as an electrically erasable programmable read-only memory (EEPROM), or may be stored on a readable medium such as a magnetic or optical storage device. It will be further appreciated that hardware components may be comprised of connected logic units, such as gates and flip-flops, and/or may be comprised of programmable units, such as programmable gate arrays or processors. In one embodiment, the components described herein are implemented as software modules, but nonetheless may be represented in hardware or firmware. Furthermore, although only a given number of discrete software/hardware components may be illustrated and/or described, such components may nonetheless be represented by additional components or fewer components without departing from the spirit and scope of embodiments of the invention.

In an embodiment, the loader <b>128,</b> the subject component <b>132,</b> the memory manager <b>136,</b> and/or the target component <b>140</b> may be supervisory-level components, e.g., kernel components. In various embodiments, kernel components may be services (e.g., loader, scheduler, memory manager, etc.), extensions/drivers (e.g., for a network card, a universal serial bus (USB) interface, a disk drive, etc.), or a service-driver hybrid (e.g., intrusion detectors to watch execution of code).

In some embodiments the main memory <b>112</b> may organize content stored therein into a number of groups of memory locations. These organizational groups, which may be fixed- and/or variable sized, may facilitate virtual memory management. The groups of memory locations may be pages, segments, or a combination thereof.

A virtual memory utilizing paging may facilitate the emulation of a large logical/linear address space with a smaller physical memory page. Therefore, the host environment <b>104</b> may provide a virtual execution environment in which the components may operate, which may then be mapped into physical pages of the main memory <b>112.</b> The OS <b>120</b> may maintain page tables to map the logical/linear addresses provided by components of the host environment <b>104</b> to physical address of the main memory <b>112.</b> More details of the implementation of paging in accordance with embodiments of the present invention may be given below.

In an embodiment, the loader <b>128</b> may receive a load request, e.g., from the OS <b>120,</b> to load content into one or more pages of the main memory <b>112,</b> e.g., subject pages <b>144.</b> The loaded content may include, e.g., data pages, having static content, and/or code pages, having executable content. The subject pages <b>144</b> may be used for providing processor instructions to a host processor in the execution of the subject component <b>132.</b> The loader <b>128</b> may make a request to the memory manager <b>136</b> to allocate subject pages <b>144.</b> The loader <b>128</b> may then load the content into the allocated subject pages <b>144.</b> The content, upon execution in the host environment <b>104</b> may be manifested as the subject component <b>132.</b>

In an embodiment, the auxiliary environment <b>108</b> may include a code location component <b>148</b> to identify the location of the subject pages <b>144</b> in the main memory <b>112.</b> The code location component <b>148</b> may use the capability of the auxiliary environment <b>108</b> to access the main memory <b>112</b> to read and locate the subject pages <b>144</b> in the main memory <b>112.</b> The code location component <b>148</b> may receive images, e.g., complete images or hashes, of the images or specific subject pages <b>144,</b> from the host environment <b>104</b> and/or a third-party trusted entity, to facilitate their location and/or state verification in the main memory <b>112.</b> A comparison, e.g., byte-by-byte or through cryptographic hashes, may be done between the image received and the subject pages <b>144</b> from the perspective of the auxiliary environment <b>108.</b> In various embodiments, the code location component <b>148</b> may search for the location of the subject pages <b>144</b> directly in the main memory <b>112,</b> e.g., through a direct memory access and/or a messaging system between the auxiliary environment <b>108</b> and the host environment <b>104.</b> A messaging system, for example, may search for the location of the subject pages <b>144</b> by using the memory mapped registers of a host processor of the host environment <b>104.</b> A read of the registers of the host processor may take place through a system management interrupt (SMI), for example.

As shown in <figref idref="f0001"><b>FIG. 1</b></figref><b>,</b> the code location component <b>148</b> is located in the auxiliary environment <b>108;</b> however, in some embodiments, the code location component <b>148,</b> or portions thereof, may be located elsewhere. Furthermore, in some embodiments, the code location component <b>148</b> may additionally/alternatively cooperate with components, e.g., agents, in other execution environments.

In an embodiment utilizing virtualized memory, the location of the subject component <b>132</b> may be reported to the code location component <b>148</b> as its linear address. The code location component <b>148</b> may receive this linear address and access host page tables setup by the host environment <b>104</b> to perform a virtual-to-physical address mapping to determine the physical location of the subject page <b>144</b> in main memory <b>112.</b> In an embodiment, the code location component <b>148</b> may optionally fetch additional information from the subject component <b>132</b> to verify the location and/or state, e.g., through hashes, relocation fix-ups, etc. In an embodiment, the determination of the location of the subject page <b>144</b> may be facilitated by having the subject pages <b>144</b> pinned in main memory <b>112.</b>

In an embodiment, the code location component <b>148</b> may report the location and/or state of the subject pages <b>144</b> to an auxiliary memory manager, e.g., a micro-context manager <b>152.</b> The micro-context manager <b>152</b> may assign an identifier, or micro-context (uC), to the subject pages <b>144</b> and store the assigned uC in the auxiliary memory <b>116,</b> e.g., subject-uC <b>156.</b> The subject-uC <b>156</b> may facilitate storage and subsequent retrieval of various meta-data associated with the subject page <b>144.</b> For example, in an embodiment, the subject-uC <b>156</b> may include access control policies that apply to the content stored in the subject pages <b>144</b> of the main memory <b>112.</b> In various embodiments, these access control policies may be referenced by components of the host environment <b>104</b> to control various memory accesses to the subject pages <b>144</b> and/or by the subject component <b>132.</b>

The various management components of the auxiliary environment <b>108,</b> e.g., the code location component <b>148</b> and the uC manager <b>152,</b> may operate independently from the OS <b>120</b> of the host environment. Therefore, management provided by such components may be referred to as OS-agnostic or "out-of-band" (OOB) management.

In an embodiment, one or more pages, e.g., target pages <b>160,</b> storing data relating to the target component <b>140</b> may be located and assigned a target-uC <b>164</b> in a manner similar to that discussed above relative to the subject page <b>144.</b> In an embodiment, the subject component <b>132</b> may issue a request to access, e.g., to read/write from/to, content stored in target pages <b>160.</b> The processor of the host environment <b>104</b> may perform an access control check, to determine whether to grant/deny this request, based at least in part on reference to the subject-uC <b>156</b> and/or a target-uC <b>164</b> stored in the auxiliary memory <b>116.</b> If the access control check fails, e.g., the subject-uC <b>156</b> and the target-uC <b>164</b> are incompatible, the processor may issue a page fault exception and/or interrupt the uC manager <b>152.</b> If the access control check passes, e.g., the subject-uC <b>156</b> and the target-uC <b>164</b> are compatible, no faults may be issued and the processor may access the requested content.

<figref idref="f0001"><b>FIG. 2</b></figref> illustrates data structures of the auxiliary memory <b>116</b> in accordance with an embodiment of the present invention. In this embodiment, an array <b>200</b> may include micro-context numbers, e.g., uC1 <b>204</b> - uCN <b>208,</b> associated with physical pages in the main memory <b>112.</b> It may be noted that the correspondence between physical pages and micro-contexts may not be one-to-one, e.g., multiple physical pages may have the same micro-context. The micro-context numbers of the array <b>200</b> may, in turn, be associated with a corresponding array <b>212</b> of micro-context data. A micro-context data entry, e.g., uCN <b>216</b> may include access policy fields for data such as permissions <b>220</b> (e.g., readable/nonreadable, writeable/nonwriteable, hidden/visible, etc.) and/or relational access data <b>224</b> (e.g., other micro-contexts that may access this micro-context if marked readable, etc.).

In some embodiments the relational access data <b>224</b> may facilitate a number of different components having access to the same pages in the main memory <b>112.</b> This may be achieved by storing one or more micro-contexts in addition to the primary micro-context associated with the particular page. Such a page may then be accessed by any of the micro-contexts listing in its associated access control data structure in the auxiliary memory <b>116.</b> This shared access may allow privileged code to be chained together in a chain-of-trust model. For example, if a layered software component A exchanges data with another layered software component B, the auxiliary environment <b>108</b> may assign micro-contexts to the layered software components and setup access control policies such that the data pages for A are also marked with a shared micro-context for B-uC. Therefore, when B-uC code accesses A's data, the accesses may be allowed.

In some embodiments, this type of shared access may provide some level of assurance that only packets that traverse a firewall or VPN intermediate driver are delivered to the device driver. Likewise, it may provide some level of assurance that only the device driver can access the frame buffer data segments and so on. This may prevent circumvention of security software by network traffic leaving/entering the system.

In an embodiment uCN <b>216</b> may also include fields for data to facilitate context switches, e.g., component entry point data <b>228</b> and/or stack state data <b>232.</b> Utilization of the information stored in these fields may be further described below in accordance with some embodiments of the present invention.

<figref idref="f0002"><b>FIG. 3</b></figref> illustrates a platform <b>300</b> having dual processors to provide dual execution environments in accordance with an embodiment of the present invention. The platform <b>300</b> may have a host processor <b>304</b> to execute components within the host environment <b>104,</b> and a service processor <b>308</b> to execute components within the auxiliary environment <b>108</b> described and discussed with reference to <figref idref="f0001"><b>FIG. 1</b></figref><b>.</b> Operational phases, noted herein by numerals in parentheses, may refer to host operations illustrated in <figref idref="f0002"><b>FIG. 4</b></figref> and/or auxiliary operations illustrated in <figref idref="f0002"><b>FIG. 5</b></figref><b>.</b>

Each processor may have associated resources on the platform <b>300</b> and may share one or more other resources. Thus, as illustrated in this example, host processor <b>304</b> and dedicated processor <b>308</b> may each have portions of memory dedicated to them, e.g., main memory <b>112</b> and auxiliary memory <b>116,</b> respectively, and may share other resources, e.g., a network interface <b>310,</b> to communicatively couple the device to a network.

In various embodiments, a variety of other dedicated and/or shared resources may be included in the platform <b>300.</b> For example, in an embodiment, the host processor <b>304</b> may be communicatively coupled to a peripheral storage device, e.g., disk drive <b>314,</b> which may include a digital versatile disk drive (DVD), a compact disk (CD) drive, a floppy disk drive, etc.

In an embodiment, the OS <b>120</b> may configure and load a page table <b>312</b> with the virtual-to-physical mapping of one or more components to be run on the host processor <b>304,</b> e.g., subject component <b>132 (404).</b> The page table <b>312</b> may have page entries <b>320,</b> offsets <b>324,</b> and/or flags <b>328</b> to facilitate this mapping. The page table <b>312,</b> or parts thereof, may be stored in a processor cache, e.g., a translation lookaside buffer (TLB) <b>332.</b>

The host processor <b>304</b> may also use its read-capability of the auxiliary memory <b>116</b> to access and load the subject-uC <b>156</b> into the TLB <b>332 (408).</b>

The host processor <b>304</b> may utilize the page table <b>312</b> for subsequent accesses to the subject pages <b>144 (412),</b> pursuant to access control policies associated with the subject-uC <b>156.</b> Execution instructions <b>336,</b> of the subject component <b>132,</b> may be processed by the host processor <b>304</b> upon a successful access and loading of the subject pages <b>144.</b>

The host processor <b>304</b> may record a micro-context of the page from where the host processor <b>304</b> is executing code, e.g., subject-uC <b>156,</b> in a uC-register <b>340 (416).</b>

In an embodiment, the code location component <b>148,</b> operating in the auxiliary environment <b>108,</b> e.g., by being executed by the service processor <b>308,</b> may determine that the subject component <b>132</b> is executing in the host environment <b>104 (504).</b> In an embodiment, the code location component <b>148</b> may determine which component is executing in the host environment <b>104</b> by reference to the uC-register <b>340.</b> In an embodiment, service processor <b>308</b> may be prevented from accessing the register directly. Therefore, in this embodiment an SMI may facilitate the provision on this information to the service processor <b>308.</b> An SMI may be issued by a system management mode (SMM) component operating in the host environment <b>104,</b> the auxiliary environment <b>108,</b> or another execution environment. An SMI may cause the host processor <b>304</b> to enter the SMM by swapping out the execution instructions <b>332</b> for processing instructions related to an interrupt service routine. The host processor <b>304</b> may provide data including the state of the uC-register <b>340,</b> e.g., the micro-context of the code that was executing prior to the interrupt, to an SMM handler. The SMM handler may provide the state of the uC-register <b>340</b> to the service processor <b>308</b> via main memory <b>112,</b> for example.

The code location component <b>148</b> may locate the subject pages <b>144</b> in main memory <b>112</b> and verify the state of the subject pages <b>144 (508)</b> as described above with reference to <figref idref="f0001"><b>FIG. 1</b></figref><b>.</b> The uC manager <b>152</b> may then associate a micro-context with the subject page <b>144</b> and save the associated micro-context in the auxiliary memory <b>116</b> based at least in part on said location and verification of the subject pages <b>144 (512).</b>

In an embodiment, the subject pages <b>144</b> may include a data page, or reference to a data page, which may be added to the page table structure for the subject component <b>132.</b> This data page may be assigned a micro-context of 0, e.g., not protected, by default. If the subject component <b>132</b> intends for the data page to be assigned the same micro-context as the subject component <b>132,</b> the subject component <b>132</b> may make an assignment request to the service processor <b>308.</b> In an embodiment, this request may be made via an SMI handler. The service processor <b>308</b> may assign the data page with the requested micro-context if it is determined that a number of assignment preconditions are met. These assignment preconditions may be met if, e.g., the subject component <b>132</b> has the same micro-context as it is requesting be assigned to the data page, and the data page does not already have another micro-context assigned to it.

In an embodiment, a request to remove, or de-assign, a micro-context assignment from a data page, e.g., reassign a protected data page with an unprotected micro-context, may be handled in a similar way. For example, a de-assignment request may be granted by the service processor <b>308</b> if a number of de-assignment preconditions are met. These de-assignment preconditions may be met if, e.g., the page was added to the micro-context and/or the data page has the same micro-context as the requestor.

In an embodiment, if the host processor <b>304</b> is to access a mapping to a component's pages, along with any associated micro-context, from the TLB <b>336,</b> the host processor <b>304</b> may additionally access the auxiliary memory <b>116</b> to determine if any updates to the micro-context have occurred. In various embodiments, updates to the micro-contexts may also be periodically provided to the TLB <b>336.</b> Provision of the periodic updates may be as a result from a specific request from the host processor <b>304</b> and/or may be pushed into the TLB <b>336.</b>

<figref idref="f0003"><b>FIG. 6</b></figref> illustrates an access operation from the host environment <b>104</b> in accordance with an embodiment of the present invention. In an embodiment, the execution instructions <b>332</b> may include instructions for the host processor <b>304</b> to access content stored in the target pages <b>160 (604).</b> When the host processor <b>304</b> is in a protected mode, the processing instructions may access memory using logical/virtual addresses. An initial lookup may be performed in the TLB <b>332</b> to determine if a mapping to the data sought and an associated micro-context are stored therein <b>(608).</b> If a mapping to the corresponding physical address of the target pages <b>160</b> and associated micro-context are found, the host processor <b>304</b> may perform uC access control check <b>(612).</b> If no uC access violation is present, the host processor <b>304</b> may access the target data based on the physical address from the TLB <b>332 (616).</b> If a uC access violation does result from the access operation, an exception may be raised, e.g., a processor Page-Fault exception <b>(620).</b> In an embodiment, these exceptions may be handled by firmware to ensure appropriate alerts and/or events are logged. However, in other embodiments alerts and/or events may be handled by hardware and/or software implementations.

In an embodiment, for instructions that access data in the main memory <b>112,</b> the host processor <b>304</b> may compare the micro-contexts of the executing code with the micro-context of the page where the address specified in the instruction lie for compatibility. In an embodiment, accesses across micro-contexts may be generally disallowed, with the exception for shared or remapped pages where a list of micro-contexts may be associated with the same physical page.

If the virtual-to-physical address mapping is not found in the TLB <b>332,</b> the host processor <b>304</b> may perform a page walk and cache the mapping to the target pages <b>160</b> in the TLB <b>332 (624).</b> The host processor <b>304</b> may additionally cache the target uC <b>164,</b> from the auxiliary memory <b>116,</b> in the TLB <b>332 (628).</b> The host processor may check for uC access violation <b>(612).</b>

<figref idref="f0003"><b>FIG. 7</b></figref> illustrates a context-switching operation in accordance with an embodiment of the present invention. In some embodiments, a number of processes may share the computational resources of the host processor <b>304.</b> This sharing of resources may be provided through context switches. Context switches may be precipitated by a switching event <b>704.</b> An implicit context switch may have a switching event such as an interrupt. An explicit context switch may have a switching event such as a CALL opcode issued from the executing component explicitly calling another component.

As discussed herein, a context switch may involve an exiting component, e.g., the component executing prior to context switch, and an entering component, e.g., the component executing following the context switch.

At the switching event, the host processor may determine whether the exiting component is protected, e.g., is the exiting component associated with a non-zero uC <b>(708).</b> If the exiting component is protected, the host processor <b>304</b> may perform a micro-context save interrupt by saving an entry point, which may be the physical address where the last instruction was fetched from when the context switch occurred, and data for subsequent verification of the stack-state <b>(712).</b> The entry-point and the stack-state verification data may be saved in the exiting component's micro-context associated space in the auxiliary memory <b>116.</b>

In various embodiments, data for stack-state verification may include a copy of the entire stack state or an integrity check value (ICV) calculation. An ICV may be calculated on the in parameters of a stack frame by setting the out parameters to default values. Likewise, an ICV may be calculated on the out parameters by setting the in parameters to default values. An ICV calculation and/or verification may be done by the host processor <b>304</b> using a key provisioned by the service processor <b>308</b> via an SMI, for example.

Following the micro-context save interrupt, the host processor <b>304</b> may switch from the exiting component to the entering component <b>(716).</b>

If it is determined that the exiting component is not protected, e.g., has a micro-context of zero, the components may be switched out without a micro-context save interrupt.

<figref idref="f0003"><b>FIG. 8</b></figref> illustrates a context switching operation on an entering component, in accordance with an embodiment of the present invention. In this embodiment, a context switch from an exiting component to an entering component may occur <b>(804).</b> A determination may be made as to whether the entering component is protected <b>(808).</b> If the entering component is protected, the host processor <b>304</b> may perform a micro-context recover interrupt <b>(812).</b> A micro-context recover interrupt may include accessing the stack-state verification data and the entry point location from the entering component's micro-context. The host processor <b>304</b> may verify the state of the stack and, if the stack is verified, resume processing opcodes from the stored entry point location <b>(816).</b> Verification of the stack-state from data stored in protected memory may provide some level of assurance that the stack has not been modified.

In some embodiments, the host processor <b>304</b> may look ahead in the pipeline by an instruction, e.g., during decode, to determine that the next instruction belongs to a micro-context other than the current one to facilitate the timely issuance of a micro-context save/restore interrupt.

While the above embodiments, refer generically to implicit and explicit context switches, some embodiments may have a particular rule set governing each type of context switch. For example, in the anticipation of an explicit context switch, entry-point opcodes may be added to verify that the entering component is being executed from special entry points identified in the component's code. If an entry-point opcode is being decoded by the entering component in response to a CALL opcode from the exiting component, no more checks may be needed. If, however, in response to a CALL opcode from exiting component, the next opcode is not an entry-point opcode, then an exception may be raised. This may be particularly useful in a situation where the exiting component is unprotected and the entering component is protected.

In some embodiments fixed entry points may be stored with micro-contexts to allow controlled flow from one uC to another. For example, a component of a first uC may jump into or call a component of a second uC at one of these entry points. At these expected entry points, proper control flow may be achieved. A policy for the component may define where the proper entry points are located. Controlled flow transitions from one component to another at a proper entry point may not generate an exception or interrupt a uC manager.

In some embodiments, fixed entry points may also be referred to as "static entry points" while entry points saved at various switching events, e.g., those saved as a result of a uC save interrupt, may also be referred to as "dynamic entry points."

<figref idref="f0004"><b>FIG. 9</b></figref> illustrates a platform <b>900</b> utilizing virtualization to provide dual execution environments in accordance with an embodiment of the present invention. The platform <b>900</b> may include only a single processor <b>904</b> but a virtual machine monitor (VMM) <b>908</b> on the device may present multiple abstractions and/or views of the device, such that the underlying hardware of the platform <b>900</b> appears as one or more independently operating virtual machines (VMs), e.g., a host VM <b>912</b> and an auxiliary VM <b>916</b> to provide the host environment <b>104</b> and the auxiliary environment <b>108,</b> respectively. The VMM <b>908</b> may be implemented in software (e.g., as a stand-alone program and/or a component of a host operating system), hardware, firmware and/or any combination thereof. The VMM <b>908</b> may manage allocation of resources on the platform <b>900</b> and perform context switching as necessary to cycle between the host VM <b>912</b> and the auxiliary VM <b>916</b> according to a round-robin or other predetermined scheme. Although only processor <b>904</b> is illustrated, embodiments of the present invention are not limited to only one processor. In various embodiments, multiple processors may also be utilized within a virtualized environment. For example, if the platform <b>900</b> includes two processors the auxiliary VM <b>916</b> may be assigned a dedicated processor while the host VM <b>912</b> (and other host VMs) may share the resources of a host processor.

While the platform <b>900</b> shows two VMs, e.g., host VM <b>912</b> and auxiliary VM <b>916,</b> other embodiments may employ any number of VMs. VMs may function as self-contained partitions respectively, running their own components hosted by VMM <b>908,</b> illustrated as host components <b>920</b> and auxiliary components <b>924.</b>

The host components <b>920</b> and auxiliary components <b>924</b> may each operate as if the were running on a dedicated computer rather than a virtual machine. That is, host components <b>920</b> and auxiliary components <b>924</b> may each expect to control various events and have access to hardware resources on the platform <b>900,</b> e.g., a wireless network interface card <b>928.</b>

A physical hardware partition with a dedicated processor (as illustrated in <figref idref="f0002"><b>FIG. 3</b></figref><b>,</b> for example) may provide a higher level of security than a virtualized partition (as illustrated in <figref idref="f0004"><b>FIG. 9</b></figref><b>,</b> for example), but embodiments of the invention may be practiced in either environment and/or a combination of these environments to provide varying levels of security.

Embodiments of the present invention shown and described above may facilitate association and management of targeted access policies from an auxiliary environment with respect to the physical pages found in main memory.

Those with skill in the art will readily appreciate that the present invention may be implemented in a very wide variety of embodiments. This description is intended to be regarded as illustrative instead of restrictive on embodiments of the present invention.