CN119806754B - Confidential virtual machine operating system, system call proxy method, terminal and medium - Google Patents
Confidential virtual machine operating system, system call proxy method, terminal and mediumInfo
- Publication number
- CN119806754B CN119806754B CN202510309126.5A CN202510309126A CN119806754B CN 119806754 B CN119806754 B CN 119806754B CN 202510309126 A CN202510309126 A CN 202510309126A CN 119806754 B CN119806754 B CN 119806754B
- Authority
- CN
- China
- Prior art keywords
- system call
- call
- operating system
- ripos
- message structure
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Storage Device Security (AREA)
Abstract
本发明公开了机密虚拟机操作系统、系统调用代理方法、终端及介质，所述系统包括：RipOS操作系统，所述RipOS操作系统用于处理由RipOS操作系统内部实现的第一类调用项，所述第一类调用项反映的是RipOS操作系统运行时所调用的功能项；ServiceOS操作系统，所述ServiceOS操作系统用于对第二类调用项进行代理处理，所述第二类调用项是由所述RipOS操作系统发起，且经过机密性验证与完整性验证后的功能项。本发明通过RipOS操作系统处理核心系统调用，ServiceOS操作系统处理需代理的系统调用，大幅缩减了机密虚拟机的可信计算基，降低了安全风险，增强了对外部攻击的防御能力，提升了系统的整体安全性和资源利用效率。
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, the RipOS operating system is used to process a first type of call item implemented by the RipOS operating system, the first type of call item reflects the function item called when the RipOS operating system is running; a ServiceOS operating system, the ServiceOS operating system is used to proxy the second type of call item, the second type of call item is initiated by the RipOS operating system and is a function item after 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.
Description
Technical Field
The present invention relates to the field 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
In the field of confidential computing, deployment of Linux kernels in confidential virtual machines is widely adopted as a common solution aimed at protecting sensitive data from unauthorized access. However, this method is not robust enough, and since the Linux kernel is written in a programming language that may present security risks, and the source code is huge in scale, up to tens of millions of lines, it is susceptible to memory security vulnerabilities and multi-thread concurrency flaws, so that comprehensive security inspection is difficult, and is not suitable for serving as a trusted computing base for a confidential virtual machine. In addition, the design concept of the Linux kernel follows the architecture principle of the traditional operating system, the isolation between application programs is realized through the authority separation of a user space and a kernel space and the virtual memory management system, and the Linux kernel depends on services provided by system software of a higher authority layer. This design does not take into account the threat environment specific to the confidential virtual machine, and an attacker may illegally access data inside the confidential virtual machine using a system interface or the like.
Accordingly, there is a need for improvement and advancement in the art.
Disclosure of Invention
Aiming at the defects in the prior art, the invention provides a confidential virtual machine operating system, a system call proxy method, a terminal and a medium, and aims to solve the problems of safety problems caused by memory safety, concurrent defects and difficulty in comprehensive audit and insufficient confidentiality and integrity verification of system call of the traditional Linux kernel in the confidential virtual machine.
In order to solve the technical problems, the technical scheme adopted by the invention is as follows:
in a first aspect, the present invention provides a confidential virtual machine operating system, wherein the system comprises:
RipOS an operating system, wherein the RipOS operating system is used for processing a first type of call item which is necessarily realized by the inside of the RipOS operating system and reflects a function item called by the RipOS operating system operation;
And the ServiceOS operating system is used for carrying out proxy processing on second-class call items, wherein the second-class call items are functional items initiated by the RipOS operating system and subjected to confidentiality verification and integrity verification.
In one implementation, the RipOS operating system includes a system call processor and a system call proxy module, wherein the system call processor is used for receiving a system call request sent by a user program and sending the system call request to the system call proxy module;
The system call agent module comprises a system call state machine, a system call verification module and a system call conversion module, wherein the system call state machine is used for storing the call execution state of the RipOS operating system, the system call verification module is used for applying the call execution state of the RipOS operating system to the system call state machine and checking whether the number and the parameter of the RipOS operating system call accord with the semantic of the RipOS operating system call or not, and the system call conversion module is used for making confidentiality protection measures on the system call parameters and applying a message structure in a shared memory;
The ServiceOS operating system comprises a system call processing program, wherein the system call processing program is used for reading the message structure body from the shared memory, reading information of a system call request to be processed from the message structure body, and converting the information of the system call request to be processed into a POSIX function corresponding to a Linux system.
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:
acquiring a system call request sent by a user program through RipOS operating system, and applying for a message structure body in a shared memory based on the system call request;
And reading the message structure body based on a ServiceOS operating system to complete the call of a second type of call item, wherein the second type of call item is a functional item initiated by the RipOS operating system and subjected to confidentiality verification and integrity verification.
In one implementation, the RipOS operating system comprises a system call proxy module and a system call processor, wherein the system call proxy module comprises a system call state machine, a system call verification module and a system call conversion module, and the ServiceOS operating system comprises a system call processing program.
In one implementation manner, the obtaining, by the RipOS operating system, a system call request sent by a user program, and applying for a message structure in a shared memory based on the system call request, includes:
Receiving a system call request sent by a user program through a system call processor, and sending the system call request to a system call proxy module;
and verifying the validity of the system call request by using the system call proxy module, taking confidentiality protection measures for the system call parameters after verification is successful, and applying for a message structure in the shared memory.
In one implementation, reading the message structure based on the ServiceOS operating system to complete the call of the second class of call items includes:
Starting a system call processing program based on a ServiceOS operating system;
reading the message structure body from the shared memory by using the system call processing program, reading information of a system call request to be processed from the message structure body, and converting the information of the system call request to be processed into a POSIX function corresponding to a Linux system;
And calling a Linux kernel of the bottom layer to process the POSIX function to finish the call of the second type of call item.
In one implementation manner, the verifying the validity of the system call request by using the system call proxy module, taking confidentiality protection measures for the system call parameters after the verification is successful, and applying for a message structure in the shared memory includes:
Applying for the call execution state of the RipOS operating system to a system call state machine by using the system call verification module, and checking whether the number and the parameters of the RipOS operating system call accord with the semantics of the RipOS operating system call;
If the call execution state is in a ready state and the semantics are correct, confidentiality protection measures are made for the system call parameters based on the system call conversion module, and a message structure body is applied for in the shared memory, wherein the message structure body comprises the number, the parameters and the data of the system call request.
In one implementation, the completing the call of the second type of call item further includes:
Acquiring a return value and data generated by the Linux kernel;
Writing the return value and the data back to the message structure by using the system call handler, and modifying the call execution state of the RipOS operating system to a responded state;
And 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.
In a third aspect, an embodiment of the present invention further provides a terminal, where the terminal includes a memory, a processor, and a system call agent stored in the memory and capable of running on the processor, and when the processor executes the system call agent, the processor implements the steps of the system call agent method in any one of the above schemes.
In a fourth aspect, an embodiment of the present invention further provides a computer readable storage medium, where a system call agent is stored on the computer readable storage medium, and when the system call agent is executed by a processor, the steps of the system call agent method in any one of the above solutions are implemented.
The confidential virtual machine operating system has the advantages that compared with the prior art, the confidential virtual machine operating system comprises a RipOS operating system, a ServiceOS operating system and a ServiceOS operating system, wherein the RipOS operating system is used for processing a first type of call item which is realized inside the RipOS operating system and reflects a function item which is called by the RipOS operating system in operation, the ServiceOS operating system is used for carrying out proxy processing on a second type of call item, and the second type of call item is a function item which is initiated by the RipOS operating system and is subjected to confidentiality verification and integrity verification. The invention processes the core system call through RipOS operating system, and the ServiceOS operating system processes the system call needing proxy, thereby greatly reducing the trusted computing base of the confidential virtual machine, reducing the security risk, enhancing the defending capability to external attack and improving the overall security and the resource utilization efficiency of the system.
Drawings
FIG. 1 is a block diagram of a confidential virtual machine operating system provided by an embodiment of the present invention.
FIG. 2 is a flow chart of a system call proxy method based on a confidential virtual machine operating system provided by an embodiment of the invention.
Fig. 3 is a schematic block diagram of an internal structure of a terminal according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and effects of the present invention clearer and more specific, the present invention will be described in further detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the invention.
In the field of confidential computing, protecting sensitive data from unauthorized access is a critical requirement, and conventional solutions often rely on deploying a Linux kernel in a confidential virtual machine. Although the method can provide a certain degree of data protection, as the Linux kernel uses a programming language which possibly has security risks and the source code is large in scale and reaches tens of millions of lines, the Linux kernel is easily affected by memory security holes and multi-thread concurrent defects, so that comprehensive security examination is difficult, and the Linux kernel is not suitable for being used as a trusted computing basis of a confidential virtual machine. In addition, the design of the Linux kernel follows the architecture principle of the traditional operating system, and isolation between application programs is realized through authority separation of a user space and a kernel space and a virtual memory management system, but the design does not particularly consider the special threat environment of the confidential virtual machine, so that an attacker can illegally access data in the confidential virtual machine through a system interface and the like.
In order to solve the problems, the embodiment provides a confidential virtual machine operating system, which comprises a RipOS operating system, a ServiceOS operating system and a second operating system, wherein the RipOS operating system is used for processing a first type of call item which is realized inside the RipOS operating system and reflects a function item which is called by the RipOS operating system, the ServiceOS operating system is used for carrying out proxy processing on a second type of call item, and the second type of call item is initiated by the RipOS operating system and is subjected to confidentiality verification and integrity verification. The invention processes the core system call through RipOS operating system, and the ServiceOS operating system processes the system call needing proxy, thereby greatly reducing the trusted computing base of the confidential virtual machine, reducing the security risk, enhancing the defending capability to external attack and improving the overall security and the resource utilization efficiency of the system.
The embodiment provides a confidential virtual machine operating system, as shown in fig. 1, which comprises a RipOS operating system, a ServiceOS operating system and a second type operating system, wherein the RipOS operating system is used for processing a first type of call item which is internally realized by the RipOS operating system and reflects a function item which is called by RipOS operating system operation, and the ServiceOS operating system is used for carrying out proxy processing on a second type of call item which is initiated by the RipOS operating system and is subjected to confidentiality verification and integrity verification.
In one implementation, the RipOS operating system comprises a system call processor and a system call proxy module, wherein the system call processor is used for receiving a system call request sent by a user program and sending the system call request to the system call proxy module, the system call proxy module comprises a system call state machine, a system call verification module and a system call conversion module, the system call state machine is used for storing the call execution state of the RipOS operating system, the system call verification module is used for applying for the call execution state of the RipOS operating system to the system call state machine and checking whether the number and parameters of the RipOS operating system call accord with the semantics of the RipOS operating system call, the system call conversion module is used for making confidentiality protection measures for the system call parameters and applying for a message structure in a shared memory, and the serviceOS operating system comprises a system call processing program which is used for reading the message structure from the shared memory, reading 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 POSIX function request corresponding to the system call request on the Linux.
In one implementation, the RipOS operating system runs inside a confidential virtual machine. The RipOS operating system also comprises a kernel core module, wherein the kernel core module comprises inter-process communication, process scheduling and a hardware abstraction layer, and the inter-process communication, the process scheduling and the hardware abstraction layer specifically comprise functions of starting, interrupt and exception handling, memory management and the like, and jointly form a minimized trusted computing base, so that the safety risk is reduced and the overall safety of the confidential virtual machine is improved. When the user program realizes the system call of the kernel core module, the system call mainly comprises process management, memory management and system call related to inter-process communication, wherein the system call is a first type of call item, is the most basic guarantee of loading and running an application program by an operating system and the communication between the application programs, and is automatically processed by the RipOS operating system through a system call interface layer so as to ensure the realization of basic system functions and safety. When the user program needs to make system call to kernel module excluded from trusted computing base, at this time, the system call is completed by proxy mode, specifically, the system call processor in the system call interface layer receives the system call request sent by user program, and sends the system call request to the system call proxy module, then the ServiceOS operating system processes the system call. In addition, the memory management module of the RipOS operating system does not contain a mechanism for changing in and out when paging on demand and processing page fault abnormality, which means that the user program needs to be statically linked and loaded into the memory before running, thus reducing the complexity of memory management and improving the memory access speed and the stability of the system. The RipOS operating system does not contain kernel modules such as a file system, a device driver, a network protocol stack and the like, and system calls corresponding to the modules are proxy-processed to the ServiceOS operating system, so that a trusted computing base is reduced, potential security holes are reduced, and the security of the system is enhanced. In addition, any user and group related kernel code is not contained in the RipOS operating system, and the RipOS operating system prohibits user input operations, further limits the attack surface and ensures the security and integrity of the data inside the confidential virtual machine.
In one implementation, the ServiceOS operating system runs on a host machine or another virtual machine. The ServiceOS operating system typically uses a Linux kernel as the internal operating system. The serviceOS operating system not only can effectively process the system call request initiated by the user program, but also can process the system call request from the RipOS operating system. The user program interacts with its kernel through the system call interface layer of the ServiceOS operating system, which exposes a series of APIs (Application Programming Interface, application programming interfaces) upward, which 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), respectively, to meet various requirements of the user program. For example, the interprocess communication subsystem supports information exchange between different processes, allows data sharing and synchronization operations between the processes, 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, 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 decides which process should obtain a CPU time slice to fairly allocate system resources, and the Hardware Abstraction Layer (HAL) subsystem provides a standardized interface enabling software development independent of underlying hardware. The device driver in the ServiceOS operating system plays an important role, and 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 processing program in the ServiceOS operating system is responsible for receiving the system call requests transmitted from the RipOS operating system, analyzing the requests, converting the requests into a format executable by the ServiceOS operating system, then calling the system call interface layer to execute actual operation, and returning the result to the RipOS operating system by the system call processing program after the processing is completed, so that seamless cooperation between the RipOS operating system and the ServiceOS operating system is realized.
In one implementation, the confidential virtual machine operating system further includes a virtual machine manager, trusted hardware and physical devices, where the virtual machine manager serves as a bridge connecting RipOS the operating system and the ServiceOS operating system, coordinates interaction between the two, and ensures secure access of the trusted hardware and the physical devices. Trusted hardware and physical devices play a vital role in a confidential virtual machine operating system, and the trusted hardware provides a hardware-level security mechanism that can verify and protect sensitive data from unauthorized access and tampering. Physical devices include various hardware resources such as processors, memory, storage devices, network interfaces, etc., which are essential 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 properly access and use these resources. The trusted hardware and the physical equipment cooperate together to provide a solid foundation for the confidential virtual machine operating system, and ensure the security of data and the stability of the system.
The system call proxy method based on the confidential virtual machine operating system provided by the embodiment can be applied to an intelligent terminal, and a processing flow chart of the system call proxy method is shown in fig. 2, and specifically comprises the following steps:
step S100, a system call request sent by a user program is obtained through RipOS operation system, and a message structure is applied in a shared memory based on the system call request.
In this embodiment, a system call request sent by a user program is obtained through RipOS operating system, and a message structure is applied in the shared memory based on the system call request. This process ensures that system call requests can be passed to the ServiceOS operating system in a structured manner, while using a 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 agent module and a system call processor; the system call agent module comprises a system call state machine, a system call verification module and a system call conversion module, wherein the system call processor is used for receiving a system call request sent by a user program and sending the system call request to the system call agent module, the system call verification module is used for applying for a call execution state of the RipOS operating system to the system call state machine and checking whether numbers and parameters of the RipOS operating system call accord with semantics of the RipOS operating system call, the system call conversion module is used for making confidentiality protection measures to the system call parameters and applying for a message structure body in a shared memory, the system call state machine is used for storing call execution states of the RipOS operating system, the system call state machine comprises four parts, wherein the first part is a file path tree structure, each node represents a directory or a file and is used for storing static information of files, the static information comprises file names, file types, authority files (read, write and execute) and file sizes, the second part is a service system file list operation descriptor, the first part is used for storing a file name, the service system call list, the third part is used for opening a service system call list, the service system call list is used for opening a file, the third part is used for a service system call list, the service list is used for opening a file, the relative state list is used for a file, and the relative state list is opened, and the relative to a list is opened, and a list of a file is opened, and mainly recording the socket descriptor and the corresponding socket state information.
Specifically, the step S100 includes the steps of:
step S101, receiving a system call request sent by a user program through a system call processor, and sending the system call request to a system call proxy module;
step S102, verifying the validity of the system call request by using the system call proxy module, taking confidentiality protection measures for the system call parameters after verification is successful, and applying for a message structure in the shared memory.
In one implementation, when a user program needs to make a system call to a kernel module excluded from the trusted computing base, for example, a read system call for reading a file and a socket system call for creating a socket, the system call is completed by a proxy mode. Firstly, a system call processor receives a system call request sent by a user program and sends the system call request to a system call proxy module, the security and flexibility of the system are increased, requests entering a kernel are controlled and filtered, the risk of directly exposing kernel codes is reduced, then, the system call verification module is utilized to apply for the call execution state of the RipOS operating system to a system call state machine, whether the number and parameters of the RipOS operating system call accord with the semantics of the RipOS operating system call or not is checked, the robustness and the security of the system are improved, the system is ensured to be further executed only by the verified request, so that the penetration of illegal requests is prevented, if the call execution state is not in a ready state or the semantics are incorrect, the system call execution state is not executed downwards, and is directly returned to error codes corresponding to the user program, the illegal requests are responded in time, unnecessary resource consumption is avoided, if the call execution state is in a ready state, and the semantics are correct, confidentiality protection measures are made on the system call parameters based on the system call conversion module, so that sensitive information leakage is prevented, the security protection is enhanced, the security is ensured, the security of the system call parameters is ensured, the shared by the system call conversion module is used for the system call parameters, and the shared by the shared memory of the system, and the memory of the system is ensured, and the memory structure of the system is required to be identical.
And step 200, reading the message structure body based on a serviceOS operating system to complete the call of a second type of call item, wherein the second type of call item is a functional item initiated by the RipOS operating system and subjected to confidentiality verification and integrity verification.
In this embodiment, after a message structure is applied in the shared memory, the ServiceOS-based operating system reads the message structure to complete the call of the second class of call items, where the second class of call items is a system call initiated by the RipOS operating system and processed by the ServiceOS operating system after confidentiality and integrity verification, so that only the verified legal system call request can be executed, thereby enhancing the security and reliability of the system.
Specifically, the step S200 includes the steps of:
Step S201, starting a system call processing program based on a ServiceOS operating system;
Step S202, reading the message structure body from the shared memory by using the system call processing program, reading information of a system call request to be processed from the message structure body, and converting the information of the system call request to be processed into a corresponding POSIX function on a Linux system;
And step S203, calling a Linux kernel at the bottom layer to process the POSIX function to finish the call of the second type of call item.
In one implementation, a system call processing program is started based on a ServiceOS operation system, the system call processing program is a user state program, better security isolation can be provided, management and debugging are facilitated, then the message structure body is read from the shared memory by the system call processing program, dequeuing operation is carried out on the message structure body, information of a system call request to be processed is read from the message structure body, the information of the system call request to be processed is converted into a corresponding POSIX function on a Linux system, the requests are ensured to be processed according to a first-in first-out principle through dequeuing operation, the correctness of a processing sequence is ensured, and finally, the POSIX function is processed by a Linux kernel at the bottom layer in the ServiceOS operation system to complete the call of a second type of call item, so that the system call request can be safely and reliably transferred and executed.
The second class 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 does not leak the execution logic of the RipOS operating system, and does not cause additional information leakage compared with the Linux kernel. The integrity means that the returned value and the returned metadata of the ServiceOS operating system cannot destroy the normal running state of the RipOS operating system, and the execution result of the ServiceOS operating system accords with POSIX semantics. The invention makes a certain security check in terms of confidentiality and integrity to ensure that confidentiality and integrity are not additionally damaged under the condition of reducing trusted computing base, and the second class of call items comprise file system related system call and network related system call.
In one implementation, the second class of call items are completed, which further includes firstly obtaining a return value and data generated by the Linux kernel, then writing the return value and the data back to the message structure by using the system call processing program, modifying the call execution state of the RipOS operating system to a responded state to inform RipOS operating system that the system call request has been processed, and then verifying the return value and the data by using the system call verification module based on the responded state 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, so that the accurate transmission and verification of the system call result are ensured, and the behavior of the ServiceOS operating system proxy system call is transparent to the user program, so that the user program does not know whether the underlying operating macro kernel or the ServiceOS operating system kernel is not required to be modified, and can work normally.
In one implementation, the present invention defines a system call that requires proxy but cannot guarantee security as a third class of system call. The third class of system calls is generally limited to confidential virtual machine architecture, resulting in failure to check confidentiality and integrity at the operating system level. This portion of the system call includes a time-acquired system call and an ioctl (Input/Output Control) system call. The ioctl system call is a system call for operating the underlying device. The parameters of the ioctl system call consist of fd (File Descriptor) device file descriptors, request type and args (Arguments) request parameters. Since the threat model of the confidential virtual machine partitions all external devices into untrusted portions, operations on external devices through ioctl system calls are all untrusted activities. In addition, the parameters of the ioctl system call have diversity and definability, and different vendors may control devices according to different devices and driver customization specific parameters, 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 in confidential virtual machine models, and secure time acquisition requires that the confidential virtual machine framework provide a trusted clock, which is beyond the resolution of the operating system. But the third class of system calls does not make RipOS operating systems less secure than the Linux kernel. Taking ioctl as an example, its security is mainly because the object of the operation is an untrusted device, but the same security issues exist for the operation of an untrusted device in the macro kernel. For the third class of system calls, the RipOS operating system, except for some analog devices implemented internally, such as zero devices, null devices, etc., does not protect the security when handling external devices using ioctl system calls, nor does it trust its return value. In addition, ripOS operating systems do not guarantee the correctness of the time obtained by the host.
In one implementation, the present invention discusses the security impact of invoking the second type of invocation item from a confidentiality and integrity perspective. From the aspect of confidentiality, the action of using the ServiceOS operating system to proxy the system call exposes the system call parameters to an unreliable host, and the leaked system call parameters can be divided into two types, namely a type of parameters which are directly or indirectly leaked by a Linux kernel, and another type of parameters which are additionally leaked due to the ServiceOS operating system proxy system call action. Considering that even if a Linux kernel is running in a confidential virtual machine, interactions between the confidential virtual machine and the hardware are visible to an attacker, while the ServiceOS operating system proxy kernel directly leaks system call related information, the file system and network related system calls eventually translate into operations on the hardware, which is equivalent to a more advanced representation of the leaked hardware operations. The hardware devices are not inherently in the trusted computing base of the confidential virtual machine architecture, so such leakage does not impose additional burden of protecting confidentiality. For the second type of leakage parameters, the system call conversion module in RipOS operating system can take measures such as anonymization to protect confidentiality.
From an integrity aspect, a malicious attacker may interface to the RipOS operating system by manipulating the system call handler of the ServiceOS operating system to return erroneous values or metadata, thereby changing the control flow of the application in the RipOS operating system and the state of the RipOS operating system itself. In this regard, the RipOS operating system semantically models the system call in a manner similar to that in BesFS (Bes FILE SYSTEM, bei Siwen systems), specifies the normal behavior of the ServiceOS operating system proxy system call, and protects the integrity of the ServiceOS operating system proxy system call in conjunction with verification of the system call state machine, any behavior that deviates from the specified semantics being considered an illegal operation and possibly an attack.
In summary, this embodiment provides a confidential virtual machine operating system, which includes a RipOS operating system, wherein the RipOS operating system is configured to process a first type of call item implemented in the RipOS operating system, the first type of call item reflects a function item called by the RipOS operating system, and a ServiceOS operating system is configured to proxy a second type of call item, and the second type of call item is initiated by the RipOS operating system and is a function item after confidentiality verification and integrity verification. The invention processes the core system call through RipOS operating system, and the ServiceOS operating system processes the system call needing proxy, thereby greatly reducing the trusted computing base of the confidential virtual machine, reducing the security risk, enhancing the defending capability to external attack and improving the overall security and the resource utilization efficiency of the system.
Based on the above embodiment, the present invention also provides a terminal, and a schematic block diagram of the terminal may be shown in fig. 3. The terminal may include one or more processors 100 (only one shown in fig. 3), a memory 101, and a computer program 102, e.g., a system call agent, stored in the memory 101 and executable on the one or more processors 100. The one or more processors 100, when executing the computer program 102, may implement various steps in a system call proxy method embodiment. Or the one or more processors 100, when executing the computer program 102, may implement the functions of the modules/elements of the system call agent method embodiment, without limitation.
In one embodiment, the Processor 100 may be a central processing unit (Central Processing Unit, CPU), but may also be other general purpose processors, digital signal processors (DIGITAL SIGNAL processors, DSPs), application SPECIFIC INTEGRATED Circuits (ASICs), off-the-shelf Programmable gate arrays (Field-Programmable GATE ARRAY, FPGA) or other Programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
In one embodiment, the memory 101 may be an internal storage unit of the electronic device, such as a hard disk or a 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 provided on the electronic device, a smart memory card (SMART MEDIA CARD, SMC), a Secure Digital (SD) card, a flash memory card (FLASH CARD), or the like. Further, the memory 101 may also include both an internal storage unit and an 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 data that has been output or is to be output.
It will be appreciated by those skilled in the art that the functional block diagram shown in fig. 3 is merely a block diagram of some of the structures associated with the present inventive arrangements and is not limiting of the terminal to which the present inventive arrangements may be applied, and that a particular terminal may include more or less components than those shown, or may combine some of the components, or have a different arrangement of components.
Those skilled in the art will appreciate that implementing all or part of the above-described methods may be accomplished by way of a computer program, which may be stored on a non-transitory computer readable storage medium, that when executed may comprise the steps of the embodiments of the methods described above. Any reference to memory, storage, operational database, or other medium used in embodiments provided herein may include non-volatile and/or volatile memory. The nonvolatile memory can include Read Only Memory (ROM), programmable ROM (PROM), electrically Programmable ROM (EPROM), electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual operation 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), among others.
It should be noted that the above-mentioned embodiments are merely for illustrating the technical solution of the present invention, and not for limiting the same, and although the present invention has been described in detail with reference to the above-mentioned embodiments, it should be understood by those skilled in the art that the technical solution described in the above-mentioned embodiments may be modified or some technical features may be equivalently replaced, and these modifications or substitutions do not make the essence of the corresponding technical solution deviate from the spirit and scope of the technical solution of the embodiments of the present invention.
Claims (9)
1. A confidential virtual machine operating system, the system comprising:
RipOS an operating system, wherein the RipOS operating system is used for processing a first type of call item which is internally realized by the RipOS operating system and reflects a function item called by RipOS operating system operation;
The serviceOS operating system is used for carrying out proxy processing on second-class call items, wherein the second-class call items are functional items initiated by the RipOS operating system and subjected to confidentiality verification and integrity verification;
the RipOS operating system comprises a system call processor and a system call proxy module, wherein the system call processor is used for receiving a system call request sent by a user program and sending the system call request to the system call proxy module;
The system call agent module comprises a system call state machine, a system call verification module and a system call conversion module, wherein the system call state machine is used for storing the call execution state of the RipOS operating system, the system call verification module is used for applying the call execution state of the RipOS operating system to the system call state machine and checking whether the number and the parameter of the RipOS operating system call accord with the semantic of the RipOS operating system call or not, and the system call conversion module is used for making confidentiality protection measures on the system call parameters and applying a message structure in a shared memory;
The ServiceOS operating system comprises a system call processing program, wherein the system call processing program is used for reading the message structure body from the shared memory, reading information of a system call request to be processed from the message structure body, and converting the information of the system call request to be processed into a POSIX function corresponding to a Linux system.
2. A system call proxy method based on the confidential virtual machine operating system of claim 1, the method comprising:
acquiring a system call request sent by a user program through RipOS operating system, and applying for a message structure body in a shared memory based on the system call request;
And reading the message structure body based on a ServiceOS operating system to complete the call of a second type of call item, wherein the second type of call item is a functional item initiated by the RipOS operating system and subjected to confidentiality verification and integrity verification.
3. The system call proxy method of claim 2 wherein said RipOS operating system includes a system call proxy module and a system call processor, said system call proxy module including a system call state machine, a system call validation module and a system call translation module, said ServiceOS operating system including a system call handler.
4. The system call proxy method of claim 3, wherein the obtaining, by the RipOS operating system, a system call request sent by a user program, and applying for a message structure in a shared memory based on the system call request, includes:
Receiving a system call request sent by a user program through a system call processor, and sending the system call request to a system call proxy module;
and verifying the validity of the system call request by using the system call proxy module, taking confidentiality protection measures for the system call parameters after verification is successful, and applying for a message structure in the shared memory.
5. The system call proxy method of claim 4, wherein the ServiceOS-based operating system reads the message structure to complete the call of the second class of call items, comprising:
Starting a system call processing program based on a ServiceOS operating system;
reading the message structure body from the shared memory by using the system call processing program, reading information of a system call request to be processed from the message structure body, and converting the information of the system call request to be processed into a POSIX function corresponding to a Linux system;
And calling a Linux kernel of the bottom layer to process the POSIX function to finish the call of the second type of call item.
6. The system call proxy method of claim 5, wherein verifying the validity of the system call request with the system call proxy module, taking confidentiality protection measures for system call parameters after verification is successful, and applying for a message structure in a shared memory, comprises:
Applying for the call execution state of the RipOS operating system to a system call state machine by using the system call verification module, and checking whether the number and the parameters of the RipOS operating system call accord with the semantics of the RipOS operating system call;
If the call execution state is in a ready state and the semantics are correct, confidentiality protection measures are made for the system call parameters based on the system call conversion module, and a message structure body is applied for in the shared memory, wherein the message structure body comprises the number, the parameters and the data of the system call request.
7. The system call proxy method of claim 6, wherein the completing the call of the second type of call item further comprises:
Acquiring a return value and data generated by the Linux kernel;
Writing the return value and the data back to the message structure by using the system call handler, and modifying the call execution state of the RipOS operating system to a responded state;
And 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 comprising a memory, a processor and a system call agent stored in the memory and operable on the processor, the processor implementing the steps of the system call agent method of any of claims 2-7 when executing the system call agent.
9. A computer readable storage medium, wherein a system call agent is stored on the computer readable storage medium, which system call agent, when executed by a processor, implements the steps of the system call agent method according to any of claims 2-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202510309126.5A CN119806754B (en) | 2025-03-17 | 2025-03-17 | Confidential virtual machine operating system, system call proxy method, terminal and medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202510309126.5A CN119806754B (en) | 2025-03-17 | 2025-03-17 | Confidential virtual machine operating system, system call proxy method, terminal and medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN119806754A CN119806754A (en) | 2025-04-11 |
| CN119806754B true CN119806754B (en) | 2025-07-18 |
Family
ID=95262920
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202510309126.5A Active CN119806754B (en) | 2025-03-17 | 2025-03-17 | Confidential virtual machine operating system, system call proxy method, terminal and medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN119806754B (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113763227A (en) * | 2021-07-19 | 2021-12-07 | 锐捷网络(苏州)有限公司 | Data processing method, device and system |
| CN118862043A (en) * | 2024-07-01 | 2024-10-29 | 亿咖通(湖北)技术有限公司 | Application calling method, device, electronic device and storage medium |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AU2008200148B2 (en) * | 2001-09-10 | 2010-01-21 | Igt | Method for developing gaming programs compatible with a computerized gaming operating system and apparatus |
| US7720671B2 (en) * | 2006-11-30 | 2010-05-18 | Oracle America, Inc. | Method and system for child-parent mechanism emulation via a general interface |
| CN105404547A (en) * | 2014-09-12 | 2016-03-16 | 阿里巴巴集团控股有限公司 | Fusion method and device of operating system |
| US9628279B2 (en) * | 2014-09-30 | 2017-04-18 | Microsoft Technology Licensing, Llc | Protecting application secrets from operating system attacks |
| CN109254902B (en) * | 2018-07-10 | 2022-02-08 | 南京大学 | Evidence obtaining system and method based on user intention detection and applied to cloud computing environment |
| CN110874468B (en) * | 2018-08-31 | 2024-02-09 | 华为技术有限公司 | Application security protection methods and related equipment |
-
2025
- 2025-03-17 CN CN202510309126.5A patent/CN119806754B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113763227A (en) * | 2021-07-19 | 2021-12-07 | 锐捷网络(苏州)有限公司 | Data processing method, device and system |
| CN118862043A (en) * | 2024-07-01 | 2024-10-29 | 亿咖通(湖北)技术有限公司 | Application calling method, device, electronic device and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN119806754A (en) | 2025-04-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112035272B (en) | Method and device for interprocess communication and computer equipment | |
| US11089016B2 (en) | Secure system on chip | |
| JP6083097B2 (en) | Method for facilitating system service request interaction of hardware protection applications | |
| KR102255767B1 (en) | Systems and methods for virtual machine auditing | |
| JP4498735B2 (en) | Secure machine platform that interfaces with operating system and customized control programs | |
| US8024564B2 (en) | Automating configuration of software applications | |
| US9059855B2 (en) | System and method for implementing a trusted dynamic launch and trusted platform module (TPM) using secure enclaves | |
| US8327415B2 (en) | Enabling byte-code based image isolation | |
| US8429648B2 (en) | Method and apparatus to service a software generated trap received by a virtual machine monitor | |
| BRPI0618027A2 (en) | configuration of isolated extensions and device triggers | |
| CN113791898B (en) | A TrustZone-Based Trusted Microkernel Operating System | |
| CN118585286A (en) | Operating system server resource isolation method and system under microkernel architecture | |
| CN118051421A (en) | IO delay fault injection method, device, electronic device and storage medium | |
| CN118093202B (en) | Processing method of access exception, computing device, storage medium and program product | |
| CN119806754B (en) | Confidential virtual machine operating system, system call proxy method, terminal and medium | |
| US7779407B2 (en) | Computer-hardware, life-extension apparatus and method | |
| WO2023045744A1 (en) | Reinforcement method, registration method, running method, electronic device and storage medium | |
| CN110852139A (en) | Biometric feature recognition method, biometric feature recognition device, biometric feature recognition equipment and storage medium | |
| US20250173129A1 (en) | Protecting and attesting program executions through shadow programs | |
| Schäfer | Securing process execution by verifying the inner process state through recording and replaying on different platforms | |
| CN111382442B (en) | Application processor, coprocessor and data processing equipment | |
| Julku et al. | Towards a Rust SDK for Keystone Enclave Application Development. | |
| HK40027792A (en) | Biological feature recognition method, device, equipment and storage medium | |
| CN116561811A (en) | File trusted tamper-proof method, device and electronic equipment | |
| Takaronis | Linux kernel exploitation, a wonderful mess |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |