Method and device for migrating Linux executable program

Abstract

The invention relates to the technical field of software migration, in particular to a Linux executable program migration method and device.The method comprises the steps that compatibility detection is conducted on system calling of a target ELF file, and gasket adaptation processing is conducted on incompatible system calling; performing dependency tree total analysis on the target ELF file, and identifying a dependency library required by the operation of the target ELF file; extracting an actual calling symbol list of each dependency library, comparing the actual calling symbol list with symbols of corresponding libraries on the target system, and collecting incompatible dependency libraries of the original system to an isolation directory; modifying a library search path when the target ELF file runs, so as to preferentially load an original system dependency library in the isolation directory; and finally, constructing a migration packet deployed to the target system, and carrying out adaptive migration verification on the migration packet. Compatibility and operation stability of the program in the target system are improved, only the software and the dependency library thereof are migrated, migration difficulty is reduced, and the migration process is accelerated.

Description

Technical Field

[0001] The present invention relates to the technical field of software migration, and particularly to a method and device for migrating Linux executable programs. Background Art

[0002] In the Linux system, software migration faces many challenges. Executable files under the Linux system are mostly in ELF format, and their operation depends on the binary interface (ABI) provided by the system, including kernel version, dynamic libraries, hardware instruction sets, etc.

[0003] When migrating across systems, program crashes are often caused by ABI incompatibility, such as glibc symbol version conflicts, kernel system call changes, etc. At the same time, the program may not be able to run due to the lack of low-version shared libraries in the target system, or become invalid due to hard-coded paths not conforming to the file standards of the target system. In addition, legacy closed-source software cannot be recompiled to adapt to the new system due to the lack of source code or compilation toolchain support, seriously hindering the cross-platform migration and deployment efficiency of software.

[0004] Therefore, there is an urgent need for a new migration method that can achieve cross-system compatibility support and efficiently and reliably migrate Linux executable programs without source code and the compilation environment of the target system. Summary of the Invention

[0005] In view of this, the present invention provides a method and device for migrating Linux executable programs to solve the defects of complex migration operations and the inability to effectively solve dependency problems in the prior art when migrating Linux executable programs.

[0006] In a first aspect, the present invention provides a method for migrating a Linux executable program, the method comprising: Obtain a target ELF file to be migrated, perform compatibility detection on the system calls used by the target ELF file and the target system, and perform shim adaptation processing on the incompatible system calls; Perform a full-scale analysis of the dependency tree on the target ELF file after passing the compatibility detection or shim adaptation processing, and identify the dependent libraries required for the operation of the target ELF file; Extract the actual call symbol list of each dependent library, compare it with the symbols of the corresponding library on the target system, and collect the original system dependent libraries that are incompatible with the target system into an isolation directory; Modify the library search path and dynamic linker when the target ELF file runs to preferentially load the original system dependent libraries in the isolation directory and replace the dynamic linker that is incompatible with the original system; Construct a migration package to be deployed to the target system and perform adaptive migration verification on the migration package; the migration package includes the target ELF file, the original system dependencies in the isolated directory, the user-mode ABI shim, and the path hijacking script.

[0007] In an alternative embodiment, the compatibility detection of the system calls used by the target ELF file with the target system and the shim adaptation processing for incompatible system calls include: Detect whether there are system calls in the target ELF file. If there are system calls, evaluate the compatibility of the system calls with the target system; For incompatible system calls, perform adaptation processing through the user-mode ABI shim. If the adaptation processing cannot be performed, terminate the migration process of the target ELF file.

[0008] In an alternative embodiment, the full-scale analysis of the dependency tree for the target ELF file after compatibility detection or shim adaptation processing to identify the dependencies required for the target ELF file to run includes: Parse the dynamic segment and symbol table of the target ELF file after compatibility detection or shim adaptation processing to recursively traverse each explicit dependency library of the target ELF file; Extract the hard-coded paths of the implicit dependency libraries through static analysis to generate a list of implicit dependency libraries; Based on each explicit dependency library and the list of implicit dependency libraries, construct a complete dependency tree.

[0009] In an alternative embodiment, the extraction of the hard-coded paths of the implicit dependency libraries through static analysis to generate a list of implicit dependency libraries includes: Detect whether there is a target dynamic loading function call in the target ELF file; If there is the target dynamic loading function call, extract the hard-coded paths called in the target dynamic loading function through static analysis; Generate a list of implicit dependency libraries based on the implicit dependency libraries corresponding to the hard-coded paths.

[0010] In an alternative embodiment, the extraction of the actual call symbol list for each dependency library and the comparison with the symbols of the corresponding library on the target system, and the collection of the original system dependencies that are incompatible with the target system into the isolated directory include: Extract the actual call symbol lists of the explicit dependency libraries and the implicit dependency libraries; Compare the actual call symbol lists with the symbols of the corresponding libraries on the target system one by one; If the symbols match, mark the corresponding dependency library as a compatible library; If the symbols do not match or are missing, mark the corresponding dependent library as an incompatible library; Collect the original system dependent libraries corresponding to the incompatible libraries into an isolation directory, and inject path hijacking logic into the implicit dependent libraries in the isolation directory.

