Method and system for injecting function calls into a virtual machine

• US 9,003,402 B1
• Filed: 12/15/2010
• Issued: 04/07/2015
• Est. Priority Date: 12/15/2010
• Status: Active Grant

• Current Assignee: CA, Inc. (d/b/a CA Technologies) (Broadcom, Inc.)
• Original Assignee: Symantec Corporation (NortonLifeLock Inc.)
• Inventors: Carbone, Martim, Conover, Matthew, Montague, Bruce Robert
• Primary Examiner(s): Wai, Eric C
• Application Number:
  US12/969,334
• Time in Patent Office: 1,574 Days
• US Class Current: 718/1
• CPC Class Codes: G06F 2009/45587 Isolation or security of virtual machine instances
• CPC Class Codes: G06F 9/4484 Executing subprograms
• CPC Class Codes: G06F 9/45554 Instruction set architectures of guest OS and hypervisor or native processor differ, e.g. Bochs or VirtualPC on PowerPC MacOS
• CPC Class Codes: G06F 9/45558 Hypervisor-specific management and integration aspects

Abstract

A method and apparatus for injecting function calls into a virtual machine whereby a Function Call Injection (FCI) process is employed, through which a Secure Virtual Machine (SVM) is used to trigger desired function call invocations inside a Guest Virtual Machine (GVM) by externally manipulating the GVMs memory and CPU register contents using a security API. Once the triggered function is executed, control is then returned at the originating SVM invocation point. Therefore, the GVM state is manipulated to externally inject function calls, making it possible to create control appliances which do not require an in-GVM agent.

Claims

1. A computing system implemented process for injecting function calls into a virtual machine comprising:

implementing a Guest Virtual Machine (GVM) on a host computing system, the GVM including associated CPU registers and at least one memory stack associated with at least one thread implemented, at least in part, by the GVM;

implementing a hypervisor on the host computing system under the control of at least one processor associated with the host computing system;

implementing a Security Virtual Machine (SVM) on the host computing system;

implementing a security API on the host computing system under the control of at least one processor associated with the host computing system, the security API providing a hypercall interface between the hypervisor, the SVM, and the GVM;

defining a SVM invocation point;

suspending a state of the GVM at the SVM invocation point;

saving the state of the GVM at the SVM invocation point;

while the state of the GVM is suspended, using the SVM and the security API to modify the CPU registers and/or the contents of at least one memory stack associated with at least one thread implemented, at least in part, by the GVM to trigger a desired function call invocation when the GVM is resumed, wherein a return address of the desired function call is initially set to a memory location in an active code segment that has no actual code and a hypervisor-enabled execution breakpoint is placed in the memory location;

resuming the GVM;

executing the desired function call in the same manner as the desired function call would be executed if the desired function call had been invoked by the GVM;

suspending the state of the GVM when the function call return address occurs;

restoring the saved GVM state at the SVM invocation point; and

resuming execution of the GVM at the SVM invocation point.

2. The computing system implemented process for injecting function calls into a virtual machine of claim 1, wherein:

the security API is configured to facilitate changes to the GVM without making changes to the hypervisor.

3. The computing system implemented process for injecting function calls into a virtual machine of claim 1, wherein:

the state of the GVM is suspended by generating a hypervisor-enabled execution breakpoint that requires no modifications inside the GVM, the hypervisor-enabled execution breakpoint being inserted at a pre-selected GVM code location, such that whenever that code is executed, a trap to the SVM occurs.

4. The computing system implemented process for injecting function calls into a virtual machine of claim 3, wherein:

the CPU registers modified include the Extended Pointer Register (EIP) and the Extended Stack Pointer Register (ESP).

5. The computing system implemented process for injecting function calls into a virtual machine of claim 4, wherein, once the trap to the SVM occurs:

the SVM initially saves a context of an interrupted GVM thread;

the SVM then sets the GVM'"'"'s Extended Instruction Pointer (EIP) register to the address of the desired function; and

the Extended Stack Pointer (ESP) is subtracted so that room can be made in the GVM stack for the arguments to be passed to the desired function and the return address.

6. The computing system implemented process for injecting function calls into a virtual machine of claim 1, wherein:

the return address of the desired function call is set to the hypervisor-enabled execution breakpoint such that when the desired function finishes executing, a final Return (RET) instruction transfers control to the memory location, suspending the GVM and trapping into the SVM.

7. The computing system implemented process for injecting function calls into a virtual machine of claim 1, wherein:

the SVM retrieves scalar results associated with the desired function by reading a value stored in an EAX register and the SVM retrieves other additional output parameters of the desired function directly from a memory associated with the GVM.

8. A system for injecting function calls into a virtual machine comprising:

a host computing system;

a Guest Virtual Machine (GVM) implemented on the host computing system, the GVM including associated CPU registers and at least one memory stack associated with at least one thread implemented, at least in part, by the GVM;

a hypervisor implemented on the host computing system;

a Security Virtual Machine (SVM) implemented on the host computing system;

a security API implemented on the host computing system, the security API providing a hypercall interface between the hypervisor, the SVM, and the GVM;

