A Method for Dynamic Update of Library Operating System Based on Static Link

Abstract

The present invention discloses a method for dynamically updating a library operating system based on static linking. First, the present invention extends the QEMU interface, and the execution of the dynamic update operation is triggered through a virtual interrupt trigger interface; secondly, the compilation and linking are enhanced and the LibOS image is started to implement compiling the symbol table of the image into the data segment for the running LibOS to obtain; a new version of the micro-library in relocatable object file format is compiled; then, a virtual interrupt is injected into the running LibOS; the micro-library is loaded, parsed and processed based on static linking; finally, the new version of the micro-library is initialized. The present invention realizes micro-library-level dynamic update during the operation of the library operating system, triggers the update operation by means of virtual interrupt injection, and minimizes the overhead of dynamic update; the design that the micro-library can be loaded into any available memory segment makes the dynamic update more flexible; the micro-library loaded into memory is statically linked with the kernel to maintain the high runtime performance of the library operating system.

Description

Technical Field

[0001] The present invention belongs to the technical field of computers, and particularly relates to a method for dynamically updating a library operating system based on static linking. Background Art

[0002] With the rapid development and wide application of cloud computing, a large number of cloud services only provide specific services, and these specific single-purpose services only need support from a few operating system function modules to run. The "big and complete" general operating system design of traditional virtual machines has problems such as large resource overhead, slow startup speed, and large attack surface when applied to such services.

[0003] A library operating system (LibOS) is an operating system with a new architecture. It only retains the necessary system libraries required to run specific applications, reducing its own size and the attack surface of the system. At the same time, LibOS has the characteristic of a single address space and provides system calls to upper-layer application programs in the form of function calls, thus avoiding the high overhead associated with system calls. The advantages of LibOS being small, fast, and secure make it an important part of today's virtualization technology and show great potential in cloud computing scenarios.

[0004] The library operating system image is compiled and linked from micro-libraries that provide different functions. In a production environment, the micro-libraries used to build the library operating system image need to be version-changed, which may be version iteration, security updates, and runtime optimization, etc. Some library operating systems also need to scale functions by adding or removing micro-libraries. Therefore, the library operating system needs to perform dynamic updates at the micro-library level to ensure meeting the latest functional, security, and performance requirements.

[0005] Due to the static design of the library operating system, any modification to the kernel micro-library requires recompiling the image and restarting. This process not only requires manual operation but also results in costly service downtime. Therefore, how to perform dynamic updates while the library operating system is running has become a problem to be solved.

[0006] The existing dynamic update implementation scheme for library operating systems is based on dynamic linking. This scheme compiles the new version of the micro-library into a shared object file that can be dynamically linked and maps it to a virtual address in the dynamic segment at runtime. When loading, the libraries on which the micro-library depends are loaded as new libraries in the order of dependencies, and all unresolved symbols in the micro-library are relocated to the correct addresses in the newly mapped libraries. However, the runtime performance of this scheme is not good, and it only applies to a small part of update scenarios and does not support updating micro-libraries that depend on the library operating system image itself. Summary of the Invention

[0007] Currently, when the library operating system needs to be updated and its functions scaled during runtime, the running system can only be stopped and a new image recompiled and redeployed. However, halting the system and recompiling and redeploying the image will result in huge losses. Therefore, how to perform dynamic updates on the library operating system during runtime has become a technical problem that urgently needs to be solved. As the foundation for applications to run, the library operating system needs to maintain high performance, and maintaining high performance before and after the update of the library operating system is another problem to be solved. New version code often depends on the interfaces provided in the library operating system image, and how to resolve the dependency of the new version code on the interfaces in the image to ensure normal service provision after the update is also a problem that needs to be solved.

[0008] To solve the above technical problems, the technical solution adopted in the present invention is as follows:

[0009] A method for dynamically updating a library operating system based on static linking includes the following steps:

[0010] Step 1: Expand the QEMU interface, and the execution of dynamic update operations triggers the interface through virtual interrupts;

[0011] Step 2: Enhance compilation, linking, and start the LibOS image, and compile the symbol table of the image into the data segment for the running LibOS to obtain;

[0012] Step 3: Compile and generate a new version of the micro-library in relocatable object file format;

[0013] Step 4: Inject virtual interrupts into the running LibOS;

[0014] Step 5: Load, parse, and process the micro-library based on static linking;

[0015] Step 6: Initialize the new version of the micro-library.

