System call processing method and processing apparatus

Abstract

The system call processing method and processing device are applied to a guest operating system, the guest operating system runs in a client, the client is obtained by virtualization of a physical processor with a hardware virtualization function, the method comprises the following steps: receiving a system call request; executing a preset first instruction, so that the system call request runs in a host operating system to complete a system call operation. By using the above scheme, the processing efficiency of the system call can be improved.

Description

Technical Field

[0001] This specification relates to the field of computer virtualization technology, and in particular to a system call processing method and processing device. Background Technology

[0002] From a software perspective, existing computers can be broadly considered to consist of an operating system (OS) and applications. The operating system is a computer program that manages computer hardware and software resources, such as the Windows operating system and the Linux operating system. Applications are computer programs that perform specific tasks; in layman's terms, they are the tools used on a computer, such as office software and browsers.

[0003] Virtualization technology allows the abstraction of one or more virtual computers, or virtual machines (VMs), onto physical hardware, thereby improving the utilization efficiency of physical resources. For a physical computer, a virtual machine is an application running on it; unlike a regular application, it includes both an operating system and the application itself.

[0004] After virtualization, the physical computer can be called the host machine, the operating system running on the physical computer can be called the host operating system (host OS), the virtual machine running on the physical computer can be called the guest machine, and the operating system running on the virtual machine can be called the guest operating system (guest OS).

[0005] In current computer architectures, applications cannot directly use the operating system's physical resources. Instead, they request these resources from the operating system via system calls, which then execute the relevant hardware functions. Therefore, in virtualization, if the guest operating system cannot handle a system call request from a guest application, it must exit the guest machine and return to the host machine. The host application then retrieves the unhandled system call request, informing the host operating system of the necessary requests and processing them. After processing, the host application must send a return request to the host operating system before the guest machine can re-enter.

[0006] As can be seen from the above, system call requests that the client cannot handle often involve relatively complex processing procedures, resulting in significant system overhead and affecting the efficiency of virtualization. Summary of the Invention

[0007] In view of this, embodiments of this specification provide a system call processing method and processing device, which can improve the processing efficiency of system calls.

[0008] This specification provides a system call processing method applied to a guest operating system, wherein the guest operating system runs on a client machine, and the client machine is virtualized through a physical processor with hardware virtualization capabilities. The method includes:

[0009] Receive system call requests;

[0010] The preset first instruction is executed to cause the system call request to enter the main operating system for execution, so as to complete the system call operation.

[0011] Optionally, before executing the preset first instruction, the system call processing method further includes:

[0012] The system call request was determined to be outside the processing authority.

[0013] Optionally, the client is configured in an isolated environment; determining that the system call request exceeds processing permissions includes:

[0014] Based on the isolation configuration information, it was determined that the system call request exceeded the processing authority.

[0015] Optionally, the system call processing method further includes:

[0016] The system call operation result fed back by the main operating system is obtained through a preset second instruction;

[0017] The second instruction is executed by the main operating system after the system call operation is completed.

[0018] This specification also provides a system call processing method applied to an operating system running on a physical processor with hardware virtualization capabilities, including a guest operating system and a host operating system, wherein: the host operating system runs on a host machine; the guest operating system runs on a guest machine obtained through physical processor virtualization; the method includes:

[0019] The guest operating system receives system call requests from guest applications;

[0020] The guest operating system executes a preset first instruction, causing the system call request to be executed in the main operating system;

[0021] The main operating system responds to the system call request and performs a system call operation.

[0022] Optionally, the system call processing method further includes:

[0023] After completing the system call operation, the main operating system sends the system call operation result back to the corresponding guest operating system through a preset second instruction.

[0024] This specification also provides a processing apparatus, including:

[0025] A storage module adapted to store an instruction set capable of running on a physical processor, the instruction set including a first instruction;

[0026] A physical processor with hardware virtualization capabilities is suitable for virtualizing a guest machine in user mode. The guest machine includes a guest operating system and guest applications. The guest operating system is adapted to receive system call requests from the guest applications and execute a preset first instruction to cause the system call request to run in the kernel-mode main operating system to complete the system call operation.

[0027] Optionally, the physical processor sets up a client in the isolated environment running in user mode, and the client operating system is adapted to determine whether the system call request exceeds the processing permissions based on the isolation configuration information.

