Patent Description:
<CIT>) discloses a processing system including a processor that implements registers to define a state of a virtual machine (VM) running on the processor. The processor detects exit conditions of the VM. The processing system also includes a memory element to store contents of the registers in a first data structure that is isolated from a hypervisor of the VM in response to the processor detecting an exit condition. The VM is to selectively expose contents of a subset of the registers to the hypervisor. <CIT>) discloses a guest interrupt control unit in a hardware processor configured to detect that an interrupt has been recorded in a memory location corresponding to a virtual processor, wherein the interrupt is targeted at the virtual processor. In response to the virtual processor being active on the hardware processor, the guest interrupt control unit is configured to provide the interrupt to the guest that includes the virtual processor.

<FIG> illustrate techniques for protecting virtualized computing environments from a malicious hypervisor by restricting the hypervisor's access to one or more portions of an event (interrupt or exception) handling pathway of a guest virtual machine, wherein the guest virtual machine includes both a secure layer to manage security for the guest and one or more non-secure layers to handle event processing. For example, in some embodiments, the hypervisor is restricted from providing normal exception information to the guest virtual machine (referred to simply as a "guest" herein), and instead is only permitted 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 specified region of memory for the 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 specified security protocols.

In other embodiments, the hypervisor is restricted from accessing event control information, such as task priority register (TPR) information, that is used by the guest to determine whether and how events are processed. The event control information is stored at an encrypted region of memory that is not accessible by the hypervisor. In particular, in response to receiving an indication of an event from the hypervisor, the secure layer of the guest stores event control information for the event at the encrypted region of memory, and an event interface of the processor uses the event control information to ensure that the event complies with specified event protocols, such as by ensuring that event priority information complies with the TPR information stored at the encrypted region. If the event information does not comply with the specified protocols, the corresponding event is not processed. Because the hypervisor is unable to access the encrypted region of memory, the hypervisor is unable to use the event control information to exploit the guest.

In some embodiments, the hypervisor is restricted both from providing exception information to unsecure layers of the guest, and from accessing event control information for the guest. Instead, the hypervisor signals an event to the secure layer of the guest, which in response reviews the associated event information for compliance with security protocols. In response to the event information complying with the security protocols, the secure layer provides the event information to the non-secure layer for processing, and stores event control information for the event at the encrypted region of memory. The non-secure layer accesses the event control information at the encrypted region of memory and uses the event control information to process the event.

By restricting the hypervisor's access to one or more of the event queue and the event control information, the guest is protected from malicious hypervisor attacks. To illustrate via an example, in some cases the event handling pathway of a guest relies on specified assumptions about system hardware behavior, such as an assumption that the system hardware will not generate or signal an interrupt that has a priority lower than the priority set by the TPR. However, because the hypervisor provides a layer of abstraction between the guest and the system hardware in a virtualized computing environment, a malicious hypervisor is able to generate events that violate the specified assumptions of device behavior, such as by providing an interrupt to a guest operating system having a lower priority than the TPR-set priority. These events, that would otherwise be prohibited, render secure data and other aspects of the guest vulnerable to unauthorized access or manipulation. Using the techniques described herein, a malicious hypervisor is prevented from exploiting a guest in this way, thus improving system security. Further, as described herein, in some embodiments the techniques are implemented with an existing event interface of a processor that is designed to receive and process events, thereby reducing the amount of software or hardware redesign required to implement the techniques.

<FIG> illustrates a block diagram of a processing system <NUM> that restricts hypervisor access to portions of an event handling pathway in accordance with some embodiments. The processing system <NUM> is a system that generally executes sets of computer instructions (e.g., computer programs) to carry out tasks on behalf of an electronic device. Accordingly, in different embodiments the processing system <NUM> is part of an electronic device such as a desktop or laptop computer, a server, a smartphone, a tablet, a game console, and the like. For purposes of description, the processing system <NUM> is assumed to be part of a server implementing a virtualized computing environment.

To support execution of computer instructions, the processing system <NUM> includes a processor <NUM> and a memory <NUM>. The memory <NUM> 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 <NUM>. In particular, as the processor <NUM> executes instructions, data (including instructions and operand data) is written to and read from the memory <NUM>. It will be appreciated that while the memory <NUM> is illustrated as separate from the processor <NUM>, in some embodiments all or a portion of the memory <NUM> is a part of the processor <NUM> and is incorporated in the same semiconductor die or semiconductor package as the processor <NUM>.

The processor <NUM> is a processing device such a central processing unit (CPU) that includes one or more processor cores (e.g., processor core <NUM>) and supporting circuitry to execute computer instructions. While the processor <NUM> is illustrated with a single processor core for simplicity, it will be appreciated that in some embodiments the processor <NUM> includes multiple processor cores.

In the depicted example, the circuitry supporting execution of instructions includes an input/output (I/O) control module <NUM> that provides an interface to one or more input/output devices, such as a keyboard. In some embodiments, the processor <NUM> includes additional supporting circuitry, such as one or more network interfaces to interface with a computer or communications network, one or more memory controllers to interface with a memory subsystem of the processor <NUM>, and the like. In the course of executing their specified operations, the supporting circuitry generates conditions referred to herein as processor events (e.g., event <NUM>).

As used herein, a processor event refers to an interrupt or exception signaled by a hardware module of a processor. For example, in response to a user manipulating an input/output device, the I/O control module <NUM> signals an interrupt to allow the processor <NUM> to respond to the user manipulation. Circuitry invokes the event in order to trigger execution of an event handler, such as an interrupt handler or an exception handler, to process the event. For example, in response to a user input at a keyboard or other input device, the I/O control module <NUM> invokes an interrupt event to trigger an interrupt handler that processes the user input, such as by storing data based on the user input at a specified buffer (not shown).

In order to trigger an exception handler in response to events signaled by the I/O control module <NUM> or other circuitry, the processor <NUM> executes specified operations in a specified sequence using designated circuitry, such as designated event queues and the like. The operations, sequence, and circuitry used by the processor <NUM> to handle processor events are referred to herein as the event processing path of the processor <NUM>. To assist in handling events, the processor <NUM> includes an event interface <NUM>. In some embodiments, the event interface <NUM> is a module that complies with a specified event interface standard, such as either of the Advanced Programmable Interrupt Controller (APIC) or x2APIC standards. Thus, in some embodiments, the event interface <NUM> is a module that receives signals indicating a processor event, 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 the processor core <NUM>. In response, the processor core <NUM> invokes an event handler associated with the event. In particular, the processor core <NUM> 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.

As noted above, in a virtualized computing environment the event processing path provides a potential avenue of attack by malicious entities seeking unauthorized access to data or operations of the processor <NUM>. To protect against such attacks, when executing a virtualized computing environment, the processor <NUM> restricts the hypervisor's access to one or more portions of the event processing path.

To illustrate, in the example of <FIG> the processor <NUM> implements a virtualized computing environment by concurrently executing two virtual machines VM1 <NUM> and VM2 <NUM>, also referred to as guests <NUM> and <NUM>. Each of the guests <NUM> and <NUM> is a virtual machine including one or more computer programs, such as an operating system, application programs, and the like. In some embodiments, to provide security from unauthorized access or manipulation, the guests <NUM> and <NUM> include multiple layers, with each layer having specified access protections to prevent unauthorized access. For example, the guest <NUM> has multiple layers, including a secure layer <NUM> (designated virtual machine privilege level <NUM> (VMPL0)) that is protected from access and manipulation by software at other layers and a non-secure layer <NUM> that performs event processing for the guest <NUM>, such as execution of interrupt handlers, exception handlers, and the like. Thus, for example, in some embodiments the non-secure layer <NUM> is a VMPL3 layer that executes the operating system, but commands from the operating system to alter data or operations at the VMPL0 layer are ignored unless they match specified security protocols, thereby protecting the guest <NUM> from exploitation.

In other embodiments the secure layer <NUM> emulates a central processing unit (CPU) for an operating system located at the non-secure layer <NUM>, and the secure layer <NUM> performs both interrupt handling and APIC emulation for the non-secure layer <NUM>. This allows an operating system executing at the non-secure layer <NUM> to employ the event interface <NUM> as a standard APIC or x2APIC interface, with the secure layer <NUM> performing event handling as described further herein.

To support virtualization, the processor <NUM> includes a hypervisor <NUM> that provides an interface between the hardware resources of the processor <NUM> and the guests <NUM> and <NUM>. In particular, the guests <NUM> and <NUM> include standard device drivers and other interface software that generates hardware requests and other communications as if the guest were executing on a dedicated computer system. The hypervisor <NUM> receives the communications from the device drivers and other interface software and based on the communications manages provision of hardware resources to the guests <NUM> and <NUM>. The hypervisor <NUM> thus provides a layer between the guests <NUM> and <NUM> and the hardware resources of the processor <NUM> that abstracts the hardware resources so that the guests <NUM> and <NUM> can use standard hardware interface software designed for dedicated computer systems.

To further support virtualization, the hypervisor <NUM> handles at least some aspects of event processing. For example, in response to indication of an interrupt from the I/O control module <NUM>, the hypervisor <NUM> identifies the guest associated with the interrupt and signals the interrupt to the guest via the event interface <NUM>, along with any associated event handling information, such as an interrupt identifier, a priority level associated with the interrupt, and the like. Conventionally, the hypervisor injects the event hardware information directly into the guest using the event interface <NUM>, and the guest employs the corresponding event handler to process the event based on the injected event handling information. However, as noted above, allowing the hypervisor to inject any event handling information via the event interface <NUM>, or other portion of the event handling path, provides a potential avenue of attack for a malicious hypervisor. Accordingly, the processor <NUM> restricts the hypervisor from accessing one or more portions of the event processing path.

To illustrate, each layer of the guests <NUM> and <NUM> is individually operable in either of two different modes, designated a Restricted Injection Mode and an Alternate Injection Mode. These modes will be described with respect to their implementation at the guest <NUM>, but it will be appreciated that guest <NUM> operates in a similar fashion. In the Restricted Injection Mode, the hypervisor <NUM> is not permitted to provide event handling information directly to a non-secure layer of the guest. Instead, the hypervisor <NUM> signals the occurrence of an event, via the event interface <NUM>, to the secure layer <NUM> of the guest <NUM> and stores the event handling information for the event at an event queue <NUM> stored at the memory <NUM>. In some embodiments, the event handling information includes one or more of: an indicator of the source of the event (e.g., the hardware module that triggered an interrupt), the type of the event (e.g., whether the event is an interrupt or an exception, the type of interrupt or exception, and the like), a priority level of the event, and the like.

In response to the event signal, the secure layer <NUM> invokes an exception handler to access the event handling information at the event queue <NUM>. Via the exception handler, the secure layer <NUM> determines if the event control information complies with specified security protocols and, if so, provides the event handling information to the non-secure layer <NUM> for normal processing. For example, in some embodiments the secure layer <NUM> determines whether the event handling information matches expected hardware behavior of the processor <NUM>. Thus, in some embodiments the secure layer <NUM> compares one or more of the event priority level, the event type, the event source, the event identifier, and the like, to corresponding specified ranges of values. If any of the event information is outside of the corresponding specified range, the secure layer <NUM> does not signal an event to the non-secure layer <NUM>, nor does the secure layer <NUM> provide the event handling information to the non-secure layer <NUM>. In some embodiments, the secure layer <NUM> takes additional remedial action, such as signaling a potential attempted security breach to a user or other computer system via a network, halting execution of the guest <NUM>, and the like.

If the event handling information complies with the specified security protocols, the secure layer <NUM> signals the event, with the event handling information, to the event interface <NUM>. In response, the event interface <NUM> notifies the non-secure layer <NUM> of the event and provides the event handling information to the non-secure layer <NUM>. The non-secure layer <NUM> then uses the event handling information to process the event, such as by invoking an exception handler for the event. Thus, the event handling information is first reviewed by the secure layer <NUM> before the information is allowed to be passed, via the event interface <NUM>, to the non-secure layer <NUM> for processing. Restricted Injection Mode is described further below with respect to <FIG> and <FIG>.

In the Alternate Injection Mode, a layer of the guest <NUM> (e.g., non-secure layer <NUM>) processes the event handling information using event control information <NUM>. The event control information <NUM> is information that controls the event interface <NUM>. For example, in some embodiments the event control information <NUM> includes task priority register (TPR) information that sets the priority level of events that are permitted to be processed. If an event provided by the hypervisor <NUM> has a priority level lower than the TPR information, the event is not processed, thereby protecting the guest <NUM> from a malicious attack.