[0011] In an optional implementation manner, modifying the library search path and dynamic linker when the target ELF file runs to preferentially load the original system dependent libraries in the isolation directory and replace the dynamic linker incompatible with the original system includes: Modify the library search path when the target ELF file runs to point to the isolation directory to preferentially load the original system dependent libraries in the isolation directory; Verify whether the dynamic linker of the target system is compatible with the dynamic linker of the original system; If they are not compatible, copy the dynamic linker of the original system to the migration package and modify the dynamic linker specified path of the target ELF file.

[0012] In an optional implementation manner, the adaptive migration verification of the migration package includes: Conduct a migration function test on the migration package. If a migration operation exception occurs, perform problem location and analysis through reverse tracing; According to the location and analysis results, supplement the missing libraries to the isolation directory and perform cyclic testing until all dependencies are completely matched.

[0013] In a second aspect, the present invention provides a migration device for Linux executable programs, and the device includes: A system call compatibility detection module, configured to obtain a target ELF file to be migrated, detect the compatibility between the system calls used by the target ELF file and the target system, and perform shim adaptation processing on the incompatible system calls; A dependency tree full-scale analysis module, configured to perform a full-scale analysis of the dependency tree on the target ELF file after compatibility detection or shim adaptation processing to identify the dependent libraries required for the target ELF file to run; A symbol-level compatibility verification module, configured to extract the actual call symbol list of each dependent library, compare it with the symbols of the corresponding library on the target system, and collect the original system dependent libraries incompatible with the target system into an isolation directory; A runtime path reconstruction module, configured to modify the library search path and dynamic linker when the target ELF file runs to preferentially load the original system dependent libraries in the isolation directory and replace the dynamic linker incompatible with the original system; An adaptive migration verification module is used to build a migration package deployed to the target system and perform adaptive migration verification on the migration package; the migration package includes the target ELF file, the original system dependent libraries in the isolation directory, user-state ABI shims, and path hijacking scripts.

[0014] In a third aspect, the present invention provides a computer device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to execute a migration method of a Linux executable program according to the first aspect or any corresponding implementation manner thereof.

[0015] In a fourth aspect, the present invention provides a computer-readable storage medium, on which computer instructions are stored. The computer instructions are used to cause a computer to execute a migration method of a Linux executable program according to the first aspect or any corresponding implementation manner thereof.

[0016] In a fifth aspect, the present invention provides a computer program product, including computer instructions, which are used to cause a computer to execute a migration method of a Linux executable program according to the first aspect or any corresponding implementation manner thereof.

[0017] The technical solution provided by the present invention may include the following beneficial effects: By performing a full-scale analysis of the dependency tree of the target ELF file, the present invention can comprehensively identify all the dependent libraries required for program operation, including explicit and implicit dependencies, effectively avoiding migration failures caused by missing dependent libraries and solving the dependency problem. At the same time, by extracting the actual call symbol list of the dependent libraries and comparing it with the target system, the problems of symbol mismatch or missing can be accurately identified, and corresponding solutions can be taken accordingly, improving the compatibility and running stability of the program on the target system.

[0018] The present invention performs shim adaptation processing on incompatible system calls to solve problems such as changes in system call interfaces between different system versions, enabling the program to normally execute system calls on the target system, adapting to different system environments, and solving the problem of insufficient support for closed-source software.

[0019] The entire migration method of the present invention covers steps such as system call detection, dependency tree analysis, symbol verification, and runtime path reconstruction, forming a complete automated migration process, reducing manual operations and interventions, and improving migration efficiency and accuracy. The incompatible original system dependent libraries are collected into an isolation directory, and path hijacking logic is injected into the implicit dependent libraries, so that the compatible libraries are preferentially loaded when the program runs, avoiding cumbersome library conflict troubleshooting, accelerating the migration process, and only migrating the software and its dependent libraries without migrating the entire operating system, reducing the migration difficulty and complexity. Description of the Drawings

[0020] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for use in the description of the specific embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0021] Figure 1 is a schematic flowchart of a method for migrating a Linux executable program according to an embodiment of the present invention; Figure 2 is a schematic flowchart of another method for migrating a Linux executable program according to an embodiment of the present invention; Figure 3 is a flowchart of yet another method for migrating a Linux executable program according to an embodiment of the present invention; Figure 4 is a block diagram of the structure of a device for migrating a Linux executable program according to an embodiment of the present invention; Figure 5 is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Specific Embodiments

[0022] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of the present invention.

[0023] According to an embodiment of the present invention, an embodiment of a method for migrating a Linux executable program is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0024] In this embodiment, a method for migrating a Linux executable program is provided. Figure 1 is a flowchart of a method for migrating a Linux executable program according to an embodiment of the present invention. As Figure 1 shown, the process includes the following steps: Step S101: Obtain the target ELF file to be migrated, perform compatibility detection on the system calls used by the target ELF file with the target system, and perform shim adaptation processing on the incompatible system calls.

[0025] Furthermore, in this embodiment, the target ELF file to be migrated is obtained, and compatibility detection of system calls is performed on it, and shim adaptation processing is performed on the incompatible system calls. The purpose of this step is to ensure that the target ELF file can execute system calls normally on the target system. Since there may be problems such as changes in system call interfaces or differences in parameter semantics between different system versions, by detecting the compatibility of the system calls used by the target ELF file with the target system, and using user-mode ABI shims to adapt the incompatible system calls, the problem of system call incompatibility is solved, and the program is prevented from crashing due to system call failures on the target system.

[0026] Step S102: Perform a full analysis of the dependency tree on the target ELF file after passing the compatibility detection or shim adaptation processing to identify the dependency libraries required for the operation of the target ELF file.

[0027] Furthermore, in this embodiment, a full analysis of the dependency tree is performed on the target ELF file after passing the compatibility detection or shim adaptation processing to identify the dependency libraries required for operation. This step aims to comprehensively identify the dependency libraries required for the operation of the target ELF file, including explicit dependency libraries and implicit dependency libraries, to ensure that no key dependencies are missed.

[0028] Step S103: Extract the actual call symbol list of each dependency library, compare it with the symbols of the corresponding library on the target system, and collect the original system dependency libraries that are incompatible with the target system into an isolation directory.

[0029] Furthermore, in this embodiment, the actual call symbol list of each dependency library is extracted, compared with the symbols of the corresponding library on the target system, and the original system dependency libraries that are incompatible are collected into an isolation directory. This step accurately identifies the dependency libraries that are incompatible with the target system by performing a detailed comparison of the symbols of the dependency libraries. Symbols are the names used in the program to identify functions, variables, etc., and different versions of the library may have differences in symbols. By extracting the actual call symbol list in the dependency library and comparing it one by one with the symbols of the corresponding library on the target system, the dependency libraries with symbol mismatches or missing symbols are marked as incompatible libraries and collected into the isolation directory for subsequent unified management and processing.

[0030] Step S104: Modify the library search path and dynamic linker when the target ELF file runs to preferentially load the original system dependency libraries in the isolation directory and replace the dynamic linker that is incompatible with the original system.

[0031] Further, in this embodiment, the library search path and dynamic linker during the runtime of the target ELF file are modified to preferentially load the original system dependent libraries in the isolation directory and replace the dynamic linker that is incompatible with the original system. This step modifies the RPATH field of the target ELF file and its dependent libraries, so that the program preferentially loads the original system dependent libraries from the isolation directory during runtime, avoiding loading incompatible libraries that may exist in the target system. Meanwhile, the dynamic linker is adapted to ensure that the program can correctly perform dynamic linking and loading. If the dynamic linker of the target system is incompatible with the original system, the dynamic linker of the original system is copied to the migration package to ensure that the program can run properly on the target system. The original system is the Linux operating system, and the target system can be any operating system based on the Linux kernel, including different distributions, versions, and hardware architecture environments.

[0032] Step S105: Build a migration package to be deployed to the target system and perform adaptive migration verification on the migration package; the migration package includes the target ELF file, the original system dependent libraries in the isolation directory, the user-mode ABI shim, and the path hijacking script.

[0033] Further, in this embodiment, a migration package to be deployed to the target system is built and adaptive migration verification is performed on the migration package. The migration package includes the target ELF file, the original system dependent libraries in the isolation directory, the user-mode ABI shim, the path hijacking script, etc. This step integrates all necessary components into a migration package to ensure smooth deployment and operation on the target system. By deploying the migration package on the target system and performing functional tests, runtime anomalies are located, and missing dependencies are iteratively supplemented until all functions pass the tests, thereby ensuring the stability and reliability of the program on the target system.

[0034] In summary, through a full-scale analysis of the dependency tree of the target ELF file, this embodiment can comprehensively identify all dependent libraries required for the program to run, including explicit and implicit dependencies, effectively avoiding migration failures caused by missing dependent libraries and solving the dependency problem. Meanwhile, by extracting the actual call symbol list of the dependent libraries and comparing it with the target system, problems of symbol mismatch or missing can be accurately identified, and corresponding solutions can be taken accordingly to improve the compatibility and runtime stability of the program on the target system.

[0035] In this embodiment, shim adaptation processing is performed on incompatible system calls to solve problems such as changes in system call interfaces between different system versions, enabling the program to correctly perform system calls on the target system, adapting to different system environments, and solving the problem of insufficient support for closed-source software.

[0036] The entire migration method of this embodiment covers steps such as system call detection, dependency tree analysis, symbol verification, and runtime path reconstruction, forming a complete automated migration process, reducing manual operations and interventions, and improving migration efficiency and accuracy. The incompatible original system dependency libraries are collected into an isolation directory, and path hijacking logic is injected into the implicit dependency libraries, so that the compatible libraries are preferentially loaded during program runtime, avoiding cumbersome library conflict troubleshooting, accelerating the migration process, and only migrating the software and its dependency libraries without migrating the entire operating system, reducing the migration difficulty and complexity.

[0037] In this embodiment, another migration method for Linux executable programs is provided. Figure 2 It is a flowchart of another migration method for Linux executable programs according to an embodiment of the present invention, as Figure 2 shown, and this process includes the following steps: Step S201: Obtain the target ELF file to be migrated, and perform compatibility detection on the system calls used by the target ELF file with the target system, and perform shim adaptation processing on the incompatible system calls.

[0038] In an optional implementation manner, this step S201 includes: Detect whether there are system calls in the target ELF file. If there are system calls, evaluate the compatibility of the system calls with the target system; For the incompatible system calls, perform adaptation processing through the user-mode ABI shim. If the adaptation processing cannot be performed, terminate the migration process of the target ELF file.

[0039] Furthermore, the purpose of this step is to ensure that the target ELF file can normally execute system calls on the target system. First, it is necessary to detect whether the target ELF file uses system calls. If there are system calls, it is necessary to further evaluate the compatibility of these system calls with the target system. For example, different Linux kernel versions may modify the parameters or behaviors of system calls. For those incompatible system calls, use the user-mode ABI shim to perform adaptation. The shim is a software layer that can convert system calls to match the interface of the target system. If a system call cannot be adapted through the shim, the migration process of the target ELF file will be terminated to avoid potential runtime errors.

[0040] That is to say, please refer to Figure 3The flowchart of another migration method for Linux executable programs is shown. System call compatibility pre - detection is the key starting step of the entire migration process. After obtaining the target ELF file, it is first necessary to verify whether it uses system calls. System calls are the interfaces for user - space programs to interact with the kernel and are used to perform key tasks such as file operations and process management. Different Linux system versions may have differences in system call parameters, behaviors, or numbers, which may cause the program to fail to run properly on the target system. If it is detected that the target ELF file uses system calls, the next step is to evaluate the compatibility of these system calls with the target system. This involves checking whether the system call numbers, parameter formats, and semantics match the kernel of the target system. For example, some system calls may not exist in older kernels, or their parameter structures may change in newer kernels. For scenarios where there are incompatible system calls, it is necessary to determine whether they can be adapted through user - space ABI shims. An ABI shim is a software layer used to convert or simulate system calls in user - space, enabling the program to execute properly on the target system. If a system call cannot be adapted through existing ABI shim technologies, the migration process will be terminated to avoid unpredictable behaviors or crashes of the program on the target system. Only when the target ELF file does not use system calls, or the system calls it uses are compatible with the target system, or can be successfully adapted through ABI shims, can the subsequent dependency analysis step be continued. This step ensures that only programs with migration feasibility can enter the subsequent process, thereby improving the efficiency and success rate of the entire migration process.

[0041] Step S202: Parse the dynamic segment and symbol table of the target ELF file after compatibility detection or shim adaptation processing to recursively traverse each explicit dependency library of the target ELF file.

[0042] Furthermore, in this embodiment, after confirming system call compatibility, the next step is to parse the dynamic segment (DT_NEEDED) and symbol table of the target ELF file. The dynamic segment contains information about the explicit dependency libraries required for the target ELF file to run, while the symbol table contains the names of functions and variables used in the program and their corresponding addresses. By recursively traversing these dependency libraries, a complete dependency tree can be constructed. This step ensures that all directly dependent libraries are identified, laying the foundation for subsequent analysis of the dependency relationships between libraries.

[0043] Step S203: Extract the hard - coded paths of implicit dependency libraries through static analysis to generate a list of implicit dependency libraries; based on each explicit dependency library and this list of implicit dependency libraries, construct a complete dependency tree.

[0044] In an alternative implementation, this step S203 includes: Check whether there is a target dynamic loading function call in the target ELF file; If there is such a target dynamic loading function call, extract the hard-coded path called in the target dynamic loading function through static analysis; Generate a list of implicit dependency libraries based on the implicit dependency libraries corresponding to the hard-coded path.

[0045] Furthermore, in addition to the explicitly dependent libraries, the program may also load implicitly dependent libraries at runtime through dynamic loading functions (such as dlopen and dlsym). The paths of these implicitly dependent libraries are usually hard-coded in the program. Through static analysis, that is, analyzing the code before the program runs, these hard-coded paths can be extracted and a list of implicit dependency libraries can be generated. Combining the information of explicitly dependent libraries and implicitly dependent libraries can build a complete dependency tree to ensure that all necessary libraries are identified and processed.

[0046] Step S204: Extract the actual call symbol list of each such dependency library, compare it with the symbols of the corresponding library on the target system, and collect the original system dependency libraries that are incompatible with the target system into an isolation directory.

[0047] In an alternative embodiment, this step S204 includes: Extract the actual call symbol lists of the explicitly dependent library and the implicitly dependent library; Compare the actual call symbol list with the symbols of the corresponding library on the target system one by one; If the symbols match, mark the corresponding dependency library as a compatible library; If the symbols do not match or are missing, mark the corresponding dependency library as an incompatible library; Collect the original system dependency libraries corresponding to the incompatible libraries into the isolation directory, and inject path hijacking logic into the implicitly dependent libraries in the isolation directory.

[0048] Furthermore, this step is a key link for verifying the compatibility of dependency libraries. First, it is necessary to extract the actual call symbol list of each dependency library, and these symbols represent the functions and variables defined in the library. Then, compare these symbols with the symbols of the corresponding library on the target system one by one. If the symbols match, it means that the dependency library is compatible with the target system; on the contrary, if they do not match or are missing on the target system, it is marked as an incompatible library. For these incompatible libraries, they need to be collected from the original system into the isolation directory. In addition, for implicitly dependent libraries, path hijacking logic also needs to be injected to ensure that the program can load these libraries from the isolation directory at runtime instead of from the default path of the target system.

[0049] That is to say, such as Figure 3As shown, the full analysis of the dependency tree in this embodiment starts from the dynamic section (DT_NEEDED) and symbol table of the target ELF file, and comprehensively identifies all the dependent libraries required for the program to run. The dynamic section (DT_NEEDED) of the ELF file records the explicit libraries directly depended on by the program, and the symbol table contains the functions and variables referenced in the program. Parsing these parts can obtain the explicit dependency relationships of the program. By parsing the dynamic section and symbol table, the libraries directly depended on by the program can be identified. Then, by traversing the dependency relationships of these libraries recursively and constructing a complete dependency tree, it can be ensured that all directly and indirectly dependent libraries are identified. The program may use dynamic loading functions (such as dlopen and dlsym) to load implicit dependent libraries at runtime, and the paths of these implicit dependent libraries are usually hard-coded in the program. By statically analyzing the program code, these hard-coded paths can be extracted, so as to identify the implicit dependent libraries and generate a list of implicit dependent libraries. In addition, this embodiment also performs compatibility verification on the explicit and implicit dependent libraries. For the libraries missing in the target system, they are directly marked as missing dependencies. For the libraries with version differences, the list of symbols actually called by them is extracted and compared with the corresponding libraries on the target system. If the symbols match, they are marked as compatible libraries, and if the symbols do not match or are missing, they are marked as incompatible libraries. The incompatible libraries and missing libraries are collected into a separate directory / lib / compat to prevent them from conflicting with other libraries in the target system. For the implicit dependent libraries, LD_PRELOAD hijacking logic is injected to ensure that the program preferentially loads these libraries from the specified directory instead of using the default path of the target system. The full analysis of the dependency tree ensures that all dependent libraries are identified and their compatibility is verified, laying a foundation for the subsequent migration steps.

[0050] Step S205: Modify the library search path and dynamic linker when the target ELF file runs, so as to preferentially load the original system dependent libraries in the isolation directory and replace the dynamic linker incompatible with the original system.

[0051] In an optional implementation manner, this step S205 includes: Modify the library search path when the target ELF file runs, pointing to the isolation directory to preferentially load the original system dependent libraries in the isolation directory; Verify whether the dynamic linker of the target system is compatible with the dynamic linker of the original system; If they are not compatible, copy the dynamic linker of the original system to the migration package and modify the specified path of the dynamic linker of the target ELF file.

[0052] Furthermore, in order to ensure that the program can correctly load the required dependent libraries on the target system, it is necessary to modify the library search path during the runtime of the target ELF file. Specifically, the library search path is pointed to the isolation directory, so that the program will preferentially load the dependent libraries from the isolation directory during runtime. At the same time, it is also necessary to verify whether the dynamic linker of the target system is compatible with that of the original system. The dynamic linker is responsible for loading and linking shared libraries during the program's runtime. If the dynamic linker of the target system is not compatible, it is necessary to copy the dynamic linker of the original system into the migration package and modify the INTERP section of the target ELF file to specify the use of the dynamic linker in the migration package.

[0053] That is to say, as Figure 3 shown, the runtime path reconstruction in this embodiment mainly adjusts the path configurations of the target ELF file and its dependent libraries to ensure that the program can correctly load the required compatible libraries on the target system. The RPATH field of the target ELF file specifies the path for the dynamic linker to search for shared libraries during runtime. By modifying the RPATH fields of the target ELF file and its dependent libraries and pointing them to the / lib / compat isolation directory, it can be ensured that the program preferentially loads the compatible libraries from this directory during runtime instead of using the libraries under the default path of the target system. This embodiment can use the patchelf tool to modify the RPATH field. The dynamic linker is responsible for loading and linking shared libraries during the program's runtime. Different systems may use different versions of the dynamic linker, so it is necessary to verify whether the dynamic linker of the target system is compatible with that of the original system. If the dynamic linker of the target system (such as / lib / ld-linux-x86-64.so.2) is not compatible with the original system, it is necessary to copy the dynamic linker of the original system into the migration package and specify the path of the dynamic linker in the migration package by modifying the INTERP section of the target ELF file. For the implicitly dependent library paths hard-coded in the program, they need to be synchronously redirected to the / lib / compat isolation directory to ensure that these implicitly dependent libraries can also be loaded from the compatible directory. Through the above operations, the runtime path reconstruction can solve the library loading problem caused by the environmental differences of the target system and ensure the stable operation of the program in the new system environment.

[0054] Step S206, construct a migration package to be deployed to the target system and perform adaptive migration verification on the migration package; the migration package includes the target ELF file, the original system dependent libraries in the isolation directory, the dynamic linker of the original system, the user-mode ABI shim, and the LD_PRELOAD path hijacking script.

[0055] In an optional implementation manner, this step S206 includes: Perform a migration function test on the migration package. If a migration operation exception occurs, use backward tracing to locate and analyze the problem; According to the results of the location and analysis, supplement the missing libraries into the isolated directory and perform loop testing until all dependencies are completely matched.

