Confidential virtual machine operating system, system call proxy method, terminal and medium

Abstract

The invention discloses a confidential virtual machine operating system, a system call proxy method, a terminal and a medium, the system comprises: a RipOS operating system, the RipOS operating system is used for processing a first class call item implemented inside the RipOS operating system, the first class call item reflects a function item called when the RipOS operating system runs; the system comprises a RipOS operating system and a ServiceOS operating system, the ServiceOS operating system is used for carrying out proxy processing on a second type of calling items, and the second type of calling items are function items which are initiated by the RipOS operating system and are subjected to confidentiality verification and integrity verification. Core system calling is processed through the RipOS operating system, system calling needing to be agented is processed through the ServiceOS operating system, the trusted computing base of the confidential virtual machine is greatly reduced, the security risk is reduced, the defense capacity for external attacks is enhanced, and the overall security and resource utilization efficiency of the system are improved.

Description

Technical Field

[0001] The present invention relates to the fields of computer technology and information security technology, and in particular to a confidential virtual machine operating system, a system call proxy method, a terminal and a medium. Background Art

[0002] In the field of confidential computing, deploying the Linux kernel in a confidential virtual machine is widely adopted as a common solution to protect sensitive data from unauthorized access. However, this method is not robust enough, and because the Linux kernel is written in a programming language that may have security risks and has a large source code size of tens of millions of lines, it is vulnerable to memory safety vulnerabilities and multi-threaded concurrency defects, making it difficult to conduct a comprehensive security review and unsuitable as a trusted computing foundation for confidential virtual machines. In addition, the design concept of the Linux kernel follows the architectural principles of traditional operating systems, and achieves isolation between applications through permission separation between user space and kernel space and a virtual memory management system, relying on services provided by system software at a higher permission level. This design does not specifically consider the threat environment unique to confidential virtual machines, and attackers may illegally access data inside confidential virtual machines through system interfaces and other means.

[0003] Therefore, the prior art still needs to be improved and enhanced. Summary of the invention

[0004] The technical problem to be solved by the present invention is that, in view of the above-mentioned defects of the prior art, a confidential virtual machine operating system, a system call proxy method, a terminal and a medium are provided, aiming to solve the security problems caused by memory security, concurrency defects and difficulty in comprehensive auditing in the traditional Linux kernel in the confidential virtual machine, as well as the problem of insufficient confidentiality and integrity verification of system calls.

[0005] In order to solve the above technical problems, the technical solution adopted by the present invention is as follows: In a first aspect, the present invention provides a confidential virtual machine operating system, wherein the system comprises: RipOS operating system, the RipOS operating system is used to process the first type of call items that must be implemented inside the RipOS operating system, the first type of call items reflecting the function items called by the RipOS operating system; The ServiceOS operating system is used to perform proxy processing on the second type of call items, where the second type of call items are function items initiated by the RipOS operating system and have undergone confidentiality verification and integrity verification.

[0006] In one implementation, the RipOS operating system includes a system call processor and a system call proxy module; the system call processor is used to receive a system call request issued by a user program and send the system call request to the system call proxy module; The system call proxy module includes a system call state machine, a system call verification module and a system call conversion module; the system call state machine is used to save the call execution state of the RipOS operating system; the system call verification module is used to apply for the call execution state of the RipOS operating system from the system call state machine, and check whether the number and parameters of the RipOS operating system call conform to the semantics of the RipOS operating system call; the system call conversion module is used to take confidentiality protection measures for the system call parameters and apply for a message structure in the shared memory; The ServiceOS operating system includes a system call handler; the system call handler is used to read the message structure from the shared memory, read the information of the system call request to be processed from the message structure, and convert the information of the system call request to be processed into a corresponding POSIX function on the Linux system.