In some embodiments, the event control information <NUM> is stored at an encrypted region of the memory <NUM>, wherein the data stored at the encrypted region is encrypted with a key associated with the guest <NUM>. The key is unknown to the hypervisor <NUM>, thereby preventing the hypervisor <NUM> from changing the event control information <NUM>, and further protecting the guest <NUM>. The Alternate Injection Mode is further described below with respect to <FIG> and <FIG>.

To set the security mode for the individual layers of the guests <NUM> and <NUM>, the processor core <NUM> includes a mode control register <NUM>. The mode control register <NUM> includes a plurality of fields, with each field setting the security mode for a corresponding guest level, thereby allowing the security mode for different guest levels to be set independently. Thus, for example, in some embodiments the secure layer <NUM> is in the Restricted Injection Mode concurrently with the non-secure layer <NUM> being in the Alternate Injection Mode. In some embodiments, the mode control register <NUM> is programmable only by a secure layer of a guest (e.g., secure layer <NUM>), and is not programmable by the hypervisor <NUM>, thereby further protecting the event processing path of the processor <NUM>. Further, in some embodiments the mode control register <NUM> does not permit both the Restricted Injection Mode and the Alternate Injection Mode to be in effect at the same time for the same guest layer.

In some embodiments, the security of the guest <NUM> is enhanced by placing the secure layer <NUM> in the Restricted Injection Mode and the non-secure layer <NUM> is placed in the Alternate Injection Mode. Under this arrangement, the hypervisor <NUM> signals an event (e.g., the event <NUM>) to the event interface <NUM> and stores the corresponding event handling information at the event queue <NUM>. In response to the event signal, the secure layer <NUM> (in the Restricted Injection Mode) retrieves the event handling information from the event queue <NUM> and determines if the event handling information complies with specified security protocols. If not, the secure layer <NUM> does not signal the event to the event interface <NUM>.

If the event handling information matches the security protocols, the secure layer <NUM> stores event control information for the event at the encrypted region of the memory <NUM>, as event control information <NUM>. The secure layer <NUM> provides the event handling information <NUM> to the event interface <NUM>. In response, and responsive to the non-secure layer <NUM> being in the Alternate Injection Mode, the event interface <NUM> accesses the event control information <NUM>, decrypts the event control information, and uses the decrypted control information and the event handling information to process the event, such as by requesting the non-secure layer <NUM> to execute an event handler (e.g., an interrupt or exception handler) associated with the event. Thus, the event handling is managed via the standard interface provided by the event interface <NUM>, but is invoked by the secure layer <NUM>, rather than directly by the hypervisor <NUM>. This allows the non-secure layer <NUM> to handle and respond to events in a standard way, without requiring redesign of the software executing at the non-secure layer <NUM> or of the event interface <NUM>.

<FIG> illustrates an example of event processing in the Restricted Injection Mode at the processor <NUM> in accordance with some embodiments. In the illustrated example, the virtual machine <NUM> includes two layers: the secure layer <NUM> and the non-secure layer <NUM>. As described above, the secure layer <NUM> is a secure portion of the guest <NUM> that is protected from modification by the non-secure layer <NUM>, by the hypervisor <NUM>, and by other non-secure entities. The non-secure layer <NUM> is a layer of the guest <NUM> that executes the guest operating system and other programs, and is generally accessible by other entities, such as other programs or layers of the guest <NUM>.

In operation, the hypervisor <NUM> receives an indication of an event (an interrupt or exception). The indication further includes event information, such as the type of event, an indicator of the guest to which the event is directed, and the like. In response to the indication of the event, the hypervisor <NUM> generates additional event information, such as an identifier of the device that generated the event, a priority level of the event, and the like. The hypervisor <NUM> stores the event handling information <NUM> at the event queue <NUM> stored at the memory <NUM>.