[0056] Furthermore, in this step, a complete migration package is constructed, which includes all necessary components such as the target ELF file, the original system dependencies in the isolated directory, the user-mode ABI shim, and the path hijacking script. After the migration package is built, adaptive migration verification needs to be performed on the target system. This includes running the migrated program and performing comprehensive function tests to ensure that all functions work properly. If an exception occurs during the test, backward tracing technology needs to be used to locate the root cause of the problem. According to the analysis results, supplement the missing libraries into the isolated directory and repeat the test process until all dependency relationships are completely matched and the program can run stably.

[0057] That is to say, as Figure 3 shown, the adaptive migration verification in this embodiment is a key step in the entire migration process, aiming to ensure that the migrated program can run stably and reliably on the target system. The construction of the migration package is the basis for adaptive migration verification. After the migration package in this embodiment is deployed to the target system, comprehensive function tests need to be performed. The purpose of the function test is to verify whether the program can run normally on the target system and whether all functions work as expected. This step can discover problems that may occur during the migration process, such as missing symbols or loading errors. During the function test, various operation exceptions may occur. At this time, backward tracing combined with dynamic instrumentation technology needs to be used to locate the root cause of the problem. Dynamic instrumentation technology allows additional monitoring code to be inserted without modifying the program source code to collect information during program execution. Backward tracing is to trace back the execution path of the program from the point where the exception occurs to find the problem. For programs using dynamic loading, special attention needs to be paid to the path matching problem of implicit libraries. Dynamically loaded libraries are usually loaded during program execution, so it is necessary to ensure that the paths of these implicit dependency libraries correctly point to the / lib / compat isolated directory to avoid loading errors. Once missing symbols or dependency libraries are found, these libraries need to be supplemented into the / lib / compat isolated directory and retested. This process may need to be iterated multiple times until all explicit and implicit dependencies are completely matched and the program can run stably on the target system. Finally, when the program passes all function tests, proving that all dependencies have been correctly matched and the program (i.e., the target ELF file) can run stably on the target system, the migration process is considered complete. Adaptive migration verification ensures the compatibility and stability of the program in the new system environment through the above systematic method.

[0058] In this embodiment, through a hierarchical compatibility verification mechanism, multi-dimensional scenarios such as system calls, explicit dependent libraries, and implicit dynamic loading libraries are covered. Combining path isolation and symbol-level ABI checking can ensure cross-system compatibility while avoiding polluting the target environment. This embodiment does not require migrating the entire operating system, only migrating the software and its dependent libraries, which reduces the migration difficulty. Moreover, there is no need to obtain the source code or modify the host environment. Adaptation is achieved through binary reverse analysis and runtime interception, solving the problem of migrating closed-source software. Compared with container technology, it avoids the functional limitations of the isolation mechanism on resource-tightly coupled software.

[0059] In summary, in this embodiment, by recursively traversing the dependency tree and statically analyzing to extract the hard-coded paths of implicit dependent libraries, all dependent libraries required for program operation can be comprehensively identified, including explicit and implicit dependencies, effectively avoiding migration failures caused by missing dependent libraries. At the same time, extracting the actual call symbol list of the dependent libraries and comparing it with the target system can accurately identify problems of symbol mismatch or missing, and then take corresponding solutions to improve the compatibility and running stability of the program in the target system.

[0060] This embodiment performs shim adaptation processing on incompatible system calls to solve problems such as changes in system call interfaces between different system versions, enabling the program to correctly execute system calls on the target system and adapt to different system environments. If the dynamic linker of the target system is incompatible with the original system, copy the dynamic linker of the original system to the migration package and modify the specified path to ensure correct dynamic linking and loading of the program, further enhancing system compatibility.

[0061] The entire migration method of this embodiment covers steps such as system call detection, dependency tree analysis, symbol verification, and runtime path reconstruction, forming a complete automated migration process, reducing manual operations and interventions, and improving migration efficiency and accuracy. Collect the incompatible original system dependent libraries into an isolation directory, and inject path hijacking logic into the implicit dependent libraries so that the compatible libraries are preferentially loaded when the program runs, avoiding cumbersome library conflict troubleshooting and accelerating the migration process.

[0062] In this embodiment, a migration device for Linux executable programs is also provided. This device is used to implement the above-mentioned embodiments and preferred implementation manners, and those that have been described will not be repeated. As used hereinafter, the term "module" can be a combination of software and / or hardware that can achieve a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0063] This embodiment provides a migration device for Linux executable programs, as Figure 4 shown, including: The system call compatibility detection module 401 is used to obtain the target ELF file to be migrated, detect the compatibility between the system calls used by the target ELF file and the target system, and perform shim adaptation processing on the incompatible system calls; The dependency tree full analysis module 402 is used to perform a full analysis of the dependency tree of the target ELF file after compatibility detection or shim adaptation processing, and identify the dependent libraries required for the operation of the target ELF file; The symbol-level compatibility verification module 403 is used to extract the actual call symbol list of each dependent library, compare it with the symbols of the corresponding library on the target system, and collect the original system-dependent libraries that are incompatible with the target system into the isolation directory; The runtime path reconstruction module 404 is used to modify the library search path and dynamic linker when the target ELF file runs, so as to preferentially load the original system-dependent libraries in the isolation directory and replace the dynamic linker that is incompatible with the original system; The adaptive migration verification module 405 is used to build a migration package deployed to the target system and perform adaptive migration verification on the migration package; the migration package includes the target ELF file, the original system-dependent libraries in the isolation directory, the user-mode ABI shim, and the path hijacking script.

