A method for detecting and controlling system-level events in a library operating system

Abstract

The present invention discloses a method for detecting and controlling system-level events in a library operating system. As a single-core operating system, Unikernel requires a thread in the traditional monitoring method, which will cause resource preemption between the monitoring thread and the main thread, greatly affecting the execution of the main program. However, the present invention is a threadless monitoring method that can collect and analyze the running state of Unikernel in real time without interfering with the main thread, improving the efficiency and accuracy of monitoring. The existing stack monitoring method is not flexible enough. If there are important events on the stack, it is necessary to continuously poll to know the situation. There is no automatic triggering mechanism to notify the stack behavior, and the controllability is not strong. The present invention constructs an event-driven stack monitoring method that can automatically trigger the corresponding callback function when changes occur on the stack, realizing timely response and processing of stack events, and improving the flexibility and controllability of stack monitoring.

Description

Technical Field

[0001] The present invention belongs to the field of computer technology, and particularly relates to a method for detecting and controlling system-level events in a library operating system. Background Art

[0002] As a lightweight and task-specific library operating system, Unikernel has received increasing attention in recent years in scenarios such as cloud computing and embedded systems. Its core idea is to integrate application programs with the operating system kernel to achieve professional customization of application programs, providing excellent performance and minimal resource consumption. However, the customization characteristics of Unikernel pose a series of challenges related to error repair, function enhancement, and environment adaptation. To adapt to dynamic requirements, Unikernel needs to support a series of functions such as hot patching and code replacement to allow immediate error repair and function enhancement. At the same time, to achieve more flexible application adaptability, Unikernel also needs to introduce some key dynamic update functions, including event monitoring, function call interception, and transaction capture, etc.

[0003] In the solutions of operating systems with architectures such as microkernels and macrokernels, a strategy of creating new processes for inspection is basically adopted. Specifically, for example, for security point inspection of dynamic updates, a method of using new processes to poll and monitor function calls on the process stack that needs attention is adopted. In this process, the system periodically checks whether there are insecure situations on the stack. If an insecure event is found, the update operation is temporarily aborted, and after waiting for a certain period of time, the check is performed again. This cycle continues until there are no longer insecure events, and then the system starts to execute the dynamic update operation. However, due to the unique characteristic of Unikernel having a single process, traditional operating system-level event monitoring and function call listening technologies are difficult to apply directly. In a single-core system, existing monitoring methods consume a large amount of CPU resources, which is unbearable in the context of Unikernel, and such resource occupancy will seriously affect the execution efficiency of the main program. Therefore, new methods and technologies need to be explored to achieve effective security inspection and dynamic update in the Unikernel environment while minimizing the impact on system performance. Summary of the Invention

[0004] Aiming at the defect that existing event monitoring occupies excessive CPU resources, the present invention proposes a method for detecting and controlling system-level events in a library operating system.

[0005] The present invention includes the following steps:

[0006] Step 1: The interrupt handler stops the execution of the original program, saves the process stack, and the event checker starts to be launched;

[0007] Step 2: The event checker obtains the memory space of the process stack from the interrupt stack, and then traverses the process stack frames to record the program call flow graph in the library operating system before the interrupt occurs;

[0008] Step 3: The address locator identifies the function library where each stack frame function is located, determines whether it is a special event, and puts it into the special event set;

[0009] Step 4: Determine whether the special event set is empty. If the special event set is empty, directly execute the specified control function; otherwise, locate the special root event and deploy the function trigger;

[0010] Step 5: After the function trigger is deployed, end the interrupt handler and start executing the source program;

[0011] Step 6: Automatically trigger the function trigger after executing to the fixed function, and call the pre-set control function;

[0012] Step 7: After the control function is executed, jump back to the source program; the program starts to execute normally.

[0013] Compared with the prior art, the beneficial effects of the present invention are:

[0014] (1) As a single-core operating system, Unikernel requires a thread in the traditional monitoring method, which will cause resource preemption between the monitoring thread and the main thread, greatly affecting the execution of the main program. However, the present invention is a threadless monitoring method, which can collect and analyze the running state of Unikernel in real time without interfering with the main thread, improving the efficiency and accuracy of monitoring.