[0016] Compared with the prior art, the beneficial effects of the present invention are as follows: The present invention realizes micro-library-level dynamic updates during the runtime of the library operating system, triggers update operations through the injection of virtual interrupts, and minimizes the overhead of dynamic updates; the design that the micro-library can be loaded into any available memory segment makes dynamic updates more flexible; the micro-library loaded into memory is statically linked with the kernel to maintain the high runtime performance of the library operating system. This method has strong compatibility, high flexibility, high availability, and maintains high performance. Description of the Drawings

[0017] Figure 1 It is a flowchart of the method of the present invention;

[0018] Figure 2 It is a flowchart of enhanced compilation and linking;

[0019] Figure 3Flow chart for the resolution and processing of static links. Detailed implementation manners

[0020] To make the objectives, technical solutions and advantages of the present invention clearer, the following will describe in detail the specific implementation manners of the present invention with reference to the accompanying drawings. Examples of these preferred implementation manners are illustrated in the accompanying drawings. The implementation manners 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 implementation manners.

[0021] Here, it should also be noted that in order to avoid obscuring the present invention due to 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] Updating the micro-library in the way of dynamic link makes the runtime performance of the library operating system lower than directly statically linking into the image; both the micro-library itself and other dependent libraries must be shared object files, but currently the compiled format of the micro-library is relocatable object files, and the existing micro-library cannot be directly applied to the existing solution; most of the new versions of the micro-library rely on the interfaces provided by the micro-library that has been compiled into the image, and the existing solution fails to solve this dependency relationship, resulting in that most of the updated library operating systems cannot provide services normally; the design of mapping the micro-library to a pre-set dynamic segment leads to the limitation that only micro-libraries of limited size and limited quantity can be dynamically updated.

[0023] Accordingly, the embodiments of the present application provide a method for dynamically updating a library operating system based on static link, as Figure 1 , which specifically includes:

[0024] Step 1: Extend the QEMU interface

[0025] The execution of the dynamic update operation is triggered by a virtual interrupt. For this purpose, it is necessary to first extend the interrupt trigger interface for QEMU. The process includes:

[0026] (1) In QEMU, the GSIState structure is used to record all interrupts of the guest OS. When creating or initializing the structure variable, a global variable pointer is used to record the structure variable for subsequent obtaining of the structure of a specific interrupt.

[0027] (2) Create the trigger_irq function. In this function, obtain the interrupt structure with the corresponding interrupt number from the GSIState structure variable, and then use this structure variable as a parameter to call qemu_irq_pulse. In this function, it will simulate the hardware to first pull the high level and then the low level to complete a virtual interrupt injection.

[0028] (3) Write the trigger_irq function and the corresponding trigger command irq_trigger into the configuration file of the QEMU Monitor command, and recompile to complete the interface extension.

[0029] Step 2: Enhance compilation, linking, and start the LibOS image

[0030] In subsequent symbol resolution operations, the running LibOS needs to obtain the symbol information of the image itself, while the native LibOS does not have this ability. By enhancing the compilation process, the symbol table of the image can be compiled into the data segment for the running LibOS to obtain. The enhanced compilation and linking process is as Figure 2 shown, specifically:

[0031] step 1: Link together the relocatable ELF files of all libraries to generate the uk debug image and the uk image. This step is the default linking process of LibOS;

[0032] step 2: Strip the symbol table from the uk debug image, parse the symbol table, and generate symbols.S. In symbols.S, all symbol names and symbol values are declared as global variables and compiled in the.rodata segment to generate symbols.o;

[0033] step 3: Link symbols.o and the relocatable files of all libraries together to generate the uk temp debug image. At this time, the symbol values stored in the global variables are partially inconsistent with the actual symbol values in the uk temp debug image because after the segment in symbols.o is inserted, the symbol addresses behind the insertion point will shift. Therefore, step 2 needs to be executed again to strip the symbol table of uk temp debug and compile to generate symbols2.o to correct the symbol addresses;

[0034] step 4: Compile symbols2.o and the relocatable files of all libraries together to generate the final uk image.

[0035] The default linking process only goes to step 1. After enhancing the compilation and linking, the linking process will go from step 1 to step 4, realizing the compilation of the uk symbol table information into the.rodata segment of the uk image and providing an interface for fast symbol query.

[0036] After the compilation and linking are completed, use QEMU to start the LibOS image, and start the QEMU Monitor and create a socket connecting to the QEMU Monitor.

[0037] Step 3: Compile to generate a new version of the micro-library in relocatable object file format