[0007] In a second aspect, an embodiment of the present invention further provides a system call proxy method based on the confidential virtual machine operating system, wherein the method comprises: Obtaining a system call request issued by a user program through the RipOS operating system, and applying for a message structure in a shared memory based on the system call request; The message structure is read based on the ServiceOS operating system to complete the calling of the second type of calling items, where the second type of calling items are function items initiated by the RipOS operating system and have undergone confidentiality verification and integrity verification.

[0008] In one implementation, the RipOS operating system includes a system call proxy module and a system call processor; the system call proxy module includes: a system call state machine, a system call verification module and a system call conversion module; the ServiceOS operating system includes a system call handler.

[0009] In one implementation, obtaining a system call request issued by a user program through the RipOS operating system and applying for a message structure in a shared memory based on the system call request includes: Receiving a system call request from a user program through a system call processor, and sending the system call request to a system call proxy module; The system call proxy module is used to verify the validity of the system call request. After successful verification, confidentiality protection measures are taken for system call parameters, and a message structure is applied for in a shared memory.

[0010] In one implementation, the ServiceOS operating system reads the message structure to complete the calling of the second type of calling item, including: Start the system call handler based on the ServiceOS operating system; Using the system call processing program to read the message structure from the shared memory, read the information of the system call request to be processed from the message structure, and convert the information of the system call request to be processed into a corresponding POSIX function on the Linux system; The underlying Linux kernel is called to process the POSIX function to complete the calling of the second type of call item.

[0011] In one implementation, the using the system call proxy module to verify the validity of the system call request, taking confidentiality protection measures for the system call parameters after successful verification, and applying for a message structure in a shared memory includes: Using the system call verification module to apply for the call execution status of the RipOS operating system to the system call state machine, and check whether the number and parameters of the RipOS operating system call conform to the semantics of the RipOS operating system call; If the call execution status is ready and the semantics are correct, confidentiality protection measures are taken for the system call parameters based on the system call conversion module, and a message structure is applied for in the shared memory. The message structure includes the number, parameters and data of the system call request.

[0012] In one implementation, the process of completing the calling of the second type of calling item further includes: Obtaining the return value and data generated by the Linux kernel; Using the system call processing program to write the return value and the data back to the message structure, and modifying the call execution state of the RipOS operating system to a responded state; Based on the responded status, the return value and the data are verified by the system call verification module, and the verified return value and data are sent to the user program.

[0013] In a third aspect, an embodiment of the present invention further provides a terminal, wherein the terminal includes a memory, a processor, and a system call proxy program stored in the memory and capable of running on the processor, and when the processor executes the system call proxy program, the steps of the system call proxy method of any one of the above schemes are implemented.

[0014] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium, wherein a system call proxy program is stored on the computer-readable storage medium, and when the system call proxy program is executed by a processor, the steps of the system call proxy method described in any one of the above schemes are implemented.

[0015] Beneficial effects: The present invention provides a confidential virtual machine operating system. Compared with the prior art, the system includes: a RipOS operating system, the RipOS operating system is used to process the first type of call items implemented by the RipOS operating system, the first type of call items reflects the function items called by the RipOS operating system; and a ServiceOS operating system, the ServiceOS operating system is used to proxy the second type of call items, the second type of call items are initiated by the RipOS operating system and are function items that have undergone confidentiality verification and integrity verification. The present invention processes core system calls through the RipOS operating system, and the ServiceOS operating system processes system calls that need to be proxied, which greatly reduces the trusted computing base of the confidential virtual machine, reduces security risks, enhances the defense capability against external attacks, and improves the overall security and resource utilization efficiency of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 A structural diagram of a confidential virtual machine operating system provided in an embodiment of the present invention.

[0017] Figure 2 A processing flow chart of a system call proxy method based on a confidential virtual machine operating system provided in an embodiment of the present invention.

[0018] Figure 3 This is a block diagram of the internal structure principle of a terminal provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0019] In order to make the purpose, technical solution and effect of the present invention clearer and more specific, the present invention is further described in detail with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0020] In the field of confidential computing, protecting sensitive data from unauthorized access is a key requirement, and its traditional solution often relies on deploying the Linux kernel in a confidential virtual machine. Although this method can provide a certain degree of data protection, the Linux kernel uses a programming language that may have security risks and has a large source code size of tens of millions of lines, which makes it vulnerable to memory security vulnerabilities and multi-threaded concurrency defects. Therefore, it is difficult to conduct a comprehensive security review and is not suitable as a trusted computing foundation for confidential virtual machines. In addition, the design of the Linux kernel follows the architectural principles of traditional operating systems, and achieves isolation between applications through permission separation between user space and kernel space and a virtual memory management system. However, this design does not specifically consider the threat environment unique to confidential virtual machines, making it possible for attackers to illegally access data inside confidential virtual machines through system interfaces and other means.

[0021] In order to solve the above problems, this embodiment provides a confidential virtual machine operating system. When implemented, the system includes: a RipOS operating system, the RipOS operating system is used to process the first type of call items implemented by the RipOS operating system, and the first type of call items reflect the function items called by the RipOS operating system; a ServiceOS operating system, the ServiceOS operating system is used to proxy the second type of call items, and the second type of call items are initiated by the RipOS operating system and are function items that have undergone confidentiality verification and integrity verification. The present invention processes core system calls through the RipOS operating system, and the ServiceOS operating system processes system calls that need to be proxied, which greatly reduces the trusted computing base of the confidential virtual machine, reduces security risks, enhances the defense capability against external attacks, and improves the overall security and resource utilization efficiency of the system.

[0022] This embodiment provides a confidential virtual machine operating system, such as Figure 1 As shown in, the system includes: a RipOS operating system, wherein the RipOS operating system is used to process a first type of call item implemented within the RipOS operating system, wherein the first type of call item reflects a function item called by the operation of the RipOS operating system; and a ServiceOS operating system, wherein the ServiceOS operating system is used to perform proxy processing on a second type of call item, wherein the second type of call item is a function item initiated by the RipOS operating system and has undergone confidentiality verification and integrity verification.

[0023] In one implementation, the RipOS operating system includes a system call processor and a system call proxy module; the system call processor is used to receive a system call request issued by a user program and send the system call request to the system call proxy module; the system call proxy module includes a system call state machine, a system call verification module and a system call conversion module; the system call state machine is used to save the call execution state of the RipOS operating system; the system call verification module is used to apply for the call execution state of the RipOS operating system to the system call state machine, and check whether the number and parameters of the RipOS operating system call conform to the semantics of the RipOS operating system call; the system call conversion module is used to take confidentiality protection measures for the system call parameters and apply for a message structure in a shared memory; the ServiceOS operating system includes a system call handler; the system call handler is used to read the message structure from the shared memory, read the information of the system call request to be processed from the message structure, and convert the information of the system call request to be processed into a corresponding POSIX function on the Linux system.

[0024] In one implementation, the RipOS operating system runs inside a confidential virtual machine. The RipOS operating system also includes a kernel core module, which includes inter-process communication, process scheduling, and a hardware abstraction layer. The inter-process communication, process scheduling, and hardware abstraction layer specifically include functions such as startup, interruption and exception handling, and memory management, which together constitute a minimized trusted computing base, thereby reducing security risks and improving the overall security of confidential virtual machines. When a user program implements a system call of the kernel core module, it mainly includes system calls related to process management, memory management, and inter-process communication. This type of system call is a first-class call item, which is the most basic guarantee for the operating system to load and run applications and communication between applications. The RipOS operating system handles it by itself through the system call interface layer to ensure the realization of basic system functions and security. When a user program needs to make a system call to a kernel module excluded from the trusted computing base, the system call must be completed by proxy, specifically by receiving a system call request issued by the user program through a system call processor in the system call interface layer, and sending the system call request to a system call proxy module, and then the ServiceOS operating system processes the system call. In addition, the memory management module of the RipOS operating system does not include on-demand paging and swap-in and swap-out mechanisms when handling page fault exceptions, which means that user programs need to be statically linked and fully loaded into memory before running. This method reduces the complexity of memory management and improves memory access speed and system stability. The RipOS operating system does not include kernel modules such as file systems, device drivers, and network protocol stacks. The system calls corresponding to these modules are proxied to the ServiceOS operating system for processing, which not only reduces the trusted computing base, but also reduces potential security vulnerabilities and enhances the security of the system. In addition, any user and group-related kernel code will not be included in the RipOS operating system, and the RipOS operating system prohibits user input operations, further limiting the attack surface and ensuring the security and integrity of the internal data of the confidential virtual machine.