[0028] Optionally, the physical processor implements the isolation environment through the user-space configurable kernel module, which, after configuration, runs the guest operating system of the client machine.

[0029] Optionally, the instruction set may further include a second instruction;

[0030] After completing the system call operation, the main operating system sends the system call operation result back to the corresponding guest operating system via the second instruction.

[0031] The system call processing scheme adopted in the embodiments of this specification allows the guest operating system to switch the runtime environment to the host operating system through a first instruction, so that the system call request can run directly on the host operating system. This allows the host operating system to directly perform system call operations without having to call through the host application, avoiding multiple switching and instruction interactions between the host application and the host operating system, saving system call processing time and improving system call processing efficiency. Attached Figure Description

[0032] To more clearly illustrate the technical solutions of the embodiments of this specification, the drawings used in the description of the embodiments of this specification or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 This is a flowchart of a system call processing method in an embodiment of this specification.

[0034] Figure 2 This is a flowchart of another system call processing method in the embodiments of this specification.

[0035] Figure 3 This is a flowchart of another system call processing method in the embodiments of this specification.

[0036] Figure 4 It is an existing system call processing flowchart based on gVisor.

[0037] Figure 5 This is a flowchart of a system call processing procedure based on gVisor, as described in an embodiment of this specification.

[0038] Figure 6 This is a flowchart of another system call processing method in the embodiments of this specification.

[0039] Figure 7 This is a structural block diagram of the processing device in the embodiments of this specification. Detailed Implementation

[0040] As described in the background section, in a virtualized operating environment, when a guest application issues a system call request that the guest operating system cannot handle, it often needs to exit to the host machine for processing. This involves multiple switching and instruction interactions between the host operating system and the host machine's applications, which is too complex, has a large system overhead, and affects the efficiency of virtualization.

[0041] To address the aforementioned technical issues, this embodiment employs instructions provided by a physical processor with hardware virtualization capabilities to convert the operating environment from the guest operating system to the host operating system. Consequently, system call requests can be directly transferred from the guest operating system to the host operating system, which can also directly perform system call operations without needing to be invoked through the host application. This avoids multiple interactions between the host application and the host operating system, saves system call processing time, and improves system call processing efficiency.

[0042] It is understood that, for ease of description, in the embodiments of this specification, the application running on the client machine is referred to as the guest application, and the application running on the host machine is referred to as the main application. There is no limitation on the primary or secondary, order or importance between the guest application and the main application.

[0043] To make the objectives, technical solutions, and advantages of the embodiments in this specification clearer, the technical solutions of the embodiments in this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments in this specification. All other embodiments obtained by those skilled in the art based on the described embodiments in this specification without creative effort are within the scope of protection of this specification.

[0044] From the client's perspective, refer to Figure 1 The flowchart illustrates a system call processing method, which can be applied to a guest operating system. The guest operating system runs on a client machine, which is virtualized using a physical processor with hardware virtualization capabilities. In embodiments of this specification, the method may include the following steps:

[0045] S01, receive system call request.

[0046] The system call request includes: access operations, such as read operations, write operations, open operations, etc., at least one or more of these.

[0047] In a specific implementation, the client machine may include virtual resources such as virtual processors, virtual memory, and virtual peripherals. These virtual resources are obtained through hardware-assisted virtualization of the physical processor. In order to use the virtual resources of the client machine, the client application needs to send system call requests to the client operating system.

[0048] S02, execute the preset first instruction to cause the system call request to enter the main operating system for execution, so as to complete the system call operation.

[0049] The system call processing scheme adopted in the embodiments of this specification allows the guest operating system to switch the runtime environment to the host operating system through a first instruction, so that the system call request can run directly on the host operating system. This allows the host operating system to directly perform system call operations without having to call through the host application, avoiding multiple switching and instruction interactions between the host application and the host operating system, saving system call processing time and improving system call processing efficiency.

[0050] In specific implementations, the first instruction is provided by a physical processor with hardware virtualization capabilities and can be stored in the instruction set of the physical processor. Further, the first instruction can be an assembly instruction. Depending on the type of physical processor used in the actual scenario, the first instruction can correspond to different opcodes. For example, the opcode of the first instruction on one processor might be 0F 01D9, while on another processor it might be 0F 01C1. This specification does not impose specific limitations on the opcode corresponding to the first instruction in the embodiments.