[0038] For a micro-library in source code form, it needs to be compiled into a micro-library in relocatable object file format first. The files of this format are binary files that can be directly executed after being loaded into memory. The files contain symbol tables, string tables, and multiple relocation segments, which can be used for subsequent parsing, loading, and static linking operations. After compilation, in order to make the micro-library itself more concise, the strip command can be used to remove some segments, such as the debug segment, etc.

[0039] Step 4: Inject virtual interrupts into the running LibOS

[0040] You can simply enter the QEMU Monitor by connecting to a socket and use the extended interface irq_trigger to inject virtual interrupts into the running LibOS to trigger dynamic update operations.

[0041] Step 5: Load, parse, and process the micro-library based on static linking

[0042] The relocatable object file format library read into memory consists of a code segment, a data segment, a read-only data segment, a.bss segment, relocation segments, etc. These segments have different memory permissions, and some segments need to be processed before they can be put into use. For example, the code segment and the data segment often need to be relocated to execute or access normally, and the.bss segment does not occupy memory space in the entire file, but space needs to be allocated for it during actual operation. In order to enable the library in memory to provide services normally and efficiently, a series of parsing and processing need to be performed on it based on static linking. The specific process is as Figure 3 , including the following operations:

[0043] Use libelf to parse the micro-library: For the library file loaded into memory, use libelf to parse it to facilitate obtaining file information and file content.

[0044] Change the module memory layout and set memory permissions: Library files in ELF format often contain a code segment, a data segment, a read-only data segment, etc. The memory permissions of these segments are different. By merging segments with the same permissions and uniformly applying for memory and setting the corresponding permissions, memory can be effectively saved and memory fragmentation can be reduced.

[0045] Symbol resolution: The symbol values in the symbol table of the library file are all invalid values and need to be modified to the virtual address of the symbol in memory. According to the different files where the symbol definitions are located, symbols can be divided into two types: symbols defined in this library and external symbols. For symbols defined in the library, calculate the symbol value according to the segment base address and offset of the segment where the symbol is located; for external symbols referenced by the library, obtain the uk symbol value through the interface provided during enhanced compilation and linking.

[0046] Note that for the same symbols in the new library and the old library, state migration is required, including variable migration and function redirection. When parsing symbols, resolve the variables in the new library to the addresses of the same variables in the old library to achieve data migration, modify the first instruction of the function in the old library and redirect it to the function in the new library to achieve function redirection.

[0047] Relocation: The compiled library file references external symbols by using the absolute addresses of the symbols. When the source code of the library is compiled into an ELF file, it does not know the addresses of the external symbols and uses default values such as 0 instead. It is necessary to correct the addresses of each reference to an external symbol in the library file instructions. This process is called relocation. In a relocatable ELF-format library file, there are zero or more segments starting with.rel, called relocation tables. The relocation tables record relocation information, including the location of the instruction that needs to be modified and which part of the instruction needs to be modified. For each code segment and data segment that needs to be relocated, there will be a corresponding relocation table. By traversing each relocation table, for each relocation table entry in the table, calculate the memory area that needs to be modified, and combine it with the symbol value to calculate the modified value on the memory area to complete the relocation.

[0048] Step 6: Initialize the new version of the micro-library

[0049] The micro-library file may contain segments related to initialization, including.uk_inittab,.uk_ctortab, etc., and may also contain data segments that need to be initialized, such as.posix_socket_driver. For segments related to initialization functions, execute the initialization functions in the segment; for data segments that require additional operations, according to the different segment names and data types in the segment, perform personalized initialization operations. Taking.posix_socket_driver as an example, during initialization, the data structure variables stored in this segment are initially registered with the socket driver manager.

[0050] Optional Step 7: Uninstall the old version of the micro-library

[0051] The old version of the micro-library can be uninstalled, which specifically includes operations such as reclaiming memory resources and releasing the micro-library structure.

[0052] After the above steps, the library operating system has the ability to dynamically update and completes the dynamic update operation at the micro-library level. At the same time, it also ensures high performance before and after the update, solves the dependency relationship of the new version of the micro-library on the interfaces in the image, so that the service can be provided normally after the update.

[0053] In summary, the present invention realizes the dynamic update of the library operating system at the micro-library level based on static linking, maintaining high performance before and after the update; for existing micro-libraries compiled into relocatable object file formats, they can be directly updated on the running library operating system without any modification and adaptation, improving the compatibility of dynamic updates; for micro-libraries that rely on the interfaces provided in the image, the dependency relationship with the image is correctly and efficiently processed during dynamic updates to ensure that services can be provided normally after the update, ensuring the high availability of the dynamic update technology; under the limitation of the available memory resources, an unlimited number and size of micro-libraries can be updated, improving the flexibility of dynamic updates.

