Hypervisor security event handling at a processor

Abstract

A virtualized computing environment is protected from a malicious hypervisor by limiting the hypervisor's access to one or more portions of the guest virtual machine's event (interrupt or exception) handling path, where the guest virtual machine includes a secure layer for managing the security of the guest and one or more non-secure layers for handling event processing. The hypervisor is limited to providing normal exception information to the guest virtual machine (herein simply "guest"), but is instead only allowed to provide an event signal to the secure layer of the guest. In response to the event signal, the secure layer of the guest accesses a designated memory region for event information, reviews the information, and provides the information to another non-secure layer of the guest for processing only if the event information complies with a designated security protocol.

Description

Background Technology

[0001] To enhance the efficient delivery of computer services, some servers and other computer systems implement virtualized computing environments. In such environments, the host computer system executes multiple virtual machines simultaneously, sometimes referred to as "guests" of the host computer system. To simplify the design and execution of guests, the host computer system employs a hypervisor that manages the provision of system hardware resources to concurrently executing guests. That is, the hypervisor manages the provision of hardware resources so that the hardware appears to each guest as if it were running on its own dedicated computer system. Therefore, guests can use standard operating systems, libraries, drivers, and other programs to interface with the system hardware. Furthermore, the hypervisor provides security for guests by providing an isolation layer between different guests, preventing, for example, a guest from accessing private data associated with different guests. However, in some cases, the hypervisor itself provides avenues for malicious access to guest data or other improper manipulation of guest operations. Attached Figure Description

[0002] This disclosure will be better understood by referring to the accompanying drawings, and many of its features and advantages will become apparent to those skilled in the art. The same reference numerals are used in different drawings to indicate similar or identical items.

[0003] Figure 1 It is a block diagram of a computer system that separates management procedures from incident handling, based on some implementation schemes.

[0004] Figure 2 It shows some implementation schemes. Figure 1 A block diagram of an example computer system that uses a virtual machine's security layer to access the event queue in response to signals from the hypervisor.

[0005] Figure 3 This is a flowchart illustrating a method for isolating the management program from event handling by using a security layer of a virtual machine to access the event queue, based on some implementation schemes.

[0006] Figure 4 It shows some implementation schemes. Figure 1 A block diagram of an example computer system that uses a secure memory area to store event control information.

[0007] Figure 5 This is a flowchart illustrating a method for isolating management procedures from event handling by using a secure storage area to store event control information, based on some implementation schemes. Detailed Implementation

[0008] Figures 1 to 5This paper illustrates a technique for protecting a virtualized computing environment from malicious hypervisors by restricting hypervisor access to one or more portions of the event (interruption or exception) handling path of a guest virtual machine, wherein the guest virtual machine includes both a security layer for managing the security of the guest and one or more non-security layers for handling event processing. For example, in some embodiments, the hypervisor is restricted from providing normal exception information to the guest virtual machine (hereinafter referred to as "guest") and is instead allowed to provide event signals only to the guest's security layer. In response to the event signal, the guest's security layer accesses a designated memory region to obtain event information, examines the information, and provides the information to another non-security layer of the guest so that processing is only performed if the event information conforms to a specified security protocol.

[0009] In other implementations, the hypervisor is restricted to accessing event control information, such as Task Priority Register (TPR) information, which is used by the visitor to determine whether and how to process an event. This event control information is stored in an encrypted memory region inaccessible to the hypervisor. Specifically, in response to receiving an indication for an event from the hypervisor, the visitor's security layer stores event control information for the event in the encrypted memory region, and the processor's event interface uses this event control information to ensure that the event conforms to a specified event protocol, such as by ensuring that the event priority information conforms to the TPR information stored in the encrypted region. If the event information does not conform to the specified protocol, the corresponding event is not processed. Because the hypervisor cannot access the encrypted memory region, it cannot use the event control information to exploit the visitor.

[0010] In some implementations, the management process is restricted from providing anomalous information to the visitor's insecure layer and from accessing event control information for the visitor. Instead, the management process signals an event to the visitor's security layer, which, in response, reviews the associated event information to ensure it conforms to a security protocol. If the event information conforms to the security protocol, the security layer provides the event information to the insecure layer for processing and stores event control information for the event in an encrypted storage area. The insecure layer accesses the event control information in the encrypted storage area and uses it to process the event.

[0011] By restricting the hypervisor's access to one or more of the event queues and event control information, visitors are protected from malicious hypervisors. To illustrate this with an example, in some cases, the visitor's event handling path relies on specified assumptions about the system hardware's behavior, such as the assumption that the system hardware will not generate interrupts with a lower priority than that set by the TPR or signal such interrupts. However, because the hypervisor provides an abstraction layer between the visitor and the system hardware in a virtualized computing environment, a malicious hypervisor can generate events that violate the specified assumptions about device behavior, such as by providing interrupts to the visitor's operating system with a lower priority than that set by the TPR. These events, which would otherwise be prohibited, would make the visitor's security data and other aspects vulnerable to unauthorized access or manipulation. Using the techniques described herein, malicious hypervisors are prevented from exploiting visitors in this way, thereby improving system security. Furthermore, as described herein, in some embodiments, the techniques are implemented using the processor's existing event interface, which is designed to receive and process events, thereby reducing the amount of software or hardware redesign required to implement the techniques.

[0012] Figure 1 A block diagram of a processing system 100 is shown, which restricts access to portions of an event handling path by a management procedure according to some embodiments. The processing system 100 is a system that typically executes a set of computer instructions (e.g., a computer program) to perform tasks on behalf of an electronic device. Therefore, in different embodiments, the processing system 100 is part of an electronic device such as a desktop or laptop computer, a server, a smartphone, a tablet computer, a game console, etc. For purposes of description, it is assumed that the processing system 100 is part of a server implementing a virtualized computing environment.

[0013] To support the execution of computer instructions, the processing system 100 includes a processor 101 and a memory 110. The memory 110 is volatile memory, such as random access memory (RAM); non-volatile memory, such as flash memory; or a combination thereof, and stores data on behalf of the processor 101. Specifically, when the processor 101 executes instructions, data (including instruction and operand data) is written to and read from the memory 110. It should be understood that although the memory 110 is shown as separate from the processor 101, in some embodiments, all or part of the memory 110 is part of the processor 101 and is incorporated into the same semiconductor die or semiconductor package as the processor 101.

[0014] Processor 101 is a processing device, such as a central processing unit (CPU), which includes one or more processor cores (e.g., processor core 102) and support circuitry for executing computer instructions. Although processor 101 is shown as having a single processor core for simplicity, it should be understood that in some embodiments, processor 101 includes multiple processor cores.

[0015] In the depicted example, the circuitry supporting instruction execution includes an input / output (I / O) control module 107 that provides an interface to one or more input / output devices, such as a keyboard. In some embodiments, the processor 101 includes additional support circuitry, such as one or more network interfaces interfacing with a computer or communication network, one or more memory controllers interfacing with the processor 101's memory subsystem, etc. During the execution of its specified operations, the support circuitry generates conditions referred to herein as processor events (e.g., event 108).

[0016] As used herein, a processor event refers to an interrupt or exception signaled by a hardware module of the processor. For example, in response to user manipulation of an input / output device, I / O control module 107 signals an interrupt to allow processor 101 to respond to user manipulation. Circuits invoke events to trigger the execution of event handlers (such as interrupt handlers or exception handlers) to process the event. For example, in response to user input at a keyboard or other input device, I / O control module 107 invokes an interrupt event to trigger an interrupt handler that processes the user input, such as by storing user-input-based data in a designated buffer (not shown).

[0017] In response to an event signaled by I / O control module 107 or other circuitry to trigger an exception handler, processor 101 uses designated circuitry to execute designated operations in a designated sequence, such as a designated event queue. The operations, sequences, and circuitry used by processor 101 to handle processor events are referred to herein as the event handling path of processor 101. To assist in event handling, processor 101 includes an event interface 109. In some embodiments, event interface 109 is a module conforming to a designated event interface standard, such as either the Advanced Programmable Interrupt Controller (APIC) or x2APIC standard. Thus, in some embodiments, event interface 109 is a module that receives signals indicating processor events (such as interrupts and exceptions), identifies the source or vector of the event, and provides an indication of the event, along with any additional information about the event to processor core 102. In response, processor core 102 invokes the event handler associated with the event. Specifically, processor core 102 uses the information provided by the event interface to select the event handler corresponding to the event and executes the event handler, thereby handling the event.

[0018] As described above, in a virtualized computing environment, the event processing path provides a potential attack avenue for malicious entities seeking unauthorized access to the data and operations of processor 101. To prevent such attacks, when a virtualized computing environment is running, processor 101 restricts the hypervisor's access to one or more portions of the event processing path.

[0019] To illustrate, in Figure 1 In the example, processor 101 implements a virtualized computing environment by simultaneously executing two virtual machines, VM1 104 and VM2 106 (also referred to as guest 104 and 106). Each of guest 104 and 106 is a virtual machine that includes one or more computer programs, such as an operating system, applications, etc. In some implementations, to provide security against unauthorized access or manipulation, guest 104 and 106 include multiple layers, each with specified access protections to prevent unauthorized access. For example, guest 104 has multiple layers, including a secure layer 120 (specified virtual machine privilege level 0 (VMPL0)) protected against access and manipulation by software in other layers, and a non-secure layer 132 that performs event handling (such as the execution of interrupt handlers, exception handlers, etc.) for guest 104. Thus, for example, in some implementations, the non-secure layer 132 is, for instance, a VMPL3 layer that executes an operating system, but commands from the operating system to modify data or operations at the VMPL0 layer are ignored unless they match a specified security protocol, thereby protecting guest 104 from exploitation.

[0020] In other embodiments, security layer 120 emulates the central processing unit (CPU) for the operating system located at non-security layer 132, and security layer 120 performs both interrupt handling and APIC emulation for non-security layer 132. This allows the operating system executing at non-security layer 132 to use event interface 109 as a standard APIC or x2APIC interface, where security layer 120 performs event handling, as further described herein.

[0021] To support virtualization, processor 101 includes a hypervisor 105, which provides an interface between the hardware resources of processor 101 and guests 104 and 106. Specifically, guests 104 and 106 include standard device drivers and other interface software that generate hardware requests and other communications as if the guests were executing on a dedicated computer system. Hypervisor 105 receives communications from the device drivers and other interface software and manages the provision of hardware resources to guests 104 and 106 based on these communications. Hypervisor 105 thus provides a layer between guests 104 and 106 and the hardware resources of processor 101, abstracting the hardware resources so that guests 104 and 106 can use standard hardware interface software designed for dedicated computer systems.

[0022] To further support virtualization, hypervisor 105 handles at least some aspects of event handling. For example, in response to an instruction for an interrupt from I / O control module 107, hypervisor 105 identifies a visitor associated with the interrupt and signals the interrupt along with any associated event handling information (such as the interrupt identifier, the priority level associated with the interrupt, etc.) to the visitor via event interface 109. Traditionally, the hypervisor uses event interface 109 to directly inject event hardware information into the visitor, and the visitor uses the corresponding event handler to process the event based on the injected event handling information. However, as mentioned above, allowing the hypervisor to inject any event handling information via event interface 109 or other parts of the event handling path provides a potential attack avenue for malicious hypervisors. Therefore, processor 101 restricts hypervisor access to one or more parts of the event handling path.

[0023] For illustration, each layer of visitors 104 and 106 can operate independently in either of two different modes (specified as restricted injection mode and alternating injection mode). These modes will be described relative to their implementation at visitor 104, but it should be understood that visitor 106 operates in a similar manner. In restricted injection mode, the supervisor 105 is not allowed to directly provide event handling information to the non-security layer of the visitor. Instead, the supervisor 105 signals the occurrence of an event to the security layer 120 of visitor 104 via event interface 109 and stores the event handling information for the event in event queue 130 stored in memory 110. In some embodiments, the event handling information includes one or more of the following: an indicator of the event source (e.g., a hardware module that triggered an interrupt), the type of event (e.g., whether the event is an interrupt or an exception, the type of interrupt or exception, etc.), the priority level of the event, etc.

[0024] In response to an event signal, security layer 120 invokes an exception handler to access event handling information in event queue 130. Through the exception handler, security layer 120 determines whether the event control information conforms to a specified security protocol, and if so, provides the event handling information to non-security layer 132 for normal processing. For example, in some embodiments, security layer 120 determines whether the event handling information matches the expected hardware behavior of processor 101. Therefore, in some embodiments, security layer 120 compares one or more of the event priority level, event type, event source, event identifier, etc., with corresponding specified value ranges. If any event information is outside the corresponding specified range, security layer 120 does not signal the event to non-security layer 132, nor does it provide event handling information to non-security layer 132. In some embodiments, security layer 120 takes additional remedial measures, such as signaling potential security vulnerabilities to the user or other computer systems via the network to stop the execution of guest 104.

[0025] If the event handling information conforms to the specified security protocol, security layer 120 signals the event along with the event handling information to event interface 109. In response, event interface 109 notifies non-security layer 132 of the event and provides the event handling information to non-security layer 132. Non-security layer 132 then uses the event handling information to handle the event, such as by invoking the event's exception handler. Therefore, the event handling information is first reviewed by security layer 120 before being allowed to be passed through event interface 109 to non-security layer 132 for processing. The following is related to... Figure 2 and Figure 3 Further description of the restricted injection pattern.

[0026] In the alternating injection mode, the layer of visitor 104 (e.g., non-security layer 132) uses event control information 118 to process event handling information. Event control information 118 is information that controls the event interface 109. For example, in some embodiments, event control information 118 includes Task Priority Register (TPR) information that sets the priority level of events that are allowed to be processed. If an event provided by the hypervisor 105 has a priority level lower than that of the TPR information, the event is not processed, thereby protecting visitor 104 from malicious attacks.

[0027] In some implementations, event control information 118 is stored in an encrypted region of memory 110, where the data stored in the encrypted region is encrypted using a key associated with visitor 104. The key is unknown to management program 105, thereby preventing management program 105 from altering the event control information 118 and further protecting visitor 104. The following is related to... Figure 4 and Figure 5 Further description of the alternating injection pattern.

[0028] To set security modes for the respective layers of visitors 104 and 106, processor core 102 includes a mode control register 111. Mode control register 111 includes multiple fields, each setting the security mode for its corresponding visitor level, thus allowing different visitor levels to have their security modes set independently. Therefore, for example, in some embodiments, security layer 120 is in restricted injection mode while non-security layer 132 is in alternating injection mode. In some embodiments, mode control register 111 is programmable only by the visitor's security layer (e.g., security layer 120) and not by the hypervisor 105, further protecting the event handling path of processor 101. Furthermore, in some embodiments, mode control register 111 does not allow restricted injection mode and alternating injection mode to be active simultaneously for the same visitor layer.

[0029] In some implementations, the security of visitor 104 is enhanced by placing security layer 120 in restricted injection mode and non-security layer 132 in alternating injection mode. In this arrangement, management program 105 signals an event (e.g., event 108) to event interface 109 and stores the corresponding event handling information in event queue 130. In response to the event signal, security layer 120 (in restricted injection mode) retrieves the event handling information from event queue 130 and determines whether the event handling information conforms to a specified security protocol. If not, security layer 120 does not signal the event to event interface 109.