[0051] It is understood that in practical applications, the name of the first instruction may be different in different types of physical processors. As long as it can realize the function of system call request from guest operating system to host operating system, it can be considered as the first instruction described in the embodiments of this specification.

[0052] For example, in one feasible operation, the first instruction can be a VMMCALL instruction. By executing the VMMCALL instruction, the guest operating system can directly switch the runtime environment to the host operating system, allowing system call requests to run in the host operating system. The host operating system then performs system call operations based on the running system call requests, completing the processing of the system call requests. This specification does not impose specific limitations on the name of the first instruction in the embodiments.

[0053] In practice, before the change of operating environment, the guest operating system can configure the hardware registers in the physical processor so that the information in the hardware registers is adapted to the host operating system. Then, the guest operating system can change the operating environment to the host operating system by executing the first instruction.

[0054] In practical implementation, to avoid multiple switching and command interactions between the main application and the main operating system during the client access process, and to improve the processing efficiency of system calls, such as... Figure 2 The diagram shows a flowchart of another system call processing method applied to a guest operating system. Steps S01 and S02 can be referred to the descriptions in the relevant sections above, and will not be repeated here. The method also includes:

[0055] S11, obtain the system call operation result fed back by the main operating system through the preset second instruction.

[0056] The second instruction is executed by the main operating system after the system call operation is completed.

[0057] In specific implementations, the second instruction is provided by a physical processor with hardware virtualization capabilities and can be stored in the instruction set of the physical processor. Further, the second instruction can be an assembly instruction. Depending on the type of physical processor used in the actual scenario, the second instruction can correspond to different opcodes. For example, the opcode of the second instruction on a certain processor can be 0F 01D8. This specification does not impose specific limitations on the opcode corresponding to the second instruction in the embodiments.

[0058] In practice, in order to enable the main operating system to automatically switch its runtime environment and enter the corresponding client after completing the system call operation, instead of switching the runtime environment after the main application initiates a return request, the code for requesting the return to the client can be stored in the corresponding code area of ​​the main operating system. Thus, after the main operating system completes the system call operation, by executing the code for requesting the return to the client, a return request is directly generated in the main operating system, enabling the main operating system to perform the corresponding return to the client operation.

[0059] It is understood that in practical applications, the name of the second instruction may be different in different types of physical processors. As long as it can realize the function of the host operating system to feed back the system call operation result to the corresponding guest operating system, it can be considered as the second instruction described in the embodiments of this specification.

[0060] For example, in one feasible operation, the second instruction can be a VMRUN instruction, by which the host operating system can switch the runtime environment from the host operating system to the guest operating system of the client machine corresponding to the system call request. This specification does not impose specific limitations on the name of the second instruction in the embodiments.

[0061] In practice, before the conversion of the operating environment, the host operating system can configure the hardware registers in the physical processor so that the information in the hardware registers is adapted to the guest operating system. Then, the host operating system can convert the operating environment to the host operating system by executing a second instruction.

[0062] In practice, after the runtime environment enters the guest operating system, the guest operating system can provide feedback on the system call operation results to the guest application, enabling the guest application to perform subsequent operations.

[0063] For example, in a guest application, a task executes three steps, a, b, and c, sequentially. Steps a and c use virtual resources, which can be processed by executing corresponding code within the guest application. Step b requires physical resources. When processing step b, the guest application sends a system call request to the guest operating system. If the guest operating system cannot process the system call request, a first instruction is needed to redirect the system call request to the host operating system. The host operating system then executes corresponding code to process the system call request for step b. After the host operating system completes processing the system call request, a second instruction is executed to switch the runtime environment to the guest operating system corresponding to the system call request. The guest operating system then continues executing corresponding code to complete step b and proceeds to process step c.

[0064] Optionally, before switching the operating environment from the guest operating system to the host operating system, guest information can be stored in the hardware storage module of the physical processor to facilitate subsequent re-virtualization and obtain the guest corresponding to the system call request. After completing the system call request, the host operating system loads the guest information stored in the hardware storage module, sets the virtual processor as the virtual hardware of the guest, runs the guest operating system, and then the host operating system enters the guest operating system by calling the second instruction.