a processor associated with the host computing system, the processor associated with the host computing system implementing at least part of a process for injecting function calls into a virtual machine, the process for injecting function calls into a virtual machine comprising;

defining a SVM invocation point;

suspending a state of the GVM at the SVM invocation point;

saving the state of the GVM at the SVM invocation point;

while the state of the GVM is suspended, using the SVM and the security API to modify the CPU registers and/or the contents of at least one memory stack associated with at least one thread implemented, at least in part, by the GVM to trigger a desired function call invocation when the GVM is resumed, wherein a return address of the desired function call is initially set to a memory location in an active code segment that has no actual code and a hypervisor-enabled execution breakpoint is placed in the memory location;

resuming the GVM;

executing the desired function call in the same manner as the desired function call would be executed if the desired function call had been invoked by the GVM;

suspending the state of the GVM when the function call return address occurs;

restoring the saved GVM state at the SVM invocation point; and

resuming execution of the GVM at the SVM invocation point.

9. The system for injecting function calls into a virtual machine of claim 8, wherein:

the security API is configured to facilitate changes to the GVM without making changes to the hypervisor.

10. The system for injecting function calls into a virtual machine of claim 8, wherein:

the state of the GVM is suspended by generating a hypervisor-enabled execution breakpoint that requires no modifications inside the GVM, the hypervisor-enabled execution breakpoint being inserted at a pre-selected GVM code location, such that whenever that code is executed, a trap to the SVM occurs.

11. The system for injecting function calls into a virtual machine of claim 10, wherein:

the CPU registers modified include the Extended Pointer Register (EIP) and the Extended Stack Pointer Register (ESP).

12. The system for injecting function calls into a virtual machine of claim 11, wherein, once the trap to the SVM occurs:

the SVM initially saves a context of an interrupted GVM thread;

the SVM then sets the GVM'"'"'s Extended Instruction Pointer (EIP) register to the address of the desired function; and

the Extended Stack Pointer (ESP) is subtracted so that room can be made in the GVM stack for the arguments to be passed to the desired function and the return address.

13. The system for injecting function calls into a virtual machine of claim 8, wherein:

the return address of the desired function call is set to the hypervisor-enabled execution breakpoint such that when the desired function finishes executing, a final Return (RET) instruction transfers control to the memory location, suspending the GVM and trapping into the SVM.

14. The system for injecting function calls into a virtual machine of claim 8, wherein:

the SVM retrieves scalar results associated with the desired function by reading a value stored in an EAX register and the SVM retrieves other additional output parameters of the desired function directly from a memory associated with the GVM.

15. A method for injecting function calls into a virtual machine comprising:

implementing a Guest Virtual Machine (GVM) on a host computing system, the GVM including associated CPU registers and at least one memory stack associated with at least one thread implemented, at least in part, by the GVM;

implementing a hypervisor on the host computing system;

implementing a Security Virtual Machine (SVM) on the host computing system;

implementing a security API on the host computing system, the security API providing a hypercall interface between the hypervisor, the SVM, and the GVM;

defining a SVM invocation point;

suspending a state of the GVM at the SVM invocation point;

saving the state of the GVM at the SVM invocation point;

while the state of the GVM is suspended, using the SVM and the security API to modify the CPU registers and/or the contents of at least one memory stack associated with at least one thread implemented, at least in part, by the GVM to trigger a desired function call invocation when the GVM is resumed, wherein a return address of the desired function call is initially set to a memory location in an active code segment that has no actual code and a hypervisor-enabled execution breakpoint is placed in the memory location;

resuming the GVM;

executing the desired function call in the same manner as the desired function call would be executed if the desired function call had been invoked by the GVM;

suspending the state of the GVM when the function call return address occurs;

restoring the saved GVM state at the SVM invocation point; and

resuming execution of the GVM at the SVM invocation point.

16. The method for injecting function calls into a virtual machine of claim 15, wherein:

the security API is configured to facilitate changes to the GVM without making changes to the hypervisor.

17. The method for injecting function calls into a virtual machine of claim 15, wherein:

the state of the GVM is suspended by generating a hypervisor-enabled execution breakpoint that requires no modifications inside the GVM, the hypervisor-enabled execution breakpoint being inserted at a pre-selected GVM code location, such that whenever that code is executed, a trap to the SVM occurs.

18. The method for injecting function calls into a virtual machine of claim 17, wherein:

the CPU registers modified include the Extended Pointer Register (EIP) and the Extended Stack Pointer Register (ESP).

19. The method for injecting function calls into a virtual machine of claim 18, wherein, once the trap to the SVM occurs:

the SVM initially saves a context of an interrupted GVM thread;

the SVM then sets the GVM'"'"'s Extended Instruction Pointer (EIP) register to the address of the desired function; and

the Extended Stack Pointer (ESP) is subtracted so that room can be made in the GVM stack for the arguments to be passed to the desired function and the return address.

20. The method for injecting function calls into a virtual machine of claim 15, wherein:

the return address of the desired function call is set to the hypervisor-enabled execution breakpoint such that when the desired function finishes executing, a final Return (RET) instruction transfers control to the memory location, suspending the GVM and trapping into the SVM.