[0025] In one implementation, the ServiceOS operating system runs on a host machine or another virtual machine. The ServiceOS operating system generally uses the Linux kernel as its internal operating system. The ServiceOS operating system can not only effectively process system call requests initiated by user programs, but also process system call requests from the RipOS operating system. User programs interact with the kernel of the ServiceOS operating system through the system call interface layer of the ServiceOS operating system. The system call interface layer exposes a series of APIs (Application Programming Interfaces) upward. These APIs correspond to multiple subsystems such as inter-process communication (IPC), virtual file system (VFS), physical file system, network protocol stack, process scheduling, and hardware abstraction layer (HAL) to meet the various needs of user programs. For example, the inter-process communication subsystem supports information exchange between different processes, allowing processes to share data and synchronize operations; the virtual file system subsystem provides a unified way to access various types of storage devices; the physical file system subsystem manages actual file storage, including file creation, deletion, reading and writing operations; the network protocol stack subsystem handles network-related tasks, such as sending and receiving data packets, establishing and disconnecting network connections, etc.; the process scheduling subsystem determines which process should obtain the CPU time slice in order to fairly allocate system resources; the hardware abstraction layer (HAL) subsystem provides a standardized interface that enables software to be developed independently of the underlying hardware. The device driver in the ServiceOS operating system also plays an important role. The device driver is responsible for initializing and controlling the operation of hardware devices, ensuring accurate data transmission, and handling hardware failures. In addition, the system call handler in the ServiceOS operating system is responsible for receiving system call requests from the RipOS operating system, parsing these requests, and converting them into a format executable by the ServiceOS operating system, and then calling the system call interface layer to perform the actual operation. After the processing is completed, the system call handler returns the result to the RipOS operating system, thereby realizing seamless collaboration between the RipOS operating system and the ServiceOS operating system.

[0026] In one implementation, the confidential virtual machine operating system also includes a virtual machine manager, trusted hardware, and physical devices. The virtual machine manager serves as a bridge connecting the RipOS operating system and the ServiceOS operating system, coordinates the interaction between the two, and ensures secure access to trusted hardware and physical devices. Trusted hardware and physical devices play a vital role in the confidential virtual machine operating system. Trusted hardware provides a hardware-level security mechanism that can verify and protect sensitive data and prevent unauthorized access and tampering. Physical devices include various hardware resources, such as processors, memory, storage devices, and network interfaces, which are basic components necessary for the operation of virtual machines. The virtual machine manager interacts with these physical devices through device drivers to ensure that the virtual machine can correctly access and use these resources. Trusted hardware and physical devices work together to provide a solid foundation for the confidential virtual machine operating system, ensuring data security and system stability.

[0027] The system call proxy method based on the confidential virtual machine operating system provided in this embodiment can be applied to a smart terminal. The processing flow chart of the system call proxy method is as follows: Figure 2 As shown in , the specific steps include: Step S100: obtaining a system call request issued by a user program through the RipOS operating system, and applying for a message structure in a shared memory based on the system call request.

[0028] In this embodiment, the system call request issued by the user program is obtained through the RipOS operating system, and a message structure is applied for in the shared memory based on the system call request. This process ensures that the system call request can be passed to the ServiceOS operating system in a structured manner, and the use of the shared memory mechanism can improve the efficiency of data exchange and reduce the overhead of context switching. In addition, the RipOS operating system includes a system call proxy module and a system call processor; the system call proxy module includes a system call state machine, a system call verification module and a system call conversion module; the system call processor is used to receive the system call request issued by the user program, and send the system call request to the system call proxy module; the system call verification module is used to apply to the system call state machine for the call execution status of the RipOS operating system, and check whether the number and parameters of the RipOS operating system call conform to the semantics of the RipOS operating system call; the system call conversion module is used to make confidentiality protection measures for the system call parameters, and apply for a message structure in the shared memory; the system call state machine is used to save the call execution status of the RipOS operating system, and the system call state machine includes four parts: the first part is the file The path tree is a tree structure, each node represents a directory or a file, and is used to save the static information of the file, which includes the file name, file type, file permissions (read, write, execute) and file size; the second part is the ServiceOS operating system file descriptor table, referred to as the ServiceOS table, which mainly records the open file descriptors and corresponding file types returned by the system call handler in the ServiceOS operating system. The file types include files, directories, symbolic links, devices and sockets; the third part is the open file table, which mainly records the dynamic file information used by the file system related system calls. The dynamic file information includes the file descriptor, the file offset and the file open flag; the fourth part is the socket status table, which mainly records the socket descriptor and the corresponding socket status information.

[0029] Specifically, the step S100 includes the following steps: Step S101: receiving a system call request issued by a user program through a system call processor, and sending the system call request to a system call proxy module; Step S102: Use the system call proxy module to verify the validity of the system call request, take confidentiality protection measures for system call parameters after successful verification, and apply for a message structure in the shared memory.

[0030] In one implementation, when a user program needs to make a system call to a kernel module that is excluded from the trusted computing base, such as a read system call to read a file or a socket system call to create a socket, the system call must be completed through a proxy. First, a system call request issued by a user program is received by a system call processor, and the system call request is sent to a system call proxy module, thereby increasing the security and flexibility of the system, controlling and filtering requests entering the kernel, and reducing the risk of directly exposing kernel code; then, the system call verification module is used to apply to the system call state machine for the call execution status of the RipOS operating system, and to check whether the number and parameters of the RipOS operating system call conform to the semantics of the RipOS operating system call, thereby improving the robustness and security of the system, ensuring that only verified requests can be further executed, and thus preventing the penetration of illegal requests; if the call execution status is not ready, If the call execution state is ready or the semantics are incorrect, it will not be executed further and the corresponding error code will be directly returned to the user program, responding to illegal requests in a timely manner and avoiding unnecessary resource consumption; if the call execution state is ready and the semantics are correct, confidentiality protection measures are taken for the system call parameters based on the system call conversion module to prevent the leakage of sensitive information, thereby enhancing the security of the data transmission process. The system call conversion module applies for a message structure in the shared memory, and the message structure includes the number, parameters and data of the system call request, that is, the system call parameters and data in the private memory of the user program are copied to the shared memory area, thereby ensuring the consistency and integrity of the data during the system call process.

[0031] Step S200: Read the message structure based on the ServiceOS operating system to complete the calling of the second type of calling items, where the second type of calling items are function items initiated by the RipOS operating system and have undergone confidentiality verification and integrity verification.

[0032] In this embodiment, after applying for a message structure in the shared memory, the ServiceOS operating system reads the message structure to complete the call of the second type of call item. The second type of call item is a system call initiated by the RipOS operating system and processed by the ServiceOS operating system after confidentiality and integrity verification, ensuring that only verified legitimate system call requests can be executed, thereby enhancing the security and reliability of the system.

[0033] Specifically, the step S200 includes the following steps: Step S201: Start a system call processing program based on the ServiceOS operating system; Step S202: using the system call processing program to read the message structure from the shared memory, reading the information of the system call request to be processed from the message structure, and converting the information of the system call request to be processed into a corresponding POSIX function on the Linux system; Step S203: calling the underlying Linux kernel to process the POSIX function to complete the calling of the second type of call item.

[0034] In one implementation, first, a system call handler is started based on the ServiceOS operating system. The system call handler is a user-mode program, which can provide better security isolation and facilitate management and debugging. Then, the system call handler is used to read the message structure from the shared memory, dequeue the message structure, read the information of the pending system call request therefrom, and convert the information of the pending system call request into the corresponding POSIX function on the Linux system. Through the dequeue operation, it is ensured that these requests are processed according to the first-in-first-out principle, thereby ensuring the correctness of the processing order. Finally, the underlying Linux kernel in the ServiceOS operating system is called to process the POSIX function to complete the call of the second type of call item, thereby ensuring that the system call request can be safely and reliably transmitted and executed.

[0035] The second type of call items described in this embodiment are system calls initiated by the RipOS operating system and processed by the ServiceOS operating system after confidentiality and integrity verification. The confidentiality means that the ServiceOS operating system will not leak the execution logic of the RipOS operating system, and will not cause additional information leakage compared to the Linux kernel. The integrity means that the return value and returned metadata of the ServiceOS operating system will not destroy the normal operation state of the RipOS operating system, and the execution result of the ServiceOS operating system conforms to POSIX semantics. The present invention makes certain security checks in terms of confidentiality and integrity to ensure that confidentiality and integrity will not be additionally damaged when reducing the trusted computing base. The second type of call items include file system-related system calls and network-related system calls.

[0036] In one implementation, the completion of the call of the second type of call item also includes: first, obtaining the return value and data generated by the Linux kernel; then, using the system call handler to write the return value and the data back to the message structure, and modifying the call execution status of the RipOS operating system to a responded status to notify the RipOS operating system that this system call request has been processed; then, based on the responded status, verifying the return value and the data through the system call verification module to ensure that the integrity of the ServiceOS operating system proxy system call is not damaged, and sending the verified return value and data to the user program, ensuring the accurate transmission and verification of the system call results, and the behavior of the ServiceOS operating system proxy system call is transparent to the user program, and the user program does not know whether the underlying macro kernel or the ServiceOS operating system kernel is running, and does not need to make any modifications to work normally.

[0037] In one implementation, the present invention defines system calls that require proxies but cannot guarantee security as the third type of system calls. The third type of system calls are generally limited by the confidential virtual machine architecture, which makes it impossible to check confidentiality and integrity at the operating system level. This part of the system calls includes time acquisition system calls and ioctl (Input / Output Control) system calls. The ioctl system call is a system call used to operate the underlying device. The parameters of the ioctl system call are composed of the fd (File Descriptor) device file descriptor, the request request type, and the args (Arguments) request parameter. Since the threat model of the confidential virtual machine divides all external devices into untrusted parts, operations on external devices through ioctl system calls are untrusted behaviors. In addition, the parameters of the ioctl system call are diverse and definable. Different manufacturers may customize specific parameters according to different devices and drivers to control the device, so the ioctl system call cannot be modeled in the operating system for security verification. In addition to accessing untrusted devices, time acquisition is also a difficult problem to solve in the confidential virtual machine model. Secure time acquisition requires the confidential virtual machine architecture to provide a trusted clock, which is beyond the scope of the operating system. However, the third type of system call does not make the RipOS operating system less secure than the Linux kernel. Taking ioctl as an example, its insecurity is mainly because the object of the operation is an untrusted device, but the operation of untrusted devices in the macro kernel has the same security problem. For the third type of system calls, except for some simulated devices implemented internally, such as zero devices and null devices, the RipOS operating system does not protect the security of using ioctl system calls to process external devices, nor does it trust its return value. In addition, the RipOS operating system does not guarantee the correctness of the time obtained through the host machine.

