Cross-architecture elf program execution method and device, terminal and storage medium

Abstract

The application discloses a cross-architecture ELF program execution method and device, a terminal and a storage medium, and belongs to the binary field, and comprises the following steps: modifying the ELF executable file suffix name to be executed, and creating a symbolic link pointing to a cross-architecture program scheduler in an original path; when the program is executed through the symbolic link, the symbolic link path is parsed, the path prefix and the modified suffix name are spliced, and the real path of the modified ELF program file is obtained; the program file and the adaptive architecture information are acquired by using the real path; global and exclusive configuration files are read, parent process environment variables are reserved, final environment variable parameter groups are generated according to the program exclusive items, the architecture items and the global items in priority, and a final command line parameter array is generated; the translator loads the program file according to the adaptive architecture information, acquires corresponding shared library files, and executes the program by using the final parameter groups and the command line array. The transparent takeover and the dynamic isolation of the running environment of the cross-architecture program are realized.

Description

Technical Field

[0001] This invention relates to the field of binary technology, and in particular to a cross-architecture ELF program execution method, apparatus, terminal and storage medium. Background Technology

[0002] As the Linux operating system (such as domestic systems like Kylin OS) ecosystem continues to expand, the demand for running ELF (Executable and Linkable Format) executables with different architectures or bit widths on the same host system is increasing.

[0003] Running i386 (32-bit) applications on an x86_64 architecture, or running x86 / x86_64 applications on non-x86 architectures (such as ARM64, LoongArch), typically requires a translator (such as QEMU-user, Box86, Box64, etc.) to translate instructions and to correctly configure environment variables such as dynamic library search paths (LD_LIBRARY_PATH) for the target program. In this case, the Linux kernel provides the binfmt_misc mechanism, which automatically assigns the matched executable file to the specified translator for execution by registering a magic number or extension for a specific binary format at the kernel level.

[0004] In the process of developing this invention, the inventors discovered the following technical problems: Registering and modifying the binfmt_misc configuration requires system-level root privileges. Its configuration takes effect globally, making it difficult to deploy in containerized or restricted user environments, and it is highly prone to conflicts with other existing configurations in the system. Furthermore, the environment variables associated with this mechanism are globally statically bound, failing to accommodate the specific dynamic library dependencies of different target programs under the same architecture, easily leading to library version conflicts between different programs and poor environment compatibility. Summary of the Invention

[0005] This invention provides a method, apparatus, terminal, and storage medium for executing cross-architecture ELF programs, in order to solve the technical problem in the prior art that it is inconvenient to execute ELF programs of different architectures on the Linux operating system.

[0006] In a first aspect, embodiments of the present invention provide a method for executing cross-architecture ELF programs, including: Scan the specified directory, modify the file extension of the ELF executable file to be executed, and create a symbolic link pointing to the cross-architecture program scheduler in the original path; When a program is executed through the symbolic link, the symbolic link path is obtained by resolving the symbolic link. The program identifier character in the symbolic link path is concatenated with the real path field to obtain the path prefix. The path prefix is ​​then combined with the modified suffix to obtain the real path of the modified ELF program file. Use the real path to obtain the ELF program's files and corresponding adaptation architecture information; Read the global configuration file and the ELF program-specific configuration file, retain all environment variables inherited from the parent process, and merge the environment variables according to the priority order of program-specific items, architecture items, and global items to generate the final environment variable parameter group; Using the information in the global configuration file and the dedicated configuration file, the final command-line parameter array is generated; The translator is determined based on the adaptation architecture information, the ELF program file is loaded using the translator, the corresponding shared library file is obtained from the information in the global configuration file, and the ELF program is executed using the final environment variable parameter group and the final command line parameter array.

[0007] Secondly, embodiments of the present invention also provide a cross-architecture ELF program execution device, comprising: The scanning module is used to scan the specified directory, modify the file extension of the ELF executable file to be executed, and create a symbolic link pointing to the cross-architecture program scheduler in the original path; The parsing module is used to parse the symbolic link to obtain the symbolic link path when the program is executed through the symbolic link; The concatenation module is used to concatenate the program identifier characters in the symbolic link path with the real path field to obtain a path prefix, and combine the path prefix with the modified suffix to obtain the real path of the modified ELF program file. The acquisition module is used to obtain the files of the ELF program and the corresponding adaptation architecture information using the real path; The reading module is used to read the global configuration file and the configuration file specific to the ELF program, retain all environment variables inherited from the parent process, and merge the environment variables according to the priority order of program-specific items, architecture items and global items to generate the final environment variable parameter group; The generation module is used to generate the final command-line parameter array using the information in the global configuration file and the dedicated configuration file; The execution module is used to determine the translator based on the adaptation architecture information, load the ELF program file using the translator, obtain the corresponding shared library file from the information in the global configuration file, and execute the ELF program using the final environment variable parameter group and the final command line parameter array.

[0008] Thirdly, embodiments of the present invention also provide a terminal, including: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the cross-architecture ELF program execution method as described in any of the above embodiments.

[0009] Fourthly, embodiments of the present invention also provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to execute the cross-architecture ELF program execution method provided in the above embodiments.

[0010] The cross-architecture ELF program execution method, apparatus, terminal, and storage medium provided in this invention scan a specified directory, modify the file extension of the ELF executable file to be executed, and create a symbolic link pointing to the cross-architecture program scheduler in the original path; when executing the program through the symbolic link, the symbolic link path is obtained by parsing the symbolic link; the program identifier character in the symbolic link path is concatenated with the real path field to obtain a path prefix, and the modified real path of the ELF program file is obtained by combining the path prefix with the modified file extension; the ELF program file and corresponding adaptation architecture information are obtained using the real path; the global configuration file and the dedicated configuration file for the ELF program are read, all environment variables inherited from the parent process are retained, and the environment variables are merged according to the priority order of program-specific items, architecture items, and global items to generate a final environment variable parameter group; the information in the global configuration file and the dedicated configuration file is used to generate a final command line parameter array; a translator is determined according to the adaptation architecture information, the ELF program file is loaded using the translator, the corresponding shared library file is obtained from the information in the global configuration file, and the ELF program is executed using the final environment variable parameter group and the final command line parameter array. Without needing to call kernel-mode interfaces, deployment can be completed in any specified directory by ordinary user privileges. When a user calls the program using the original command name, although the kernel hands over the execution flow to the scheduler, the scheduler can reverse engineer the actual physical path of the intercepted program by parsing its own path when it was called. At runtime, the scheduler reverse-engineers the symbolic link path to restore the actual physical path and architecture identity of the intercepted program, breaking the coarse-grained identification limitations of existing technologies. Based on this, it triggers a dynamic merging mechanism of program-specific, architecture-global three-level configurations, achieving fine-grained environment variable isolation at the program level and completely resolving dynamic library version conflicts when multiple programs coexist. All configurations are executed in a closed loop within the scheduler, without polluting the host system environment, significantly improving the compatibility and availability of cross-architecture programs in complex environments such as containerization and restricted users. Attached Figure Description

[0011] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a flowchart illustrating the cross-architecture ELF program execution method provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart illustrating the cross-architecture ELF program execution method provided in Embodiment 2 of the present invention; Figure 3 This is a schematic diagram of the cross-architecture ELF program execution device provided in Embodiment 3 of the present invention; Figure 4 This is a schematic diagram of the terminal provided in Embodiment 4 of the present invention. Detailed Implementation

[0012] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0013] Example 1 Figure 1 This is a flowchart of a cross-architecture ELF program execution method provided in Embodiment 1 of the present invention. This embodiment is applicable to the execution of ELF programs of different architectures in a Linux system. The method can be executed by a cross-architecture ELF program execution device, and specifically includes the following steps: Step 110: Scan the specified directory, modify the file extension of the ELF executable to be executed, and create a symbolic link pointing to the cross-architecture program scheduler in the original path.

[0014] In this embodiment, to achieve transparent takeover of cross-architecture programs without requiring system-level root privileges or modifying kernel configuration, user-mode file system operations can be used to hijack execution during the deployment phase.

[0015] The system scans a specified directory. This specified directory can be the system's default application directory or a user-defined directory for cross-architecture applications. During the scan, the system can identify the ELF executable file to be executed by reading the magic number in the file header or by checking the file's execution permissions.

[0016] For ELF executable files identified during scanning, the system modifies their file extensions. For example, an ELF executable file originally named target_app is renamed to target_app.real. This appended real file extension (e.g., .real) explicitly identifies the file as the original, real program file being managed by the scheduler, distinguishing it from subsequently created symbolic links in the file system and preventing name conflicts.

[0017] In the original path where the ELF executable file is located, create a symbolic link pointing to the cross-architecture program scheduler, and the name of this symbolic link is the same as the original filename of the ELF executable file. For example, create a symbolic link named target_app in the original path, pointing to a pre-deployed cross-architecture program scheduler, such as the scheduler program located at / usr / bin / cross-dispatcher.

[0018] Using the above method, the ELF executable file in the original path has actually become a symbolic link pointing to cross-dispatcher, while the actual ELF executable program is safely renamed and saved in the same directory.

[0019] Step 120: When executing the program through the symbolic link, the symbolic link is parsed to obtain the symbolic link path.

[0020] When a user enters the original name of the ELF executable file to be executed in the terminal or script (when attempting to run the program), the Linux kernel's virtual file system layer resolves that path. Since the `target_app` path was replaced with a symbolic link pointing to the cross-architecture program scheduler during deployment, the kernel does not directly load the actual ELF program file. Instead, it automatically follows the symbolic link's pointer, loads the cross-architecture program scheduler into memory, and starts it as the current process. After being awakened and started, the cross-architecture program scheduler needs to understand the execution context, i.e., determine which application is currently invoking it. To do this, the scheduler resolves the symbolic link. In the Linux operating system, each running process has a symbolic link in the ` / proc` file system pointing to its own executable file path. Normally, the symbolic link points to the actual binary file path loaded by the process. However, since the scheduler in this embodiment is indirectly awakened through a user-created symbolic link, the path recorded in ` / proc / self / exe` is not the scheduler's own installation path, but rather the absolute path of the symbolic link that triggered this call in the file system.

[0021] Therefore, the scheduler can extract the absolute path of the symbolic link by reading the ` / proc / self / exe` information of the current process. Using this method, the scheduler can obtain the path of the symbolic link.

[0022] Step 130: Concatenate the program identifier character in the symbolic link path with the real path field to obtain the path prefix. Combine the path prefix with the modified suffix to obtain the real path of the modified ELF program file.

[0023] For example, concatenating the program identifier character in the symbolic link path with the real path field to obtain the path prefix may include: parsing the symbolic link path, extracting the link file name as the ELF program identifier character, and extracting the directory path where the symbolic link path is located as the real path field; concatenating the directory path with the link file name to obtain the path prefix.

[0024] The scheduler parses the symbolic link path, extracting the link filename as the program identifier and the directory path containing the symbolic link as the actual path field. Taking the symbolic link path ` / opt / cross_apps / target_app` as an example, the scheduler uses string processing or a system path splitting function to extract the link filename `target_app` from the last level of the symbolic link path, using it as the program identifier to uniquely identify the program body currently being executed. Simultaneously, it extracts the directory portion ` / opt / cross_apps / ` containing the path, using it as the actual path field to locate the file's physical location in the file system. The scheduler then concatenates the extracted directory path (the actual path field) with the program identifier (in this embodiment, the actual filename) to obtain a path prefix. In the example above, concatenating ` / opt / cross_apps / ` with `target_app` yields the path prefix ` / opt / cross_apps / target_app`. This path prefix represents the complete absolute path of the original ELF executable file before modification.

[0025] The scheduler combines the path prefix with the actual file extension appended during the deployment phase to obtain the real path of the modified ELF program file. Since the actual ELF program files have been uniformly appended with a suffix such as .real during the deployment phase, the scheduler appends .real to the end of the path prefix. In the example above, the final real path of the modified ELF program file is / opt / cross_apps / target_app.real.

[0026] Using the above method, the cross-architecture program scheduler can accurately bypass the symbolic link interception it creates and locate the actual entity ELF program file that needs to be executed across architectures.

[0027] Step 140: Use the real path to obtain the ELF program files and corresponding adaptation architecture information.

[0028] For example, it may include: reading the ei_class field, e_machine field, and ei_data field from the file header of the ELF program; using the e_machine field to determine the architecture type, using the ei_class field to determine the program bit width, and using the ei_data field to determine the program byte order.

[0029] The scheduler reads the program header of the ELF program file based on the actual path. In the ELF (Executable and Linkable Format) file format specification, the beginning of the program header contains an identifier segment that describes the file's basic architectural attributes. In this embodiment, the scheduler focuses on reading the ei_class, e_machine, and ei_data fields within this identifier segment. The scheduler uses the value of the e_machine field to determine the required instruction set architecture type of the ELF program file. For example, if the field value is 0x3E, the architecture type is determined to be x86_64; if it is 0xB7, the architecture type is determined to be AArch64 (ARM64); and if it is 0x102, the architecture type is determined to be LoongArch. This architectural information is used to determine which instruction translator (such as QEMU-x86_64 or Box64) to select subsequently.

[0030] The scheduler uses the value of the `ei_class` field to determine the program's bit width. For example, a value of 1 indicates a 32-bit (ELFCLASS32) program, while a value of 2 indicates a 64-bit (ELFCLASS64) program. This bit width information guides the translator to load the target program in the correct bit-width mode. The scheduler also uses the value of the `ei_data` field to determine the program's byte order. For example, a value of 1 indicates little-endian, while a value of 2 indicates big-endian. This information ensures that the translator processes memory data and instructions in the correct byte order during subsequent operations.

[0031] The parsed architecture type, program bitness, and program byte order are combined to generate the corresponding architecture adaptation information for the ELF program file. This architecture adaptation information accurately describes the underlying runtime environment requirements of the target program, facilitating subsequent precise matching and invocation of the translator.

[0032] Step 150: Read the global configuration file and the ELF program-specific configuration file, retain all environment variables inherited from the parent process, and merge the environment variables according to the priority order of program-specific items, architecture items, and global items to generate the final environment variable parameter group.

[0033] For example, reading the global configuration file and the dedicated configuration file for the ELF program may include: parsing the adaptation scope item in the dedicated configuration file, determining whether the applicable program scope limited by the adaptation scope item includes the file of the currently executed ELF program; if it includes, extracting the information in the dedicated configuration file to participate in generating the final environment variable parameter group and the final command line parameter array; if it does not include, skipping the dedicated configuration file.

[0034] Accordingly, merging environment variables according to the priority order of program-specific items, architecture items, and global items may include: determining whether there are environment variables with the same name in the program-specific items, architecture items, and global items; if there are environment variables with the same name, retaining the environment variable values ​​in the high-priority items and discarding the environment variable values ​​with the same name in the low-priority items; if there are no conflicts, summarizing and merging the environment variables in each item.

[0035] After obtaining the architecture adaptation information of the ELF program file, the cross-architecture program scheduler begins to build the environment context required for the target program to run. To completely resolve the dynamic library version conflict problem caused by the global static binding of environment variables in existing technologies, in this embodiment, the scheduler retains all environment variables inherited from the parent process. When a user triggers an execution command in a terminal or script, the parent process inherits its own environment variables (such as PATH, USER, etc.) to the scheduler process. The scheduler retains the environment variables inherited from the parent process as a basic environment layer to ensure that the target program can perceive the basic system runtime context. The scheduler reads a pre-set global configuration file and a dedicated configuration file for the ELF program. The global configuration file contains global items applicable to all cross-architecture programs; the dedicated configuration file contains program-specific items for a specific program. When reading the dedicated configuration file, to prevent configurations of irrelevant programs from interfering with the current execution flow, the scheduler performs the following filtering mechanism: parses the adaptation scope item (e.g., the files= field in the configuration file) in the dedicated configuration file, and determines whether the applicable program scope limited by the adaptation scope item includes the file of the currently executed ELF program (e.g., determining whether the actual path or program identifier character of the current program is in the files= list). If the configuration file is included, it is confirmed that the dedicated configuration file is effective for the current program, and its information, namely the program-specific items, is extracted to participate in the subsequent generation of the final environment variable parameter set and the final command-line parameter array; if it is not included, the dedicated configuration file is skipped. In addition, the scheduler also extracts architecture items applicable to the current architecture based on the previously obtained adaptation architecture information.

[0036] After obtaining the parent process environment variables, global items, architecture items, and program-specific items, the scheduler merges the environment variables according to the priority order of program-specific items, architecture items, and global items. This priority order can be: program-specific items have the highest priority, followed by architecture items, and then global items have the lowest priority. The parent process inherited variables serve as the basic information. For example, the merging rules are as follows: The scheduler checks one by one whether there are environment variables with the same name in the program-specific items, architecture items, and global items (including parent process variables). If there are environment variables with the same name (for example, all three items—global items, architecture items, and program-specific items—defin LD_LIBRARY_PATH), the environment variable value in the highest priority item is retained, and the values ​​of environment variables with the same name in lower priority items are discarded; if there are no name conflicts, the environment variables in each item are summarized and merged.

[0037] Through the aforementioned filtering and three-level priority merging mechanism, the scheduler ultimately generates a final set of environment variable parameters that is compatible with the host's basic environment, meets specific architectural requirements, and aligns with the current program's personalized dependencies. This merging process is dynamically generated within the scheduler, without modifying the system's global static environment, effectively avoiding library version conflicts between different target programs under the same architecture, and achieving fine-grained environment isolation at the program level.

[0038] Step 160: Using the information in the global configuration file and the dedicated configuration file, generate the final command-line parameter array.

[0039] The scheduler obtains the raw command-line arguments of the current process. When a user executes a command such as target_app-cconfig.ini in the terminal, the scheduler process receives the raw argument vector, such as the first argument argv[0], which is usually the symbolic link name target_app that triggers the execution, and the subsequent arguments are -c and config.ini passed by the user. The scheduler retains these raw arguments that reflect the user's true execution intent for later use in passing to the target program. The scheduler extracts predefined additional parameter information from the global configuration file and the dedicated configuration file. The global configuration file can be configured with general translator parameters applicable to all similar cross-architecture programs; while the dedicated configuration file can be configured with special additional parameters for specific programs (e.g., the configuration item extra_args=--no-runtime-config, used to hide certain runtime checks within the specific program when it is run). The scheduler concatenates the extracted configuration information with the raw command-line arguments in an ordered manner according to a predetermined assembly rule to generate the final command-line argument array. Optionally, the array is constructed in the following order: Translator execution path: As the first element of the array, such as the new argv[0], for example / usr / bin / qemu-x86_64, it points to the translator entity determined according to the adaptation architecture information; Translator control parameters: Parameters extracted from the global configuration file and the dedicated configuration file that need to be passed to the translator itself (such as -L / opt / x86_libs mentioned above). The actual path of the target program: the actual path of the modified ELF program file obtained from the aforementioned restoration (e.g., / opt / cross_apps / target_app.real), which is the target entity that the translator needs to load; Target program execution parameters: all parameters in the original command line parameters input by the user except the original argv[0] (such as -cconfig.ini mentioned above), and additional parameters extracted from the dedicated configuration file that need to be injected into the target program itself.

[0040] The scheduler writes the above elements sequentially into a contiguous string array and appends a null pointer to the end as an end marker, thus generating the complete final command-line argument array.

[0041] Using the above method, the scheduler can cleverly inject the underlying control parameters required by the translator and the customized running parameters required by specific programs into the execution flow without modifying the user's original input habits.

[0042] Step 170: Determine the translator based on the adaptation architecture information, load the ELF program file using the translator, obtain the corresponding shared library file from the information in the global configuration file, and execute the ELF program using the final environment variable parameter group and the final command line parameter array.

[0043] The scheduler determines the corresponding instruction translator based on the previously parsed adaptation architecture information. Since the global configuration file maintains a pre-maintained mapping table of architecture type, program bitness, and translator execution path, the scheduler searches this table based on the architecture type and program bitness from the adaptation architecture information to locate the absolute path of the translator entity capable of simulating the target architecture's instruction set.

[0044] Because cross-architecture programs must link to shared library files of the target architecture version at runtime—for example, an x86_64 architecture program needs to link to x86_64 versions of dynamic libraries such as libc.so—the scheduler further obtains the corresponding shared library file paths from the information in the global configuration file. The global configuration file records the root directories of shared libraries for each architecture, for example, the configuration item lib_path_x86_64= / opt / cross_libs / x86_64. The scheduler extracts this path information and uses it as the base directory for the translator to search for dynamic link libraries. It should be noted that the shared library file paths are usually injected into the LD_LIBRARY_PATH variable in the final environment variable parameter group according to priority rules during the merging phase described above.

[0045] The scheduler loads the ELF program file using the translator and executes the ELF program using the final environment variable parameter set and the final command-line argument array. For example, the scheduler replaces the execution image of the current process with the translator by calling the operating system's process execution interface, such as the execve system call. When calling this interface, the scheduler passes three core parameters: the translator path, the final command-line argument array, and the final environment variable parameter set.

[0046] Through the call to the execve interface, the cross-architecture program scheduler completes the scheduling, and process control is formally transferred to the translator. After being awakened, the translator reads and parses the ELF program file pointed to by the real path according to the guidance of the final command-line parameter array, translates its heterogeneous instruction set into native instructions executable by the host machine, and begins to execute the ELF program in the environment context provided by the final environment variable parameter group.

[0047] This embodiment scans a specified directory, modifies the file extension of the ELF executable file to be executed, and creates a symbolic link pointing to the cross-architecture program scheduler in the original path. When the program is executed through the symbolic link, the symbolic link path is obtained by parsing the symbolic link. The program identifier character in the symbolic link path is concatenated with the real path field to obtain the path prefix. Combined with the path prefix and the modified file extension, the real path of the modified ELF program file is obtained. The real path is used to obtain the ELF program file and the corresponding adaptation architecture information. The global configuration file and the dedicated configuration file for the ELF program are read, all environment variables inherited from the parent process are retained, and the environment variables are merged according to the priority order of program-specific items, architecture items, and global items to generate the final environment variable parameter group. The information in the global configuration file and the dedicated configuration file is used to generate the final command line parameter array. The translator is determined according to the adaptation architecture information, the ELF program file is loaded using the translator, the corresponding shared library file is obtained from the information in the global configuration file, and the ELF program is executed using the final environment variable parameter group and the final command line parameter array. Without needing to call kernel-mode interfaces, deployment can be completed in any specified directory by ordinary user privileges. When a user calls the program using the original command name, although the kernel hands over the execution flow to the scheduler, the scheduler can reverse engineer the actual physical path of the intercepted program by parsing its own path when it was called. At runtime, the scheduler reverse-engineers the symbolic link path to restore the actual physical path and architecture identity of the intercepted program, breaking the coarse-grained identification limitations of existing technologies. Based on this, it triggers a dynamic merging mechanism of program-specific, architecture-global three-level configurations, achieving fine-grained environment variable isolation at the program level and completely resolving dynamic library version conflicts when multiple programs coexist. All configurations are executed in a closed loop within the scheduler, without polluting the host system environment, significantly improving the compatibility and availability of cross-architecture programs in complex environments such as containerization and restricted users.

[0048] Example 2 Figure 2This is a flowchart illustrating the cross-architecture ELF program execution method provided in Embodiment 2 of the present invention. This embodiment is an optimization based on the above embodiment. The file extension of the ELF executable file to be executed is modified, and a symbolic link pointing to the cross-architecture program scheduler is created in the original path. Specifically, the optimization is as follows: the ELF executable file is moved to a temporary backup file; the temporary backup file is renamed by appending a suffix indicating the real file attributes to the original file name to form a modified ELF program file; a temporary symbolic link named after the original file name is created in the original path, and the temporary symbolic link is renamed to a target symbolic link pointing to the cross-architecture program scheduler.

[0049] See Figure 2 The cross-architecture ELF program execution method includes: Step 210: Scan the specified directory, move the ELF executable file to a temporary backup file, and rename the temporary backup file by appending a suffix indicating the real file attributes to the original file name, thus forming the modified ELF program file.

[0050] To avoid execution failure or file status abnormalities caused by another process calling the program at the exact moment the filename is modified, this embodiment first moves the identified ELF executable file to a temporary backup file in the same directory. For example, the system moves or renames the original file / opt / cross_apps / target_app to a hidden temporary file / opt / cross_apps / .target_app.tmp in the same directory. This step temporarily isolates the original file in the directory entry, freeing up the space occupied by the original filename target_app. The temporary backup file is then renamed by appending a suffix indicating the real file attributes to the original filename, forming the modified ELF program file. The system renames the temporary backup file again, restoring it to the original filename and appending a suffix (e.g., .real) to the end of the original filename to indicate its real file attributes. For example, .target_app.tmp is renamed to / opt / cross_apps / target_app.real.

[0051] After the above operations, the original ELF executable file is safely converted and saved as a modified ELF program file. The suffix added here, indicating the true file attributes, not only strictly distinguishes this actual program entity from any subsequent symbolic links with the same name created in the file system, but also avoids name conflicts.

[0052] Step 220: Under the original path, create a temporary symbolic link named after the original file name, and rename the temporary symbolic link to a target symbolic link pointing to the cross-architecture program scheduler.

[0053] To take over the execution flow of the program, the system needs to create a symbolic link pointing to the cross-architecture program scheduler in the original path. To avoid misreading by other concurrent processes or interruption of the execution flow due to incomplete node allocation during the symbolic link creation process, a temporary symbolic link with a temporary filename is created in the original path. For example, the system creates a temporary symbolic link with a different but related name in the original path (such as the / opt / cross_apps / directory), for example, named .target_app.lnk.tmp. The target of the temporary symbolic link is the pre-deployed cross-architecture program scheduler. Because a temporary filename is used at this stage, external processes cannot access the temporary node through the original command name, thus ensuring the stealth and security of the creation process.

[0054] The temporary symbolic link is renamed to a target symbolic link pointing to the cross-architecture program scheduler. The system atomically changes the name of the temporary symbolic link .target_app.lnk.tmp to the original filename target_app by calling the atomic rename interface of the underlying file system.

[0055] After the creation and renaming operations described above, the original `target_app` path has essentially become a symbolic link pointing to the cross-dispatcher. Because the renaming operation is atomic, the operating system kernel guarantees that throughout the entire operation, the directory entry named `target_app` either points to the original ELF file before the modification or to the newly created symbolic link pointing to the scheduler; there is no inconsistency in between. This ensures that any execution requests for this program can be handled correctly and smoothly during deployment takeover.

[0056] Step 230: When executing the program through the symbolic link, the symbolic link is parsed to obtain the symbolic link path.

[0057] Step 240: Concatenate the program identifier character in the symbolic link path with the real path field to obtain the path prefix. Combine the path prefix with the modified suffix to obtain the real path of the modified ELF program file.

[0058] Step 250: Use the real path to obtain the ELF program's files and corresponding adaptation architecture information, read the global configuration file and the ELF program's dedicated configuration file, retain all environment variables inherited from the parent process, and merge the environment variables according to the priority order of program-specific items, architecture items, and global items to generate the final environment variable parameter group.

[0059] Step 260: Using the information in the global configuration file and the dedicated configuration file, generate the final command-line parameter array, determine the translator according to the adaptation architecture information, load the ELF program file using the translator, obtain the corresponding shared library file from the information in the global configuration file, and execute the ELF program using the final environment variable parameter group and the final command-line parameter array.

[0060] This embodiment optimizes the process by modifying the file extension of the ELF executable file to be executed and creating a symbolic link pointing to the cross-architecture program scheduler in the original path. Specifically, it moves the ELF executable file to a temporary backup file; renames the temporary backup file by appending a suffix indicating the actual file attributes to the original filename, forming the modified ELF program file; and creates a temporary symbolic link named after the original filename in the original path, renaming the temporary symbolic link to the target symbolic link pointing to the cross-architecture program scheduler. Since the renaming operation of the underlying file system is atomic, this ensures that directory entries in the original path can be instantly and seamlessly switched from the original ELF file to a symbolic link pointing to the scheduler, eliminating intermediate inconsistencies and greatly reducing the risk of failure during concurrent execution. It avoids deadlocks or performance bottlenecks caused by read-write locks on files with the same name within the file system, ensuring the universality and stability of the deployment operation across various file systems.

[0061] In a preferred embodiment of this example, the method may further include the following steps: receiving a recovery command, scanning symbolic links in a specified directory; deleting symbolic links pointing to the cross-architecture program scheduler, and removing the suffix of the corresponding modified ELF program file to restore it to the original ELF executable file. In scenarios involving system maintenance or the need to restore the host's native execution environment, the cross-architecture program scheduler receives a recovery command. In response to this recovery command, the system begins a reverse unloading operation to release control over the execution flow of the target program. The system reads each directory entry in the specified directory, identifies the symbolic link files within them, and further reads the target attributes of these symbolic links to filter out all target symbolic links pointing to the cross-architecture program scheduler. For each scanned target symbolic link, it is removed from the directory entry by calling the file system's deletion interface. This operation directly severs the trigger path between the user's execution command and the scheduler, and releases the occupied original filename. After deleting the symbolic link, the system removes the suffix of the corresponding modified ELF program file, restoring it to the original ELF executable file. Using the above recovery process, there is no need to re-download or copy the original program files. It can be completed simply by reversing the file system layer node attributes, achieving efficient and residue-free environment rollback and ensuring that the target program can be executed directly again in the native architecture.

[0062] Example 3 Figure 3 This is a schematic diagram of the cross-architecture ELF program execution device provided in Embodiment 3 of the present invention. See also... Figure 3 The cross-architecture ELF program execution device includes: The scanning module 310 is used to scan the specified directory, modify the file extension of the ELF executable file to be executed, and create a symbolic link pointing to the cross-architecture program scheduler in the original path; The parsing module 320 is used to parse the symbolic link to obtain the symbolic link path when executing a program through the symbolic link; The splicing module 330 is used to splice the program identifier characters in the symbolic link path with the real path field to obtain a path prefix, and combine the path prefix with the modified suffix to obtain the real path of the modified ELF program file. The acquisition module 340 is used to acquire the files of the ELF program and the corresponding adaptation architecture information using the real path; The reading module 350 is used to read the global configuration file and the dedicated configuration file for the ELF program, retain all environment variables inherited from the parent process, and merge the environment variables according to the priority order of program-specific items, architecture items and global items to generate the final environment variable parameter group. The generation module 360 ​​is used to generate the final command-line parameter array using the information in the global configuration file and the dedicated configuration file; The execution module 370 is used to determine a translator based on the adaptation architecture information, load the ELF program file using the translator, obtain the corresponding shared library file from the information in the global configuration file, and execute the ELF program using the final environment variable parameter group and the final command line parameter array.

[0063] The cross-architecture ELF program execution device provided in this embodiment scans a specified directory, modifies the file extension of the ELF executable file to be executed, and creates a symbolic link pointing to the cross-architecture program scheduler in the original path. When executing the program through the symbolic link, the symbolic link is parsed to obtain the symbolic link path. The program identifier character in the symbolic link path is concatenated with the real path field to obtain the path prefix. Combined with the path prefix and the modified file extension, the real path of the modified ELF program file is obtained. The real path is used to obtain the ELF program file and the corresponding adaptation architecture information. The global configuration file and the dedicated configuration file for the ELF program are read. All environment variables inherited from the parent process are retained, and the environment variables are merged according to the priority order of program-specific items, architecture items, and global items to generate the final environment variable parameter group. The information in the global configuration file and the dedicated configuration file is used to generate the final command line parameter array. The translator is determined according to the adaptation architecture information. The translator is used to load the ELF program file, obtain the corresponding shared library file from the information in the global configuration file, and execute the ELF program using the final environment variable parameter group and the final command line parameter array. Without needing to call kernel-mode interfaces, deployment can be completed in any specified directory by ordinary user privileges. When a user calls the program using the original command name, although the kernel hands over the execution flow to the scheduler, the scheduler can reverse engineer the actual physical path of the intercepted program by parsing its own path when it was called. At runtime, the scheduler reverse-engineers the symbolic link path to restore the actual physical path and architecture identity of the intercepted program, breaking the coarse-grained identification limitations of existing technologies. Based on this, it triggers a dynamic merging mechanism of program-specific, architecture-global three-level configurations, achieving fine-grained environment variable isolation at the program level and completely resolving dynamic library version conflicts when multiple programs coexist. All configurations are executed in a closed loop within the scheduler, without polluting the host system environment, significantly improving the compatibility and availability of cross-architecture programs in complex environments such as containerization and restricted users.

[0064] Based on the above embodiments, the scanning module includes: The moving unit is used to move the ELF executable file as a temporary backup file; The append unit is used to rename the temporary backup file by appending a suffix indicating the true file attributes to the original file name, thereby forming a modified ELF program file; The renaming unit is used to create a temporary symbolic link named after the original file name in the original path, and rename the temporary symbolic link to a target symbolic link pointing to the cross-architecture program scheduler.

[0065] Based on the above embodiments, the splicing module includes: The parsing unit is used to parse the symbolic link path, extract the link file name as the ELF program identifier character, and extract the directory path where the symbolic link path is located as the real path field. The concatenation unit is used to concatenate the directory path with the link file name to obtain the path prefix.

[0066] Based on the above embodiments, the acquisition module includes: The field reading unit is used to read the ei_class field, e_machine field, and ei_data field from the file header of the ELF program; The determining unit is used to determine the architecture type using the e_machine field, the program bit length using the ei_class field, and the program byte order using the ei_data field.

[0067] Based on the above embodiments, the reading module includes: The judgment unit is used to parse the adaptation scope item in the dedicated configuration file and determine whether the applicable program scope limited by the adaptation scope item includes the file of the currently executed ELF program; The extraction unit is used to extract information from the dedicated configuration file if it contains the information, and to use it to generate the final environment variable parameter set and the final command line parameter array; if it does not contain the information, the dedicated configuration file is skipped.

[0068] Based on the above embodiments, the reading module further includes: The same-name variable judgment unit is used to determine whether there is an environment variable with the same name in the ELF program-specific item and the architecture item and global item; The merge unit is used to retain the environment variable values ​​in the higher priority items and discard the environment variable values ​​in the lower priority items if there are environment variables with the same name; if there are no conflicts, the environment variables in each item are summarized and merged.

[0069] Based on the above embodiments, the device further includes: The receiving module is used to receive recovery instructions and scan symbolic links in a specified directory. The deletion module is used to delete symbolic links pointing to the cross-architecture program scheduler and remove the suffix of the corresponding modified ELF program file, restoring it to the original ELF executable file.

[0070] The cross-architecture ELF program execution device provided in the embodiments of the present invention can execute the cross-architecture ELF program execution method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0071] Example 4 Figure 4 This is a schematic diagram of the structure of a terminal provided in Embodiment 4 of the present invention. Figure 4 A block diagram is shown of an exemplary terminal 12 suitable for implementing embodiments of the present invention. Figure 4 The terminal 12 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0072] like Figure 4 As shown, terminal 12 is presented in the form of a general-purpose computing terminal. The components of terminal 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processing unit 16).

[0073] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0074] Terminal 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by terminal 12, including volatile and non-volatile media, removable and non-removable media.

[0075] System memory 28 may include computer system readable media in the form of volatile memory, such as RAM 30 and / or cache 32. Terminal 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media ( Figure 4 Not shown; usually referred to as a "hard drive"). Although Figure 4 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. System memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0076] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28. Such program modules 42 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.

[0077] Terminal 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing terminal, display 24, etc.), and with one or more terminals that enable a user to interact with terminal 12, and / or with any terminal (e.g., network card, modem, etc.) that enables terminal 12 to communicate with one or more other computing terminals. This communication can be performed via I / O interface 22. Furthermore, terminal 12 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 20. As shown, network adapter 20 communicates with other modules of terminal 12 via bus 18. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with terminal 12, including but not limited to: microcode, terminal drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0078] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing the cross-architecture ELF program execution method provided in the embodiments of the present invention.