[0015] (2) The existing stack monitoring method is not flexible enough. If there is an important event on the stack, it must be continuously polled to know its situation. There is no automatic trigger mechanism to notify the stack behavior, and the controllability is not strong. The present invention constructs an event-driven stack monitoring method, which can automatically trigger the corresponding callback function when there is a change on the stack, realizing the timely response and processing of stack events, and improving the flexibility and controllability of stack monitoring.

[0016] (3) Traditional monitoring and control are often difficult to be effectively combined. The present invention can realize the integration of monitoring and control, and can automatically execute the corresponding control strategy when detecting the abnormality or requirement change of Unikernel, realizing the adaptive adjustment and optimization of Unikernel, and improving the stability and adaptability of Unikernel.

[0017] (4) Traditional monitoring and control means may intrude into the execution flow of Unikernel programs, affecting the normal operation of the programs. The present invention proposes a non-intrusive monitoring and control technology that can monitor and control the execution flow of Unikernel programs without modifying the source code or binary code of Unikernel programs, realizing transparent management of Unikernel programs and improving the credibility and maintainability of Unikernel programs.

[0018] (5) The Unikernel system is a lightweight and dynamically loaded system. The present invention is a technology that can dynamically detect and process events as the program runs to adapt to the changing requirements in different scenarios. The technology of dynamic instrumentation through the constructed function triggers can dynamically insert and delete monitoring and control codes at key points of Unikernel programs without affecting the performance of Unikernel programs, realizing dynamic monitoring and control of Unikernel programs and improving the flexibility and adaptability of Unikernel programs. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 It is a flowchart of the method of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0020] To make the objectives, technical solutions and advantages of the present invention clearer, the following further describes in detail the specific embodiments of the present invention with reference to the drawings. Examples of these preferred embodiments are illustrated in the drawings. The embodiments of the present invention shown in the drawings and described according to the drawings are merely exemplary, and the present invention is not limited to these embodiments.

[0021] Here, it should also be noted that in order to avoid obscuring the present invention with unnecessary details, only the structures and / or processing steps closely related to the solution of the present invention are shown in the drawings, while other details less related to the present invention are omitted.

[0022] The present invention will be further described below with reference to the drawings and specific embodiments. It should be understood that these embodiments are only used to illustrate the present invention and not to limit the scope of the present invention. The operating methods without specific conditions noted in the following embodiments are generally in accordance with conventional conditions or in accordance with the conditions recommended by the manufacturers. The present invention will be further described below with reference to the drawings and specific embodiments. It should be understood that these embodiments are only used to illustrate the present invention and not to limit the scope of the present invention. The operating methods without specific conditions noted in the following embodiments are generally in accordance with conventional conditions or in accordance with the conditions recommended by the manufacturers.

[0023] This application proposes a system-level event detection and control technique method for the Unikernel library operating system to address the deficiencies of the prior art. This method mainly includes three parts: an event checker, an address locator, and a function trigger.

[0024] Among them: The address locator is used to locate the function call addresses of Unikernel programs. The event checker is used to monitor and intercept unsafe or special function events. The function trigger is used to automatically execute corresponding functional operations.

[0025] Furthermore, the event checker is the core part. It pauses the execution of the Unikernel program through the interrupt mechanism, then checks the function call flow of the stack, determines the current function call status based on the information of the address locator. If an event that needs to be processed is found, the function trigger is deployed to the call location of this event and waits for automatic triggering. The event checker can utilize stack management to achieve transparent asynchronous function triggering in a single-threaded environment. If no event that needs to be processed is found, the event checker resumes the execution of the Unikernel program until all function events are detected.

[0026] The specific steps of the embodiments of this application are as Figure 1 shown as follows:

[0027] Step 1: The interrupt handler stops the execution of the original program, saves the process stack, and the event checker starts.

[0028] The startup process of the event checker is implemented by registering a startup command in the interrupt handler.

[0029] Specifically, this startup command registers the event checker as part of the event check interrupt handler. When the user issues a monitoring request, the hypervisor immediately responds and triggers the event check interrupt handler.