[0038] In one implementation, the present invention discusses the security impact of the call of the second type of call item from the perspective of confidentiality and integrity. From the perspective of confidentiality, the behavior of using the ServiceOS operating system to proxy system calls will expose system call parameters to an untrusted host machine. The leaked system call parameters can be divided into two categories: one is the parameters that the Linux kernel will also directly or indirectly leak; the other is the parameters that are additionally leaked due to the ServiceOS operating system proxy system call behavior. Considering that even if a Linux kernel is running in a confidential virtual machine, the interaction between the confidential virtual machine and the hardware is visible to attackers. Although the ServiceOS operating system proxy kernel directly leaks system call related information, the file system and network related system calls will eventually be converted into hardware operations, which is equivalent to leaking a more advanced representation of the hardware operation. The hardware device is not originally in the trusted computing base of the confidential virtual machine architecture, so such leakage does not bring additional burdens for protecting confidentiality. For the second type of leaked parameters, the system call conversion module in the RipOS operating system will take measures such as anonymization to protect its confidentiality.

[0039] From the perspective of integrity, malicious attackers can manipulate the system call handler of the ServiceOS operating system to return incorrect values ​​or metadata to attack the interface of the RipOS operating system, thereby changing the control flow of the application in the RipOS operating system and the state of the RipOS operating system itself. In response to this, the RipOS operating system uses a method similar to BesFS (Bes File System) to model the semantics of system calls, stipulate the normal behavior of the ServiceOS operating system proxy system call, and protect the integrity of the ServiceOS operating system proxy system call in combination with the verification of the system call state machine. Any behavior that deviates from the specified semantics is considered an illegal operation and a behavior that may cause an attack.

[0040] In summary, this embodiment provides a confidential virtual machine operating system. When implemented specifically, the system includes: a RipOS operating system, the RipOS operating system is used to process the first type of call items implemented by the RipOS operating system, the first type of call items reflects the function items called by the RipOS operating system; and a ServiceOS operating system, the ServiceOS operating system is used to proxy the second type of call items, the second type of call items are initiated by the RipOS operating system, and are function items that have undergone confidentiality verification and integrity verification. The present invention processes core system calls through the RipOS operating system, and the ServiceOS operating system processes system calls that need to be proxied, which greatly reduces the trusted computing base of the confidential virtual machine, reduces security risks, enhances the defense capability against external attacks, and improves the overall security and resource utilization efficiency of the system.

[0041] Based on the above embodiment, the present invention further provides a terminal, the principle block diagram of the terminal can be as follows: Figure 3 The terminal may include one or more processors 100 ( Figure 3 Only one is shown in the figure), a memory 101 and a computer program 102 stored in the memory 101 and executable on one or more processors 100, for example, a system call proxy program. When one or more processors 100 execute the computer program 102, the various steps in the embodiment of the system call proxy method can be implemented. Alternatively, when one or more processors 100 execute the computer program 102, the functions of the various modules / units in the embodiment of the system call proxy method can be implemented, which is not limited here.

[0042] In one embodiment, the processor 100 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0043] In one embodiment, the memory 101 may be an internal storage unit of an electronic device, such as a hard disk or memory of the electronic device. The memory 101 may also be an external storage device of the electronic device, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the electronic device. Further, the memory 101 may also include both an internal storage unit of the electronic device and an external storage device. The memory 101 is used to store computer programs and other programs and data required by the terminal. The memory 101 may also be used to temporarily store data that has been output or is to be output.

[0044] Those skilled in the art will understand that Figure 3 The principle block diagram shown in the figure is only a block diagram of a partial structure related to the scheme of the present invention, and does not constitute a limitation on the terminal to which the scheme of the present invention is applied. The specific terminal may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0045] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, operating database or other media used in the embodiments provided by the present invention may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double operational data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0046] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A confidential virtual machine operating system, characterized in that: The system comprises: RipOS operating system, the RipOS operating system is used to process the first type of call items implemented by the RipOS operating system, the first type of call items reflect the function items called by the RipOS operating system; The ServiceOS operating system is used to perform proxy processing on the second type of call items, where the second type of call items are function items initiated by the RipOS operating system and have undergone confidentiality verification and integrity verification.