[0065] In practical implementation, the client and host machines can run in different operating modes of the physical processor. The operating mode of the physical processor determines the program's runtime environment. Specifically, the operating modes of the physical processor can include: a first operating mode and a second operating mode. When the physical processor is in the first operating mode, the program runs on the client machine, and the physical processor executes the guest operating system code to implement the guest operating system on the client machine. When the physical processor is in the second operating mode, the program runs on the host operating system, and the physical processor executes the host operating system code to implement the host operating system on the host machine.

[0066] Based on this, the guest operating system executes a preset first instruction to cause the system call request to run in the host operating system. Specifically, this may include: the guest operating system switching the physical processor's operating mode from a first operating mode to a second operating mode through the first instruction, the physical processor executing the host operating system's code, thereby causing the system call request to run in the host operating system, and the host operating system completing the processing of the system call request.

[0067] The guest operating system obtains the system call operation results fed back by the host operating system through the second instruction. Specifically, this may include: the guest operating system switching the working mode of the physical processor from the second working mode to the first working mode through the second instruction; the physical processor executing the code of the guest operating system; thereby switching the running environment to the guest operating system; and the guest operating system obtaining the system call operation results of the host operating system.

[0068] Optionally, before the physical processor switches from the first working mode to the second working mode, client information can be stored in the hardware register of the physical processor to facilitate subsequent re-virtualization and obtain the client corresponding to the system call request.

[0069] It is understood that in practical applications, the names of the operating modes of the physical processor may differ across different types of physical processors. As long as the operating mode can distinguish the program's runtime environment, it can be considered the operating mode described in the embodiments of this specification. For example, in one feasible operation, the first operating mode can be called non-root mode, and the second mode can be called root mode; as another example, in one feasible operation, the first operating mode can be called guest mode, and the second mode can be called host mode. The embodiments of this specification do not impose any limitations on this.

[0070] In practice, if all system call requests from guest applications are handled by the main operating system, it will reduce the overall efficiency of the computer and make the main operating system vulnerable to security vulnerabilities and attacks by malicious programs. Therefore, physical resources can be divided so that the guest operating system can use some of the physical resources. When the guest operating system receives system call requests corresponding to these physical resources, it can process these system call requests.

[0071] In other words, depending on the types of physical resources that the guest operating system is allowed to use directly, the guest operating system has processing permissions. When a system call request initiated by a guest application corresponds to a type of physical resource that the guest operating system is allowed to use, the system call request does not exceed the processing permissions, and the guest operating system can process it. When a system call request initiated by a guest application corresponds to a type of physical resource that the guest operating system is not allowed to use, the system call request exceeds the processing permissions, and the guest operating system cannot process it.

[0072] Based on the above description, if the guest operating system is allowed to directly use at least a portion of the physical resources, the following steps may also be included before executing the preset first instruction:

[0073] Determine whether the system call request exceeds the processing permissions.

[0074] Therefore, system call requests that exceed the processing authority of the guest operating system are processed by the host operating system, while system call requests that do not exceed the processing authority of the guest operating system are processed by the guest operating system itself.

[0075] For example, such as Figure 3 The diagram shows a flowchart of another system call processing method. Between steps S01 and S02, there is also step S21: determine whether the system call request exceeds the processing permission. If so, execute step S02; otherwise, execute step S22, and the guest operating system processes the system call request to complete the system call operation.

[0076] In practice, to improve the security of the virtualization runtime environment and prevent malicious code on the client machine from accessing the host machine, some isolation methods can be used to provide an independent and secure runtime environment for programs running on the client machine.

[0077] For example, by setting up the client in a container, the virtual resources of a single client operating system can be effectively isolated into isolated groups, so as to better balance conflicting physical resource usage demands among the isolated groups.

[0078] For example, the client machine can be set up in a sandbox, so that at least some of the programs in the client machine run in the isolated environment provided by the sandbox, without being handled by the host machine.

[0079] Based on the above description, the processing permissions of the guest operating system are determined by the isolation configuration information. After determining that the system call request exceeds the processing permissions according to the isolation configuration information, the guest operating system can call the first instruction to switch the running environment to the guest operating system, so that the system call request runs directly in the host operating system and is processed by the host operating system.

[0080] It should be noted that regardless of whether a container, sandbox, or a combination of both is used for isolation, the problems described in the background technology still exist for system call requests that the client cannot handle. The following will explain this in detail through a specific application scenario.

[0081] In one embodiment, such as Figure 4 The diagram shown is a flowchart of an existing system call processing flow based on gVisor. gVisor is a sandbox, with the virtual machine set up within it. gVisor can handle some system call requests from guest applications.

[0082] Specifically, gVisor is based on a fully virtualized architecture, such as a kernel-based Virtual Machine (KVM). It can obtain system call requests sent by guest applications through system call instructions (such as the SYSCALL instruction) and hand them over to the kernel module sentry in gVisor for processing. sentry is the guest operating system of the guest application.

[0083] However, Sentry has restrictions on access to physical resources. When Sentry cannot access the physical resources requested by a guest application, the system call request exceeds Sentry's processing authority and needs to be processed by the host operating system with higher privileges.

[0084] If sentry cannot handle system call request A from the guest application, sentry will use an exit instruction (such as the HLT instruction) to cause the physical processor to exit from guest mode and enter host mode. Since this is only a switch in working mode, and from the perspective of the host machine, gVisor and its contained guests are just a main application, after exiting gVisor, system call request A will run in the main application.

[0085] After the physical processor enters host mode, the main operating system completes the processing of exit instructions (such as the HLT instruction). Since system call request A runs in the main application, the main operating system is unaware of the system call request that needs to be processed. The main operating system needs to return to the main application via a return instruction (such as the SYSRET instruction). The main application then sends system call request A to the main operating system via a system call instruction (such as the SYSCALL instruction), and the main operating system processes system call request A.

[0086] After system call request A is processed, from the perspective of the host operating system, it is the system call request initiated by the host application. Therefore, the host operating system sends a return instruction (such as the SYSRET instruction) to the host application to indicate that processing is complete. The host application then sends a request to the host operating system to invoke virtualization runtime instructions (such as the VMRUN instruction), which is equivalent to sending system call request B to the host operating system again, causing the host operating system to return to the corresponding guest (i.e., the guest in gVisor). After the host operating system processes the VMRUN instruction, the physical processor exits from host mode and enters guest mode; the runtime environment returns to the guest operating system in gVisor, and the guest operating system returns to the guest application via a return instruction (such as the SYSRET instruction) to perform subsequent operations.

[0087] Combination Figure 4As described above, when the guest operating system cannot handle system call requests issued by the guest application, multiple switches and command interactions between the host operating system and the host application are required (e.g., ...). Figure 4 The part shown in the dashed box at the midpoint is used to handle system call requests. The process is too complicated, the system overhead is large, and it affects the efficiency of virtualization.

[0088] In practical applications, the system call processing method provided in the embodiments of this specification can avoid multiple switching and command interactions between the main operating system and the main application.

[0089] Continuing with the example of gVisor-based computer virtualization, such as... Figure 5 The diagram shows a system call processing flowchart based on gVisor using the system call method provided in the embodiments of this specification. Assuming that sentry cannot process system call request A sent by a guest application through a system call instruction (such as the SYSCALL instruction), sentry uses a first instruction (such as the VMMCALL instruction) to switch the physical processor from guest mode to host mode, and switches the running environment to the host operating system, so that the system call request A can run directly in the host operating system.

[0090] After the host operating system completes the processing of system call request A, it generates a return request based on the code for returning the request to the guest stored in the corresponding code area of ​​the host operating system. The host operating system executes the second instruction, returns to the guest in gVisor, and causes the physical processor to exit from host mode and enter guest mode. The runtime environment returns to the guest operating system in gVisor, and the guest operating system returns to the guest application through a return instruction (such as the SYSRET instruction) to perform subsequent operations.

[0091] As can be seen from the above, by calling the first instruction, the main operating system can directly process the system call request. After completing the processing of the system call request, the main operating system can directly re-enter gVisor through the second instruction, thereby avoiding multiple switching between the main operating system and the main application. This optimizes the main operating system's processing of system call requests and requests to return gVisor, reduces the time for processing gVisor system calls, and improves the processing efficiency of system calls.

[0092] It is understood that the above description provides multiple embodiment solutions, and the optional methods described in each embodiment solution can be combined and cross-referenced with each other without conflict, thereby extending to a variety of possible embodiment solutions, all of which can be considered as the embodiment solutions disclosed and made public in this specification.