[0030] If the event handling information matches the security protocol, security layer 120 stores the event control information for the event in an encrypted area of ​​memory 110 as event control information 118. Security layer 120 provides event handling information 118 to event interface 109. In response, and in response to non-security layer 132 being in alternating injection mode, event interface 109 accesses event control information 118, decrypts the event control information, and uses the decrypted control information and event handling information to handle the event, such as by requesting non-security layer 132 to execute the event-associated event handler (e.g., interrupt or exception handler). Thus, event handling is managed via the standard interface provided by event interface 109, but is invoked by security layer 120, rather than directly by hypervisor 105. This allows non-security layer 132 to handle and respond to events in a standard manner without requiring redesign of the software or event interface 109 that executes at non-security layer 132.

[0031] Figure 2 An example of event handling in restricted injection mode at processor 101 is shown according to some implementation schemes. In the example shown, virtual machine 104 includes two layers: a security layer 120 and a non-security layer 132. As described above, the security layer 120 is the secure part of guest 104, protected from modification by the non-security layer 132, hypervisor 105, and other non-security entities. The non-security layer 132 is the layer of guest 104 where guest operating system and other programs are executed, and is generally accessible by other entities, such as other programs or layers of guest 104.

[0032] During operation, management program 105 receives indications for events (interruptions or exceptions). The indications also include event information, such as the type of event and the identifier of the visitor to whom the event is directed. In response to the indication of an event, management program 105 generates additional event information, such as the identifier of the device that generated the event and the priority level of the event. Management program 105 stores event handling information 234 in event queue 130 stored in memory 110.

[0033] In addition, in response to an event, the management procedure provides an event signal 208 to the event interface 109. In some implementations, the event signal 208 is a simple anomalous signal (e.g., an x86 anomalous signal) that does not include event handling information 234 or any indication of the type or source of the event, but simply signals that an event has occurred. In response to event signal 208, the event interface notifies visitor 104. In response, security layer 120 executes an event handling procedure to access the event queue 230 at memory 110 to retrieve event handling information 234. In some implementations, security layer 120 reviews whether the event handling information 234 conforms to specified security protocols, such as ensuring that the source and type of the event are as expected, and that the event priority level conforms to TPR information. If the event handling information 234 fails to conform to the security protocols, security layer 120 does not signal the event to event interface 109 for processing, thereby protecting visitor 104 from potential attacks. In response to event handling information 234 conforming to the security protocols, security layer 120 signals the event to event interface 109 for normal event processing.

[0034] Therefore, as illustrated in the example above, in the restricted injection mode, the hypervisor 105 is restricted from directly transmitting event information to the non-security layer 132. Instead, the hypervisor 105 provides a relatively simple indication of the event to the security layer 120 and provides event information via an event queue accessible only to the visitor 104 from the security layer 120. This protects the non-security layer 132 from malicious hypervisors that directly provide event information to the non-security layer 132 and may access security information or otherwise manipulate the visitor 104.

[0035] Figure 3 This is a flowchart of method 300 for operating a visitor layer in a restricted injection mode according to some implementation schemes. For descriptive purposes, method 300 is about... Figure 1 This is described using an example implementation of the processing system 100. At block 302, the hypervisor 105 receives indications of processor events from hardware resources of the processor 101, such as from the I / O control module 107. In response, the hypervisor 105 determines event information associated with the event, such as the resource that generated the event, the visitor to which the event is directed, and the priority level associated with the event. At block 304, the hypervisor 105 stores the event information in event queue 230 located at memory 110.

[0036] At box 306, management program 105 provides an indication of an event occurring to event interface 109, whereby the signal indicates the visitor to whom the event is directed. Therefore, if the event is directed to visitor 104, management program 105 provides an indication of that event to event interface 109. In some embodiments, the event interface ignores any event information provided by management program 105 along with the signal. Thus, the signal merely acts as a "doorbell," informing the visitor that an event has occurred without any associated event information.

[0037] At box 308, in response to a signal from hypervisor 105, event interface 109 notifies the security layer of the event. In response, security layer 120 accesses event queue 230 and retrieves event information. If the event information conforms to the event security protocol, security layer 120 provides the event information to non-security layer 232, such as by indicating the event to event interface 109 of processor 101. Non-security layer 232 executes an exception handler to process the event. If the event information does not conform to the security protocol, security layer 120 does not signal the event to event interface 109 and therefore does not process the event, thereby protecting visitor 104 from exploitation.

