Migration method and device of Linux executable program

Abstract

The present application relates to the technical field of software migration, and particularly relates to a Linux executable program migration method and device, which comprises the following steps: performing compatibility detection on system calls of a target ELF file, performing patch adaptation processing on incompatible system calls; performing full analysis on a dependency tree of the target ELF file, and identifying dependency libraries required for running the target ELF file; then extracting actual call symbol lists of the dependency libraries, and comparing the actual call symbol lists with symbols of corresponding libraries on a target system; collecting incompatible original system dependency libraries to an isolated directory; modifying a library search path of the target ELF file during running, so as to preferentially load the original system dependency libraries in the isolated directory; finally, constructing a migration package deployed to the target system, and performing self-adaptive migration verification on the migration package. The present application improves the compatibility and running stability of a program on a target system, only migrates software and dependency libraries, reduces migration difficulty, and accelerates the migration process.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software migration, in particular to a Linux executable program migration method and device. BACKGROUND

[0002] In the Linux system, software migration faces many challenges. The executable files under the Linux system are mostly in ELF format, and their running relies on the binary interface (ABI) provided by the system, including the kernel version, dynamic library, hardware instruction set, etc.

[0003] When migrating across systems, ABI incompatibility often causes program crashes, such as glibc symbol version conflicts, kernel system call changes, etc. At the same time, the program may not run due to the lack of low-version shared libraries on the target system, or fail due to hardcoded paths that do not comply with the target system file standards. In addition, the historical legacy of closed-source software cannot be adapted to new systems through recompilation due to the lack of source code or compiler tool chain support, which seriously hinders the cross-platform migration and deployment efficiency of software.

[0004] Therefore, a new migration method is needed to support cross-system compatibility under the conditions of no source code and target system compilation environment, and to efficiently and reliably migrate Linux executable programs. SUMMARY

[0005] Therefore, the present application provides a Linux executable program migration method and device to solve the defects of complex migration operation and ineffective dependency resolution when migrating Linux executable programs in the prior art.

[0006] In a first aspect, the present application provides a Linux executable program migration method, which comprises:

[0007] Obtaining a target ELF file to be migrated, and performing compatibility detection on the system calls used by the target ELF file and the target system, and performing shim adaptation processing on the incompatible system calls;

[0008] Performing full dependency tree analysis on the target ELF file after compatibility detection or shim adaptation processing, and identifying the dependent libraries required for running the target ELF file;

[0009] Extracting the actual call symbol list of each dependent library and comparing it with the symbols of the corresponding library on the target system, and collecting the original system dependent libraries incompatible with the target system to an isolated directory;

[0010] modify the library search path and dynamic linker of the target ELF file at runtime to preferentially load the original system dependent library in the isolated directory and replace the dynamic linker incompatible with the original system;

[0011] construct 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 library in the isolated directory, the user mode ABI shim, and the path hijacking script.

[0012] In an optional implementation, the system call used by the target ELF file is subjected to compatibility detection with the target system, and the system call incompatible with the target system is subjected to shim adaptation processing, including:

[0013] detecting whether the target ELF file has a system call, and if so, evaluating the compatibility of the system call with the target system;

[0014] for the system call incompatible with the target system, the system call is subjected to adaptation processing through a user mode ABI shim, and if adaptation processing cannot be performed, the migration process of the target ELF file is terminated.

[0015] In an optional implementation, the target ELF file subjected to compatibility detection or shim adaptation processing is subjected to full dependency tree analysis, and the dependent library required for running the target ELF file is identified, including:

[0016] parsing the dynamic segment and symbol table of the target ELF file subjected to compatibility detection or shim adaptation processing to recursively traverse each explicit dependent library of the target ELF file;

[0017] extracting the hard-coded path of an implicit dependent library through static analysis to generate an implicit dependent library list;

[0018] based on each explicit dependent library and the implicit dependent library list, a complete dependency tree is constructed.

[0019] In an optional implementation, the hard-coded path of an implicit dependent library is extracted through static analysis to generate an implicit dependent library list, including:

[0020] detecting whether the target ELF file has a target dynamic loading function call;

[0021] if the target dynamic loading function call exists, the hard-coded path called in the target dynamic loading function is extracted through static analysis;

[0022] based on the implicit dependent library corresponding to the hard-coded path, an implicit dependent library list is generated.

[0023] In an alternative embodiment, the actual call symbol list of each of the dependent libraries is extracted and compared with the symbols of the corresponding libraries on the target system, and the original system dependent libraries incompatible with the target system are collected into the isolated directory, including:

[0024] The actual call symbol list of the explicit dependent libraries and the implicit dependent libraries is extracted;

[0025] The actual call symbol list is compared with the symbols of the corresponding libraries on the target system one by one;

[0026] If the symbols match, the corresponding dependent library is marked as a compatible library;

[0027] If the symbols do not match or are missing, the corresponding dependent library is marked as an incompatible library;

[0028] The original system dependent library corresponding to the incompatible library is collected into the isolated directory, and path hijacking logic is injected into the implicit dependent library in the isolated directory.

[0029] In an alternative embodiment, the library search path and the dynamic linker at the runtime of the target ELF file are modified to preferentially load the original system dependent libraries in the isolated directory and replace the dynamic linker incompatible with the original system, including:

[0030] The library search path at the runtime of the target ELF file is modified to point to the isolated directory to preferentially load the original system dependent libraries in the isolated directory;

[0031] It is verified whether the dynamic linker of the target system is compatible with the dynamic linker of the original system;

[0032] If incompatible, the dynamic linker of the original system is copied to the migration package, and the dynamic linker specified path of the target ELF file is modified.

[0033] In an alternative embodiment, the migration package is adaptively migrated and verified, including:

[0034] The migration function test is performed on the migration package, and if migration running abnormity occurs, problem positioning and analysis are performed through reverse tracking;

[0035] According to the positioning and analysis results, the missing libraries are supplemented into the isolated directory, and the cyclic test is performed until all dependencies are completely matched.

[0036] In a second aspect, the application provides a Linux executable program migration device, including:

[0037] The system call compatibility detection module is configured to obtain a target ELF file to be migrated, and perform compatibility detection on system calls used by the target ELF file and a target system, and perform shim adaptation processing on the incompatible system calls.

[0038] The dependency tree full analysis module is configured to perform dependency tree full analysis on the target ELF file after the compatibility detection or the shim adaptation processing, and identify dependency libraries required for running the target ELF file.

[0039] The symbol level compatibility verification module is configured to extract actual call symbol lists of the dependency libraries, and compare the actual call symbol lists with symbols of corresponding libraries on the target system, and collect original system dependency libraries incompatible with the target system to an isolated directory.

[0040] The runtime path reconstruction module is configured to modify a library search path and a dynamic linker at runtime of the target ELF file, so as to preferentially load the original system dependency libraries in the isolated directory, and replace a dynamic linker incompatible with the original system.

[0041] The adaptive migration verification module is configured to construct 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 dependency libraries in the isolated directory, a user mode ABI shim, and a path hijacking script.

[0042] In a third aspect, the present application provides a computer device, comprising a memory and a processor, the memory and the processor are connected with each other in communication, the memory stores computer instructions, and the processor executes the computer instructions to perform the migration method of the Linux executable program according to the first aspect or any one of the corresponding embodiments thereof.

[0043] In a fourth aspect, the present application provides a computer readable storage medium, which stores computer instructions, and the computer instructions are used to make a computer execute the migration method of the Linux executable program according to the first aspect or any one of the corresponding embodiments thereof.

[0044] In a fifth aspect, the present application provides a computer program product, which comprises computer instructions, and the computer instructions are used to make a computer execute the migration method of the Linux executable program according to the first aspect or any one of the corresponding embodiments thereof.

[0045] The technical solution provided by the present application can have the following beneficial effects:

[0046] The application can comprehensively identify all dependent libraries required by program running, including explicit and implicit dependencies, effectively avoid migration failure caused by missing dependent libraries, and solve the dependency problem by performing full analysis on the dependency tree of the target ELF file. At the same time, the actual call symbol list of the dependent library is extracted and compared with the target system, which can accurately identify the problem of symbol mismatch or missing, and then take corresponding solving measures to improve the compatibility and running stability of the program on the target system.

[0047] The application performs shim adaptation processing on incompatible system calls to solve the problem of system call interface changes between different system versions, so that the program can normally perform system calls on the target system, adapt to different system environments, and solve the problem of insufficient support of closed-source software.

[0048] The whole migration method of the application covers system call detection, dependency tree analysis, symbol verification, and runtime path reconstruction, forming a complete automatic migration process, reducing manual operation and intervention, and improving migration efficiency and accuracy. The incompatible original system dependent library is collected to the isolated directory, and the path hijacking logic is injected to the implicit dependent library, so that the compatible library is loaded preferentially during program running, avoiding tedious library conflict investigation, accelerating the migration process, without migrating the whole operating system, only migrating the software and its dependent library, reducing the migration difficulty and complexity. BRIEF DESCRIPTION OF DRAWINGS

[0049] In order to more clearly illustrate the specific embodiments of the present application or the technical solutions in the prior art, the following will briefly introduce the drawings needed to be used in the specific embodiments or prior art description. Obviously, the drawings described below are some embodiments of the present application, and those skilled in the art can also obtain other drawings according to these drawings without creative labor.

[0050] Figure 1 is a flowchart of a Linux executable program migration method according to an embodiment of the application;

[0051] Figure 2 is a flowchart of another Linux executable program migration method according to an embodiment of the application;

[0052] Figure 3 is a flowchart of another Linux executable program migration method according to an embodiment of the application;

[0053] Figure 4 is a structural block diagram of a Linux executable program migration device according to an embodiment of the application;

[0054] Figure 5 is a hardware structure schematic diagram of a computer device according to an embodiment of the application. DETAILED DESCRIPTION

[0055] In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0056] According to the embodiments of the present application, a Linux executable program migration method embodiment is provided. It should be noted that the steps shown in the flowchart of the 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 herein can be executed in an order different from that shown herein.

[0057] In the present embodiment, a Linux executable program migration method is provided, Figure 1 is a flowchart of a Linux executable program migration method according to the embodiments of the present application, as Figure 1 shown, the flow includes the following steps:

[0058] Step S101, obtaining a target ELF file to be migrated, and performing compatibility detection on the system calls used by the target ELF file and the target system, and performing shim adaptation processing on the incompatible system calls.

[0059] Further, the present embodiment obtains a target ELF file to be migrated, and performs system call compatibility detection thereon, and performs shim adaptation processing on the incompatible system calls. The purpose of this step is to ensure that the target ELF file can normally execute system calls on the target system. Since there may be system call interface changes or parameter semantic differences between different system versions, by detecting the compatibility of the system calls used by the target ELF file and the target system, and adapting the incompatible system calls using user-mode ABI shim, the problem of incompatible system calls is solved, and the program is prevented from crashing on the target system due to system call failure.

[0060] Step S102, performing full dependency tree analysis on the target ELF file after compatibility detection or shim adaptation processing, and identifying the dependent libraries required for running the target ELF file.

[0061] Further, the embodiment performs full analysis on the dependency tree of the target ELF file after compatibility detection or pad adaptation processing, and identifies the required dependent libraries. This step aims to comprehensively identify the required dependent libraries for the target ELF file, including explicit dependent libraries and implicit dependent libraries, to ensure that no critical dependencies are missed.

[0062] In step S103, the actual call symbol list of each dependent library is extracted and compared with the symbols of the corresponding library on the target system. The original system dependent libraries incompatible with the target system are collected into the isolation directory.

[0063] Further, the embodiment extracts the actual call symbol list of each dependent library and compares it with the symbols of the corresponding library on the target system. The original system dependent libraries incompatible with the target system are collected into the isolation directory. This step accurately identifies the dependent libraries incompatible with the target system by detailed comparison of the symbols of the dependent libraries. Symbols are names used to identify functions, variables, etc. in a program, and different versions of libraries may differ in symbols. By extracting the actual call symbol list of the dependent libraries and comparing them one by one with the symbols of the corresponding library on the target system, the dependent libraries with unmatched or missing symbols are marked as incompatible libraries and collected into the isolation directory for subsequent unified management and processing.

[0064] In step S104, the library search path and dynamic linker at 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 incompatible with the original system.

[0065] Further, the embodiment modifies the library search path and dynamic linker at runtime of the target ELF file to preferentially load the original system dependent libraries in the isolation directory and replace the dynamic linker incompatible with the original system. This step modifies the RPATH field of the target ELF file and its dependent libraries to make the program preferentially load the original system dependent libraries from the isolation directory at runtime, avoiding loading incompatible libraries that may exist in the target system. At the same time, 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 normally on the target system. The original system is a 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.

[0066] In step S105, a migration package is built for deployment to the target system, and the migration package is adaptively verified. The migration package includes the target ELF file, the original system dependent libraries in the isolation directory, the user-mode ABI pad, and the path hijacking script.

[0067] Further, the embodiment constructs a migration package deployed to the target system, and performs adaptive migration verification on the migration package. The migration package includes a target ELF file, original system dependent libraries in an isolated directory, user-mode ABI patch, and path hijacking scripts, etc. This step integrates all necessary components into a migration package, ensuring smooth deployment and operation on the target system. By deploying the migration package on the target system and performing function testing, locating operation abnormalities, and iteratively supplementing missing dependencies until all functions pass the test, the stability and reliability of the program on the target system are ensured.

[0068] In summary, the embodiment can comprehensively identify all dependent libraries required for program operation, including explicit and implicit dependencies, by performing full dependency tree analysis on the target ELF file, effectively avoiding migration failures due to missing dependent libraries, and solving dependency problems. At the same time, by extracting the actual call symbol list of the dependent library and comparing it with the target system, the problem of symbol mismatch or missing can be accurately identified, and appropriate solutions can be taken to improve the compatibility and running stability of the program on the target system.

[0069] The embodiment performs patch adaptation processing on incompatible system calls, solves problems such as system call interface changes between different system versions, and enables the program to perform system calls normally on the target system, adapt to different system environments, and solve the problem of insufficient support for closed-source software.

[0070] The entire migration method of the embodiment covers system call detection, dependency tree analysis, symbol verification, and runtime path reconstruction, forming a complete and automated migration process, reducing manual operation and intervention, and improving migration efficiency and accuracy. Incompatible original system dependent libraries are collected to an isolated directory, and path hijacking logic is injected for implicit dependent libraries, so that the program loads compatible libraries preferentially during runtime, avoiding tedious library conflict investigation, accelerating the migration process, without the need to migrate the entire operating system, only migrating software and its dependent libraries, reducing migration difficulty and complexity.

[0071] In the embodiment, another migration method of a Linux executable program is provided, Figure 2 is a flowchart of another migration method of a Linux executable program according to an embodiment of the present application, as shown in Figure 2 The flowchart includes the following steps:

[0072] In step S201, a target ELF file to be migrated is obtained, and the system calls used by the target ELF file are detected for compatibility with the target system. Patch adaptation processing is performed on incompatible system calls.

[0073] In an optional embodiment, step S201 includes:

[0074] detecting whether the target ELF file uses system calls, and if so, evaluating the compatibility of the system calls with the target system;

[0075] For incompatible system calls, the system call is adapted through a user-mode ABI shim, and if adaptation is not possible, the migration process of the target ELF file is terminated.

[0076] Further, the purpose of this step is to ensure that the target ELF file can execute system calls normally on the target system. First, it is necessary to detect whether the target ELF file uses system calls. If there are system calls, further evaluation of the compatibility of these system calls with the target system is required. For example, different Linux kernel versions can modify the parameters or behavior of system calls. For those incompatible system calls, adaptation is performed through the use of a user-mode ABI shim. A 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 a shim, the migration process of the target ELF file will be terminated to avoid potential runtime errors.

[0077] That is, please refer to Figure 3 Another flowchart of a migration method of a Linux executable program is shown. System call compatibility pre-detection is a key starting step in the entire migration process. After obtaining the target ELF file, it is first verified whether it uses system calls. System calls are the interface between user space programs and the kernel, used to perform critical tasks such as file operations and process management. Different Linux system versions can have differences in the parameters, behavior or numbering of system calls, which can cause programs to not run normally on the target system. If it is detected that the target ELF file uses system calls, the compatibility of these system calls with the target system is then evaluated. This involves checking whether the numbering, parameter format and semantics of the system calls match the kernel of the target system. For example, some system calls can not exist in older kernels, or their parameter structures can change in newer kernels. For scenarios where there are incompatible system calls, it is necessary to determine whether they can be adapted through a user-mode ABI shim. An ABI shim is a software layer that converts or simulates system calls in user mode, allowing programs to execute normally on the target system. If a system call cannot be adapted through existing ABI shim technology, the migration process will be terminated to avoid unpredictable behavior 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 an ABI shim, can the subsequent dependency analysis step be continued. This step ensures that only programs that are feasible for migration can enter the subsequent process, thereby improving the efficiency and success rate of the entire migration process.

[0078] Step S202, parsing the dynamic segment and symbol table of the target ELF file after compatibility detection or gasket adaptation processing, to recursively traverse each explicit dependent library of the target ELF file.

[0079] Further, after confirming the 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 dependent libraries required by the target ELF file at runtime, while the symbol table contains the names and corresponding addresses of functions and variables used in the program. By recursively traversing these dependent 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 library dependencies.

[0080] Step S203, extracting the hard-coded path of implicit dependent libraries through static analysis, generating an implicit dependent library list; based on each explicit dependent library and the implicit dependent library list, a complete dependency tree is constructed.

[0081] In an optional implementation, step S203 includes:

[0082] Detecting whether there is a target dynamic loading function call in the target ELF file;

[0083] If the target dynamic loading function call exists, extract the hard-coded path called in the target dynamic loading function through static analysis;

[0084] Based on the implicit dependent library corresponding to the hard-coded path, generate an implicit dependent library list.

[0085] Further, in addition to explicit dependent libraries, programs may also load implicit dependent libraries at runtime through dynamic loading functions such as dlopen and dlsym. The paths of these implicit dependent libraries are usually hard-coded in the program. Through static analysis, i.e., analyzing the code before the program runs, these hard-coded paths can be extracted and an implicit dependent library list can be generated. Combining the information of explicit dependent libraries and implicit dependent libraries, a complete dependency tree can be constructed, ensuring that all necessary libraries are identified and processed.

[0086] Step S204, extracting the actual call symbol list of each dependent library and comparing it with the symbols of the corresponding library on the target system, and collecting the original system dependent libraries incompatible with the target system to the isolation directory.

[0087] In an optional implementation, step S204 includes:

[0088] Extracting the actual call symbol list of the explicit dependent library and the implicit dependent library;

[0089] The actual call symbol list is compared with the corresponding library symbols on the target system one by one;

[0090] If the symbols match, the corresponding dependent library is marked as a compatible library;

[0091] If the symbols do not match or are missing, the corresponding dependent library is marked as an incompatible library;

[0092] The original system dependent library corresponding to the incompatible library is collected into an isolated directory, and path hijacking logic is injected into the implicit dependent library in the isolated directory.

[0093] Further, this step is a key link for compatibility verification of dependent libraries. First, the actual call symbol list of each dependent library needs to be extracted, and these symbols represent the functions and variables defined in the library. Then, these symbols are compared with the corresponding library symbols on the target system one by one. If the symbols match, it means that the dependent library is compatible with the target system; otherwise, 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 to an isolated directory. In addition, for implicit dependent libraries, path hijacking logic needs to be injected to ensure that the program can load these libraries from the isolated directory during runtime, rather than from the default path of the target system.

[0094] That is, as Figure 3As shown, the dependency tree full analysis of the present embodiment is a process of comprehensively identifying all dependent libraries required for program running, starting from the dynamic segment (DT_NEEDED) and symbol table of the target ELF file. The dynamic segment (DT_NEEDED) of the ELF file records the explicit libraries directly dependent by the program, and the symbol table contains the functions and variables referenced in the program. Parsing these parts can obtain the explicit dependency relationship of the program. By parsing the dynamic segment and the symbol table, the libraries directly dependent by the program can be identified. Then, the dependency relationship of these libraries is traversed in a recursive manner to construct a complete dependency tree, which can ensure that all directly and indirectly dependent libraries are identified. The program can 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 to identify the implicit dependent libraries and generate an implicit dependent library list. In addition, the present embodiment also performs compatibility verification on the explicit and implicit dependent libraries. For libraries missing in the target system, they are directly marked as missing dependencies. For libraries with version differences, the actual call symbol list thereof is extracted and compared with the corresponding library on the target system. If the symbols match, the library is marked as a compatible library, and if the symbols do not match or are missing, the library is marked as an incompatible library. The incompatible libraries and missing libraries are collected into a separate directory / lib / compat to prevent conflicts with other libraries in the target system. For implicit dependent libraries, LD_PRELOAD hijacking logic is injected to ensure that the program loads these libraries from the specified directory first, rather than using the default path of the target system. The dependency tree full analysis ensures that all dependent libraries are identified and their compatibility is verified, laying a foundation for subsequent migration steps.

[0095] In step S205, the library search path and dynamic linker of the target ELF file at runtime are modified to preferentially load the original system dependent libraries in the isolated directory and replace the dynamic linker incompatible with the original system.

[0096] In an optional implementation, step S205 includes:

[0097] modifying the library search path of the target ELF file at runtime to point to the isolated directory to preferentially load the original system dependent libraries in the isolated directory;

[0098] verifying whether the dynamic linker of the target system is compatible with the dynamic linker of the original system;

[0099] if incompatible, copying the dynamic linker of the original system to the migration package and modifying the dynamic linker of the target ELF file to specify the path.

[0100] Further, in order to ensure that the program can correctly load the required dependent libraries on the target system, the library search path of the target ELF file at runtime needs to be modified. Specifically, the library search path is pointed to the isolated directory, so that the program will preferentially load dependent libraries from the isolated directory at runtime. At the same time, it is also necessary to verify whether the dynamic linker of the target system is compatible with the dynamic linker of the original system. The dynamic linker is responsible for loading and linking shared libraries at program runtime. If the dynamic linker of the target system is incompatible, the dynamic linker of the original system needs to be copied into the migration package, and the INTERP section of the target ELF file is modified to specify the use of the dynamic linker in the migration package.

[0101] That is, as shown in Figure 3 The runtime path reconstruction of the embodiment mainly adjusts the path configuration 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 at runtime. By modifying the RPATH field of the target ELF file and its dependent libraries to point to the / lib / compat isolated directory, it can be ensured that the program will preferentially load compatible libraries from this directory at runtime, rather than using the libraries in the default path of the target system. The patchelf tool can be used to modify the RPATH field in this embodiment. The dynamic linker is responsible for loading and linking shared libraries at program runtime. Different systems may use different versions of dynamic linkers, so it is necessary to verify whether the dynamic linker of the target system is compatible with the original system. If the dynamic linker of the target system (such as / lib / ld-linux-x86-64.so.2) is incompatible with the original system, the dynamic linker of the original system needs to be copied into the migration package, and the INTERP section of the target ELF file is modified to specify the use of the dynamic linker path in the migration package. For the implicit dependent library path hardcoded in the program, it needs to be redirected to the / lib / compat isolated directory to ensure that these implicit 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 difference between the target system environment and ensure the stable operation of the program in the new system environment.

[0102] Step S206, a migration package deployed to the target system is constructed, and the migration package is adaptively migrated and verified; the migration package includes the target ELF file, the original system dependent libraries in the isolated directory, the dynamic linker of the original system, the user mode ABI shim, and the LD_PRELOAD path hijacking script.

[0103] In an optional embodiment, the step S206 includes:

[0104] The migration function test is performed on the migration package. If migration operation abnormity occurs, problem positioning and analysis are performed through reverse tracking;

[0105] According to the positioning and analysis results, the missing libraries are supplemented to the isolated directory, and the test is cycled until all dependencies are completely matched.

[0106] Further, this step constructs a complete migration package, which includes all necessary components such as the target ELF file, the original system dependent libraries in the isolated directory, the user-mode ABI shim, and the path hijacking script. After the migration package is constructed, self-adaptive migration verification needs to be performed on the target system. This includes running the migrated program and performing comprehensive functional testing to ensure that all functions work normally. If abnormality occurs during testing, the root cause of the problem needs to be located through reverse tracking technology. According to the analysis results, the missing libraries are supplemented to the isolated directory, and the testing process is repeated until all dependencies are completely matched and the program can run stably.

[0107] That is, as shown in Figure 3 The self-adaptive migration verification of the present 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 self-adaptive migration verification. After the migration package is deployed to the target system, comprehensive functional testing needs to be performed. The purpose of functional testing is to verify whether the program can run normally on the target system and whether all functions work as expected. This step can find problems that may occur during migration, such as symbol missing or loading error. During functional testing, various running abnormities may occur. At this time, reverse tracking combined with dynamic instrumentation technology is needed 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 runtime. Reverse tracking is to backtrack the program execution path 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. Dynamic libraries are usually loaded during program runtime, so it is necessary to ensure that the paths of these implicit dependent libraries correctly point to the / lib / compat isolated directory to avoid loading errors. Once missing symbols or dependent libraries are found, these libraries need to be supplemented to the / lib / compat isolated directory and retested. This process may need to be iterated several 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 functional tests and proves that all dependencies have been correctly matched, the program (i.e. the target ELF file) can run stably on the target system, the migration process is completed. Self-adaptive migration verification ensures the compatibility and stability of the program in the new system environment through the above systematic method.

[0108] The embodiment covers multi-dimensional scenarios such as system calls, explicit dependent libraries, and implicit dynamically loaded libraries through a layered compatibility verification mechanism, and combines path isolation and symbol-level ABI checking to ensure cross-system compatibility while avoiding pollution of the target environment. The embodiment does not need to migrate the entire operating system, but only migrates the software and its dependent libraries, reducing the difficulty of migration. And without obtaining the source code or modifying the host environment, the adaptation is achieved through binary reverse analysis and runtime interception, solving the migration problem of closed-source software. Compared with container technology, the isolation mechanism avoids the functional limitation of resource-coupled software.

[0109] In summary, the embodiment can comprehensively identify all dependent libraries required for program execution, including explicit and implicit dependencies, by recursively traversing the dependency tree and statically analyzing the hardcoded paths of implicit dependent libraries, effectively avoiding migration failures caused by missing dependent libraries. At the same time, by extracting the actual call symbol list of the dependent library and comparing it with the target system, the problem of symbol mismatch or missing can be accurately identified, and appropriate solutions can be taken to improve the compatibility and running stability of the program on the target system.

[0110] The embodiment performs shim adaptation processing on incompatible system calls to solve problems such as system call interface changes between different system versions, so that the program can perform system calls normally on the target system and adapt to different system environments. If the target system's dynamic linker is incompatible with the original system, the dynamic linker of the original system is copied to the migration package and the specified path is modified to ensure correct dynamic linking and loading of the program, further improving system compatibility.

[0111] The entire migration method of the embodiment covers system call detection, dependency tree analysis, symbol verification, and runtime path reconstruction, forming a complete and automated migration process, reducing manual operations and interventions, and improving migration efficiency and accuracy. The incompatible dependent libraries of the original system are collected into an isolated directory, and path hijacking logic is injected into the implicit dependent libraries to make the program load compatible libraries first during runtime, avoiding tedious library conflict troubleshooting and speeding up the migration process.

[0112] In the embodiment, a Linux executable program migration device is also provided, which is used to implement the above-mentioned embodiments and preferred embodiments, and details are not repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware implementation is also possible and contemplated.

[0113] The embodiment provides a Linux executable program migration device, as shown in Figure 4 , comprising:

[0114] The system call compatibility detection module 401 is configured to obtain a target ELF file to be migrated, and perform compatibility detection on system calls used by the target ELF file and a target system, and perform shim adaptation processing on the system calls that are incompatible.

[0115] The dependency tree full analysis module 402 is configured to perform dependency tree full analysis on the target ELF file after compatibility detection or shim adaptation processing, and identify dependency libraries required for running the target ELF file.

[0116] The symbol-level compatibility verification module 403 is configured to extract actual call symbol lists of the dependency libraries, and compare the actual call symbol lists with symbols of corresponding libraries on the target system, and collect original system dependency libraries that are incompatible with the target system to an isolated directory.

[0117] The runtime path reconstruction module 404 is configured to modify a library search path and a dynamic linker at runtime of the target ELF file, so as to preferentially load the original system dependency libraries in the isolated directory, and replace a dynamic linker that is incompatible with the original system.

[0118] The adaptive migration verification module 405 is configured to construct 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 dependency libraries in the isolated directory, a user-mode ABI shim, and a path hijacking script.

[0119] In some optional embodiments, the system call compatibility detection module 401 is further configured to:

[0120] detect whether the target ELF file has a system call, and if the target ELF file has the system call, evaluate compatibility of the system call with the target system;

[0121] for the system call that is incompatible, perform adaptation processing through a user-mode ABI shim, and if the adaptation processing cannot be performed, terminate a migration process of the target ELF file.

[0122] In some optional embodiments, the dependency tree full analysis module 402 is further configured to:

[0123] analyze a dynamic segment and a symbol table of the target ELF file after compatibility detection or shim adaptation processing, so as to recursively traverse each explicit dependency library of the target ELF file;

[0124] extract a hard-coded path of an implicit dependency library through static analysis, and generate an implicit dependency library list;

[0125] based on each explicit dependency library and the implicit dependency library list, construct a complete dependency tree.

[0126] In some optional embodiments, the dependency tree full analysis module 402 is further configured to:

[0127] detect whether there is a target dynamic loading function call in the target ELF file;

[0128] if there is the target dynamic loading function call, extract a hard-coded path called in the target dynamic loading function through static analysis;

[0129] generate an implicit dependency library list based on an implicit dependency library corresponding to the hard-coded path.

[0130] In some optional embodiments, the symbol-level compatibility verification module 403 is further configured to:

[0131] extract actual call symbol lists of the explicit dependency library and the implicit dependency library;

[0132] compare the actual call symbol lists with symbols of corresponding libraries on the target system one by one;

[0133] if the symbols match, mark the corresponding dependency library as a compatible library;

[0134] if the symbols do not match or are missing, mark the corresponding dependency library as an incompatible library;

[0135] collect original system dependency libraries corresponding to the incompatible library to an isolated directory, and inject path hijacking logic into the implicit dependency library in the isolated directory.

[0136] In an optional embodiment, the runtime path reconstruction module 404 is further configured to:

[0137] modify a library search path of the target ELF file at runtime to point to the isolated directory to preferentially load the original system dependency library in the isolated directory;

[0138] verify whether a dynamic linker of the target system is compatible with a dynamic linker of the original system;

[0139] if not compatible, copy the dynamic linker of the original system to the migration package, and modify a dynamic linker specified path of the target ELF file.

[0140] In an optional embodiment, the adaptive migration verification module 405 is further configured to:

[0141] perform migration function testing on the migration package, and if migration running abnormity occurs, perform problem positioning and analysis through reverse tracking;

[0142] according to the positioning and analysis results, supplement missing libraries to the isolated directory, and perform cyclic testing until all dependencies are completely matched.

[0143] Further function description of each module and unit is the same as the corresponding embodiment described above, which will not be repeated here.

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

[0145] The embodiment of the present application also provides a computer device, please refer to Figure 5 , Figure 5 is a structural schematic diagram of a computer device provided by the optional embodiment of the present application, as Figure 5 shown, the computer device comprises one or more processors 10, a memory 20, and an interface for connecting various components, including a high-speed interface and a low-speed interface. Various components are communicatively connected to each other by different buses, and can be installed on a common motherboard or in other ways as needed. The processor can process instructions executed in the computer device, including instructions stored in the memory or on the memory to display graphical information on a GUI on an external input / output device (such as a display device coupled to the interface). In some optional embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memories, if necessary. Similarly, multiple computer devices can be connected, each providing part of the necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Figure 5 In the embodiment, the processor 10 is taken as an example.

[0146] The processor 10 can be a central processor, a network processor or a combination thereof. The processor 10 can further include a hardware chip. The hardware chip can be an application specific integrated circuit, a programmable logic device or a combination thereof. The programmable logic device can be a complex programmable logic device, a field programmable logic gate array, a general array logic or any combination thereof.

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

[0148] The memory 20 can include a program storage area and a data storage area. The program storage area can store an operating system, application programs required for at least one function, etc. The data storage area can store data created by the computer device, etc. In addition, the memory 20 can include a high-speed random access memory, and can also include a non-transitory memory such as at least one disk storage device, a flash memory device, or other non-transitory solid state memory device. In some alternative embodiments, the memory 20 can optionally include memory that is remotely located with respect to the processor 10, and which can be connected to the computer device through a network. Examples of such networks include, but are not limited to, the Internet, an enterprise intranet, a local area network, a mobile communications network, and combinations thereof.

[0149] The memory 20 can include a volatile memory, such as a random access memory, and / or can include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid state memory device. The memory 20 can also include an array of memories of the same kind or of different kinds.

[0150] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0151] The embodiments of the present application also provide a computer readable storage medium, and the method according to the embodiments of the present application can be implemented in hardware, firmware, or as software code that can be recorded in a storage medium or downloaded from a network and stored in a remote storage medium or a non-transitory machine readable storage medium and then stored in a local storage medium, so that the method described herein can be processed by such software using a general purpose computer, a special purpose processor, or programmable or dedicated hardware. 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 disk, etc. Further, the storage medium can also include a combination of the above-mentioned kinds of memories. It can be understood that the computer, the processor, the microprocessor controller, or the 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 method shown in the above embodiments is implemented.

[0152] Part of the present application can be applied as a computer program product, for example, computer program instructions, when executed by a computer, through the operation of the computer, the method and / or technical solutions according to the present application can be called or provided. Those skilled in the art should understand that the form of computer program instructions in computer readable medium includes but is not limited to source file, executable file, installation package file and the like, and accordingly, the way of computer program instructions executed by computer includes but is not limited to: the computer directly executes the instructions, or the computer compiles the instructions and then executes the corresponding compiled program, or the computer reads and executes the instructions, or the computer reads and installs the instructions and then executes the corresponding installed program. Here, the computer readable medium can be any available computer readable storage medium or communication medium accessible to the computer.

[0153] Although the embodiments of the present application are described in conjunction with the drawings, various modifications and changes can be made by those skilled in the art without departing from the spirit and scope of the present application, and such modifications and changes fall within the scope defined.

Claims

1. A migration method of a Linux executable program, characterized by, The method comprises: obtaining a target ELF file to be migrated, and performing compatibility detection on system calls used by the target ELF file and a target system, and performing shim adaptation processing on the system calls incompatible with the target system; performing full dependency tree analysis on the target ELF file after compatibility detection or shim adaptation processing, and identifying dependency libraries required for running the target ELF file; extracting actual call symbol lists of the dependency libraries, and comparing the actual call symbol lists with symbols of corresponding libraries on the target system, and collecting original system dependency libraries incompatible with the target system to an isolated directory; modifying a library search path and a dynamic linker during running of the target ELF file, so as to preferentially load the original system dependency libraries in the isolated directory, and replace a dynamic linker incompatible with the original system; constructing a migration package deployed to the target system, and performing adaptive migration verification on the migration package; the full dependency tree analysis on the target ELF file after compatibility detection or shim adaptation processing, and the identifying of the dependency libraries required for running the target ELF file, comprise: parsing a dynamic segment and a symbol table of the target ELF file after compatibility detection or shim adaptation processing, so as to recursively traverse each explicit dependency library of the target ELF file; extracting a hard-coded path of an implicit dependency library through static analysis, and generating an implicit dependency library list; based on each explicit dependency library and the implicit dependency library list, a complete dependency tree is constructed; the extracting of actual call symbol lists of each dependency library, and the comparing of the actual call symbol lists with symbols of corresponding libraries on the target system, and the collecting of original system dependency libraries incompatible with the target system to an isolated directory, comprise: extracting actual call symbol lists of the explicit dependency libraries and the implicit dependency libraries; the actual call symbol lists are compared with symbols of corresponding libraries on the target system one by one; if the symbols match, the corresponding dependency library is marked as a compatible library; if the symbols do not match or are missing, the corresponding dependency library is marked as an incompatible library; the original system dependency libraries corresponding to the incompatible libraries are collected to the isolated directory, and path hijacking logic is injected into the implicit dependency libraries in the isolated directory.

2. The method of claim 1, wherein, the compatibility detection on system calls used by the target ELF file and the target system, and the shim adaptation processing on the system calls incompatible with the target system, comprise: detecting whether there is a system call in the target ELF file, and if there is a system call, evaluating the compatibility of the system call with the target system; for the system call incompatible with the target system, the system call is adapted through a user-mode ABI shim, and if the adaptation cannot be performed, the migration process of the target ELF file is terminated.

3. The method of claim 1, wherein, the extracting of a hard-coded path of an implicit dependency library through static analysis, and the generating of an implicit dependency library list, comprise: detecting whether there is a target dynamic loading function call in the target ELF file; if there is the target dynamic loading function call, a hard-coded path called in the target dynamic loading function is extracted through static analysis; based on the implicit dependency library corresponding to the hard-coded path, an implicit dependency library list is generated.

4. The method of claim 1, wherein, The modification of the library search path and the dynamic linker of the target ELF file running time is to preferentially load the original system dependent library in the isolated directory and replace the dynamic linker incompatible with the original system, including: The modification of the library search path of the target ELF file running time is to point to the isolated directory to preferentially load the original system dependent library in the isolated directory; Verify whether the dynamic linker of the target system is compatible with the dynamic linker of the original system; If incompatible, copy the dynamic linker of the original system to the migration package, and modify the dynamic linker specified path of the target ELF file.

5. The method according to any one of claims 1 to 4, characterized in that, The adaptive migration verification of the migration package includes: Perform migration function test on the migration package, and if migration running exception occurs, perform problem positioning and analysis through reverse tracking; According to the positioning and analysis results, the missing library is supplemented into the isolated directory, and the cycle test is performed until all dependencies are completely matched.

6. A migration apparatus of a Linux executable program, characterized by comprising: The device includes: A system call compatibility detection module is configured to obtain a target ELF file to be migrated, and perform compatibility detection on system calls used by the target ELF file and a target system, and perform shim adaptation processing on incompatible system calls; the original system is a Linux operating system; and the target system is an operating system based on a Linux kernel; A dependency tree full analysis module is configured to perform dependency tree full analysis on the target ELF file after compatibility detection or shim adaptation processing, and identify dependent libraries required for running the target ELF file; A symbol level compatibility verification module is configured to extract actual call symbol lists of the dependent libraries, and compare the actual call symbol lists with symbols of corresponding libraries on the target system, and collect original system dependent libraries incompatible with the target system to an isolated directory; A runtime path reconstruction module is configured to modify a library search path and a dynamic linker of the target ELF file running time, to preferentially load original system dependent libraries in the isolated directory, and replace dynamic linkers incompatible with the original system; An adaptive migration verification module is configured to construct a migration package deployed to the target system, and perform adaptive migration verification on the migration package; The dependency tree full analysis on the target ELF file after compatibility detection or shim adaptation processing includes: Parsing a dynamic segment and a 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; Extracting a hard-coded path of an implicit dependent library through static analysis, to generate an implicit dependent library list; Based on each explicit dependent library and the implicit dependent library list, a complete dependency tree is constructed; The extraction of actual call symbol lists of the dependent libraries and the comparison of the actual call symbol lists with symbols of corresponding libraries on the target system include: extracting actual call symbol lists of the explicit dependent libraries and the implicit dependent libraries; The actual call symbol lists are compared with symbols of corresponding libraries 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 library corresponding to the incompatible library to an isolation directory, and inject path hijacking logic into the implicit dependent library in the isolation directory.

7. A computer device, comprising: Comprise: A memory and a processor, which are connected in communication with each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the migration method of the Linux executable program in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer instructions for causing a computer to execute the migration method of the Linux executable program in any one of claims 1 to 5.

Images