Library operating system system level event detection and control method

Abstract

The invention discloses a system level event detection and control method of a library operating system, Unikernel is used as a single-core operating system, a traditional monitoring mode needs to use a thread, a monitoring thread and a main thread can perform resource preemption, and execution of a main program is greatly influenced. According to the method, a wireless monitoring mode is adopted, the running state of the Unikernel can be collected and analyzed in real time under the condition that the main thread is not interfered, and the monitoring efficiency and accuracy are improved. An existing stack monitoring mode is not flexible enough, and if an important event exists on a stack, the important event can be monitored through continuous polling. No automatic triggering mechanism is used for informing behaviors on a stack, and controllability is not high. According to the method, a stack monitoring mode based on event driving is constructed, the corresponding callback function can be automatically triggered when the stack changes, the events on the stack can be responded and processed in time, and the flexibility and controllability of stack monitoring are improved.

Description

Technical Field

[0001] The invention belongs to the field of computer technology, and in particular relates to a library operating system system level event detection and control method. Background Art

[0002] As a lightweight, task-focused library operating system, Unikernel has attracted increasing attention in cloud computing and embedded scenarios in recent years. Its core idea is to integrate applications with the operating system kernel to achieve professional customization of applications to provide excellent performance and minimal resource consumption. However, the customized characteristics of Unikernel make it face a series of challenges related to bug fixing, function enhancement, and environmental adaptation. To adapt to dynamic needs, Unikernel needs to support a series of functions, such as hot patching and code replacement, to allow instant bug fixing and function enhancement. At the same time, in order 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.

[0003] In the schemes of microkernel, macrokernel and other architecture operating systems, the strategy of re-opening a new process for inspection is basically adopted. Specifically, for the security point inspection of dynamic updates, a method of using new process polling to monitor the function calls on the process stack that need to be paid attention to is adopted. In this process, the system will periodically check whether there are unsafe situations on the stack. If unsafe events are found, the update operation will be temporarily suspended and the inspection will be carried out again after a certain period of time. This cycle will continue until there are no more unsafe events, and then the system will start to perform dynamic update operations. However, due to the unique characteristics of Unikernel as a single process, traditional operating system-level event monitoring and function call monitoring technologies are difficult to apply directly. In a single-core system, the existing monitoring method will consume a lot of CPU resources, which is unbearable in the context of Unikernel. Such resource occupation will seriously affect the execution efficiency of the main program. Therefore, it is necessary to explore new methods and technologies 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 of excessive CPU resource occupation in existing event monitoring, the present invention proposes a system-level event detection and control method for a library operating system.

[0005] The present invention comprises the following steps: Step 1: The interrupt handler stops the original program execution, saves the process stack, and starts the event checker; Step 2: The event checker will obtain the memory space of the process stack from the interrupt stack, and then traverse the process stack frame to record the program call flow graph in the library operating system before the interrupt 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 continues to execute; Step 6: After executing the fixed function, the function trigger is automatically triggered to call the pre-set control function; Step 7: After the control function is executed, jump back to the source program; the program starts to execute normally.

[0006] Compared with the prior art, the present invention has the following beneficial effects: (1) As a single-core operating system, the traditional monitoring method of Unikernel requires the use of one thread, which will cause the monitoring thread and the main thread to compete for resources, greatly affecting the execution of the main program. The present invention is a threadless monitoring method that can collect and analyze the running status of Unikernel in real time without interfering with the main thread, thereby improving the efficiency and accuracy of monitoring.

[0007] (2) The existing stack monitoring method is not flexible enough. If there is an important event on the stack, it must be polled continuously to know its situation. There is no automatic triggering mechanism to notify the behavior on the stack, 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 a change occurs on the stack, realize timely response and processing of events on the stack, and improve the flexibility and controllability of stack monitoring.

[0008] (3) Traditional monitoring and control are often difficult to combine effectively. The present invention can realize the integration of monitoring and control. When the Unikernel is detected to be abnormal or demand changes, the corresponding control strategy can be automatically executed to achieve adaptive adjustment and optimization of the Unikernel, thereby improving the stability and adaptability of the Unikernel.

[0009] (4) Traditional monitoring and control methods may invade the execution flow of the unikernel program and affect the normal operation of the program. The present invention proposes a non-intrusive monitoring and control technology that can monitor and control the execution flow of the unikernel program without modifying the source code or binary code of the unikernel program, thereby realizing transparent management of the unikernel program and improving the reliability and maintainability of the unikernel program.

[0010] (5) The Unikernel system is a lightweight, dynamically loaded system. The present invention is a technology that can dynamically detect and process events as the program runs to adapt to changes in demand in different scenarios. The technology of dynamic plugging can be realized by constructing functional triggers. It can dynamically insert and delete monitoring and control codes at key points of the Unikernel program without affecting the performance of the Unikernel program, realize dynamic monitoring and control of the Unikernel program, and improve the flexibility and adaptability of the Unikernel program. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 The figure is a flow chart of the method of the present invention. DETAILED DESCRIPTION

[0012] In order to make the purpose, technical scheme and advantages of the present invention clearer, the specific embodiments of the present invention are described in detail below in conjunction with the accompanying drawings. Examples of these preferred embodiments are illustrated in the accompanying drawings. The embodiments of the present invention shown in the accompanying drawings and described according to the accompanying drawings are merely exemplary, and the present invention is not limited to these embodiments.

[0013] It should also be noted that, in order to avoid obscuring the present invention due to unnecessary details, only structures and / or processing steps closely related to the solutions according to the present invention are shown in the accompanying drawings, while other details that are not closely related to the present invention are omitted.

[0014] The present invention is further described below in conjunction with the accompanying drawings and specific examples. It should be understood that these embodiments are only used to illustrate the present invention and are not intended to limit the scope of the present invention. The operating methods in the following examples where specific conditions are not specified are usually performed under conventional conditions or under conditions recommended by the manufacturer. The present invention is further described below in conjunction with the accompanying drawings and specific examples. It should be understood that these embodiments are only used to illustrate the present invention and are not intended to limit the scope of the present invention. The operating methods in the following examples where specific conditions are not specified are usually performed under conventional conditions or under conditions recommended by the manufacturer.

[0015] This application proposes a Unikernel library operating system system level event detection and control technology method to solve the deficiencies of the prior art. The method mainly includes three parts: event checker, address locator and function trigger.

[0016] Among them: the address locator is used to locate the function call address of the Unikernel program, the event checker is used to monitor and intercept unsafe or special function events, and the function trigger is used to automatically execute the corresponding function operation.

[0017] Furthermore, the event checker is the core part. It pauses the running 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, and if an event that needs to be processed is found, the function trigger is deployed to the call location of the event and waits for automatic triggering. The event checker can use stack management to achieve transparent asynchronous function triggering in a single-threaded environment through function triggers. If no event that needs to be processed is found, the event checker resumes the running of the Unikernel program until all function events are detected.

[0018] The specific steps of the embodiment of this application are as follows Figure 1 As shown, the details are as follows: Step 1: The interrupt handler stops the original program execution, saves the process stack, and starts the event checker.

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

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

[0021] Furthermore, when a user's monitoring request arrives, the hypervisor first identifies the nature of the request and calls the event check interrupt handler according to the preset rules and procedures. The original normal execution of the Unikernel program will be stopped, and all relevant registers will be stored on the stack. The event check interrupt handler will be executed in the interrupt stack. At this time, the event checker is started and enters its specified operation mode, ready to perform a series of predetermined monitoring and control tasks. The start of the event checker is registered in the Unikernel software interrupt handler as the event check interrupt handler.

[0022] Furthermore, when the event checker is started, it immediately executes the local_irq_disable command to disable all other software interrupts to maintain the stack environment of the current program undisturbed. Preventing other interrupt sources from damaging the current program stack environment, the event checker can work in a controlled environment, ensuring that it can accurately record and analyze events.

[0023] Step 2: The event inspector obtains the memory space of the process stack from the interrupt stack, then traverses the process stack frame and records the program call flow graph in the Unikernel before the interrupt occurs.

[0024] After the event checker is started, it will start checking the stack, because the information of the program being executed by the unikernel before the interrupt is stored in the stack. The stack check is performed in the event check interrupt handler, and the interrupt stack is scanned at this time.

[0025] In one example, under the X86 instruction set, the event checker first obtains the value of the RBP register of the current CPU, which carries the base address of the current function, and can accurately locate the starting position of the current interrupt stack frame through it. 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, the previous stack frame can be scanned according to this 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 spatial positioning of the entire interrupt stack. That is, by traversing all the stack frames on the interrupt stack, access and move the stack frame operations in advance until the bottom of the stack is reached. At the bottom of the interrupt stack, this is the first stack frame of the interrupt stack, and it is also the location of the interrupt handler when the interrupt is started. The context of the process stack is saved here when the event check interrupt is executed, that is, the RBP, RSP and other registers on the process stack. The memory space of the process stack can be found through this.

[0026] The event checker then starts checking the process stack. The process stack is checked in the same stack frame traversal method as the interrupt stack, but the event checker extracts key information by accessing the current stack frame, including 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 frame, the calling process of the Unikernel program before the interrupt occurs can be obtained, and each stack frame base address is recorded and then moved forward by eight bytes of memory (the return address of the current stack frame), thereby constructing a Unikernel program call flow graph.

[0027] Furthermore, during the traversal, the event checker also checks whether each stack frame conforms to the expected format and content, and whether there are signs of stack overflow or corruption. If any anomalies or errors are found, the event checker will immediately report and terminate the stack inspection.

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

[0029] For the location of the function, this embodiment mainly determines 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 the return address stored in each stack frame on the process stack.

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

[0031] The program call flow chart records the detailed information of each stack frame in the process stack. The address locator will identify the function library corresponding to each stack frame and determine 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 based on the return address of each function. If function A calls function B, the return address at the stack frame where function B is located points to the next instruction after function A executes function B. Subsequently, the address locator matches the return address with the micro-library symbol address table it maintains, thereby determining the information of the current function, that is, clarifying which function function function function A specifically belongs to. Since the function corresponding to the top stack frame of the process stack has no return address to determine. At this time, the address locator will obtain the function instruction address of the function being executed by the function through the RIP register saved at the bottom of the interrupt stack.

[0032] Furthermore, in order to distinguish the specific type of each program in the program call flow graph, the present application constructs a micro-library symbol address table when the Unikernel is compiled and linked. The address locator will locate and record the relative address range and offset of each library function instruction when linking and merging the .text segment compiled according to each library through the link script. Specifically: First, based on the default link script, the address locator defines local symbols representing the start and end addresses of the code segment through the PROVIDE_HIDDEN instruction before and after .text. Then, a structure variable containing the symbols of the library name, the start address and the end address of the library code segment is defined in the source file, and it is assigned to the .uk_libaddr segment. This application compiles the source file with each library to generate the .o file corresponding to each library, and contains the .uk_libaddr segment that stores the library name and the start and end addresses of the code segment. When linked into the final uk image, the .uk_libaddr segments in all library files are used as input to generate a separate .uk_libaddr segment, which is the micro-library symbol address table of the address locator, which contains the offset address and range information of each function library in memory after the program is loaded, which is convenient for subsequent event checkers to query function events.

[0033] The address locator identifies the function library where each stack frame function of the process stack is located based on the instruction address and the microlibrary symbol address table. If the function is an unsafe event or the user needs to control the event, the event checker can put the event into a special event set. The special event set refers to the collection of special events that are being executed before the interruption. Special events will match different requirements in different scenarios. For example, during a security check, a special event can be an unsafe event. The event checker will check each function in turn based on the program call flow graph until all events are checked.

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