[0038] Figure 4 An example of event handling in an alternating injection mode at processor 101 according to some implementation schemes is shown. In the example shown, similar to Figure 2 For example, virtual machine 104 includes two layers: a security layer 120 and a non-security layer 132. As described above, security layer 120 is the secure part of guest 104, protected from modification by the non-security layer 132, hypervisor 105, and other insecure entities. Figure 2 As described in the example, the non-secure layer 132 is the layer on which the guest 104 executes the guest operating system and other programs, and is generally accessible by other programs or layers on the guest 104.

[0039] Furthermore, in the illustrated example, memory 110 includes an encrypted region designated as Virtual Machine State Area (VMSA) region 442. VMSA region 442 stores data encrypted with a key uniquely associated with guest 104. In some embodiments, the key is accessible only to security layer 120 and not to hypervisor 105. Security layer 120 thus manages all access to VMSA region 442. Specifically, security layer 120 manages writing data to and reading data from VMSA region 442 by encrypting and decrypting data for writing and reading using a guest-specific key, respectively. In some embodiments, the encryption and decryption of data is performed by dedicated hardware (not shown) of processor 101 at the request of security layer 120. The guest-specific key is unknown and inaccessible to hypervisor 105, and the data stored in VMSA region 442 is therefore inaccessible to hypervisor 105.

[0040] VMSA zone 442 stores event control information 444, which manages what events visitor 104 processes and how one or more of those events are processed. For example, in some implementations, event control information 444 stores TPR information, which indicates the lowest priority level of events that are allowed to be processed by the operating system of visitor 104. The operating system sets the TPR level according to conventional operating system protocols and indicates the TPR level to security layer 120, which stores the TPR level in event control information 444, as further described below.

[0041] In operation, the management program 105 receives indications of events from hardware resources (such as the I / O control module 107). In response, the management program 105 determines event information 408 associated with the event. As described above, event information 408 includes information such as the priority level associated with the event, the hardware resource that generated the event, and the type of event. The management program 105 provides event information 408 directly or via event queue 130 to the security layer 120, as described above. Figure 2 As described.

[0042] In response to event information 408 conforming to a specified security protocol, security layer 120 stores event control information 444 for the event at VMSA region 442. In some embodiments, when information is stored in memory 110, event control information 444 is automatically encrypted by the hardware of processor 101. Furthermore, security layer 120 signals the event along with event information 408 to event interface 109. In response, event interface 109 accesses the event control information 444 at VMSA region 442 and processes the event based on the event control information 444 and event information 408. Therefore, in Figure 4In the example, the administrator 105 is restricted from accessing event control information that manages which events are processed and how they are processed, thereby protecting the visitor 104 from malicious administrators.

[0043] Figure 5 A flowchart of a method 500 for operating a processor in an alternating injection mode according to some embodiments is shown. Method 500 relates to... Figure 1 An example implementation of the processing system 100 is described below. At block 502, the hypervisor 105 receives an indication of an event from hardware resources, such as I / O control module 107. In response, at block 504, the hypervisor 105 indicates the event to security layer 120. In some implementations, security layer 120 is in restricted injection mode and, in response to the event indication, retrieves event handling information for the event from event queue 130. Security layer 120 determines whether the event handling information matches a specified security protocol, and if not, blocks further processing of the event. If the event handling information conforms to the security protocol, the method proceeds to block 506.

[0044] At box 506, the security layer 120 of visitor 104 stores event control data (such as task priority level (TPR)) as event control information 444 at VMSA area 442 of memory 110. Before or during the stored procedure, the security layer 120 encrypts the event control information 444 with a key associated with visitor 104, wherein the key is unknown and inaccessible to the management program 105.

[0045] At box 508, the security layer 120 of visitor 104 indicates to the non-security layer 132 via event interface 109 that event information 408 is ready for processing. In response, event interface 109 retrieves encrypted event control information 444 from VMSA 442, decrypts the information, and uses the decrypted event control information 444 to process the event using a standard event processing protocol.