In addition, in response to the event, the hypervisor provides an event signal <NUM> to the event interface <NUM>. In some embodiments, the event signal <NUM> is a simple exception signal (e.g., an x86 exception signal) that does not include the event handling information <NUM> or any indication of the type or source of the event, but instead only signals that an event has occurred. In response to the event signal <NUM>, the event interface notifies the guest <NUM>. In response, the secure layer <NUM> executes an event handler to access the event queue <NUM> at the memory <NUM> to retrieve the event handling information <NUM>. In some embodiments, the secure layer <NUM> reviews the event handling information <NUM> for compliance with specified security protocols, such as ensuring that the source and type of event are of an expected source and type, that a priority level of the event complies with TPR information, and the like. If the event handling information <NUM> fails to comply with the security protocols, the secure layer <NUM> does not signal the event to the event interface <NUM> for processing, thereby protecting the guest <NUM> from a potential attack. In response to the event handling information <NUM> complying with the security protocols, the secure layer <NUM> signals the event to the event interface <NUM> for normal event processing.

Thus, as shown by the above example, in the Restricted Injection Mode the hypervisor <NUM> is restricted from communicating event information to the non-secure layer <NUM> directly. Instead, the hypervisor <NUM> provides relatively simple indications of events to the secure layer <NUM> and provides event information via an event queue that is accessible only by the secure layer <NUM> of the guest <NUM>. The non-secure layer <NUM> is thereby protected from a malicious hypervisor providing event information directly to the non-secure layer <NUM> and potentially accessing secure information or otherwise manipulating the guest <NUM>.

<FIG> is a flow diagram of a method <NUM> of operating a guest layer in the Restricted Injection Mode in accordance with some embodiments. For purposes of description, the method <NUM> is described with respect to an example implementation at the processing system <NUM> of <FIG>. At block <NUM>, the hypervisor <NUM> receives an indication of a processor event from a hardware resource of the processor <NUM>, such as from the I/O control module <NUM>. In response, the hypervisor <NUM> determines event information associated with the event, such as the resource that generated the event, the guest to which the event is directed, a priority level associated with the event, and the like. At block <NUM>, the hypervisor <NUM> stores the event information at the event queue <NUM>, located at the memory <NUM>.

At block <NUM>, the hypervisor <NUM> provides a signal to the event interface <NUM>, indicating the occurrence of an event, wherein the signal indicates the guest to which the event is targeted. Thus, if the event is targeted to the guest <NUM>, the hypervisor <NUM> provides a signal indicating the event to the event interface <NUM>. In some embodiments, the event interface ignores any event information provided by the hypervisor <NUM> with the signal. Thus, the signal acts only as a "doorbell", indicating to the guest that an event has occurred, without any associated event information.

At block <NUM>, in response to the signal from the hypervisor <NUM>, the event interface <NUM> notifies the secure layer of the event. In response, the secure layer <NUM> accesses the event queue <NUM> and retrieves the event information. If the event information complies with event security protocols, the secure layer <NUM> provides the event information to the non-secure layer <NUM>, such as by indicating the event to the event interface <NUM> of the processor <NUM>. The non-secure layer <NUM> executes an exception handler to process the event. If the event information does not comply with security protocols, the secure layer <NUM> does not signal the event to the event interface <NUM>, and the event is therefore not processed, thereby protecting the guest <NUM> from exploitation.

<FIG> illustrates an example of event processing in the Alternate Injection Mode at the processor <NUM> in accordance with some embodiments. In the illustrated example, similar to the example of <FIG>, the virtual machine <NUM> includes two layers: the secure layer <NUM> and the non-secure layer <NUM>. As described above, the secure layer <NUM> is a secure portion of the guest <NUM> that is protected from modification by the non-secure layer <NUM>, by the hypervisor <NUM>, and by other non-secure entities. As in the example of <FIG>, the non-secure layer <NUM> is a layer of the guest <NUM> that executes the guest operating system and other programs and is generally accessible by other programs or layers of the guest <NUM>.

In addition, in the illustrated example the memory <NUM> includes an encrypted region, designated Virtual Machine State Area (VMSA) region <NUM>. The VMSA region <NUM> stores data encrypted with a key that is uniquely associated with the guest <NUM>. In some embodiments, the key is available for use only by the secure layer <NUM> and is not available for use by the hypervisor <NUM>. The secure layer <NUM> thus manages all accesses to the VMSA region <NUM>. In particular, the secure layer <NUM> manages writing and reading of data to and from the VMSA region <NUM> by encrypting and decrypting data for writing and reading, respectively, using the guest-specific key. In some embodiments, the encrypting and decrypting of data is implemented by dedicated hardware (not shown) of the processor <NUM> at the request of the secure layer <NUM>. The guest-specific key is unknown and inaccessible to the hypervisor <NUM>, and the data stored at the VMSA region <NUM> is therefore inaccessible to the hypervisor <NUM>.