[0079] Example 5 Embodiment 5 of the present invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to execute the cross-architecture ELF program execution method as described in any of the above embodiments.

[0080] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0081] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0082] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including, but not limited to, wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0083] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or terminal. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0084] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A method for executing cross-architecture ELF programs, characterized in that, include: Scan the specified directory, modify the file extension of the ELF executable file to be executed, and create a symbolic link pointing to the cross-architecture program scheduler in the original path; When a program is executed through the symbolic link, the symbolic link path is obtained by resolving the symbolic link. The program identifier character in the symbolic link path is concatenated with the real path field to obtain the path prefix. The path prefix is ​​then combined with the modified suffix to obtain the real path of the modified ELF program file. Use the real path to obtain the ELF program's files and corresponding adaptation architecture information; Read the global configuration file and the ELF program-specific configuration file, retain all environment variables inherited from the parent process, and merge the environment variables according to the priority order of program-specific items, architecture items, and global items to generate the final environment variable parameter group; Using the information in the global configuration file and the dedicated configuration file, the final command-line parameter array is generated; The translator is determined based on the adaptation architecture information, the ELF program file is loaded using the translator, the corresponding shared library file is obtained from the information in the global configuration file, and the ELF program is executed using the final environment variable parameter group and the final command line parameter array.

2. The method according to claim 1, characterized in that, Modifying the file extension of the ELF executable file to be executed and creating a symbolic link pointing to the cross-architecture program scheduler in the original path includes: Move the ELF executable file to a temporary backup file; The temporary backup file is renamed by appending a suffix indicating the actual file attributes to the original filename, thus creating a modified ELF program file; In the original path, create a temporary symbolic link named after the original file name, and rename the temporary symbolic link to a target symbolic link pointing to the cross-architecture program scheduler.

3. The method according to claim 1, characterized in that, The step of concatenating the program identifier characters in the symbolic link path with the actual path field to obtain the path prefix includes: Parse the symbolic link path, extract the link file name as the ELF program identifier character, and extract the directory path where the symbolic link path is located as the real path field; The path prefix is ​​obtained by concatenating the directory path with the link file name.

4. The method according to claim 1, characterized in that, The step of obtaining the ELF program's files and corresponding adaptation architecture information using the real path includes: Read the ei_class, e_machine, and ei_data fields from the file header of the ELF program; The architecture type is determined using the e_machine field, the program bit width is determined using the ei_class field, and the program byte order is determined using the ei_data field.

5. The method according to claim 1, characterized in that, The reading of the global configuration file and the ELF program-specific configuration file includes: The adaptation scope item is parsed in the dedicated configuration file to determine whether the applicable program scope limited by the adaptation scope item includes the file of the currently executed ELF program; If the configuration file is included, the information in the configuration file is extracted to participate in the generation of the final environment variable parameter set and the final command line parameter array; if it is not included, the configuration file is skipped.

6. The method according to claim 1, characterized in that, The merging of environment variables according to the priority order of program-specific items, architecture items, and global items includes: Determine whether there is an environment variable with the same name in the ELF program-specific item, the architecture item, and the global item; If environment variables with the same name exist, the values ​​of the environment variables in the higher priority items are retained, while the values ​​of the environment variables with the same name in the lower priority items are discarded; if there are no name conflicts, the environment variables in each item are summarized and merged.

7. The method according to claim 1, characterized in that, The method further includes: Receive recovery instructions and scan for symbolic links in the specified directory; Delete the symbolic link pointing to the cross-architecture program scheduler and remove the suffix from the corresponding modified ELF program file to restore it to the original ELF executable file.

8. A cross-architecture ELF program execution device, characterized in that, include: The scanning module is used to scan the specified directory, modify the file extension of the ELF executable file to be executed, and create a symbolic link pointing to the cross-architecture program scheduler in the original path; The parsing module is used to parse the symbolic link to obtain the symbolic link path when the program is executed through the symbolic link; The concatenation module is used to concatenate the program identifier characters in the symbolic link path with the real path field to obtain a path prefix, and combine the path prefix with the modified suffix to obtain the real path of the modified ELF program file. The acquisition module is used to obtain the files of the ELF program and the corresponding adaptation architecture information using the real path; The reading module is used to read the global configuration file and the configuration file specific to the ELF program, retain all environment variables inherited from the parent process, and merge the environment variables according to the priority order of program-specific items, architecture items and global items to generate the final environment variable parameter group; The generation module is used to generate the final command-line parameter array using the information in the global configuration file and the dedicated configuration file; The execution module is used to determine the translator based on the adaptation architecture information, load the ELF program file using the translator, obtain the corresponding shared library file from the information in the global configuration file, and execute the ELF program using the final environment variable parameter group and the final command line parameter array.

9. A terminal, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the cross-architecture ELF program execution method as described in any one of claims 1-7.

10. A storage medium containing computer-executable instructions, characterized in that, The computer-executable instructions, when executed by a computer processor, are used to perform the cross-architecture ELF program execution method as described in any one of claims 1-7.

Images