[0030] Furthermore, when the user's monitoring request arrives, the hypervisor first identifies the nature of the request and invokes the event check interrupt handler according to preset rules and program calls. The original normally executing program of Unikernel will be stopped, and all relevant registers will also be stored on the stack. The event check interrupt handler will execute in the interrupt stack. At this time, the event checker is started and enters its specified operation mode, ready to execute a series of predetermined monitoring and control tasks. The startup registration of the event checker is in the Unikernel software interrupt handler, making it the event check interrupt handler.

[0031] Furthermore, when the event checker starts, it immediately executes the local_irq_disable command to prohibit all other software interrupts, so as to maintain the stack environment of the current program undisturbed. To prevent other interrupt sources from damaging the stack environment of the current program, the event checker can work in a controlled environment to ensure that it can accurately record and analyze events.

[0032] Step 2: The event checker will obtain the memory space of the process stack from the interrupt stack, and then traverse the stack frames of the process stack to record the program call flow graph in the Unikernel before the interrupt occurs.

[0033] After the event checker starts, it will begin to check the stack because the program information that the Unikernel was executing before the interrupt is stored in the stack. The stack check is performed in the event check interrupt handler, and at this time, the interrupt stack will be scanned.

[0034] In an example, under the X86 instruction set, the event checker will first obtain the value of the RBP register of the current CPU. This register carries the base address of the current function, and through it, the starting position of the current interrupt stack frame can be accurately located. Then, by accessing the memory at the starting position of the current stack frame, the base address of the previous stack frame can be obtained. Subsequently, based on this address, the previous stack frame can be scanned. By continuously moving up the stack frame and checking the stack memory space under the stack frame, the event checker realizes the scanning and spatial positioning of the entire interrupt stack. That is, by traversing all the stack frames on the interrupt stack and performing access and stack frame movement operations in advance until reaching the bottom of the stack. At the bottom of the interrupt stack, this is the first stack frame of the interrupt stack and also the position of the interrupt handler when the interrupt is started. Here, the context of the process stack saved during the execution of the event check interrupt is saved, that is, registers such as RBP and RSP on the process stack. The memory space of the process stack can be found through this.

[0035] Subsequently, the event checker starts to check the process stack. The process stack is checked in the same way of traversing stack frames as the interrupt stack. However, the event checker will extract key information by accessing the current stack frame, including elements such as the return address and parameter values. Through precise stack frame access, the event checker can obtain important data about the current execution context. By continuously traversing the stack frames, the call process of the Unikernel program before the interrupt occurs can be obtained, and by recording the base address of each stack frame and then moving eight bytes forward in memory (the return address of the current stack frame), a Unikernel program call flow graph can be constructed.

[0036] Furthermore, during the traversal process, the event checker will also check whether each stack frame conforms to the expected format and content, and whether there are signs of stack overflow or damage. If any abnormalities or errors are found, the event checker will immediately report and terminate the stack check.

[0037] Step 3: The address locator identifies the function library where each stack frame function is located, determines whether it is a special event, and puts it into the special event set.

[0038] For the location of functions, in this embodiment, it is mainly judged by the function instruction address. The address locator matches the instruction address with the memory area where the function is located to determine whether it belongs to the required function. The function instruction address is mainly obtained from the return address stored in each stack frame on the process stack.

[0039] After obtaining the program call flow graph, through the return address, the memory address of the instruction being executed by the function caller can be obtained. According to the stack space allocation, the return address is stored in the eight-byte memory location before the stack frame. This address is the position where the program needs to jump after the current function execution ends, that is, the memory address of the instruction that the function caller needs to execute next.

[0040] The program call flow graph records the detailed information of each stack frame in the process stack. The address locator will identify the function library where the function corresponding to each stack frame is located and which type of function it belongs to. The event checker can obtain the memory address of the instruction that the function caller needs to execute next according to the return address of each function. If function A calls function B, then the return address at the stack frame where function B is located points to the next instruction after function A finishes executing function B. Subsequently, the address locator matches the return address with the micro-library symbol address table it maintains, thereby judging the information of the current function, that is, clarifying which function function A specifically is. Since there is no return address to judge for the function corresponding to the topmost stack frame in the process stack. At this time, the address locator will obtain the function instruction address being executed by this function through the RIP register saved at the bottom of the interrupt stack.

[0041] Furthermore, in order to distinguish the specific types of each program in the program call flow graph, this application constructs a micro-library symbol address table during the Unikernel compilation and linking. The address locator will locate and record the relative address range and offset of each library function instruction by the link script according to the.text segment compiled for each library during the link merge. Specifically:

[0042] First, based on the default link script, the address locator defines local symbols representing the start and end addresses of the code segment before and after the.text section through the PROVIDE_HIDDEN directive. Subsequently, a structure variable containing symbols such as the library name, the start address, and the end address of the library code segment is defined in the source file and placed in the.uk_libaddr section. In this application, the source file is compiled with each library separately to generate the corresponding.o file for each library, and the.uk_libaddr section containing the library name and the start and end addresses of the code segment will be included. When linking into the final uk image, the.uk_libaddr sections in all library files are used as input to generate a single.uk_libaddr section, which is the micro-library symbol address table of the address locator. It contains the offset address and its range information of each function library in memory after the program is loaded, facilitating subsequent querying of function events by the event checker.

[0043] Based on the instruction address and the micro-library symbol address table, the address locator identifies the function library to which each stack frame function in the process stack belongs. If the function is an unsafe event or an event that the user needs to control, the event checker can put the event into a special event set. The special event set refers to the set of special events that were being executed before the interruption, and special events will match different requirements in different scenarios. For example, during a security check, the special event can be an unsafe event. The event checker will sequentially check each function relying on the program call flow graph until all events are checked.

[0044] Step 4: If the special event set is empty, directly execute the specified control function.

[0045] The empty special event set indicates that the function execution flow before the interruption is secure. At this time, in the event check interrupt handling function, the pre-set control function will be directly executed. The implementation of the control function is similar to a callback function, which is set in advance by the developer, exists as a function library, and is added to the Unikernel image after Unikernel compilation and linking.

[0046] When the control function execution is completed, directly end the interrupt handling program and resume the execution of the normal program.

[0047] Step 5: If the special event set is not empty, locate the special root event and deploy the function trigger.

[0048] If the special event set is not empty, the event checker will search for the special root event in the special event set and deploy the function trigger. The function trigger can automatically execute the pre-set control function operations, such as logging, sending notifications, calling other functions, etc., after the special root event is executed, according to the type of the special root event, and does not require invasive modification to the original program.

[0049] Furthermore, the deployment of the function trigger requires a prerequisite that at least one special event must be included in the special event set. The event checker will traverse each event in the special event set, find the special event closest to the bottom of the process stack, and use it as the special root event. In the program execution environment of a Unikernel single-process, any function event in the stack will affect the subsequent function event calls. Therefore, the event checker will use the special event closest to the bottom of the stack as the special root event.

[0050] To trigger the function after all special events on the stack have been completed, the event checker will obtain the call return address of the special root event. After the special root event execution ends, by default, the ret instruction will jump to its caller according to the return address. The event checker processes this return address in advance and saves the return address into the function trigger. Subsequently, the event checker points this address to the location where the function trigger is located, completing the deployment of the function trigger.

[0051] Step 6: After the function trigger is deployed, end the interrupt handler and start executing the source program again.

[0052] When the function trigger is successfully deployed, the execution of the interrupt handler will end. At this time, the Unikernel continues to execute the program before the interruption, that is, execute the program functions along the process stack call order.

[0053] Step 7: Automatically trigger the function trigger after executing to the fixed function, and call the pre-set control function.

[0054] As time goes by, the special root event will be executed at a certain moment. At this time, the CPU will jump according to the return address through the ret instruction. Due to the deployment of the function trigger, at this time, the IP instruction register points to the instruction of the function trigger, and starts to trigger the set function by the function trigger. During this process, the CPU will jump to the specified code segment according to the return address and then execute the instructions in that code segment.

[0055] Since the function trigger changes the execution logic of the original function calls on the stack, in order to avoid damaging the program execution flow and protecting the context of the original function caller, the function trigger will save the register values that may be affected by the function trigger by pushing them onto the stack. In the X86 64-bit instruction set, rax, rbx, rcx, rdx, rsi, rdi, rbp, rsp, r8, r9, r10, r11, r12, r13, r14, and r15 will be pushed onto the stack and saved.

[0056] Subsequently, the function trigger executes the pre-set function, which can be freely set by the user and can be demand operations such as program update, data monitoring, error capture, etc.

[0057] Step 8: After the control function is executed, jump back to the original program. The program starts to execute normally.

[0058] After the set control function is completed, the function trigger pops the originally saved register from the stack to restore the context of the original program, and simulates the ret instruction after the function call on the stack. It jumps back to the next instruction of the Unikernel original program through the jmp instruction, and the program starts to execute normally. In this way, it is possible to complete the external special function trigger without the awareness of the original program flow by means of the current process and CPU, without affecting the execution of the original stack operations.

[0059] In addition, it should be noted that in this specification, "including", "comprising" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "including one..." does not exclude the existence of additional identical elements in the process, method, article or device including the said element.

[0060] It should be understood that although this specification is described according to the embodiments, not every embodiment only contains an independent technical solution. This narrative way of the specification is only for clarity. Those skilled in the art should regard the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A method for detecting and controlling system-level events in a library operating system, characterized in that The method includes the following steps: Step 1: The interrupt handler stops the execution of the original program, saves the process stack, and the event checker starts to be launched; Step 2: The event checker obtains the memory space of the process stack from the interrupt stack, and then traverses the process stack frames to record the program call flow graph in the library operating system before the interruption occurs; Step 3: The address locator identifies the function library where each stack frame function is located, determines whether it is a special event, and puts it into the special event set; Step 4: Determine whether the special event set is empty. If the special event set is empty, directly execute the specified control function; otherwise, locate the special root event and deploy the function trigger; Step 5: After the function trigger is deployed, the interrupt handler ends, and the source program starts to be executed continuously; Step 6: After executing to a fixed function, the function trigger is automatically triggered, and the pre-set control function is called; Step 7: After the control function is executed, jump back to the source program; the program starts to execute normally.

2. The method for library operating system system-level event detection and control according to claim 1, characterized in that: The launch of the event checker described in Step 1 is achieved by registering a launch command in the interrupt handler.

3. A method for library operating system system-level event detection and control according to claim 1, characterized in that: In Step 2, the event checker first obtains the value of the RBP register of the current CPU. This register carries the base address of the current function, and through it, the starting position of the current interrupt stack frame is accurately located; Then, by accessing the memory at the starting position of the current stack frame, the base address of the previous stack frame is obtained; Subsequently, the previous stack frame is scanned according to the base address; By continuously moving up the stack frame and checking the stack memory space under the stack frame, the event checker realizes the scanning and space positioning of the entire interrupt stack.

4. A method for system-level event detection and control of a library operating system according to claim 3, characterized in that: By continuously traversing the stack frames, the call process of the program in the library operating system before the interruption occurs is obtained, and the memory eight bytes ahead of the base address of each stack frame is recorded, thereby constructing the program call flow graph.

5. A method for library operating system system-level event detection and control according to claim 1, characterized in that: The program call flow graph records the detailed information of each stack frame in the process stack. The address locator will identify the function library where each stack frame corresponds to the function. The event checker obtains the memory address of the instruction that the function caller needs to execute next according to the return address of each function.

6. A method for system-level event detection and control in a library operating system according to claim 1, characterized in that: In order to distinguish the specific types of each program in the program call flow graph, a micro-library symbol address table is constructed during the compilation and linking of the library operating system. The address locator locates and records the relative address range and offset of each library function instruction according to the.text segment compiled by each library through the link script during the link merge.

7. A method for library operating system system-level event detection and control according to claim 1, characterized in that: The function trigger described in Step 6 saves the register values that may be affected by the function trigger by pushing them onto the stack.

Images