[0093] To enable those skilled in the art to better understand and implement the concepts, implementation schemes, and advantages of the embodiments in this specification, the operating system process will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0094] In one specific embodiment, such as Figure 6 The diagram shown is a flowchart of another system call processing method in an embodiment of this specification. The method is applied to an operating system, which runs on a physical processor with hardware virtualization capabilities. The operating system includes a guest operating system and a host operating system, wherein the host operating system runs on a host machine, and the guest operating system runs on a guest machine obtained through physical processor virtualization.

[0095] Reference Figure 6 The system call processing method may include the following steps:

[0096] S31, the guest operating system receives a system call request from the guest application.

[0097] S32, the guest operating system executes a preset first instruction, causing the system call request to be executed in the main operating system.

[0098] S33, the main operating system responds to the system call request and performs a system call operation.

[0099] S34, after the main operating system completes the system call operation, it sends the system call operation result back to the corresponding guest operating system through a preset second instruction.

[0100] It is understood that the above steps can be referred to the descriptions in the relevant content, and will not be repeated here.

[0101] This specification also provides a processing device corresponding to the above-described system call processing method, which will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that the processing device described below can be considered as the hardware required to implement the system call processing method provided in this specification; the content of the processing device described below can be referred to in correspondence with the content of the system call processing method described above.

[0102] In practical applications, computer architecture can be divided into two permission states: user mode (also known as user space) and kernel mode (also known as kernel space). By using different permission states, access control can be implemented for programs, ensuring that different programs can only access the physical resources that their permissions allow, thereby reducing access conflicts and usage conflicts of limited resources.

[0103] Kernel mode has higher privileges than user mode. To enable user-mode programs to use kernel-mode physical resources, kernel mode provides access interfaces for user-mode programs, which are accessed through system calls. Specifically, when a user-mode program initiates a system call request, the privilege state switches from user mode to kernel mode, and the program jumps to the kernel code location corresponding to the system call request for execution. After execution is complete, the program returns from kernel mode to user mode.

[0104] In practice, the operating system runs in kernel mode, while applications run in user mode. Operating systems have higher privileges than user programs. Applications cannot directly use the operating system's physical resources; instead, they request these resources from the operating system through system calls. Accordingly, in virtualization, the main operating system runs in kernel mode, while the main application and guest applications run in user mode.

[0105] In specific implementation, refer to Figure 7 The diagram shows a structural block diagram of a processing device 70, which may include a storage module 71 and a physical processor 72, wherein:

[0106] The storage module 71 is adapted to store an instruction set that can run on a physical processor, the instruction set including a first instruction;

[0107] The physical processor 72 has hardware virtualization capabilities and virtualizes a guest machine in user mode. The guest machine includes a guest operating system and a guest application. The guest operating system is adapted to receive system call requests from the guest application, execute a preset first instruction, and cause the system call request to run in the kernel mode of the main operating system to complete the system call operation.

[0108] The system call processing device in the embodiments of this specification performs system call processing. The guest operating system converts the running environment to the host operating system through a first instruction, so that the system call request can run directly on the host operating system. This allows the host operating system to directly perform system call operations without having to call through the host application, avoiding multiple switching and instruction interactions between the host application and the host operating system, saving system call processing time and improving system call processing efficiency.

[0109] In specific implementations, the physical processor can be a processor with a single processor core or a processor with multiple processor cores. This specification does not impose any limitations on the embodiments described herein.

[0110] In specific implementation, the system call request includes: access operations, such as at least one of read operations, write operations, and open operations.

[0111] In practical implementation, the client machine may include virtual resources such as virtual processors, virtual memory, and virtual peripherals. These virtual resources are obtained through hardware-assisted virtualization of the physical processor. Access control also exists within the client machine. In order to use the client machine's virtual resources, the client application needs to send a system call request to the client operating system. Therefore, the client operating system and the client application need to be in different access control states.

[0112] In practice, the first instruction can be an assembly instruction. Depending on the type of physical processor used in the actual scenario, the first instruction can correspond to different opcodes. For details, please refer to the relevant parts mentioned above, which will not be repeated here.

[0113] It is understood that in practical applications, the name of the first instruction may be different in different types of physical processors. As long as it can realize the function of system call request from guest operating system to host operating system, it can be considered as the first instruction described in the embodiments of this specification.

[0114] In a specific implementation, the instruction set also includes a second instruction. After completing the system call operation, the main operating system running in the physical processor uses the second instruction to send the system call operation result back to the corresponding guest operating system.

[0115] In order to enable the main operating system to automatically switch its runtime environment and enter the corresponding client after completing the system call operation, instead of switching the runtime environment after the main application initiates a return request, the code for requesting the return to the client can be stored in the code area corresponding to the main operating system. In other words, the code for requesting the return to the client is stored as kernel code in the code area corresponding to the kernel mode. Thus, after the main operating system completes the system call operation, by executing the code for requesting the return to the client, a return request is directly generated in the main operating system, causing the main operating system to perform the corresponding return to the client operation.

[0116] By adopting the above solution, multiple switching and command interactions between the main application and the main operating system during the process of entering the client can be avoided, thereby improving the processing efficiency of system calls.

[0117] In practice, the second instruction is an assembly instruction. Depending on the type of physical processor used in the actual scenario, the second instruction may correspond to different opcodes. For details, please refer to the relevant sections above, which will not be repeated here.

[0118] It is understood that in practical applications, the name of the second instruction may be different in different types of physical processors. As long as it can realize the function of the host operating system to feed back the system call operation result to the corresponding guest operating system, it can be considered as the second instruction described in the embodiments of this specification.

[0119] In practical implementation, the client and host machines can run in different operating modes of the physical processor. The operating mode of the physical processor determines the program's runtime environment. Specifically, the operating modes of the physical processor can include: a first operating mode and a second operating mode. When the physical processor is in the first operating mode, the program runs on the client machine, and the physical processor executes the code of the guest operating system to implement the guest operating system on the client machine. When the physical processor is in the second operating mode, the program runs on the host operating system, and the physical processor executes the code of the host operating system to implement the host operating system on the host machine. For details, please refer to the description of the relevant embodiments above, which will not be repeated here.

[0120] In a specific implementation, the physical processor sets up a client in the isolated environment running in user mode, and the client operating system is adapted to determine whether the system call request exceeds the processing authority based on the isolation configuration information.

[0121] In specific implementation, the physical processor implements the isolation environment through a user-space configurable kernel module, which, after configuration, runs the guest operating system of the client machine. For details, please refer to the descriptions of the relevant embodiments above; further elaboration will not be repeated here.

[0122] Virtualization technology enables access control on the guest machine, where the guest operating system has higher privileges than guest applications, and the guest operating system and guest applications need to be in different privilege states. For ease of description, the user mode and kernel mode in the host machine can be referred to as the main user mode (Host Ring 3, HR3) and the main kernel mode (Host Ring 0, HR0), respectively, and the user mode and kernel mode in the guest machine can be referred to as the guest user mode (Guest Ring 3, GR3) and the guest kernel mode (Guest Ring 0, GR0), respectively.

[0123] Essentially, there are still only two permission states: user mode and kernel mode. However, since physical processors have two operating modes, these two permission states combine to form four permission states. For example, the user mode and kernel mode of a physical processor in its first operating mode can be considered as guest user mode and guest kernel mode, and the user mode and kernel mode of a physical processor in its second operating mode can be considered as master user mode and master kernel mode.

[0124] To enable those skilled in the art to more clearly understand the technical solutions and advantages of the embodiments in this specification, the above-described gVisor-based computer virtualization embodiments will continue to be described in conjunction with reference to... Figure 5 The main operating system is in main kernel mode HR0, the main application is in main user mode HR3, the guest operating system sentry is in guest kernel mode GR0, and the guest application is in guest user mode GR3.

[0125] In the processing apparatus provided in the embodiments of this specification, the physical processor has a sandbox gVisor set in the main user mode HR3, and a guest is virtualized in gVisor, wherein the guest application is in the guest user mode GR3, and the kernel module sentry, as the guest operating system, is in the guest kernel mode GR0.

[0126] The system call request from the guest application is sent to the sentry. If the sentry cannot handle the system call request, it uses a first instruction (such as the VMMCALL instruction) to cause the physical processor to exit the guest mode and enter the host mode, and the runtime environment changes from the guest operating system to the host operating system.