2. The confidential virtual machine operating system according to claim 1, characterized in that: The RipOS operating system includes a system call processor and a system call proxy module; the system call processor is used to receive a system call request issued by a user program and send the system call request to the system call proxy module; The system call proxy module includes a system call state machine, a system call verification module and a system call conversion module; the system call state machine is used to save the call execution state of the RipOS operating system; the system call verification module is used to apply for the call execution state of the RipOS operating system from the system call state machine, and check whether the number and parameters of the RipOS operating system call conform to the semantics of the RipOS operating system call; the system call conversion module is used to take confidentiality protection measures for the system call parameters and apply for a message structure in the shared memory; The ServiceOS operating system includes a system call handler; The system call processing program is used to read the message structure from the shared memory, read the information of the system call request to be processed from the message structure, and convert the information of the system call request to be processed into a corresponding POSIX function on the Linux system.

3. A system call proxy method for a confidential virtual machine operating system based on any one of claims 1-2, characterized in that: The method comprises: Obtaining a system call request issued by a user program through the RipOS operating system, and applying for a message structure in a shared memory based on the system call request; The message structure is read based on the ServiceOS operating system to complete the calling of the second type of calling items, where the second type of calling items are function items initiated by the RipOS operating system and have undergone confidentiality verification and integrity verification.

4. The system call proxy method according to claim 3, characterized in that: The RipOS operating system includes a system call proxy module and a system call processor; the system call proxy module includes: a system call state machine, a system call verification module and a system call conversion module; the ServiceOS operating system includes a system call handler.

5. The system call proxy method according to claim 4, characterized in that: The method of obtaining a system call request issued by a user program through the RipOS operating system and applying for a message structure in a shared memory based on the system call request includes: Receiving a system call request from a user program through a system call processor, and sending the system call request to a system call proxy module; The system call proxy module is used to verify the validity of the system call request. After successful verification, confidentiality protection measures are taken for system call parameters, and a message structure is applied for in a shared memory.

6. The system call proxy method according to claim 5, characterized in that: The reading of the message structure based on the ServiceOS operating system to complete the calling of the second type of calling item includes: Start the system call handler based on the ServiceOS operating system; Using the system call processing program to read the message structure from the shared memory, read the information of the system call request to be processed from the message structure, and convert the information of the system call request to be processed into a corresponding POSIX function on the Linux system; The underlying Linux kernel is called to process the POSIX function to complete the calling of the second type of call item.

7. The system call proxy method according to claim 6, characterized in that: The method of using the system call proxy module to verify the validity of the system call request, taking confidentiality protection measures for system call parameters after successful verification, and applying for a message structure in a shared memory includes: Using the system call verification module to apply for the call execution status of the RipOS operating system to the system call state machine, and check whether the number and parameters of the RipOS operating system call conform to the semantics of the RipOS operating system call; If the call execution status is ready and the semantics are correct, confidentiality protection measures are taken for the system call parameters based on the system call conversion module, and a message structure is applied for in the shared memory. The message structure includes the number, parameters and data of the system call request.

8. The system call proxy method according to claim 7, characterized in that: The calling of the second type of calling item is completed, and then further includes: Obtaining the return value and data generated by the Linux kernel; Using the system call processing program to write the return value and the data back to the message structure, and modifying the call execution state of the RipOS operating system to a responded state; Based on the responded status, the return value and the data are verified by the system call verification module, and the verified return value and data are sent to the user program.

9. A terminal, characterized in that: The terminal includes a memory, a processor, and a system call proxy program stored in the memory and executable on the processor. When the processor executes the system call proxy program, the steps of the system call proxy method according to any one of claims 3 to 8 are implemented.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a system call proxy program, and when the system call proxy program is executed by the processor, the steps of the system call proxy method according to any one of claims 3 to 8 are implemented.

Images