[0064] In some alternative embodiments, the system call compatibility detection module 401 is further used for: Detect whether there are system calls in the target ELF file. If there are system calls, evaluate the compatibility between the system calls and the target system; For the incompatible system calls, perform adaptation processing through the user-mode ABI shim. If the adaptation processing cannot be performed, terminate the migration process of the target ELF file.

[0065] In some alternative embodiments, the dependency tree full analysis module 402 is further used for: Parse the dynamic segment and symbol table of the target ELF file after compatibility detection or shim adaptation processing to recursively traverse each explicit dependent library of the target ELF file; Extract the hard-coded paths of the implicit dependent libraries through static analysis to generate a list of implicit dependent libraries; Based on each explicit dependent library and the list of implicit dependent libraries, construct a complete dependency tree.

[0066] In some alternative embodiments, the dependency tree full analysis module 402 is further used for: Detect whether there is a target dynamic loading function call in the target ELF file; If there is the target dynamic loading function call, extract the hard-coded path called in the target dynamic loading function through static analysis; Generate a list of implicit dependency libraries based on the implicit dependency libraries corresponding to the hard-coded paths.

[0067] In some alternative embodiments, the symbol-level compatibility verification module 403 is further configured to: Extract the actual call symbol lists of the explicit dependency libraries and the implicit dependency libraries; Compare each symbol in the actual call symbol list with the symbols of the corresponding libraries on the target system one by one; If the symbols match, mark the corresponding dependency libraries as compatible libraries; If the symbols do not match or are missing, mark the corresponding dependency libraries as incompatible libraries; Collect the original system dependency libraries corresponding to the incompatible libraries into an isolation directory, and inject path hijacking logic into the implicit dependency libraries in the isolation directory.

[0068] In an alternative embodiment, the runtime path reconstruction module 404 is further configured to: Modify the library search path during the runtime of the target ELF file to point to the isolation directory to preferentially load the original system dependency libraries in the isolation directory; Verify whether the dynamic linker of the target system is compatible with the dynamic linker of the original system; If they are not compatible, copy the dynamic linker of the original system to the migration package and modify the dynamic linker specified path of the target ELF file.

[0069] In an alternative embodiment, the adaptive migration verification module 405 is further configured to: Perform a migration function test on the migration package. If a migration runtime exception occurs, perform problem location and analysis through backward tracing; According to the results of the location and analysis, supplement the missing libraries to the isolation directory and perform loop testing until all dependencies are completely matched.

[0070] The further function descriptions of the above-mentioned various modules and units are the same as those in the corresponding foregoing embodiments, and will not be elaborated herein.

[0071] The migration device for a Linux executable program in this embodiment is presented in the form of functional units. Here, the unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and a memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0072] This embodiment of the present invention further provides a computer device. Please refer to Figure 5 , Figure 5The following is a schematic structural diagram of a computer device provided by an optional embodiment of the present invention. As Figure 5 shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including a high-speed interface and a low-speed interface. Each component communicates with each other using different buses and can be installed on a common motherboard or installed in other ways as needed. The processor can process instructions executed within the computer device, including instructions stored in the memory or on the memory to display graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (such as an array of servers, a set of blade servers, or a multi-processor system). Figure 5 In

[0073] FIG.

[0074] The memory 20 stores instructions executable by at least one processor 10, so that at least one processor 10 executes the method shown in the above embodiments.

[0075] The memory 20 may include a program storage area and a data storage area. Among them, the program storage area can store an operating system and application programs required for at least one function; the data storage area can store data created according to the use of the computer device. In addition, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some optional embodiments, the memory 20 may optionally include a memory remotely set relative to the processor 10, and these remote memories can be connected to the computer device through a network. Examples of the above networks include, but are not limited to, the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0076] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, a hard disk, or a solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0077] The computer device further includes a communication interface 30 for the computer device to communicate with other devices or communication networks.

[0078] Embodiments of the present invention also provide a computer-readable storage medium. The method according to the embodiments of the present invention can be implemented in hardware, firmware, or be implemented as computer code that can be recorded on a storage medium, or be implemented as computer code originally stored in a remote storage medium or a non-transitory machine-readable storage medium and to be downloaded through a network and stored in a local storage medium, so that the method described herein can be stored in such software processes on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only memory, a random access memory, a flash memory, a hard disk, or a solid-state drive, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by the computer, the processor, or the hardware, the methods shown in the above embodiments are implemented.

[0079] A part of the present invention can be applied as a computer program product, such as computer program instructions. When executed by a computer, through the operation of the computer, the methods and / or technical solutions according to the present invention can be invoked or provided. Those skilled in the art should be able to understand that the forms of existence of computer program instructions in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways for a computer to execute computer program instructions include, but are not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Herein, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to the computer.

