CN108241801B - Method and device for processing system call - Google Patents
Method and device for processing system call Download PDFInfo
- Publication number
- CN108241801B CN108241801B CN201611218930.XA CN201611218930A CN108241801B CN 108241801 B CN108241801 B CN 108241801B CN 201611218930 A CN201611218930 A CN 201611218930A CN 108241801 B CN108241801 B CN 108241801B
- Authority
- CN
- China
- Prior art keywords
- virtual machine
- system call
- host
- kernel
- target virtual
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 69
- 238000012545 processing Methods 0.000 title claims abstract description 40
- 230000006399 behavior Effects 0.000 claims description 12
- 238000012546 transfer Methods 0.000 claims description 6
- 230000008569 process Effects 0.000 description 27
- 230000006870 function Effects 0.000 description 14
- 238000010586 diagram Methods 0.000 description 6
- 238000004891 communication Methods 0.000 description 5
- 238000002955 isolation Methods 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 4
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 238000013519 translation Methods 0.000 description 2
- 238000004590 computer program Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 238000012800 visualization Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
- G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
- G06F21/106—Enforcing content protection by specific content processing
- G06F21/1064—Restricting content processing at operating system level
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Multimedia (AREA)
- Technology Law (AREA)
- Storage Device Security (AREA)
Abstract
The embodiment of the application discloses a method and a device for processing system call, which can improve the safety of an operating system. The method comprises the following steps: intercepting system calls needing to be executed by an application program by a host computer kernel, and transferring the intercepted system calls to a target virtual machine for execution, wherein the target virtual machine and the host computer share a host computer kernel; and the host kernel judges the legality of the system call according to the execution result of the system call executed by the target virtual machine and a preset first strategy.
Description
Technical Field
The embodiment of the application relates to the technical field of software, in particular to a method and a device for processing system calls.
Background
The operating system plays a very critical role in the system security of the computer. In one aspect, the security features provided by the operating system may be used to enhance security of applications, isolate malicious applications, detect unauthorized access by applications, whether intended or unintended. On the other hand, the number of code lines of an operating system is usually on the order of tens of millions of lines, and therefore, the operating system usually inevitably contains some bugs, making the operating system a possible target to be attacked. A common attack method is that a user-mode application utilizes a vulnerability of an operating system through system call to obtain a higher authority, thereby controlling the entire operating system. Therefore, it is critical for computer systems to improve the security of operating systems.
Disclosure of Invention
The application provides a method and a device for processing system call, which can improve the safety of an operating system.
In a first aspect, the present application provides a method for processing a system call, the method comprising: intercepting a system call required to be executed by an application program by a host computer kernel, and transferring the intercepted system call to a target virtual machine for execution, wherein the target virtual machine and the host computer share a host computer kernel; and the host kernel judges the legality of the system call according to the execution result of the system call executed by the target virtual machine and a preset first strategy.
In an embodiment of the present application, the first policy is used to determine the validity of a system call. The first policy may be set according to a known vulnerability according to a system call specification and an operating system running on the host. The detailed description can be referred to the specification.
The host kernel creates a target virtual machine with the same running environment as the host kernel and transfers the system call which may have potential risk to the target virtual machine for execution. Therefore, the host kernel can judge whether the operation of the system call is legal or not according to the execution result of the system call executed by the target virtual machine and the preset first strategy, so that the system call with potential risk is prevented from directly running in the host kernel, the isolation of the system call is enhanced, and the safety of an operating system can be improved.
In one possible implementation, intercepting, by the host kernel, a system call that needs to be executed by the application program includes: and the host kernel judges to intercept the system call according to a preset second strategy.
In this embodiment of the present application, the second policy is a preset security policy for determining whether to intercept a system call. The second policy may be set according to the system call number and the parameter of the system call. For example, the second policy may be a list of system calls that need to be intercepted.
In one possible implementation, before the host kernel forwards the system call to the target virtual machine for execution, the method further includes: the host kernel sends a creation request to the virtual machine monitor, wherein the creation request is used for requesting the virtual machine monitor to create a target virtual machine sharing the host kernel with the host.
In a possible implementation manner, the host runs on a virtual machine monitor and at least one virtual machine, and the target virtual machine is obtained by modifying a control register CR3 of a first virtual machine and an extended page table of the first virtual machine for the virtual machine monitor, wherein the modified first virtual machine shares the host kernel with the host, and the first virtual machine is any one of the at least one virtual machine.
It should be noted that the Extended Page Tables (EPTs) are a hardware mechanism provided by a Central Processing Unit (CPU) for accelerating address translation of a virtual machine. On Intel's CPUs, this mechanism is called EPT. On the CPU of ultra-Micro semiconductor (AMD), this mechanism is called Nested Page Tables (NPT). In the embodiment of the present application, the extended page table is described by taking EPT as an example.
In one possible implementation, the method further includes: the method comprises the steps that a host kernel obtains read-write behaviors of memory data of the host kernel when a target virtual machine execution system is called; and the host kernel judges the legality of the system call according to the execution result of the system call executed by the target virtual machine and a preset first strategy, and the judging method comprises the following steps: and the host kernel judges the legality of the system call according to the read-write behavior of the memory data of the host kernel and the first strategy when the target virtual machine executes the system call.
Specifically, the virtual machine monitor records an execution result of the application executing the system call, and notifies the host kernel of the execution result of the target virtual machine after the system call is executed. And if the read-write behavior of the application program to the memory data of the host kernel in the process of executing the system call is inconsistent with the read-write permission of the memory data of the system call preset in the first strategy, the host kernel judges that the system call is illegal. On the contrary, if the read-write behavior of the system call to the memory data of the host kernel is consistent with the read-write permission of the system call to the memory data preset in the first strategy in the process of executing the system call by the application program, the system call is judged to be legal.
In this embodiment of the present application, the virtual machine monitor modifies the extended page table of the first virtual machine to set the read-write permission of the target virtual machine to the memory data of the host kernel. Specifically, the virtual machine monitor sets that the target virtual machine only has read permission for the memory data of the host kernel. Thus, when the target virtual machine writes the memory data of the host kernel, a permission error is triggered. After the virtual machine monitor obtains the permission error message, the target virtual machine is temporarily suspended. Meanwhile, the virtual machine monitor allocates a physical page to the target virtual machine, copies data which needs to be written in a memory page of the host kernel to the physical page, and sets the write permission of the target virtual machine to the physical page as writable.
In one possible implementation, the first policy is pre-configured according to a system call specification and a known vulnerability of an operating system running on the host.
In a second aspect, the present application provides an apparatus for processing a system call, configured to perform the method of the first aspect or any possible implementation manner of the first aspect. In particular, the apparatus comprises means for performing the method of the first aspect or any possible implementation manner of the first aspect.
In a third aspect, the present application provides a terminal comprising the apparatus according to the second aspect.
In a fourth aspect, the present application provides a cloud server comprising the apparatus according to the second aspect.
In a fifth aspect, the present application provides a computer readable medium for storing a computer program comprising instructions for performing the method of the first aspect or any possible implementation manner of the first aspect.
In the embodiment of the application, the host kernel establishes the target virtual machine with the running environment completely same as that of the host kernel, and transfers the system call which possibly has the potential risk to the target virtual machine for execution, so that the host kernel judges whether the operation of the system call is legal or not according to the execution result of the system call executed by the target virtual machine and a preset first strategy, the system call with the potential risk is prevented from directly running in the host kernel, the isolation of the system call is enhanced, and the safety of an operating system can be improved.
Drawings
Fig. 1 is a flowchart of a method 100 for processing a system call according to an embodiment of the present application
Fig. 2 is a schematic diagram of a method for processing a system call according to an embodiment of the present application.
Fig. 3 is a schematic block diagram of an apparatus 400 for processing a system call according to an embodiment of the present application.
Fig. 4 is a schematic block diagram of an apparatus 500 for processing a system call according to an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application are described below with reference to the accompanying drawings.
First, a brief description will be given of several related concepts involved in the embodiments of the present application.
User mode and kernel mode
Since the resources of the operating system are limited, if the resources are accessed too much, the resources are inevitably consumed too much. If these operations are not differentiated, it is likely that resource access conflicts will result. To reduce access and usage conflicts for limited resources, the Unix/Linux operating system assigns different execution levels, i.e., the concept of "privileges," to different operations. Programs of different privilege levels have different access capabilities to resources. For example, some particularly critical operations associated with the system must be performed by the most privileged program.
For example, the CPU of the Intel X86 architecture provides four privilege levels 0 to 3, with the lower the number, the higher the privilege. The Linux operating system mainly adopts two privilege levels of 0 and 3, and respectively corresponds to a kernel mode and a user mode. The operations that a process running in user mode can perform and access resources are greatly limited. The process running in the kernel mode can perform any operation, and has no limitation on the use of resources.
System call
Some programs initially run in a user mode. However, in the execution process, some operations need to be executed under the kernel authority, and this involves switching from the user mode to the kernel mode, and this mechanism is called a system call.
A system call may actually be understood as an interface provided by the kernel to access resources for upper layer applications. The system calls the request of the program to the kernel, calls the corresponding kernel function to complete the operation to be executed by the program, and returns the processing result to the program.
Fig. 1 is a flowchart of a method 100 for processing a system call according to an embodiment of the present disclosure. As shown in FIG. 1, the method 100 includes steps 110-120.
110. And intercepting the system call required to be executed by the application program by the host computer core, and transferring the intercepted system call to the target virtual machine for execution.
It should be understood that a target virtual machine refers to a virtual machine created by a virtual machine monitor that shares a host kernel with a host.
It should be noted that, the target virtual machine and the host share the host kernel means that the target virtual machine and the host have the same kernel environment.
Currently, there are two types of Virtual Machine Monitors (VMMs) in the mainstream. One is Xen, which is located between the kernel and the hardware of the operating system. The other is KVM, which is part of the kernel of the operating system. In a KVM architecture, the virtual machine manager is itself part of the host kernel.
The method for processing the system call is not only suitable for the framework of the virtual machine monitor independent of the host kernel. Meanwhile, the method is also suitable for the framework that the virtual machine monitor is a part of the kernel of the host.
For convenience of explanation, in the embodiments of the present application, a virtual machine monitor is described as an example, which is independent of a host kernel.
In the embodiment of the present application, whether the host kernel intercepts a system call may include two cases.
Case 1
All system calls are intercepted.
Whether a system call is intercepted is determined according to a preset strategy (i.e., a second strategy).
Optionally, as an embodiment, the intercepting, by the host kernel, a system call that needs to be executed by the application program includes:
and the host kernel judges whether to intercept the system call to be executed by the application program according to a preset second strategy.
That is, in order to improve the security of the operating system, the host kernel may intercept all system calls executed by the application program and execute the intercepted system calls by the target virtual machine, so as to avoid the potentially risky system calls from running directly on the host kernel. Or, the host kernel may also determine whether to intercept a system call to be executed by the application program based on a preset second policy.
It should be understood that the host kernel intercepts the system call that needs to be executed by the application program according to the preset second policy, which indicates that the system call may have a potential security risk. At this time, the host kernel intercepts the system call, so as to prevent the system call with potential safety hazard from directly executing operation in the host kernel, thereby avoiding the risk that the host kernel is attacked maliciously.
The second policy is a preset security policy for determining whether to intercept a system call. Specifically, the second policy may be set according to a system call number, a parameter of the system call, and the like.
For example, the second policy may be a list of system calls that need to be intercepted. This list may be set empirically. For example, some system calls are very simple and have a low probability of bugs, and such system calls do not need to be monitored (or intercepted). On the contrary, some system calls have a high possibility of bugs, and should be set in the list of system calls to be intercepted.
Optionally, as an embodiment, before the host kernel forwards the system call to the target virtual machine for execution, the method further includes:
the host kernel sends a create request to the virtual machine monitor requesting the virtual machine monitor to create a target virtual machine sharing the host kernel with the host.
Optionally, as an embodiment, a virtual machine monitor and at least one virtual machine run on the host, where the target virtual machine is obtained by modifying, by the virtual machine monitor, the control register CR3 of the first virtual machine and the extended page table of the first virtual machine, where the modified first virtual machine shares a host kernel with the host, and the first virtual machine is any one of the at least one virtual machine.
It should be understood that the control register CR3 is one of the control registers (CR0-CR3) used to control and determine the operating mode of the processor and the characteristics of the currently executing task. CR3 contains the page directory physical memory address. Thus, the CR3 Register is also referred to as the Page Directory Base address Register (PDBR).
Specifically, in the embodiment of the present application, a target virtual machine is created in multiple ways.
Mode 1
The virtual machine monitor creates a target virtual machine.
In the method 1, when the host kernel determines that the system call needs to be intercepted, the host kernel sends a creation request to the virtual machine monitor. The virtual machine monitor creates a virtual machine based on the creation request, and causes the virtual machine to share the host kernel with the host. That is, the virtual machine has exactly the same kernel runtime as the host.
The virtual machine monitor modifies a virtual machine running on the host machine to a target virtual machine sharing a host kernel with the host machine.
In manner 2, the virtual machine monitor can arbitrarily select a virtual machine (for convenience of illustration, referred to as virtual machine # a) from a virtual machine resource pool running on the host, and the modified virtual machine # a shares the host kernel with the host by modifying the CR3 register of the virtual machine # a and the extended page table of the virtual machine # a.
Specifically, the virtual machine monitor may set the read-write permission of the virtual machine # a to the memory data of the host kernel by modifying the extended page table of the virtual machine # a. Since the modified virtual machine # a (hereinafter referred to as a target virtual machine) shares the host kernel with the host, in order to prevent the target virtual machine from modifying the memory data of the host kernel in the process of executing the system call, the virtual machine manager may set the access right of the virtual machine # a to the memory data to contain only read, not write. Thus, when the target virtual machine writes the memory data of the host kernel, the virtual machine monitor can obtain the authority error message and suspend the target virtual machine temporarily. Meanwhile, the virtual machine monitor allocates a physical page to the target virtual machine, copies data to be modified (i.e., data to be written) in the memory page of the host kernel to the physical page, and sets the write permission of the target virtual machine to the physical page to be writable. Thus, the target virtual machine can modify the memory data.
120. And the host kernel judges the legality of the system call according to the execution result of the system call executed by the target virtual machine and a preset first strategy.
In an embodiment of the present application, the first policy is a security policy for determining the validity of a system call executed by the host kernel.
When the virtual machine monitor creates the target virtual machine, the virtual machine monitor can set the read permission and the write permission of the target virtual machine to the host kernel data. Subsequently, the virtual machine monitor monitors the access behavior of the target virtual machine, and once the actual access behavior of the target virtual machine on the memory data is not consistent with the access authority of the system call on the memory data set in the first strategy in the process of executing the system call, the host kernel can judge that the system call is illegal.
For example, the host kernel sets that the target virtual machine cannot write all data of the host kernel when executing a certain system call, and the target virtual machine performs a write operation on the host kernel in the process of executing the system call, that is, the system call can be determined to be illegal.
In the embodiments of the present application, the setting of the first policy mainly originates from two aspects.
(1) And (5) system call specification.
The data which is possibly modified and the data which is not necessarily modified in the execution process of the system call can be judged through the system call specification. Therefore, if the host kernel finds that the data which is not modified in the system call specification is modified, the system call can be judged to be illegal.
For example, a sysinfo system call may obtain data such as the system runtime of the operating system while being executed, but does not modify any kernel data. Therefore, when the target virtual machine is in the process of executing the syslnfo system call, if the kernel data is found to be modified, it can be determined that the syslnfo system call is illegal.
(2) A known vulnerability of the operating system.
Taking an Escape vulnerability of a container as an example, a malicious attacker modifies FS—Kernel data structures such as stucts may be used to access host resources.
Therefore, it is possible to monitor the FS exclusively by setting—Modification of the STRUCT kernel data sets the first policy so that such vulnerabilities can be identified and blocked.
For another example, in the existing attack behavior, an attacker utilizes kernel bugs in a container, modifies a task _ struct- > ns _ proxy data structure through system call, can get rid of the limitation of the container, and achieves the purpose of accessing resources outside the container.
According to the specification of the system call, only 3 system calls may modify the data structure of task _ struct- > ns _ proxy, which is clone, unshare, and setns, respectively. For this reason, the first policy may be set such that if a system call modifies the data related to ns _ proxy, and the system call is not any of clone, unshared and setns, the host kernel may determine that the system call is illegal.
As another example, there is an attack behavior where the attacker repeatedly calls open _ by _ handle _ at in the container until reaching the root node of some file system of the host. Then, starting from the root node, any file on the host is accessed. Based on the characteristics of the vulnerability, the first policy can be set by the following two aspects: (1) when the virtual machine monitor establishes the target virtual machine, the target virtual machine does not have read permission for a memory corresponding to a root node of a host file system; (2) if a system call invokes the root node of the host file system during execution, the system call is determined to be illegal.
It can be seen from the above process that, in the embodiment of the present application, the host kernel creates the target virtual machine having the same operating environment as the host kernel, and transfers the system call that may have the potential risk to the target virtual machine for execution, so that the host kernel determines whether the operation of the system call is legal according to the execution result of the system call executed by the target virtual machine and a preset security policy (i.e., a first policy), so as to prevent the system call that has the potential risk from directly running in the host kernel, enhance the isolation of the system call, and thus can improve the security of the operating system.
Fig. 2 is a schematic diagram of a method 300 for processing a system call according to an embodiment of the present application. As shown in FIG. 2, the method 300 generally includes steps 301-310.
Note that the following sequence numbers 301-310 correspond to the sequence numbers (r-r) in fig. 2, respectively.
301. The process invokes a system call.
302. The host kernel determines whether to intercept the system call.
Specifically, the system call entry function of the host kernel searches a corresponding system call processing function in the system call table according to the incoming system call number, and then executes the searched system call processing function.
In the embodiment of the application, whether the system call needs to be intercepted or not can be determined according to the policy # A, the system call number and the parameters of the system call by modifying the system call entry function.
Here, policy # a is an example of the second policy.
At step 302, two cases are included:
(1) if policy # A indicates that the system call does not need to be intercepted, then the system call is executed normally.
(2) If policy # A indicates that the system call should be intercepted, the host kernel puts the process to sleep and performs step 303.
Namely, whether the system call needs to be intercepted is judged according to the strategy # A, the system call entry function, the system call number and the parameters of the system call. If interception is required, the host kernel may notify the virtual machine monitor to create a virtual machine that shares the host kernel with the host. And if the interception is not needed, executing the system call function in the system call table according to the logic for executing the system call.
303. The host kernel sends a create request to the virtual machine monitor to request the virtual machine monitor to create the target virtual machine.
As previously described, the target virtual machine created by the virtual machine monitor shares the host kernel with the host.
304. The virtual machine monitor receives a creation request sent by the host kernel and creates a virtual machine based on the creation request.
In particular, the virtual machine monitor may newly create a virtual machine such that the virtual machine shares a host kernel with the host. Alternatively, the virtual machine monitor may select a virtual machine from the virtual machines running on the host, and the virtual machine may share the host kernel by modifying CR3 registers inside the virtual machine and Extended Page Tables (EPTs) stored on the virtual machine monitor.
Meanwhile, the virtual machine monitor configures the read permission and the write permission of the target virtual machine. For example, the virtual machine may cause the virtual machine kernel to be unable to write to the host kernel and only view the memory of certain host kernels by filling access bits in a data structure associated with memory management.
The virtual machine monitor makes the value of the CR3 register inside the virtual machine the same as the CR3 register of the host, i.e. the page table physical addresses of the virtual machine and the host are the same, by modifying the CR3 register inside the virtual machine. And. The virtual machine monitor modifies the stored EPT. After the EPT translation, the Guest Physical Address (GPA) is made to be the same as the Host Physical Address (HPA).
Specifically, the Guest Virtual Address (GVA) is translated into a Guest Physical Address (GPA) by the Virtual machine internal page tables. GPA is translated into HPA by EPT.
Through the two modifications, the target virtual machine and the host machine share one kernel.
In particular, the process of the virtual machine monitor translating the virtual machine address can refer to the prior art, and is not described in detail here.
305. The virtual machine monitor loads the target virtual machine data so that the target virtual machine, once executed, executes the system call in step 301 described above.
The target virtual machine is caused to share the host kernel with the host, via step 304. When the target virtual machine has the same kernel environment as the host, the system call can be executed in the target virtual machine.
A specific method may be that an Instruction Address Register (EIP) in a Virtual Machine Control Structure (VMCS) is modified to point to a specified system call function entry. When the virtual machine is started, the virtual machine starts to execute the specified system call.
It can be seen from the above process that, after the main kernel determines that a system call needs to be intercepted, the virtual machine monitor creates a target virtual machine, and the intercepted system call is transferred to the target virtual machine for execution.
Under the condition that the target virtual machine and the host share the kernel, in order to prevent the target virtual machine from modifying the data of the host kernel in the execution process, the virtual machine monitor modifies the data structure related to the EPT when the target virtual machine is created, so that the access authority of the target virtual machine to all memory pages of the host kernel does not contain write operation.
Also, to prevent the target virtual machine from reading certain data of the host kernel during execution, the virtual machine monitor modifies the EPT-related data structure such that the target virtual machine's access rights to certain memory of the host kernel also do not include the read.
306. The target virtual machine executes the system call.
In the implementation, step 306 may specifically include the following sub-steps:
(1) a situation where the target virtual machine violates a memory access permission.
(2) The virtual machine monitor records the illegal memory access of the target virtual machine.
And if the access is write access, the virtual machine monitor allocates a new memory for the target virtual machine and copies the memory data to be written by the target virtual machine to the new memory. And simultaneously, modifying the memory management table to ensure that the target virtual machine has write permission to the new memory.
(3) And returning the exception.
Note that step 306 here corresponds to the reference number |, in fig. 2. Wherein sub-steps (1), (2) and (3) correspond to i, ii and iii, respectively, as shown in FIG. 2.
Specifically, in step 305, the virtual machine monitor configures access rights of the target virtual machine. By configuring the access rights (including read rights and write rights) of the target virtual machine, an EPT Violation (EPT virtualization) exception occurs when the target virtual machine is writing any data of the host kernel, or reading some data of the host kernel. Illegal access data information is collected and recorded in an EPT visualization exception handling function of the virtual machine monitor. If it is a Write access, the virtual machine monitor performs a Copy-on-Write (Copy-on-Write) operation.
The copy-on-write operation means that when the target virtual machine needs to perform the write operation, the virtual machine monitor allocates a physical page to the target virtual machine, copies the data to be modified to a new physical page, and configures the new physical page as writable. Thereafter, the exception handling function of the virtual machine monitor ends the operation, and the target virtual machine continues to perform the write operation on the new physical page.
307. And exiting after the target virtual machine executes the system call.
308. And the virtual machine monitor returns the result of the virtual machine executing the system call and the memory violation condition to the host kernel.
309. And the host kernel judges whether the system call is legal or not according to the strategy # B.
Here, policy # B is taken as an example of the first policy. The specific process can be seen in the aforementioned step 120.
310. And the host kernel generates a corresponding return value according to the execution result of the target virtual machine and the strategy # B and returns the return value to the user mode process.
In the embodiment of the application, the host kernel establishes the target virtual machine with the running environment completely same as that of the host kernel, and transfers the system call which possibly has the potential risk to the target virtual machine for execution, so that the host kernel judges whether the operation of the system call is legal or not according to the execution result of the system call executed by the target virtual machine and a preset first strategy, the system call with the potential risk is prevented from directly running in the host kernel, the isolation of the system call is enhanced, and the safety of an operating system can be improved.
Fig. 3 is a schematic block diagram of an apparatus 400 for processing a system call according to an embodiment of the present application. As shown in fig. 3, the apparatus 400 includes:
the processing unit 410 is configured to intercept a system call that needs to be executed by an application program, and transfer the intercepted system call to a target virtual machine for execution;
the processing unit 410 is further configured to determine validity of the system call according to an execution result of the target virtual machine executing the system call and a preset first policy.
In addition, the apparatus 400 may further include a transmitting unit 420.
In particular, the processing unit 410 may be a processor and the transmitting unit may be a transmitter.
The units and other operations or functions in the apparatus 400 provided according to the embodiment of the present application are respectively for implementing the method 100 for processing a system call provided by the embodiment of the present application and the corresponding flows in the embodiments. For brevity, no further description is provided herein.
Fig. 4 is a schematic block diagram of an apparatus 500 for processing a system call according to an embodiment of the present application. As shown in fig. 4, the apparatus 500 includes: memory 510, processor 520, and communication interface 530.
The memory 510 is used to store applications, code or instructions that implement aspects of the present application. Processor 520 is configured to execute applications, code or instructions stored in memory 510 to perform method 100 of handling system calls and the corresponding processes and/or operations of the various embodiments. And will not be described in detail herein.
It should be understood that the apparatus 400 for processing system calls provided in fig. 3 may be implemented by the device 500 for processing system calls shown in fig. 4. For example, processing unit 410 in fig. 3 may be implemented by processor 520 in fig. 4. The transmitting unit 420 may be implemented by one or more communication interfaces 530 shown in fig. 4.
The Memory 510 may be, but is not limited to, a Read-Only Memory (ROM) or other type of static storage device that can store static information and instructions, a Random Access Memory (RAM) or other type of dynamic storage device that can store information and instructions, an Electrically Erasable Programmable Read-Only Memory (EEPROM), a Compact Disc Read-Only Memory (CD-ROM) or other optical Disc storage, optical Disc storage (including Compact Disc, laser Disc, optical Disc, digital versatile Disc, blu-ray Disc, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. The memory may be self-contained. Alternatively, the memory may be integral to the processor.
The processor 520 may be a Central Processing Unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of programs according to the present disclosure.
The communication Interface 530 may be a wired Interface, such as a Fiber Distributed Data Interface (FDDI), Gigabit Ethernet (GE) Interface, or a wireless Interface. The embodiment of the present application is not particularly limited to this.
In addition, the present application provides a terminal device and a cloud server, including the apparatus for processing a system call in the foregoing embodiment. Also, the terminal device or the cloud server includes a processor, and the processor executes the method for processing the system call provided in the embodiment of the present application.
It should be understood that, in the various embodiments of the present application, the sequence numbers of the above-mentioned processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.
In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit.
The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.
It should be understood that, in the various embodiments of the present application, the sequence numbers of the above-mentioned processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.
The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.
Claims (14)
1. A method of processing system calls, the method comprising:
intercepting a system call required to be executed by an application program by a host computer kernel, and transferring the intercepted system call to a target virtual machine for execution, wherein the target virtual machine and the host computer share the host computer kernel, and the target virtual machine forbids write permission on any memory data of the host computer kernel or forbids read permission on specific memory data of the host computer kernel;
and the host kernel judges the legality of the system call according to the execution result of the system call executed by the target virtual machine and a preset first strategy, wherein the first strategy is used for judging the legality of the system call, and the first strategy is set according to the system call specification and/or the known vulnerability of the operating system running on the host.
2. The method of claim 1, wherein intercepting system calls to be executed by an application in the host computer comprises:
and the host kernel judges to intercept the system call according to a preset second strategy.
3. The method of claim 1 or 2, wherein before the host kernel forwards the system call to a target virtual machine for execution, the method further comprises:
the host kernel sends a creation request to a virtual machine monitor, the creation request requesting the virtual machine monitor to create the target virtual machine sharing the host kernel with the host.
4. The method according to claim 1 or 2, wherein a virtual machine monitor and at least one virtual machine run on the host, and the target virtual machine is obtained by modifying a control register CR3 of a first virtual machine and an extended page table of the first virtual machine by the virtual machine monitor, wherein the modified first virtual machine shares the host kernel with the host, and the first virtual machine is any one of the at least one virtual machine.
5. The method according to claim 1 or 2, characterized in that the method further comprises:
the host kernel acquires the read-write behavior of the memory data of the host kernel when the target virtual machine executes the system call;
and the host kernel judges the legality of the system call according to the execution result of the system call executed by the target virtual machine and a preset first strategy, and the judging comprises the following steps:
and the host kernel judges the legality of the system call according to the read-write behavior of the target virtual machine to the memory data of the host kernel when executing the system call and the first strategy.
6. The method of claim 1 or 2, wherein the first policy is pre-configured according to a system call specification and a known vulnerability of an operating system running on the host.
7. An apparatus for processing a system call, the apparatus comprising:
the system comprises a processing unit, a host kernel and a target virtual machine, wherein the processing unit is used for intercepting a system call required to be executed by an application program and transferring the intercepted system call to the target virtual machine for execution, the target virtual machine and the host share the host kernel, and the target virtual machine forbids write permission on any memory data of the host kernel or forbids read permission on specific memory data of the host kernel;
the processing unit is further configured to determine validity of the system call according to an execution result of the target virtual machine executing the system call and a preset first policy, where the first policy is used to determine validity of one system call, and the first policy is set according to a system call specification and/or a known vulnerability of an operating system running on the host.
8. The apparatus according to claim 7, wherein the processing unit is specifically configured to: and judging to intercept the system call according to a preset second strategy.
9. The apparatus of claim 7 or 8, further comprising:
a sending unit, configured to send a creation request to a virtual machine monitor before the processing unit transfers the system call to the target virtual machine for execution, where the creation request is used to request the virtual machine monitor to create the target virtual machine sharing a host kernel with the host.
10. The apparatus according to claim 7 or 8, wherein a virtual machine monitor and at least one virtual machine run on the host, and the target virtual machine is obtained by modifying a control register CR3 of a first virtual machine and an extended page table of the first virtual machine by the virtual machine monitor, wherein the modified first virtual machine shares the host kernel with the host, and the first virtual machine is any one of the at least one virtual machine.
11. The apparatus according to claim 7 or 8, wherein the processing unit is further configured to obtain a read-write behavior of the memory data of the host kernel when the target virtual machine executes the system call;
and the processing unit is specifically configured to:
and judging the legality of the system call according to the read-write behavior of the target virtual machine to the memory data of the host kernel when the system call is executed and the first strategy.
12. The apparatus of claim 7 or 8, wherein the first policy is pre-configured according to a system call specification and a known vulnerability of an operating system running on the host.
13. A terminal device, characterized in that it comprises the apparatus of any one of claims 7 to 12.
14. A cloud server, characterized in that it comprises the apparatus of any one of claims 7 to 12.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201611218930.XA CN108241801B (en) | 2016-12-26 | 2016-12-26 | Method and device for processing system call |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201611218930.XA CN108241801B (en) | 2016-12-26 | 2016-12-26 | Method and device for processing system call |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108241801A CN108241801A (en) | 2018-07-03 |
| CN108241801B true CN108241801B (en) | 2021-03-30 |
Family
ID=62701392
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201611218930.XA Active CN108241801B (en) | 2016-12-26 | 2016-12-26 | Method and device for processing system call |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108241801B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112395617A (en) * | 2019-08-15 | 2021-02-23 | 奇安信安全技术(珠海)有限公司 | Method and device for protecting docker escape vulnerability, storage medium and computer equipment |
| CN112596921A (en) * | 2020-12-17 | 2021-04-02 | 海光信息技术股份有限公司 | System call processing method and processing device |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101727348A (en) * | 2008-10-10 | 2010-06-09 | 成都市华为赛门铁克科技有限公司 | Method and device for analyzing suspicious codes |
| US20100192150A1 (en) * | 2005-08-09 | 2010-07-29 | Steven Grobman | Exclusive access for secure audio program |
| CN102096786A (en) * | 2011-03-04 | 2011-06-15 | 上海交通大学 | Cross-platform safety protection system based on hardware virtualization |
| EP2354995A1 (en) * | 2010-02-09 | 2011-08-10 | Siemens Aktiengesellschaft | Software licensing in a virtual computing environment |
| CN103778368A (en) * | 2014-01-23 | 2014-05-07 | 重庆邮电大学 | Safe progress isolating method based on system virtualization technology |
| CN104573422A (en) * | 2015-01-08 | 2015-04-29 | 浪潮软件股份有限公司 | Virtual machine-based application process operation method and device |
| CN105068859A (en) * | 2015-07-29 | 2015-11-18 | 上海谐桐信息技术有限公司 | Cross-virtual-machine multi-service calling method and system |
| CN105393255A (en) * | 2013-07-05 | 2016-03-09 | 比特梵德知识产权管理有限公司 | Process evaluation for malware detection in virtual machines |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8099596B1 (en) * | 2011-06-30 | 2012-01-17 | Kaspersky Lab Zao | System and method for malware protection using virtualization |
-
2016
- 2016-12-26 CN CN201611218930.XA patent/CN108241801B/en active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20100192150A1 (en) * | 2005-08-09 | 2010-07-29 | Steven Grobman | Exclusive access for secure audio program |
| CN101727348A (en) * | 2008-10-10 | 2010-06-09 | 成都市华为赛门铁克科技有限公司 | Method and device for analyzing suspicious codes |
| EP2354995A1 (en) * | 2010-02-09 | 2011-08-10 | Siemens Aktiengesellschaft | Software licensing in a virtual computing environment |
| CN102096786A (en) * | 2011-03-04 | 2011-06-15 | 上海交通大学 | Cross-platform safety protection system based on hardware virtualization |
| CN105393255A (en) * | 2013-07-05 | 2016-03-09 | 比特梵德知识产权管理有限公司 | Process evaluation for malware detection in virtual machines |
| CN103778368A (en) * | 2014-01-23 | 2014-05-07 | 重庆邮电大学 | Safe progress isolating method based on system virtualization technology |
| CN104573422A (en) * | 2015-01-08 | 2015-04-29 | 浪潮软件股份有限公司 | Virtual machine-based application process operation method and device |
| CN105068859A (en) * | 2015-07-29 | 2015-11-18 | 上海谐桐信息技术有限公司 | Cross-virtual-machine multi-service calling method and system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN108241801A (en) | 2018-07-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10447728B1 (en) | Technique for protecting guest processes using a layered virtualization architecture | |
| KR101946982B1 (en) | Process Evaluation for Malware Detection in Virtual Machines | |
| US9946562B2 (en) | System and method for kernel rootkit protection in a hypervisor environment | |
| KR102255767B1 (en) | Systems and methods for virtual machine auditing | |
| EP3047419B1 (en) | Virtual secure mode for virtual machines | |
| US20150248554A1 (en) | Systems And Methods For Executing Arbitrary Applications In Secure Environments | |
| US20150309832A1 (en) | Isolation Method for Management Virtual Machine and Apparatus | |
| CN110383256B (en) | Kernel integrity protection method and device | |
| US9183391B2 (en) | Managing device driver cross ring accesses | |
| CN110874468B (en) | Application program security protection method and related equipment | |
| EP3178032B1 (en) | Embedding secret data in code | |
| CN108241801B (en) | Method and device for processing system call | |
| CN113391881A (en) | Interrupt management method and device, electronic equipment and computer storage medium | |
| US11301282B2 (en) | Information protection method and apparatus | |
| Gutstein | Towards Efficient and Effective IOMMU-based Protection from DMA Attacks | |
| US11934857B2 (en) | Supporting execution of a computer program by using a memory page of another computer program | |
| US20220300314A1 (en) | Hypervisor-assisted secured memory sharing among host and guest operating system | |
| CN116561824A (en) | Method and apparatus for managing memory in a confidential computing architecture |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |