Confidential Virtual Machine Operating System, System Call Agent Method, Terminal, and Medium

Abstract

The present invention discloses a confidential virtual machine operating system, a system call proxy method, a terminal, and a medium. The system includes: a RipOS operating system for processing a first type of call items implemented internally by the RipOS operating system, where the first type of call items reflect the functional items called during the operation of the RipOS operating system; and a ServiceOS operating system for proxy processing of a second type of call items, where the second type of call items are initiated by the RipOS operating system and are functional items after confidentiality verification and integrity verification. By having the RipOS operating system process core system calls and the ServiceOS operating system process system calls that need to be proxied, the present invention significantly reduces the trusted computing base of the confidential virtual machine, reduces security risks, enhances the defense ability against external attacks, and improves the overall security and resource utilization efficiency of the system.

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, which aims to protect sensitive data from unauthorized access. However, the robustness of this method is insufficient. Since the Linux kernel is written in a programming language that may have security risks and the source code scale is huge, reaching tens of millions of lines, it is vulnerable to memory security vulnerabilities and multithreaded concurrency defects, making it difficult to conduct a comprehensive security review and not suitable as a trusted computing base for confidential virtual machines. In addition, the design concept of the Linux kernel follows the architecture principles of traditional operating systems, and realizes the isolation between application programs through the permission separation between the user space and the kernel space and the virtual memory management system, relying on the services provided by system software at a higher privilege level. This design does not specifically consider the unique threat environment of confidential virtual machines, and attackers may illegally access the data inside the confidential virtual machine 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, in view of the above-mentioned defects of the prior art, to provide a confidential virtual machine operating system, a system call proxy method, a terminal, and a medium, aiming to solve the security problems brought by the traditional Linux kernel in the confidential virtual machine due to memory security, concurrency defects, and difficulty in comprehensive auditing, as well as the problem of insufficient confidentiality and integrity verification of system calls.

[0005] To solve the above technical problems, the technical solutions adopted by the present invention are as follows:

[0006] In a first aspect, the present invention provides a confidential virtual machine operating system, wherein the system includes:

[0007] The RipOS operating system, which is used to process the first type of call items that must be implemented inside the RipOS operating system, and the first type of call items reflect the function items called during the operation of the RipOS operating system;

[0008] The ServiceOS operating system, which is used to proxy-process the second type of call items, and the second type of call items are function items initiated by the RipOS operating system and verified for confidentiality and integrity.

[0009] In one implementation, the RipOS operating system includes a system call processor and a system call proxy module; the system call processor is configured to receive a system call request issued by a user program and send the system call request to the system call proxy module;

[0010] 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 configured to apply to the system call state machine for the call execution state 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 take confidentiality protection measures for system call parameters and apply for a message structure in the shared memory;

[0011] The ServiceOS operating system includes a system call handler; the system call handler is configured 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.

[0012] 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, where the method includes:

[0013] Obtain a system call request issued by a user program through the RipOS operating system, and apply for a message structure in the shared memory based on the system call request;

[0014] Read the message structure based on the ServiceOS operating system to complete the call of the second type of call items, where the second type of call items are function items initiated by the RipOS operating system and verified for confidentiality and integrity.

[0015] 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.

[0016] In one implementation, the obtaining a system call request issued by a user program through the RipOS operating system and applying for a message structure in the shared memory based on the system call request includes:

[0017] Receive a system call request sent by a user program through a system call processor, and send the system call request to a system call proxy module;

[0018] 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 shared memory.

[0019] In one implementation, read the message structure based on the ServiceOS operating system to complete the invocation of the second type of call items, including:

[0020] Start a system call handler based on the ServiceOS operating system;

[0021] Use the system call handler 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;

[0022] Invoke the underlying Linux kernel to process the POSIX function to complete the invocation of the second type of call items.

[0023] In one implementation, the step 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 shared memory includes:

[0024] Use the system call verification module to apply for the call execution status 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;

[0025] If the call execution status is the ready state and the semantics are correct, make confidentiality protection measures for system call parameters based on the system call conversion module, and apply for a message structure in shared memory, where the message structure includes the number, parameters, and data of the system call request.

[0026] In one implementation, after completing the invocation of the second type of call items, it further includes:

[0027] Obtain the return value and data generated by the Linux kernel;

[0028] Use the system call handler to write the return value and the data back to the message structure, and modify the call execution status of the RipOS operating system to the responded state;

[0029] Based on the said responded status, verify the return value and the data through the system call verification module, and send the verified return value and data to the user program.

[0030] In a third aspect, an embodiment of the present invention further provides a terminal. 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 in any one of the above solutions are implemented.

[0031] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium. A system call proxy program is stored on the computer-readable storage medium. When the system call proxy program is executed by a processor, the steps of the system call proxy method in any one of the above solutions are implemented.

[0032] Beneficial effects: The present invention provides a confidential virtual machine operating system. Compared with the prior art, the system includes: a RipOS operating system for processing the first type of call items implemented internally by the RipOS operating system, and the first type of call items reflect the functional items called during the operation of the RipOS operating system; a ServiceOS operating system for proxy processing the second type of call items, and the second type of call items are initiated by the RipOS operating system and are functional items after confidentiality verification and integrity verification. The present invention processes core system calls through the RipOS operating system and processes system calls that need to be proxied through the ServiceOS operating system, greatly reducing the trusted computing base of the confidential virtual machine, reducing security risks, enhancing the defense ability against external attacks, and improving the overall security and resource utilization efficiency of the system. Description of the Drawings

[0033] Figure 1 It is a structural diagram of the confidential virtual machine operating system provided by an embodiment of the present invention.

[0034] Figure 2 It is a processing flow chart of the system call proxy method based on the confidential virtual machine operating system provided by an embodiment of the present invention.

[0035] Figure 3 It is a block diagram of the internal structure principle of the terminal provided by an embodiment of the present invention. Detailed Embodiments

[0036] To make the objectives, technical solutions and effects of the present invention clearer and more definite, the following further describes the present invention in detail with reference to the accompanying drawings and by way of 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.

[0037] In the field of confidential computing, protecting sensitive data from unauthorized access is a key requirement. Traditional solutions often rely on deploying the Linux kernel in a confidential virtual machine. Although this approach can provide a certain degree of data protection, since the Linux kernel uses programming languages that may have security risks and its source code size is huge, reaching tens of millions of lines, it is vulnerable to memory security vulnerabilities and multi-threaded concurrency defects, making it difficult to conduct a comprehensive security review and not suitable as the trusted computing base for a confidential virtual machine. In addition, the design of the Linux kernel follows the architecture principles of traditional operating systems, achieving isolation between application programs through the separation of permissions between the user space and the kernel space and the virtual memory management system. However, this design does not specifically consider the unique threat environment of confidential virtual machines, allowing attackers to illegally access the data inside the confidential virtual machine through system interfaces and other means.

[0038] To solve the above problems, this embodiment provides a confidential virtual machine operating system. Specifically, when implemented, the system includes: the RipOS operating system, which is used to process the first type of call items implemented internally by the RipOS operating system, and the first type of call items reflect the functional items called during the operation of the RipOS operating system; the ServiceOS operating system, which is used to proxy-process the second type of call items. The second type of call items are the functional items initiated by the RipOS operating system and verified for confidentiality and integrity. Through the RipOS operating system to process core system calls and the ServiceOS operating system to process system calls that need to be proxied, the trusted computing base of the confidential virtual machine is greatly reduced, the security risk is lowered, the defense ability against external attacks is enhanced, and the overall security and resource utilization efficiency of the system are improved.

[0039] This embodiment provides a confidential virtual machine operating system, as Figure 1 shown, the system includes: the RipOS operating system, which is used to process the first type of call items implemented internally by the RipOS operating system, and the first type of call items reflect the functional items called during the operation of the RipOS operating system; the ServiceOS operating system, which is used to proxy-process the second type of call items. The second type of call items are the functional items initiated by the RipOS operating system and verified for confidentiality and integrity.

[0040] 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 sent 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 to the system call state machine for the call execution state 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 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.

[0041] 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, interrupt and exception handling, and memory management, which together constitute a minimized trusted computing base, thereby reducing security risks and enhancing the overall security of the confidential virtual machine. When a user program makes a system call to 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 the first type of call item and is the most basic guarantee for the operating system to load and run application programs and for application programs to communicate with each other. It is handled by the RipOS operating system itself through the system call interface layer to ensure the implementation 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 is completed through a proxy method. Specifically, the system call processor in the system call interface layer receives the system call request sent by the user program and sends the system call request to the 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 the on-demand paging and swapping mechanisms when handling page faults. This means that the user program needs to be statically linked and fully loaded into memory before running. This method reduces the complexity of memory management, improves the memory access speed, and enhances the stability of the system. 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. This not only reduces the trusted computing base but also reduces potential security vulnerabilities and enhances the security of the system. Additionally, any kernel code related to users and groups is not included in the RipOS operating system, and the RipOS operating system prohibits user input operations, further restricting the attack surface and ensuring the security and integrity of the data inside the confidential virtual machine.

[0042] 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 handle system call requests initiated by user programs, but also handle system call requests from the RipOS operating system. User programs interact with its kernel through the system call interface layer of the ServiceOS operating system. The system call interface layer exposes a series of APIs (Application Programming Interface) upward. These APIs respectively 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 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 operations such as file creation, deletion, reading, and writing; 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 to fairly allocate system resources; the hardware abstraction layer (HAL) subsystem provides a standardized interface to enable software to be developed independently of the underlying hardware. Device drivers in the ServiceOS operating system also play an important role. Device drivers are responsible for initializing and controlling the operations 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 transmitted from the RipOS operating system, parsing these requests, converting them into a format executable by the ServiceOS operating system, then calling the system call interface layer to perform actual operations. After the processing is completed, the system call handler returns the result to the RipOS operating system, thus realizing seamless cooperation between the RipOS operating system and the ServiceOS operating system.

[0043] In one implementation, the confidential virtual machine operating system further 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 the trusted hardware and physical devices. The trusted hardware and physical devices play a crucial role in the confidential virtual machine operating system. The trusted hardware provides a hardware-level security guarantee mechanism that can verify and protect sensitive data, preventing unauthorized access and tampering. The physical devices include various hardware resources such as processors, memory, storage devices, and network interfaces, etc., which are essential components for the operation of the virtual machine. 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. The trusted hardware and physical devices cooperate together to provide a solid foundation for the confidential virtual machine operating system, ensuring data security and system stability.

[0044] The system call proxy method provided in this embodiment based on the above-mentioned confidential virtual machine operating system can be applied to intelligent terminals. The processing flow chart of the system call proxy method is as Figure 2 shown below, and specifically includes the following steps:

[0045] Step S100: Obtain the system call request sent by the user program through the RipOS operating system, and apply for a message structure in the shared memory based on the system call request.

[0046] In this embodiment, the RipOS operating system obtains the system call requests sent by the user program and applies for a message structure in the shared memory based on the system call requests. This process ensures that the system call requests can be transmitted to the ServiceOS operating system in a structured manner, and at the same time, 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 requests sent by the user program and send the system call requests to the system call proxy module; the system call verification module is used to apply for the call execution status of the RipOS operating system from the system call state machine and check whether the numbers and parameters of the RipOS operating system calls conform to the semantics of the RipOS operating system calls; 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 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 a file path tree, which is a tree structure, and each node represents a directory or a file and is used to save the static information of the file. The static information includes the file name, file type, file permissions (read, write, execute), and file size; the second part is the file descriptor table of the ServiceOS operating system, abbreviated as the ServiceOS table, which mainly records the opened file descriptors returned by the system call handlers in the ServiceOS operating system and the corresponding file types. The file types include files, directories, symbolic links, devices, and socket sockets; the third part is the open file table, which mainly records the dynamic information of the files used by the file system-related system calls. The file dynamic information includes file descriptors, file offsets, and file open flags; the fourth part is the socket status table, which mainly records the socket descriptors and the status information of the corresponding sockets.

[0047] Specifically, step S100 includes the following steps:

[0048] Step S101: Receive the system call requests sent by the user program through the system call processor and send the system call requests to the system call proxy module;

[0049] Step S102: Use the system call proxy module to verify the validity of the system call requests, take confidentiality protection measures for the system call parameters after successful verification, and apply for a message structure in the shared memory.

[0050] In one implementation, when a user program needs to make a system call to a kernel module excluded from the trusted computing base, such as the read system call for reading a file or the socket system call for creating a socket, the system call is completed through a proxy. First, the system call processor receives the system call request sent by the user program and sends the system call request to the system call proxy module, which increases the security and flexibility of the system, controls and filters the requests entering the kernel, and reduces the risk of directly exposing the 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 check whether the number and parameters of the RipOS operating system call conform to the semantics of the RipOS operating system call, which improves the robustness and security of the system, ensures that only verified requests can be further executed, and thus prevents the penetration of illegal requests. If the call execution status is not the ready state or the semantics is incorrect, the execution will not continue and an error code corresponding to the user program will be directly returned in a timely manner to respond to the illegal request and avoid unnecessary resource consumption. If the call execution status is the ready state and the semantics is 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, which enhances the security during 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 to ensure the consistency and integrity of the data during the system call process.

[0051] Step S200: Read the message structure based on the ServiceOS operating system to complete the call of the second type of call item, where the second type of call item is a function item initiated by the RipOS operating system and verified for confidentiality and integrity.

[0052] In this embodiment, after applying for a message structure in the shared memory, the message structure is read based on the ServiceOS operating system 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, which ensures that only verified legitimate system call requests can be executed, thereby enhancing the security and reliability of the system.

[0053] Specifically, the step S200 includes the following steps:

[0054] Step S201: Start the system call handler based on the ServiceOS operating system;

[0055] Step S202: Use the system call handler 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 the corresponding POSIX function on the Linux system;

[0056] Step S203: Call the underlying Linux kernel to process the POSIX function to complete the call of the second type of call item.

[0057] In one implementation, first, based on the ServiceOS operating system, start the system call handler. The system call handler is a user-mode program, which can provide better security isolation and is convenient for management and debugging; then, use the system call handler to read the message structure from the shared memory, perform a dequeue operation on the message structure, read the information of the system call request to be processed from it, and convert the information of the system call request to be processed into the corresponding POSIX function on the Linux system. Through the dequeue operation, it is ensured that these requests are processed in the first-in, first-out principle, ensuring the correctness of the processing order; finally, call the underlying Linux kernel in the ServiceOS operating system to process the POSIX function to complete the call of the second type of call item, ensuring that the system call request can be safely and reliably transmitted and executed.

[0058] The second type of call item described in this embodiment is a system call 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 disclose 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 the returned metadata of the ServiceOS operating system will not damage the normal running state of the RipOS operating system, and the execution result of the ServiceOS operating system conforms to the POSIX semantics. The present invention makes certain security checks in terms of confidentiality and integrity to ensure that confidentiality and integrity will not be damaged additionally when reducing the trusted computing base. The second type of call item includes system calls related to the file system and system calls related to the network.

[0059] In one implementation, after completing the invocation of the second type of call item, the following steps are further included: First, obtain the return value and data generated by the Linux kernel; then, use the system call handler to write the return value and the data back to the message structure, and modify the call execution status of the RipOS operating system to the responded status to notify the RipOS operating system that this system call request has been processed; then, based on the responded status, verify 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 send the verified return value and data to the user program, ensuring the accurate transmission and verification of the system call result, and the behavior of the ServiceOS operating system proxy system call is transparent to the user program. The user program will not know whether the underlying kernel is a macro kernel or the ServiceOS operating system kernel, and can work properly without any modification.

[0060] In one implementation, the present invention defines system calls that need to be proxied but cannot guarantee security as the third type of system calls. The third type of system calls is generally restricted by the confidential virtual machine architecture, resulting in the inability to perform confidentiality and integrity checks at the operating system level. This part of the system calls includes system calls for time acquisition and ioctl (Input / Output Control) system calls. The ioctl system call is a system call for operating on underlying devices. The parameters of the ioctl system call consist of the fd (File Descriptor) device file descriptor, the request request type, and the args (Arguments) request parameters. Since the threat model of the confidential virtual machine classifies all external devices into untrusted parts, the operations on external devices through the ioctl system call are all untrusted behaviors. In addition, the parameters of the ioctl system call are diverse and definable, and different manufacturers may customize specific parameters according to different devices and drivers to control the devices. Therefore, it is impossible to model the ioctl system call in the operating system for security verification. In addition to accessing untrusted devices, time acquisition is also a difficult problem 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 to solve. However, the third type of system calls 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 operation is an untrusted device, but there are also the same security problems in the operation of untrusted devices in the macro kernel. For the third type of system calls, except for some simulated devices implemented internally, such as the zero device, the null device, etc., the RipOS operating system does not protect the security when using the ioctl system call 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.

[0061] In one implementation, the present invention discusses the security impacts brought by the invocation of the second type of call items from the perspectives of confidentiality and integrity. From the aspect of confidentiality, the behavior of using the ServiceOS operating system to proxy system calls will expose the system call parameters to the untrusted host. The leaked system call parameters can be divided into two categories: one category is the parameters that the Linux kernel will also directly or indirectly leak; the other category is the parameters that are additionally leaked due to the behavior of the ServiceOS operating system proxying system calls. Considering that even if a Linux kernel runs in a confidential virtual machine, the interaction between the confidential virtual machine and the hardware is visible to the attacker. Although the ServiceOS operating system proxy kernel directly leaks system call-related information, the file system and network-related system calls will ultimately be converted into operations on the hardware, which is equivalent to leaking a more advanced representation of the hardware operations. Since the hardware devices are not originally in the trusted computing base of the confidential virtual machine architecture, such leakage will not bring an additional burden on protecting confidentiality. For the parameters leaked in the second category, the system call conversion module in the RipOS operating system will take measures such as anonymization to protect their confidentiality.

[0062] From the aspect of integrity, malicious attackers can conduct interface attacks on the RipOS operating system by manipulating the system call handlers of the ServiceOS operating system to return incorrect values or metadata, thereby changing the control flow of the applications in the RipOS operating system and the state of the RipOS operating system itself. In response, the RipOS operating system adopts a method similar to that in BesFS (Bes File System) to semantically model the system calls, stipulate the normal behavior of the ServiceOS operating system proxying system calls, and combine the verification of the system call state machine to protect the integrity of the ServiceOS operating system proxying system calls. Any behavior that deviates from the specified semantics is considered an illegal operation and a behavior that may cause an attack.

[0063] In summary, this embodiment provides a confidential virtual machine operating system. Specifically, when implemented, the system includes: a RipOS operating system, which is used to process the first type of call items implemented internally by the RipOS operating system, and the first type of call items reflect the functional items called by the RipOS operating system during operation; a ServiceOS operating system, which is used to proxy-process 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 passed confidentiality verification and integrity verification. Through the RipOS operating system to process core system calls and the ServiceOS operating system to process system calls that need to be proxied, the trusted computing base of the confidential virtual machine is greatly reduced, the security risk is reduced, the defense ability against external attacks is enhanced, and the overall security and resource utilization efficiency of the system are improved.

[0064] Based on the above embodiment, the present invention also provides a terminal, and the principle block diagram of the terminal can be as Figure 3 shown. 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, each step 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 each module / unit in the embodiment of the system call proxy method can be implemented, which is not limited herein.