[0054] In addition, it should be noted that in this specification, "including", "comprising" or any other variation thereof is 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.

[0055] It should be understood that although this specification is described according to 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 understandable to those skilled in the art.

Claims

1. A method for dynamically updating a library operating system based on static linking, characterized in that The method comprises the following steps: Step 1: Extending the QEMU interface, the execution of the dynamic update operation triggers the interface through a virtual interrupt; Step 2: Enhance the compilation link and start the LibOS image to compile the image's symbol table into the data segment for the running LibOS to obtain; Step 3: Compile and generate a new version of the micro library in the relocatable target file format; Step 4: Inject virtual interrupts into the running LibOS; Step 5: Load, parse and process the microlibrary based on static linking; Step 6: Initialize the new version of the micro library; Step 1 is as follows: (1) When the GSIState structure variable is created or initialized, the global variable pointer is used to record the structure variable for subsequent acquisition of the structure of the specific interrupt; (2) Create the trigger_irq function. In this function, get the interrupt structure of the corresponding interrupt number from the GSIState structure variable, and use the structure variable as a parameter to call qemu_irq_pulse to complete a virtual interrupt injection; (3) Write the trigger_irq function and the corresponding trigger command irq_trigger into the configuration file of the QEMU Monitor command and recompile to complete the interface expansion; Step 2 is specifically: Step 1: Link all the relocatable ELF files of the library together to generate uk debug image and uk image; Step 2: Strip the symbol table from the uk debug image, parse the symbol table and generate symbols.S. In symbols.S, all symbol names and symbol values ​​are declared as global variables and compiled in the .rodata segment to generate symbols.o. Step 3: Link symbols.o and all library relocatable files together to generate uk temp debug image; Step 4: Compile symbols2.o and all library relocatable files together to generate the final uk image; By default, the linking process only goes to step 1. After enhanced compilation and linking, the linking process will go from step 1 to step 4, compiling the uk symbol table information into the .rodata segment of the uk image and providing an interface for fast symbol query; After the compilation and linking is complete, use QEMU to start the LibOS image, open the QEMU Monitor, and create a socket connected to the QEMUMonitor; Step 4 is as follows: Enter QEMU Monitor by connecting to the socket, and use the extended interface irq_trigger to inject virtual interrupts into the running LibOS to trigger the dynamic update operation.

2. The method for dynamically updating a library operating system based on static linking according to claim 1, characterized in that: The symbol value stored in the global variable in step 3 is inconsistent with the actual symbol value in the uk temp debug image. Execute step 2 again, strip the symbol table of uk temp debug, and compile to generate symbols2.o to correct the symbol address.

3. The method for dynamically updating a library operating system based on static linking according to claim 1, characterized in that: After step 3, use the strip command to remove the debug segment.

4. The method for dynamically updating a library operating system based on static linking according to claim 1, characterized in that: Step 5 is as follows: Use libelf to parse micro libraries: Use libelf to parse the library files loaded into memory; Change the module memory layout and set memory permissions: merge segments with the same permissions, apply for memory uniformly, and set corresponding permissions; Symbol resolution: Modify the virtual address of the symbol in the memory. Depending on the file where the symbol definition is located, the symbols are divided into two types: symbols defined in this library and external symbols; For symbols defined in this library, the symbol value is calculated based on the segment base address and offset of the segment where the symbol is located; For external symbols, the uk symbol value is obtained through the interface provided during enhanced compilation and linking; Relocation: For each code segment and data segment that needs to be relocated, each relocation table is traversed, and for each relocation table entry in the table, the memory area that needs to be modified is calculated, and the modified value in the memory area is calculated in combination with the symbol value to complete the relocation.

5. The method for dynamically updating a library operating system based on static linking according to claim 4, characterized in that: The relocation refers to the address correction of each reference to an external symbol in the library file instruction; the relocation table refers to 0 or more segments starting with .rel in the relocatable ELF format library file; the relocation table records the relocation information, including the location of the instruction to be modified and which part of the instruction needs to be modified.

6. A method for dynamically updating a library operating system based on static linking according to any one of claims 1 to 5, characterized in that: Also includes step 7: Uninstall the old version of the micro library.

Images