[0080] Although the embodiments of the present invention are described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations all fall within the defined scope.

Claims

1. A migration method for Linux executable programs, characterized in that The method includes: Obtain the target ELF file to be migrated, perform compatibility detection on the system calls used by the target ELF file with the target system, and perform shim adaptation processing on the incompatible system calls; Perform a full-scale analysis of the dependency tree on the target ELF file after compatibility detection or shim adaptation processing, and identify the dependent libraries required for the target ELF file to run; Extract the actual call symbol list of each dependent library, compare it with the symbols of the corresponding library on the target system, and collect the original system dependent libraries that are incompatible with the target system into an isolation directory; Modify the library search path and dynamic linker when the target ELF file runs to preferentially load the original system dependent libraries in the isolation directory and replace the dynamic linker that is incompatible with the original system; Build a migration package to be deployed to the target system and perform adaptive migration verification on the migration package.

2. The method according to claim 1, wherein The compatibility detection of the system calls used by the target ELF file with the target system and the shim adaptation processing of the incompatible system calls include: Detect whether there are system calls in the target ELF file. If there are system calls, evaluate the compatibility of the system calls with the target system; For the incompatible system calls, perform adaptation processing through the user-mode ABI shim. If the adaptation processing cannot be performed, terminate the migration process of the target ELF file.

3. The method according to claim 1, characterized in that, The full-scale analysis of the dependency tree on the target ELF file after compatibility detection or shim adaptation processing to identify the dependent libraries required for the target ELF file to run includes: Parse the dynamic segment and symbol table of the target ELF file after compatibility detection or shim adaptation processing to recursively traverse each explicit dependent library of the target ELF file; Extract the hard-coded paths of the implicit dependent libraries through static analysis and generate a list of implicit dependent libraries; Based on each explicit dependent library and the list of implicit dependent libraries, construct a complete dependency tree.

4. The method according to claim 3, wherein The extraction of the hard-coded paths of the implicit dependent libraries through static analysis and the generation of a list of implicit dependent libraries includes: Detect whether there is a target dynamic loading function call in the target ELF file; If there is the target dynamic loading function call, extract the hard-coded path called in the target dynamic loading function through static analysis; Generate a list of implicit dependent libraries based on the implicit dependent libraries corresponding to the hard-coded paths.

5. The method according to claim 4, characterized in that, The extraction of the actual call symbol list of each dependent library, the comparison with the symbols of the corresponding library on the target system, and the collection of the original system dependent libraries that are incompatible with the target system into an isolation directory include: Extract the actual call symbol list of the explicit dependent libraries and the implicit dependent libraries; Compare the actual call symbol list with the symbols of the corresponding library on the target system one by one; If the symbols match, mark the corresponding dependent library as a compatible library; If the symbols do not match or are missing, mark the corresponding dependent library as an incompatible library; Collect the original system dependent libraries corresponding to the incompatible libraries into the isolation directory and inject path hijacking logic into the implicit dependent libraries in the isolation directory.

6. The method according to claim 1, characterized in that, Modify the library search path and dynamic linker of the target ELF file during runtime to preferentially load the original system-dependent libraries in the isolation directory and replace the dynamic linker that is incompatible with the original system, including: Modify the library search path of the target ELF file during runtime to point to the isolation directory to preferentially load the original system-dependent libraries in the isolation directory; Verify whether the dynamic linker of the target system is compatible with the dynamic linker of the original system; If they are not compatible, copy the dynamic linker of the original system to the migration package and modify the specified path of the dynamic linker of the target ELF file.

7. The method according to any one of claims 1 to 6, characterized in that, The adaptive migration verification of the migration package includes: Conduct a migration function test on the migration package. If a migration runtime exception occurs, perform problem location and analysis through reverse tracing; According to the results of location and analysis, supplement the missing libraries to the isolation directory and perform loop testing until all dependencies are completely matched.

8. A migration device for Linux executable programs, characterized in that, The device includes: A system call compatibility detection module, configured to obtain the target ELF file to be migrated, perform compatibility detection on the system calls used by the target ELF file and the target system, and perform shim adaptation processing on the incompatible system calls; A dependency tree full-scale analysis module, configured to perform full-scale analysis of the dependency tree of the target ELF file after compatibility detection or shim adaptation processing to identify the dependent libraries required for the target ELF file to run; A symbol-level compatibility verification module, configured to extract the actual call symbol list of each dependent library and compare it with the symbols of the corresponding library on the target system, and collect the original system-dependent libraries that are incompatible with the target system into the isolation directory; A runtime path reconstruction module, configured to modify the library search path and dynamic linker of the target ELF file during runtime to preferentially load the original system-dependent libraries in the isolation directory and replace the dynamic linker that is incompatible with the original system; An adaptive migration verification module, configured to build a migration package deployed to the target system and perform adaptive migration verification on the migration package.

9. A computer device, characterized in that, Including: A memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to execute the migration method of a Linux executable program according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Computer instructions are stored on the computer-readable storage medium, and the computer instructions are used to cause a computer to execute the migration method of a Linux executable program according to any one of claims 1 to 7.

Images