CN107450962B - Exception handling method, device and system in virtualized operation environment - Google Patents

Exception handling method, device and system in virtualized operation environment Download PDF

Info

Publication number
CN107450962B
CN107450962B CN201710554394.9A CN201710554394A CN107450962B CN 107450962 B CN107450962 B CN 107450962B CN 201710554394 A CN201710554394 A CN 201710554394A CN 107450962 B CN107450962 B CN 107450962B
Authority
CN
China
Prior art keywords
guest
virtual machine
exception
kernel code
generated
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201710554394.9A
Other languages
Chinese (zh)
Other versions
CN107450962A (en
Inventor
邱学强
张朝鹏
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Coretek Systems Technology Co ltd
Kyland Technology Co Ltd
Original Assignee
Beijing Coretek Systems Technology Co ltd
Kyland Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Coretek Systems Technology Co ltd, Kyland Technology Co Ltd filed Critical Beijing Coretek Systems Technology Co ltd
Priority to CN201710554394.9A priority Critical patent/CN107450962B/en
Publication of CN107450962A publication Critical patent/CN107450962A/en
Application granted granted Critical
Publication of CN107450962B publication Critical patent/CN107450962B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45587Isolation or security of virtual machine instances
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45591Monitoring or debugging support

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Storage Device Security (AREA)

Abstract

The application relates to the technical field of industrial internet operating systems, in particular to an exception handling method, device and system in a virtualization operation environment, which are used for solving the problem that Guest OS running in the virtualization environment in the prior art is poor in robustness; the exception handling method in the virtualized operating environment provided by the embodiment of the application comprises the following steps: monitoring for anomalies by a Guest OS running on a virtual machine; if the abnormity is determined to be generated by the out-of-limit operation of the Guest OS on the kernel code with limited operation authority in the virtual machine according to the acquired abnormal context information, the out-of-limit operation of the Guest OS on the kernel code is rejected, wherein the operation authority of the Guest OS on the kernel code can be increased for the important kernel code in the virtual machine, so that a layer of security protection is added on the kernel code in the virtual machine, and the security of the running environment of the virtual machine can be effectively improved by the protection on the kernel code, so that the robustness of the Guest OS running in the virtual machine can be enhanced.

Description

Exception handling method, device and system in virtualized operation environment
Technical Field
The application relates to the technical field of industrial internet operating systems, in particular to an exception handling method, device and system in a virtualized operating environment.
Background
The virtualization technology is to abstract hardware resources of a physical Machine, such as a server and a memory, for a user to use, and the core of the virtualization technology is to construct a Virtual Machine Manager (VMM) on the physical Machine, and then create a plurality of Virtual Machines (VMs) on the VMM, so that only one Guest Operating System (Guest OS) can be originally run on the physical Machine, and the Virtual machines can run in parallel in the VMs after virtualization, thereby maximally utilizing the hardware resources of the physical Machine.
In the prior art, the VMM monitors the running process of the Guest OS, and delivers the monitored exception generated in the running process of the Guest OS to an exception handling module deployed in the Guest OS for handling, where the exception handled by the exception handling module is, for example, an exception generated by a zero-removing operation, a page fault exception, an illegal instruction exception, and the like, and the exceptions are generated by a software design error in the Guest OS. For a VM providing a virtualized operating environment for a Guest OS, ensuring the security of kernel codes in the VM is a precondition that the Guest OS and an exception handling module can work normally. At present, the security of kernel codes in a VM is only protected by an operating system running on the VM, such as Windows, and under normal conditions, a Guest OS cannot access important kernel codes in the VM, and once the security of the operating system is breached, the important kernel codes in the VM are easily tampered with maliciously, which may cause that the Guest OS cannot run normally and may paralyze the Guest OS when the Guest OS is serious, and the Guest OS is already located at a user application level in a virtualization technology, so that it is very important for clients and merchants providing the Guest OS to run robustly.
Therefore, the Guest OS running in the virtualization environment in the prior art has the problem of poor robustness.
Disclosure of Invention
The embodiment of the application provides an exception handling method, device and system in a virtualization running environment, which are used for solving the problem that Guest OS running in the virtualization environment in the prior art is poor in robustness.
An exception handling method in a virtualized operating environment provided in an embodiment of the present application includes:
monitoring an exception generated by a Guest operating system Guest OS running on a virtual machine;
and if the abnormity is determined to be generated by the out-of-limit operation of the Guest OS on the kernel code with limited operation authority in the virtual machine according to the acquired abnormal context information, rejecting the out-of-limit operation of the Guest OS on the kernel code.
Optionally, it is determined that the exception is caused by an out-of-limit operation of the Guest OS on kernel code in the virtual machine whose operation authority is limited, according to the following steps:
acquiring a memory page fault address in the abnormal context information;
and if the memory page fault address is contained in an address field corresponding to a pre-stored kernel code with limited operation authority and the Guest OS has access authority to the kernel code in the address field, determining that the exception is generated by the out-of-limit operation of the Guest OS to the kernel code with limited operation authority in the virtual machine.
Optionally, denying the Guest OS of the out-of-limit operation on the kernel code, comprising:
judging whether an exception handling function customized by a user exists;
if yes, calling the exception handling function to handle the out-of-limit operation;
otherwise, rejecting the operation instruction executed by Guest OS when the abnormity occurs; the operation instruction is obtained from the context information of the exception.
Optionally, the method further comprises:
and monitoring and processing secondary exceptions generated in the process of calling the exception handling function to handle the out-of-limit operation.
An exception handling apparatus in a virtualized operating environment provided in an embodiment of the present application includes:
the monitoring module is used for monitoring the abnormity generated by a Guest operating system Guest OS running on the virtual machine;
and the processing module is used for refusing the out-of-limit operation of the Guest OS on the kernel code if the exception is determined to be generated by the out-of-limit operation of the Guest OS on the kernel code with limited operation authority in the virtual machine according to the acquired context information of the exception.
The monitoring module is used for monitoring the abnormity generated by a Guest operating system Guest OS running on the virtual machine;
and the processing module is used for refusing the out-of-limit operation of the Guest OS on the kernel code if the exception is determined to be generated by the out-of-limit operation of the Guest OS on the kernel code with limited operation authority in the virtual machine according to the acquired context information of the exception.
Optionally, the processing module is specifically configured to:
determining that the exception is caused by an out-of-limit operation of a Guest OS on kernel code in a virtual machine with restricted operating permissions according to the following steps:
acquiring a memory page fault address in the abnormal context information;
and if the memory page fault address is contained in an address field corresponding to a pre-stored kernel code with limited operation authority and the Guest OS has access authority to the kernel code in the address field, determining that the exception is generated by the out-of-limit operation of the Guest OS to the kernel code with limited operation authority in the virtual machine.
Optionally, the processing module is specifically configured to:
judging whether an exception handling function customized by a user exists;
if yes, calling the exception handling function to handle the out-of-limit operation;
otherwise, rejecting the operation instruction executed by Guest OS when the abnormity occurs; the operation instruction is obtained from the context information of the exception.
Optionally, the monitoring module is further configured to monitor a secondary exception generated in a process of calling the exception handling function to handle the out-of-limit operation;
and the processing module is also used for processing the secondary exception.
An exception handling system in a virtualized operating environment provided in an embodiment of the present application includes: the system comprises a virtual machine manager, at least one first virtual machine and a second virtual machine used for carrying out security protection on the at least one first virtual machine, wherein:
the virtual machine manager is used for monitoring each first virtual machine for the abnormity generated by a Guest operating system Guest OS running on the first virtual machine; sending the acquired abnormal context information to the second virtual machine;
the second virtual machine is used for receiving the abnormal context information; and if the abnormality is determined to be generated by the out-of-limit operation of the Guest OS on the kernel code with limited operation authority in the first virtual machine according to the abnormal context information, rejecting the out-of-limit operation of the Guest OS on the kernel code.
Optionally, the second virtual machine is specifically configured to:
acquiring a memory page fault address in the abnormal context information;
if the memory page fault address is contained in an address field corresponding to a pre-stored kernel code with limited operation authority, and the Guest OS has access authority to the kernel code in the address field, determining that the exception is generated by the out-of-limit operation of the Guest OS to the kernel code with limited operation authority in the first virtual machine.
Optionally, the second virtual machine is specifically configured to:
judging whether an exception handling function customized by a user exists;
if yes, calling the exception handling function to handle the out-of-limit operation;
otherwise, rejecting the operation instruction executed by Guest OS when the abnormity occurs; the operation instruction is obtained from the context information of the exception.
Optionally, the virtual machine manager is further configured to:
and monitoring and processing secondary exceptions generated in the process of calling the exception handling function to handle the out-of-limit operation.
An electronic device provided in an embodiment of the present application includes at least one processing unit and at least one storage unit, where the storage unit stores program codes, and when the program codes are executed by the processing unit, the processing unit is caused to execute the steps of the exception handling method in the virtualized operating environment.
A computer-readable storage medium provided in an embodiment of the present application includes a program code, and when the program product runs on a computing device, the program code is configured to enable the electronic device to execute the steps of the exception handling method in the virtualized running environment.
In the embodiment of the application, an exception generated by a Guest OS running on a virtual machine is monitored, and if the exception is determined to be generated by the out-of-limit operation of the Guest OS on kernel codes with limited operation permission in the virtual machine according to the acquired context information of the exception, the out-of-limit operation of the Guest OS on the kernel codes is rejected. Compared with the prior art that the security protection is performed only by adopting an operating system running on a VM (virtual machine) for important kernel codes in the virtual machine, the operating authority of a Guest OS to the important kernel codes can be increased in the embodiment of the application, namely, one layer of security protection is additionally added to the kernel codes in the virtual machine, and the security protection of the kernel codes can effectively improve the security of the running environment of the virtual machine, so that the robustness of the Guest OS running in the virtual machine can be enhanced.
Drawings
The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description serve to explain the invention and not to limit the invention. In the drawings:
fig. 1 is a flowchart of an exception handling method in a virtualized operating environment according to an embodiment of the present application;
fig. 2 is a schematic diagram of an exception handling system in a virtualized operating environment according to an embodiment of the present application;
FIG. 3 is a schematic diagram of an exception handling system in a further virtualized operating environment according to an embodiment of the present application;
FIG. 4 is a flow diagram of a health management subsystem handling an exception according to an embodiment of the present application;
fig. 5 is a structural diagram of an exception handling apparatus in a virtualized operating environment according to an embodiment of the present application;
fig. 6 is a schematic hardware structure diagram of an exception handling apparatus in a virtualized operating environment according to an embodiment of the present application.
Detailed Description
In the embodiment of the application, an exception generated by a Guest OS running on a virtual machine is monitored, and if the exception is determined to be generated by the out-of-limit operation of the Guest OS on kernel codes with limited operation permission in the virtual machine according to the acquired context information of the exception, the out-of-limit operation of the Guest OS on the kernel codes is rejected. Compared with the prior art that the security protection is performed only by adopting an operating system running on a VM (virtual machine) for important kernel codes in the virtual machine, the operating authority of a Guest OS to the important kernel codes can be increased in the embodiment of the application, namely, one layer of security protection is additionally added to the kernel codes in the virtual machine, and the security protection of the kernel codes can effectively improve the security of the running environment of the virtual machine, so that the robustness of the Guest OS running in the virtual machine can be enhanced.
The preferred embodiments of the present invention will be described below with reference to the accompanying drawings of the specification, it being understood that the preferred embodiments described herein are merely for illustrating and explaining the present invention, and are not intended to limit the present invention, and that the embodiments and features of the embodiments in the present invention may be combined with each other without conflict.
Example one
As shown in fig. 1, a flowchart of an exception handling method in a virtualized operating environment provided in the embodiment of the present application includes the following steps:
s101: an exception generated by a Guest operating system Guest OS running on a virtual machine is monitored.
The exception generated by the Guest OS includes an exception generated by a software design error in the Guest OS, and also includes an exception generated by an illegal program performing operations such as tampering of kernel code in a virtual machine running the Guest OS.
S102: and if the abnormity is determined to be generated by the out-of-limit operation of the Guest OS on the kernel code with limited operation authority in the virtual machine according to the acquired abnormal context information, rejecting the out-of-limit operation of the Guest OS on the kernel code.
Optionally, after the exception is detected, context information of the exception may be obtained, where the context information includes an operation instruction when the exception occurs, an address of the operation instruction, a memory page fault address, pointer information in a task stack, and the like.
In practical application, because the operating system running on the VM already plays a certain safety protection role on the kernel code, under normal conditions, the Guest OS cannot access the important kernel code in the VM, and if the Guest OS performs out-of-limit operation on the important kernel code in the VM, it indicates that the operating system of the current VM cannot guarantee the safety of the kernel code, and the running environment of the VM may have potential safety hazards.
Specifically, a memory page fault address in the abnormal context information may be obtained, an address segment to which the memory page fault address belongs in the memory is determined according to a partition rule of the operating system on the address segment in the memory, if the address segment is a certain address segment corresponding to a kernel code with limited operating authority stored in the memory in advance and the Guest OS has access authority on the kernel code in the address segment, it is determined that a potential safety hazard exists in the operating environment of the VM, and the abnormality is generated by the out-of-limit operation of the Guest OS on the kernel code with limited operating authority in the virtual machine.
If the Guest OS has access right to the kernel code in the address field, it is indicated that the exception should not occur in the Guest OS, but the exception that occurs now can only be generated because the programmer sets access right in advance for the kernel code, so that it can be determined that the exception is generated by the out-of-limit operation of the Guest OS on the kernel code whose operation right is limited in the virtual machine.
Further, after the Guest OS determines that the operation of the kernel code is the out-of-limit operation, whether the exception has an exception handling function defined by a user in the system can be judged, and if the exception has the exception handling function defined by the user, the out-of-limit operation which generates the exception can be processed by calling the exception handling function defined by the user; otherwise, the operation instruction executed by the Guest OS when the exception is generated can be rejected; wherein the operation instruction is obtained from the context information of the exception.
For example, a user-defined exception handling function exists for an exception in the system, and the exception handling function, except for not responding to an operation instruction executed by a Guest OS when the exception occurs, can jump a page currently accessed by a user to a specified page instead of directly reporting an error to the user, so that the user experience is better; if the exception handling function customized by the user does not exist in the system for the exception, the operation instruction executed by Guest OS when the exception is generated can be directly rejected.
In addition, in the process, secondary exception generated in the process of calling the exception handling function customized by the user to handle the out-of-limit operation can be monitored and processed.
For example, when a stack overflow exception is generated in the process of calling an exception handling function customized by a user to handle an out-of-limit operation, at this time, a task for handling the out-of-limit operation may be suspended, or the task for handling the out-of-limit operation may be restarted to solve the stack overflow exception.
In a specific implementation process, if it is determined that the exception is not generated by the out-of-limit operation of the Guest OS on the kernel code of which the operation authority is limited in the virtual machine according to the acquired context information of the exception, the exception can be processed by an exception processing module in the Guest OS.
In the embodiment of the application, an exception generated by a Guest OS running on a virtual machine is monitored, and if the exception is determined to be generated by the out-of-limit operation of the Guest OS on kernel codes with limited operation permission in the virtual machine according to the acquired context information of the exception, the out-of-limit operation of the Guest OS on the kernel codes is rejected. Compared with the prior art that the security protection is performed only by adopting an operating system running on a VM (virtual machine) for important kernel codes in the virtual machine, the operating authority of a Guest OS to the important kernel codes can be increased in the embodiment of the application, namely, one layer of security protection is additionally added to the kernel codes in the virtual machine, and the security protection of the kernel codes can effectively improve the security of the running environment of the virtual machine, so that the robustness of the Guest OS running in the virtual machine can be enhanced.
Example two
As shown in fig. 2, a schematic diagram of an exception handling system 200 in a virtualized operating environment provided in the embodiment of the present application includes: hardware, a virtual machine manager 201, at least one first virtual machine 202, and a second virtual machine 203 for securing the at least one first virtual machine, wherein:
the virtual machine manager 201 is configured to monitor, for each first virtual machine 202, an exception generated by a Guest operating system Guest OS running on the first virtual machine, acquire context information of the exception, and then send the context information of the exception to a second virtual machine;
the second virtual machine 203 is configured to receive abnormal context information sent by the virtual machine manager; and if the abnormality is determined to be generated by the out-of-limit operation of the Guest OS on the kernel code with limited operation authority in the first virtual machine according to the abnormal context information, rejecting the out-of-limit operation of the Guest OS on the kernel code.
In a specific implementation process, the second virtual machine is specifically configured to: and acquiring a memory page fault address in the abnormal context information, and if the memory page fault address is contained in an address field corresponding to a pre-stored kernel code with limited operation authority and the Guest OS has access authority to the kernel code in the address field, determining that the abnormality is generated by the out-of-limit operation of the Guest OS to the kernel code with limited operation authority in the first virtual machine.
Further, the second virtual machine judges whether an exception handling function defined by a user exists or not, and if yes, the exception handling function is called to handle the out-of-limit operation; otherwise, rejecting the operation instruction executed by Guest OS when the abnormity occurs; the operation instruction is obtained from the context information of the exception.
In addition, the virtual machine manager is further configured to: and monitoring and processing secondary exceptions generated in the process of calling an exception handling function to handle the out-of-limit operation.
In the embodiment of the application, a virtual machine manager monitors the abnormality generated by a Guest operating system (Guest OS) running on each first virtual machine, and sends the acquired context information of the abnormality to a second virtual machine; after the second virtual machine receives the abnormal context information, if the abnormality is determined to be generated by the out-of-limit operation of the Guest OS on the kernel code with limited operation authority in the first virtual machine according to the abnormal context information, the out-of-limit operation of the Guest OS on the kernel code is refused. For the important kernel codes in the first virtual machine, compared with the prior art that only the operating system running on the VM is used for security protection, in the embodiment of the present application, a second virtual machine for security protection of each first virtual machine is further added, and the second virtual machine can control the operation permission of Guest OS to the important kernel codes in the first virtual machine, which is equivalent to adding one layer of security protection to the kernel codes in the first virtual machine, and the security protection to the kernel codes can effectively improve the security of the running environment of the first virtual machine, so that the robustness of the Guest OS running in the first virtual machine can be enhanced.
EXAMPLE III
As shown in fig. 3, a schematic diagram of an exception handling system 300 in a virtualized operating environment provided in the embodiment of the present application is shown, where a VMM virtualizes underlying hardware to form multiple VMs, the VMM includes a core health management module and an inter-domain communication management module, the core health management module is responsible for collecting abnormal context information at the first time and has a capability of handling a specific exception (an exception generated by a health management subsystem), and the inter-domain communication management module is responsible for communication among the multiple VMs; one of the VMs is a health monitoring virtual machine, the other VMs are Guest system virtual machines, a health management subsystem is operated in the health monitoring virtual machine, a Guest OS is operated in the Guest system virtual machine, an exception handling module is also included in the Guest OS, and the exception handling module handles exceptions, such as zero exception, illegal instruction exception and the like, which are generated due to software design errors in the operating process of the Guest OS.
In the specific implementation process, each Guest system virtual machine provides a virtualized operation environment for the Guest OS, an operating system on each Guest system virtual machine performs security protection on important kernel codes in the virtual machine to provide security guarantee for the Guest OS, but for any Guest system virtual machine, if the operating environment of the virtual machine cannot be secured, the normal operation of the Guest OS is difficult to guarantee, therefore, a health management subsystem is added in the health monitoring virtual machine, the health management subsystem can be arranged between the Guest system virtual machine and a VMM to provide another layer of security guarantee for each Guest system virtual machine, the anomalies generated by the Guest OS can be analyzed by the health management subsystem, if the health management subsystem determines that the anomalies are generated due to the out-of-limit operation of the Guest OS on the kernel codes with limited operation authority in the virtual machine, the out-of-limit operation of the Guest OS on the kernel code can be refused, so that the safety of the kernel code in the virtual machine is ensured, and the robustness of the Guest OS is ensured.
Specifically, as shown by the arrow in fig. 3, an exception generated in the Guest OS is first obtained by the CPU, the CPU then sends the exception to the core health management module in the VMM, the core health management module obtains the context information of the exception, and if the core health management module determines that the exception is generated by the health management subsystem according to the exception context information, the exception generated by the health management subsystem may be processed, for example, for a stack overflow exception generated in the process of processing the out-of-limit operation by the health management subsystem, the core health management module may suspend a task of processing the out-of-limit operation in the health management subsystem, or restart a task of processing the out-of-limit operation in the health management subsystem. If the core health management module determines that the abnormality is not generated by the health management subsystem according to the abnormal context information, the abnormal context information can be sent to the health management subsystem, further, the health management subsystem obtains a memory page fault address in the abnormal context information, if the memory page fault address is contained in an address field corresponding to a kernel code with limited operation authority which is stored in advance and the Guest OS has access authority to the kernel code in the address field, the abnormality is determined to be generated by the out-of-limit operation of the Guest OS on the kernel code with limited operation authority in the virtual machine, which indicates that the operating environment of the Guest OS has potential safety hazard, and the out-of-limit operation of the Guest OS on the kernel code can be refused at this time.
Optionally, when rejecting the out-of-limit operation of the Guest OS on the kernel code, the health management subsystem may determine whether a user-defined exception handling function exists, and if so, may call the user-defined exception handling function to handle the out-of-limit operation; otherwise, rejecting the operation instruction executed by Guest OS when the exception is generated.
In addition, in the specific implementation process, if the health management subsystem determines that the exception is not generated by the out-of-limit operation of the Guest OS on the kernel code with limited operation permission in the virtual machine, the inter-domain communication management module in the VMM may send the context information of the exception to the Guest OS generating the exception, and the exception is processed by the exception processing module in the Guest OS.
In a specific implementation, the health management subsystem may process the exception according to the flow shown in fig. 4:
s401: and receiving abnormal context information sent by the core health management module.
The abnormal context information is collected by a core health management module in the VMM at the first time after receiving the abnormality sent by the CPU, and the abnormal context information comprises an operation instruction when the abnormality is generated, an address of the operation instruction, a memory page fault address, pointer information in a task stack and the like.
S402: judging whether the received abnormity is generated by the out-of-limit operation of Guest OS on the kernel code with limited operation authority in the virtual machine, if so, entering S404; otherwise, the process proceeds to S403.
In a specific implementation process, the health management subsystem may obtain a memory page fault address in the abnormal context information, determine an address field to which the memory page fault address belongs according to a partition rule of an operating system on the address field, and if the address field is a certain address field corresponding to a kernel code with limited operation permission that is pre-stored, and a Guest OS has access permission for the kernel code in the address field, it indicates that the abnormality should not occur in the Guest OS, but the abnormality is generated because a programmer sets access permission for the kernel code in advance, and thus it may be determined that the abnormality is generated by an out-of-limit operation of the Guest OS on the kernel code with limited operation permission in the virtual machine.
S403: and delivering the exception context information to an exception handling module in Guest OS.
The abnormal context information can be delivered to an abnormal processing module in Guest OS through an inter-domain communication management module in VMM.
S404: judging whether an exception handling function customized by a user exists, if so, entering S405; otherwise, the process proceeds to S406.
S405: and calling an exception handling function customized by a user to handle the exception.
For example, for an exception handling function customized by a user in an exception system, the exception handling function may jump a page currently accessed by the user to a specified page without responding to an operation instruction executed by a Guest OS when an exception occurs, which is not directly guaranteed for the user and provides better user experience.
S406: operations performed on the virtual machine by the Guest OS when the exception is generated are rejected.
In addition, in the above process, the core health management module may also monitor and process a secondary exception generated by the health management subsystem in the process of calling the user-defined exception handling function to process the out-of-limit operation, for example, a stack overflow exception is generated by the health management subsystem in the process of calling the user-defined exception handling function to process the out-of-limit operation, at this time, the core health management module may suspend a task of processing the out-of-limit operation in the health management subsystem, or restart the task of processing the out-of-limit operation in the health management subsystem, so as to ensure that the health management subsystem can normally operate.
Example four
Based on the same inventive concept, the embodiment of the present application further provides an exception handling device in the virtualized operation environment corresponding to the exception handling method in the virtualized operation environment, and because the principle of solving the problem of the device is similar to the exception handling method in the virtualized operation environment in the embodiment of the present application, the implementation of the device may refer to the implementation of the method, and repeated details are not repeated.
As shown in fig. 5, a structure diagram of an exception handling apparatus in a virtualized operating environment according to an embodiment of the present application includes:
a monitoring module 501, configured to monitor an exception generated by a Guest operating system Guest OS running on a virtual machine;
the processing module 502 is configured to reject the out-of-limit operation of the Guest OS on the kernel code of the virtual machine if it is determined that the exception is generated by the out-of-limit operation of the Guest OS on the kernel code of which the operation authority is limited in the virtual machine according to the obtained context information of the exception.
Optionally, the processing module 502 is specifically configured to:
determining that the exception is caused by an out-of-limit operation of a Guest OS on kernel code in a virtual machine with restricted operating permissions according to the following steps:
acquiring a memory page fault address in the abnormal context information;
and if the memory page fault address is contained in an address field corresponding to a pre-stored kernel code with limited operation authority and the Guest OS has access authority to the kernel code in the address field, determining that the exception is generated by the out-of-limit operation of the Guest OS to the kernel code with limited operation authority in the virtual machine.
Optionally, the processing module 502 is specifically configured to:
judging whether an exception handling function customized by a user exists;
if yes, calling the exception handling function to handle the out-of-limit operation;
otherwise, rejecting the operation instruction executed by Guest OS when the abnormity occurs; the operation instruction is obtained from the context information of the exception.
Optionally, the monitoring module 501 is further configured to monitor a secondary exception generated in a process of calling the exception handling function to handle the out-of-limit operation;
the processing module 502 is further configured to process the secondary exception.
EXAMPLE five
As shown in fig. 6, a schematic hardware structure diagram of an exception handling apparatus in a virtualized execution environment provided in this embodiment of the present application includes at least one processing unit 601 and at least one storage unit 602, where the storage unit stores program codes, and when the program codes are executed by the processing unit, the processing unit is caused to execute the steps of the exception handling method in the virtualized execution environment.
EXAMPLE six
An embodiment of the present application provides a computer-readable storage medium, which includes program code, when a program product runs on a computing device, the program code is configured to enable an electronic device to execute the steps of the exception handling method in the virtualized running environment.
As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
While the preferred embodiments of the present application have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all alterations and modifications as fall within the scope of the application.
It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.

Claims (9)

1. An exception handling method in a virtualized operating environment, comprising:
monitoring an exception generated by a Guest operating system Guest OS running on a virtual machine;
if the abnormity is determined to be generated by the out-of-limit operation of the Guest OS on the kernel code with limited operation authority in the virtual machine according to the acquired abnormal context information, rejecting the out-of-limit operation of the Guest OS on the kernel code;
determining that the exception is caused by an out-of-limit operation of a Guest OS on kernel code in a virtual machine with restricted operating permissions according to the following steps:
acquiring a memory page fault address in the abnormal context information;
and if the memory page fault address is contained in an address field corresponding to a pre-stored kernel code with limited operation authority and the Guest OS has access authority to the kernel code in the address field, determining that the exception is generated by the out-of-limit operation of the Guest OS to the kernel code with limited operation authority in the virtual machine.
2. The method of claim 1, wherein denying the Guest OS an out-of-limit operation on the kernel code comprises:
judging whether an exception handling function customized by a user exists;
if yes, calling the exception handling function to handle the out-of-limit operation;
otherwise, rejecting the operation instruction executed by Guest OS when the abnormity occurs; the operation instruction is obtained from the context information of the exception.
3. The method of claim 2, further comprising:
and monitoring and processing secondary exceptions generated in the process of calling the exception handling function to handle the out-of-limit operation.
4. An exception handling apparatus in a virtualized execution environment, comprising:
the monitoring module is used for monitoring the abnormity generated by a Guest operating system Guest OS running on the virtual machine;
the processing module is used for refusing the out-of-limit operation of the Guest OS on the kernel code if the exception is determined to be generated by the out-of-limit operation of the Guest OS on the kernel code with limited operation authority in the virtual machine according to the acquired context information of the exception;
the processing module is specifically configured to determine that the exception is generated by an out-of-limit operation of a Guest OS on kernel code of which the operation authority is limited in the virtual machine, according to the following steps:
acquiring a memory page fault address in the abnormal context information;
and if the memory page fault address is contained in an address field corresponding to a pre-stored kernel code with limited operation authority and the Guest OS has access authority to the kernel code in the address field, determining that the exception is generated by the out-of-limit operation of the Guest OS to the kernel code with limited operation authority in the virtual machine.
5. The apparatus of claim 4, wherein the processing module is specifically configured to:
judging whether an exception handling function customized by a user exists;
if yes, calling the exception handling function to handle the out-of-limit operation;
otherwise, rejecting the operation instruction executed by Guest OS when the abnormity occurs; the operation instruction is obtained from the context information of the exception.
6. The apparatus of claim 5, further comprising:
the monitoring module is further used for monitoring secondary exception generated in the process of calling the exception handling function to handle the out-of-limit operation;
and the processing module is also used for processing the secondary exception.
7. An exception handling system in a virtualized operating environment, comprising: the system comprises a virtual machine manager, at least one first virtual machine and a second virtual machine used for carrying out security protection on the at least one first virtual machine, wherein:
the virtual machine manager is used for monitoring each first virtual machine for the abnormity generated by a Guest operating system Guest OS running on the first virtual machine; sending the acquired abnormal context information to the second virtual machine;
the second virtual machine is used for receiving the abnormal context information; if the abnormality is determined to be generated by the out-of-limit operation of the Guest OS on the kernel code with limited operation authority in the first virtual machine according to the abnormal context information, rejecting the out-of-limit operation of the Guest OS on the kernel code;
the second virtual machine is specifically configured to:
acquiring a memory page fault address in the abnormal context information;
and if the memory page fault address is contained in an address field corresponding to a pre-stored kernel code with limited operation authority, and the Guest OS has access authority to the kernel code in the address field, determining that the exception is generated by the out-of-limit operation of the Guest OS to the kernel code with limited operation authority in the first virtual machine.
8. The system of claim 7, wherein the second virtual machine is specifically configured to:
judging whether an exception handling function customized by a user exists;
if yes, calling the exception handling function to handle the out-of-limit operation;
otherwise, rejecting the operation instruction executed by Guest OS when the abnormity occurs; the operation instruction is obtained from the context information of the exception.
9. The system of claim 8, wherein the virtual machine manager is further to:
and monitoring and processing secondary exceptions generated in the process of calling the exception handling function to handle the out-of-limit operation.
CN201710554394.9A 2017-07-03 2017-07-03 Exception handling method, device and system in virtualized operation environment Active CN107450962B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710554394.9A CN107450962B (en) 2017-07-03 2017-07-03 Exception handling method, device and system in virtualized operation environment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710554394.9A CN107450962B (en) 2017-07-03 2017-07-03 Exception handling method, device and system in virtualized operation environment

Publications (2)

Publication Number Publication Date
CN107450962A CN107450962A (en) 2017-12-08
CN107450962B true CN107450962B (en) 2020-04-24

Family

ID=60487786

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710554394.9A Active CN107450962B (en) 2017-07-03 2017-07-03 Exception handling method, device and system in virtualized operation environment

Country Status (1)

Country Link
CN (1) CN107450962B (en)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109858265B (en) * 2018-11-22 2022-01-28 海光信息技术股份有限公司 Encryption method, device and related equipment
CN109684829B (en) * 2018-12-04 2020-12-04 中国科学院数据与通信保护研究教育中心 Service call monitoring method and system in virtualization environment
CN111240898B (en) * 2020-01-09 2023-08-15 中瓴智行(成都)科技有限公司 Method and system for realizing black box based on Hypervisor
CN113268726B (en) * 2020-02-17 2023-10-20 华为技术有限公司 Method for monitoring program code execution behavior and computer equipment
CN114327648B (en) * 2021-12-16 2024-02-02 北京安天网络安全技术有限公司 Driving debugging method and device, electronic equipment and storage medium

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102231138A (en) * 2011-07-08 2011-11-02 上海交通大学 Accurate memory data acquisition system and method of computer
CN103996004A (en) * 2014-06-12 2014-08-20 浪潮电子信息产业股份有限公司 Highly-available system design method based on virtualization
CN105354155A (en) * 2015-12-03 2016-02-24 上海高性能集成电路设计中心 Memory access authority control method based on page table checking mechanism
CN105740046A (en) * 2016-01-26 2016-07-06 华中科技大学 Virtual machine process behavior monitoring method and system based on dynamic library
CN106203082A (en) * 2016-06-29 2016-12-07 上海交通大学 The system and method efficiently isolating kernel module based on virtualization hardware characteristic

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9335943B2 (en) * 2014-06-30 2016-05-10 Intel Corporation Method and apparatus for fine grain memory protection

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102231138A (en) * 2011-07-08 2011-11-02 上海交通大学 Accurate memory data acquisition system and method of computer
CN103996004A (en) * 2014-06-12 2014-08-20 浪潮电子信息产业股份有限公司 Highly-available system design method based on virtualization
CN105354155A (en) * 2015-12-03 2016-02-24 上海高性能集成电路设计中心 Memory access authority control method based on page table checking mechanism
CN105740046A (en) * 2016-01-26 2016-07-06 华中科技大学 Virtual machine process behavior monitoring method and system based on dynamic library
CN106203082A (en) * 2016-06-29 2016-12-07 上海交通大学 The system and method efficiently isolating kernel module based on virtualization hardware characteristic

Also Published As

Publication number Publication date
CN107450962A (en) 2017-12-08

Similar Documents

Publication Publication Date Title
CN107450962B (en) Exception handling method, device and system in virtualized operation environment
US9935971B2 (en) Mitigation of virtual machine security breaches
KR101946982B1 (en) Process Evaluation for Malware Detection in Virtual Machines
US9594881B2 (en) System and method for passive threat detection using virtual memory inspection
EP2656206B1 (en) Probe insertion via background virtual machine
EP2940615B1 (en) Method and apparatus for isolating management virtual machine
US20140053272A1 (en) Multilevel Introspection of Nested Virtual Machines
US10102373B2 (en) Method and apparatus for capturing operation in a container-based virtualization system
US8793688B1 (en) Systems and methods for double hulled virtualization operations
CN107580703B (en) Migration service method and module for software module
KR101701014B1 (en) Reporting malicious activity to an operating system
US10430261B2 (en) Detecting a guest operating system crash on a virtual computing instance
US9824225B1 (en) Protecting virtual machines processing sensitive information
CN108509251A (en) A kind of safety virtualization system suitable for credible performing environment
US9785492B1 (en) Technique for hypervisor-based firmware acquisition and analysis
US20230161867A1 (en) Method and device for securely starting up a container instance
US9766917B2 (en) Limited virtual device polling based on virtual CPU pre-emption
CN106529284B (en) Virtual machine monitor security reinforcement method based on security chip
US20210133357A1 (en) Privacy Preserving Centralized Evaluation of Sensitive User Features for Anomaly Detection
CN105138388A (en) Virtual machine monitoring method and apparatus
EP3535681B1 (en) System and method for detecting and for alerting of exploits in computerized systems
US20180260563A1 (en) Computer system for executing analysis program, and method of monitoring execution of analysis program
US9696940B1 (en) Technique for verifying virtual machine integrity using hypervisor-based memory snapshots
JP5747765B2 (en) Failure analysis apparatus, failure analysis method, and program
US9436523B1 (en) Holistic non-invasive evaluation of an asynchronous distributed software process

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
EE01 Entry into force of recordation of patent licensing contract

Application publication date: 20171208

Assignee: Kedong (Guangzhou) Software Technology Co., Ltd

Assignor: Beijing Dongtu Technology Co., Ltd.|Beijing keyin Jingcheng Technology Co., Ltd

Contract record no.: X2020980000255

Denomination of invention: Exception handling method, apparatus and system in virtual operating environment

License type: Exclusive License

Record date: 20200218

EE01 Entry into force of recordation of patent licensing contract
GR01 Patent grant
GR01 Patent grant