[0127] In Host mode, after receiving the first instruction (such as the VMMCALL instruction), the host operating system enters the system call handling function to process the system call request. After the system call request is processed, based on the request return code for the guest machine in the host kernel mode HR0, a return request is directly generated in the host operating system. This allows the host operating system to prepare to re-enter the guest machine, such as loading the guest machine information and setting the virtual processor mode obtained through virtualization to Guest. Then, by calling the second instruction (such as the VMRUN instruction), the host enters the guest machine and completes the system call request process.

[0128] By adopting the above scheme, the system call request is processed in the main kernel mode by calling the first instruction, and then the system call request is processed in the main kernel mode. Finally, the system call request is re-entered in the gvisor by the second instruction. This reduces the number of switching and instruction interaction between the main user mode and the main kernel mode, reduces the time that the system call request needs to be processed in the gvisor, and improves the efficiency of system call processing.

[0129] In practical applications, the processing device can be a system-on-a-chip, a processing chip, etc., and this specification does not limit it.

[0130] It is understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. Furthermore, the terms "first," "second," etc., are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein.

[0131] While the embodiments disclosed in this specification are as described above, they are not limited thereto. Any person skilled in the art can make various modifications and alterations without departing from the spirit and scope of the embodiments in this specification. Therefore, the scope of protection of the embodiments in this specification should be determined by the scope defined in the claims.

Claims

1. A system call processing method, characterized in that, Applied to a guest operating system, wherein the guest operating system runs on a guest machine, and the guest machine is virtualized through a physical processor with hardware virtualization capabilities, the method includes: Receive system call requests; Configure the hardware registers in the physical processor so that the information in the hardware registers is adapted to the main operating system, execute the preset first instruction, convert the running environment to the main operating system, and make the system call request run in the main operating system to complete the system call operation; Obtain the system call operation result fed back by the main operating system; wherein, after completing the system call operation, the main operating system feeds back the system call operation result to the corresponding guest operating system through a preset second instruction, and the main operating system switches the running environment from the main operating system to the guest operating system of the client corresponding to the system call request by executing the second instruction.

2. The system call processing method according to claim 1, characterized in that, Before executing the preset first instruction, the following is also included: The system call request was determined to be outside the processing authority.

3. The system call processing method according to claim 2, characterized in that, The client machine is set up in an isolated environment; Determining that the system call request exceeds processing permissions includes: Based on the isolation configuration information, it was determined that the system call request exceeded the processing authority.

4. A system call processing method, characterized in that, The method applies to an operating system that runs on a physical processor with hardware virtualization capabilities, including a guest operating system and a host operating system, wherein: the host operating system runs on a host machine; and the guest operating system runs on a guest machine obtained through physical processor virtualization; the method includes: The guest operating system receives system call requests from guest applications; The guest operating system configures the hardware registers in the physical processor so that the information in the hardware registers is adapted to the host operating system, executes a preset first instruction, converts the running environment to the host operating system, and causes the system call request to run in the host operating system. The host operating system responds to the system call request by performing a system call operation; after completing the system call operation, it sends the system call operation result back to the corresponding guest operating system through a preset second instruction; the host operating system switches the running environment from the host operating system to the guest operating system of the client machine corresponding to the system call request by executing the second instruction.

5. A processing apparatus, characterized in that, include: A storage module adapted to store an instruction set capable of running on a physical processor, the instruction set including a first instruction; A physical processor with hardware virtualization capabilities is suitable for virtualizing a guest machine in user mode. The guest machine includes a guest operating system and a guest application. The guest operating system is adapted to receive system call requests from the guest application, configure the hardware registers in the physical processor so that the information in the hardware registers is adapted to the host operating system, and execute a preset first instruction to convert the running environment into the host operating system, so that the system call request enters the kernel-mode host operating system to run and complete the system call operation. The instruction set also includes a second instruction; after completing the system call operation, the main operating system sends the system call operation result back to the corresponding guest operating system through the preset second instruction. The main operating system switches the runtime environment from the main operating system to the guest operating system of the client machine corresponding to the system call request by executing the second instruction.

6. The processing apparatus according to claim 5, characterized in that, The physical processor sets up a client in the isolated environment running in user mode, and the client operating system is adapted to determine whether the system call request exceeds the processing authority based on the isolation configuration information.

7. The processing apparatus according to claim 6, characterized in that, The physical processor implements the isolation environment through the user-mode configurable kernel module, which, after configuration, runs the guest operating system of the client machine.

Images