The VMSA region <NUM> stores event control information <NUM> that governs one or more of what events are processed by the guest <NUM> and how those events are processed. For example, in some embodiments the event control information <NUM> stores TPR information that indicates the minimum priority level of events that are permitted to be processed by an operating system of the guest <NUM>. The operating system sets the TPR level, according to conventional operating system protocols, and indicates the TPR level to the secure layer <NUM>, which stores the TPR level at the event control information <NUM> as described further below.

In operation, the hypervisor <NUM> receives an indication of an event from a hardware resource such as the I/O control module <NUM>. In response, the hypervisor <NUM> determines event information <NUM> associated with the event. As noted above, the event information <NUM> includes information such as a priority level associated with the event, the hardware resource that generated the event, the type of event, and the like. The hypervisor <NUM> provides the event information <NUM> to the secure layer <NUM>, either directly or via the event queue <NUM> as described above with respect to <FIG>.

In response to the event information <NUM> complying with specified security protocols, the secure layer <NUM> stores event control information <NUM> for the event at the VMSA region <NUM>. In some embodiments, the event control information <NUM> is automatically encrypted by hardware of the processor <NUM> as the information is stored at the memory <NUM>. In addition, the secure layer <NUM> signals the event to the event interface <NUM> along with the event information <NUM>. In response, the event interface <NUM> accesses the event control information <NUM> at the VMSA region <NUM> and processes the event based on the event control information <NUM> and the event information <NUM>. Thus, in the example of <FIG>, the hypervisor <NUM> is restricted from accessing event control information that governs which events are processed and how they are processed, thereby protecting the guest <NUM> from a malicious hypervisor.

<FIG> illustrates a flow diagram of a method <NUM> of operating a processor in the Alternate Injection Mode in accordance with some embodiments. The method <NUM> is described with respect to an example implementation at the processing system <NUM> of <FIG>. At block <NUM>, the hypervisor <NUM> receives an indication of an event from a hardware resource such as the I/O control module <NUM>. In response, at block <NUM>, the hypervisor <NUM> indicates the event to the secure layer <NUM>. In some embodiments, the secure layer <NUM> is in the Restricted Injection Mode and, in response to the event indication, retrieves event handling information for the event from the event queue <NUM>. The secure layer <NUM> determines if the event handling information matches specified security protocols and, if not, prevents further processing of the event. If the event handling information complies with the security protocols, the method proceeds to block <NUM>.

At block <NUM>, the secure layer <NUM> of the guest <NUM> stores event control data, such as a task priority level (TPR) as event control information <NUM> at the VMSA region <NUM> of the memory <NUM>. Prior to or during the storage process, the secure layer <NUM> encrypts the event control information <NUM> with a key associated with the guest <NUM>, wherein the key is unknown and inaccessible to the hypervisor <NUM>.

At block <NUM>, the secure layer <NUM> of the guest <NUM> indicates, via the event interface <NUM> to the non-secure layer <NUM> that the event information <NUM> is ready to be processed. In response, the event interface <NUM> retrieves the encrypted event control information <NUM> from the VMSA <NUM>, decrypts the information, and uses the decrypted event control information <NUM> to process the event using a standard event processing protocol.

The software includes one or more sets of executable instructions stored or otherwise tangibly embodied on a non-transitory computer readable storage medium.

Claim 1:
A method, comprising:
receiving, at a guest program (<NUM>), an indication of a processor event (<NUM>) from a hypervisor (<NUM>);
in response to receiving the indication of the processor event, accessing event handling information at a specified region of memory; and
processing the processor event based on the event handling information,
wherein the guest program (<NUM>) comprises a secure layer (<NUM>) and a non-secure layer (<NUM>), and receiving the indication of the processor event (<NUM>) comprises receiving the indication of the processor event at the secure layer (<NUM>) of the guest program; and
wherein the secure layer (<NUM>) provides the event handling information to the non-secure layer (<NUM>) only when the event handling information complies with specified security protocols.