[0065] In one embodiment, the so-called processor 100 may be a central processing unit (CPU), or may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0066] In one embodiment, the memory 101 may be an internal storage unit of the electronic device, such as the 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 equipped on the electronic device, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. Further, the memory 101 may also include both the internal storage unit and the external storage device of the electronic 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 the data that has been output or will be output.

[0067] Those skilled in the art can understand that Figure 3 the principle block diagram shown is only a block diagram of some structures related to the solution of the present invention, and does not constitute a limitation on the terminal to which the solution of the present invention is applied. The specific terminal may include more or fewer components than those shown in the figure, or combine some components, or have different component arrangements.

[0068] Those of ordinary skill in the art can understand that all or part of the processes of implementing the methods in the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it may include the processes of the embodiments of the above methods. Among them, any reference to the memory, storage, operational database or other media used in the various embodiments provided by the present invention may include non-volatile and / or volatile memories. The non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. The volatile memory may include random access memory (RAM) or an 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 data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM), etc.

[0069] 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 foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate 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 includes: The RipOS operating system, which is used to process the first type of call items implemented internally by the RipOS operating system, and the first type of call items reflect the function items called during the operation of the RipOS operating system; The ServiceOS operating system, which is used to proxy-process the second type of call items. The second type of call items are function items initiated by the RipOS operating system and verified for confidentiality and integrity; The RipOS operating system includes a system call processor and a system call proxy module; the system call processor is used to receive system call requests sent by user programs and send the system call requests 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 to the system call state machine for the call execution state 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 take confidentiality protection measures for system call parameters and apply for a message structure in 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 the corresponding POSIX function on the Linux system.

2. A system call proxy method for the confidential virtual machine operating system according to claim 1 above, characterized in that, The method includes: Obtaining a system call request sent by a user program through the RipOS operating system and applying for a message structure in shared memory based on the system call request; Reading the message structure based on the ServiceOS operating system to complete the call of the second type of call items. The second type of call items are function items initiated by the RipOS operating system and verified for confidentiality and integrity.

3. The system call proxy method according to claim 2, wherein 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.

4. The system call proxy method according to claim 3, wherein The obtaining a system call request sent by a user program through the RipOS operating system and applying for a message structure in shared memory based on the system call request includes: Receiving a system call request sent by a user program through the system call processor and sending the system call request to the system call proxy module; 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 shared memory.

5. The system call proxy method according to claim 4, wherein Reading the message structure based on the ServiceOS operating system to complete the invocation of the second type of invocation item, including: Starting a system call handler based on the ServiceOS operating system; Using the system call handler 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 the corresponding POSIX function on the Linux system; Invoking the underlying Linux kernel to process the POSIX function to complete the invocation of the second type of invocation item.

6. The system call proxy method according to claim 5, characterized in that 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 the shared memory, including: Using the system call verification module to apply for the invocation execution status of the RipOS operating system from the system call state machine, and checking whether the number and parameters of the RipOS operating system invocation conform to the semantics of the RipOS operating system invocation; If the invocation execution status is the ready state and the semantics are correct, making confidentiality protection measures for the system call parameters based on the system call conversion module, and applying for a message structure in the shared memory, where the message structure includes the number, parameters, and data of the system call request.

7. The system call proxy method according to claim 6, characterized in that After completing the invocation of the second type of invocation item, it further includes: Obtaining the return value and data generated by the Linux kernel; Using the system call handler to write the return value and the data back to the message structure, and modifying the invocation execution status of the RipOS operating system to the responded state; Based on the responded state, verifying the return value and the data through the system call verification module, and sending the verified return value and data to the user program.

8. 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, it implements the steps of the system call proxy method according to any one of claims 2-7.

9. A computer-readable storage medium, characterized in that, A system call proxy program is stored on the computer-readable storage medium. When the system call proxy program is executed by the processor, it implements the steps of the system call proxy method according to any one of claims 2-7.

Images