[0046] In some implementations, certain aspects of the techniques described above may be implemented by one or more processors of a processing system executing software. The software includes one or more sets of executable instructions stored or otherwise tangibly embodied on a non-transitory computer-readable storage medium. The software may include instructions and certain data that, when executed by one or more processors, manipulate the one or more processors to perform one or more aspects of the techniques described above. The non-transitory computer-readable storage medium may include, for example, disk or optical disk storage devices, solid-state storage devices such as flash memory, caches, random access memory (RAM), or one or more other non-volatile memory devices. The executable instructions stored on the non-transitory computer-readable storage medium may be source code, assembly language code, object code, or other instruction formats that are interpreted or otherwise executed by one or more processors.

[0047] It should be noted that not all activities or elements described in the general description above are required. A particular activity or apparatus may be unnecessary and may perform one or more other activities, or may include elements other than those described. Furthermore, the order in which the activities are listed is not necessarily the order in which they are performed. Additionally, the corresponding concepts have been described with reference to specific embodiments. However, those skilled in the art will understand that various modifications and changes can be made without departing from the scope of this disclosure as set forth in the appended claims. Therefore, this specification and drawings are to be regarded as illustrative rather than restrictive, and all such modifications are intended to be included within the scope of this disclosure.

[0048] The benefits, other advantages, and solutions to the problems have been described above with reference to specific embodiments. However, the benefits, advantages, solutions to the problems, and any features that bring any benefit, advantage, or solution to the event or make it more prominent should not be construed as key, essential, or necessary features of any or all claims. Furthermore, the specific embodiments disclosed above are merely illustrative, as the disclosed subject matter can be modified and practiced in different but equivalent ways that will be readily apparent to those skilled in the art who benefit from the teachings herein. There is no intention to limit oneself to the details of the construction or design shown herein, except as described in the appended claims. Therefore, it is apparent that the specific embodiments disclosed above can be altered or modified, and all such changes are considered to be within the scope of the disclosed subject matter. Therefore, the protection sought herein is as set forth in the appended claims.

Claims

1. A method comprising: Receive instructions for processor events from the management program at the guest program; In response to receiving the instruction for the processor event, access the event handling information at the specified memory region; as well as The processor event is processed based on the event handling information, wherein: The visitor procedure includes a security layer and a non-security layer; as well as Receiving the indication for the processor event includes receiving the indication for the processor event at the security layer of the guest application; and The security layer will provide information to the non-security layer based on the processor events.

2. The method of claim 1, wherein: Access to event handling information includes the security layer accessing the event handling information.

3. The method of claim 1, wherein: Receiving the indication for the processor event includes receiving the indication for the processor event at the processor's event interface.

4. The method as claimed in any of the preceding claims, wherein: The designated memory region includes memory regions that are inaccessible to the management program.

5. The method of claim 4, wherein the designated memory region is an encrypted memory region.

6. The method of claim 4, wherein the event handling information includes Task Priority Register (TPR) information.

7. A processor comprising: A processor core configured to execute a guest program; A management program configured to provide the guest program with indications of processor events; as well as The guest program, configured to, in response to receiving the indication for the processor event, access event handling information in a specified memory region and process the processor event based on the event handling information, wherein the guest program includes a security layer and a non-security layer, the security layer being configured to receive the indication for the processor event; and The security layer will provide information to the non-security layer based on the processor events.

8. The processor of claim 7, wherein: The security layer is configured to access the event handling information.

9. The processor of claim 7, wherein: Receiving the indication for the processor event includes receiving the indication at the processor's event interface.

10. The processor as claimed in any one of claims 7-9, wherein: The designated memory region includes memory regions that are inaccessible to the management program.

11. The processor of claim 10, wherein the designated memory region is an encrypted memory region.

12. The processor of claim 11, wherein the event handling information includes Task Priority Register (TPR) information.

Images