[0035] The special event set is empty, which means that the function execution flow before the interruption is safe. At this time, the pre-set control function will be directly executed in the event check interrupt processing function. The implementation of the control function is similar to a callback function, which is set by the developer in advance and exists as a function library. It is added to the Unikernel image after the Unikernel is compiled and linked.

[0036] When the control function is executed, the interrupt processing program is terminated directly and the execution of the normal program is resumed.

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

[0038] If the special event set is not empty, the event checker will search for special root events in the special event set and deploy function triggers. Function triggers can automatically execute pre-set control function operations according to the type of special root events after the special root events are executed, such as logging, sending notifications, calling other functions, etc., without intrusive modification to the original program.

[0039] Furthermore, the deployment of function triggers needs to meet a prerequisite, that is, the special event set must contain at least one special event. 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 the 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.

[0040] In order 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 is executed, it jumps to its caller according to the return address by default through the ret instruction. The event checker processes this return address in advance and saves it to the function trigger. Then the event checker points the address to the location of the function trigger to complete the deployment of the function trigger.

[0041] Step 6: After the function trigger is deployed, the interrupt handler ends and the source program continues to execute.

[0042] When the function trigger is successfully deployed, the execution of the interrupt handler ends. At this time, the Unikernel continues to execute the program before the interrupt, that is, executes the program function along the process stack call sequence.

[0043] Step 7: After executing the fixed function, the function trigger is automatically triggered to call the pre-set control function function.

[0044] 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, the IP instruction register now points to the instruction of the function trigger, and the function trigger begins to trigger the set function. In this process, the CPU will jump to the specified code segment according to the return address, and then execute the instructions in the code segment.

[0045] Since the function trigger changes the execution logic of the function call on the original stack, in order to avoid damaging the program execution flow and protect 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. Under 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 for storage.

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

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

[0048] After completing the set control function, the function trigger will pop the previously saved registers to restore the context of the original program, and simulate the ret instruction after the function call on the stack is completed, and jump back to the next instruction of the Unikernel source program through the jmp instruction, and the program will start to execute normally. In this way, the current process and CPU can be used to complete the external special function trigger without the original program flow being aware of it, and it will not affect the execution of the original stack operation.

[0049] In addition, it should be noted that in this specification, "includes", "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprising a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

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

Claims

1. A library operating system system level event detection and control method, characterized in that The method comprises the following steps: Step 1: The interrupt handler stops the original program execution, saves the process stack, and starts the event checker; Step 2: The event checker will obtain the memory space of the process stack from the interrupt stack, and then traverse the process stack frame to record the program call flow graph in the library operating system before the interrupt 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 continues to execute; Step 6: After executing the fixed function, the function trigger is automatically triggered to call the pre-set control function; Step 7: After the control function is executed, jump back to the source program; the program starts to execute normally.

2. A library operating system system level event detection and control method according to claim 1, characterized in that: The event checker described in step 1 is started by registering a start command in the interrupt handler.

3. A library operating system system level event detection and control method 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, which carries the base address of the current function, and uses it to accurately locate the starting position of the current interrupt stack frame; Then, the base address of the previous stack frame is obtained by accessing the memory at the starting position of the current stack frame; Then scan the previous stack frame 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 scans and spatially locates the entire interrupt stack.

4. A library operating system system level event detection and control method according to claim 3, characterized in that: The calling process of the program in the library operating system before the interrupt occurs is obtained by continuously traversing the stack frame, and each stack frame base address is recorded and then moved forward eight bytes of memory, so as to construct the program calling flow graph.

5. A library operating system system level event detection and control method according to claim 1, characterized in that: The program call flow chart records the detailed information of each stack frame in the process stack. The address locator will identify the function library where the functions corresponding to each stack frame are located, and the event checker will obtain the memory address of the instruction that the function caller needs to execute next based on the return address of each function.

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

7. A library operating system system level event detection and control method according to claim 1, characterized in that: The function trigger in step 6 saves the register value that may be affected by the function trigger by pushing it onto a stack.

Images