Method and device for evaluating compatibility of system calling interface in application software

Abstract

The invention provides a compatibility evaluation method and device for a system calling interface in application software, and the method comprises the steps: S1, analyzing a kernel system calling interface of an operating system before and after the application software is migrated, and obtaining a system calling difference data set; s2, analyzing an application software system call interface to obtain a system call number list; and S3, analyzing the system calling compatibility of the application software based on the system calling difference data set and the system calling number list. According to the method, source codes do not need to be provided, a program does not need to be operated, system calling compatibility analysis is directly carried out on the binary file of the application software, and the problem that compatibility coverage is incomplete due to the fact that a kernel layer lacks an evaluation method in an existing application software compatibility evaluation scheme in the market is solved.

Description

Technical Field

[0001] The invention belongs to the field of information technology, and in particular relates to a method and a device for evaluating the compatibility of a system call interface in application software. Background Art

[0002] As one of the most widely used operating systems, Linux has already penetrated into all walks of life. With the development of Linux technology, when the old system cannot meet the needs of security and business continuity, it will enter the EOL stage of the operating system life cycle. However, the life cycle of application software will not end with the end of the Linux operating system. At this time, a systematic compatibility assessment tool is needed to ensure the migration of application software.

[0003] The existing application software compatibility assessment solutions in the market mainly check the compatibility of the application software's dependent libraries and the ABI (Application Binary Interface) interfaces contained in the dependent libraries.

[0004] The existing application software compatibility assessment solutions on the market have the following problems: 1. Application software compatibility analysis relies on source code. However, due to copyright, history, technology and other factors, many software cannot provide source code for compatibility checking. In addition, when the application software coding cannot be mastered, only the upper-level dependency is considered while the kernel-level system call dependency is ignored, resulting in incomplete coverage of compatibility checking.

[0005] 2. System call compatibility check requires the program to run dynamically to capture system calls. This method requires starting the program, and due to the various functions of the program, it is impossible to ensure that the program is fully covered; the program running at the same time will pollute the environment of the application software. The application software itself runs in the production environment, and there is a lot of production data. Unsafe operations may cause data loss or damage. Summary of the invention

[0006] The purpose of the present invention is to provide a method and device for evaluating the compatibility of system call interfaces in application software. It does not require providing source code or running programs, and directly performs system call compatibility analysis on application software binary files, thereby solving the problem of incomplete compatibility coverage caused by the lack of evaluation methods at the kernel level in existing application software compatibility evaluation solutions on the market.

[0007] Due to the coding habits of developers and the purpose of application software, applications such as C, C++, ASM, etc. that can be compiled into ELF (Executable and Linkable Format) files will directly interact with the system calls of the kernel layer as needed. When such programs are compiled into ELF (Executable and Linkable Format) files, the system call numbers will be directly hard-coded in the ELF files. Since the definition of system calls will not be modified in a major kernel version, when migrating application software across major versions, it is necessary to consider whether the definition of system calls has changed.

[0008] The definition of a system call contains four elements: the system call number, the function name corresponding to the system call number, the parameter list, and the return value. Any change in the system call number, function name, number and type of parameters in the parameter list, and the type of the return value will affect compatibility.

[0009] The main purpose of system call compatibility assessment is to analyze the system calls contained in binary applications through disassembly technology, check whether the application software contains system calls that directly interact with the kernel, and whether the definitions of these system calls have changed in the system kernel before and after the application software migration. If there is a change, and there are system calls used by the application software, after the application software migration, the incompatibility of the system calls will cause the application software to execute incorrectly or unpredictable operation risks.

[0010] Based on the above principle, the technical solution of the present invention is as follows: A method for evaluating the compatibility of a system call interface in application software, comprising: S1. Analyze the kernel system call interface of the operating system before and after the application software migration to obtain a system call difference data set; S2, parsing the application software system call interface to obtain a system call number list; S3. Analyze the compatibility of application software system calls based on the system call difference data set and the system call number list.

[0011] Furthermore, step S1 specifically includes: S101, obtaining a kernel-devel software package of a corresponding kernel according to the versions and system architecture of the operating system before and after the application software is migrated; S102, parsing the system call interfaces in the two kernel-devel software packages before and after the migration, and obtaining the system call definition; S103, using regular expressions to parse out the data used in the two kernel-devel software packages before and after the migration, obtaining a complete system call definition, and constructing a system call definition list of two different kernel versions before and after the migration; S104, traverse the two system call definition lists and analyze each system call definition, and combine the different system call definitions into a system call difference data set.

[0012] Furthermore, step S2 specifically includes: S201, obtaining application software to be migrated; S202, determining whether the format of the application software is a file or a directory, and obtaining an ELF file; S203, each ELF file is disassembled to obtain corresponding assembly code; S204, parsing the assembly code in reverse order to obtain a system call identifier and a corresponding register; S205. According to the system call identifier and the corresponding register, a system call number corresponding to the register is parsed using a regular expression, and a system call number list is output.

[0013] Furthermore, step S3 specifically includes: S301, if the system call number list or the system call difference data set has an empty set, the evaluation conclusion is compatible; if there is no empty set, go to step S302; S302 , traverse the system call numbers in the system call number list, and evaluate the compatibility according to whether each system call number is in the system call difference data set.

[0014] Another aspect of the present invention also provides a device for evaluating the compatibility of a system call interface in application software, comprising: Kernel analysis module: analyzes the kernel system call interface of the operating system before and after application software migration to obtain a system call difference data set; Software parsing module: parses the application software system call interface to obtain a list of system call numbers; Compatibility assessment module: Analyzes the compatibility of application software system calls based on the system call difference data set and system call number list.

[0015] Furthermore, the kernel analysis module includes: Kernel acquisition unit: obtains the kernel-devel software package of the corresponding kernel according to the operating system version and system architecture before and after the application software migration; Interface parsing unit: parses the system call interfaces in the two kernel-devel packages before and after the migration and obtains the system call definitions; Call definition list unit: Use regular expressions to parse the data used in the two kernel-devel software packages before and after the migration, obtain the complete system call definition, and construct the system call definition list of the two different kernel versions before and after the migration; Difference data set unit: traverses two system call definition lists and analyzes each system call definition, and the system call definitions with differences are separately combined into a system call difference data set.

[0016] Furthermore, the software analysis module includes: Acquisition unit: acquires application software to be migrated; File unit: determines whether the format of the application software is a file or a directory, and obtains an ELF file; Disassembly unit: disassemble each ELF file to get the corresponding assembly code; Reverse parsing unit: parses the assembly code in reverse order to obtain a system call identifier and a corresponding register; Call number list unit: according to the system call identifier and the corresponding register, parse the system call number corresponding to the register using a regular expression, and output the system call number list.

[0017] Furthermore, the compatibility assessment module includes: Empty set unit: if the system call number list or the system call difference data set has an empty set, the evaluation conclusion is compatible; if there is no empty set, the evaluation unit is transferred; Evaluation unit: traverses the system call numbers in the system call number list, and evaluates the compatibility according to whether each system call number is in the system call difference data set.

[0018] Another aspect of the present invention further provides a computer-readable storage medium, wherein the storage medium stores a computer program, and the computer program is used to execute the above-mentioned method for evaluating the compatibility of the system call interface in the application software.

[0019] Another aspect of the present invention further provides a computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the computer program implements the above-mentioned method for evaluating the compatibility of a system call interface in application software.

[0020] Compared with the prior art, the present invention has the following beneficial effects: 1. The method for evaluating the compatibility of the system call interface in the application software proposed in the present invention can analyze the compatibility of the application software from the kernel level, making the application software compatibility evaluation more comprehensive. At the same time, it greatly improves the accuracy of the application software compatibility evaluation and solves the problem of incomplete compatibility coverage caused by the lack of evaluation methods at the kernel level in the existing application software compatibility evaluation solutions on the market.

[0021] 2. The present invention disassembles the ELF file in the application software to obtain the assembly language, identifies the system call instructions in the assembly languages ​​of different architectures, and the registers that transmit the system call number, and traverses to find out the system call number, thereby realizing the identification of the ELF file system call interface. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 This is a schematic diagram of the method flow of Example 1 of the present invention; Figure 2 This is a schematic diagram of the kernel system call interface analysis process of Example 1 of the present invention; Figure 3 This is a schematic diagram of the application software system call interface parsing process of embodiment 1 of the present invention; Figure 4 It is a schematic diagram of the system call interface compatibility evaluation process of Example 1 of the present invention. DETAILED DESCRIPTION

[0023] It should be noted that, in the absence of conflict, the embodiments of the present invention and the features in the embodiments may be combined with each other.

[0024] The present invention is described in detail below in conjunction with specific embodiments and drawings.

[0025] Embodiment 1: This embodiment proposes a method for evaluating the compatibility of application software system call interfaces. Figure 1 As shown, it is divided into three major stages: S1-S3.

[0026] S1. Analyze the kernel system call interface of the operating system before and after the application software migration to obtain a system call difference data set.

[0027] The process at this stage is as follows Figure 2 As shown, including: 1. Obtain the kernel-devel software package of the corresponding kernel according to the operating system version and system architecture before and after the application software migration; 2. Parse the system call interface in the two kernel-devel packages. The kernel-devel package contains the definition of system calls, involving the following files: (1) The file include / linux / syscalls.h declares the function definition of the system call, including the function name, return value, parameter list, and starts with the modifier asmlinkage. The system call interfaces of different architectures are all declared in this file; (2) The file arch / x86 / include / asm / unistd_64.h (kernel version 2.x) and the file arch / x86 / include / generated / uapi / asm / unistd_64.h (kernel version 2.x and above) declare the correspondence between the system call number and the system call function for the x86_64 architecture; (3) The file include / uapi / asm-generic / unistd.h declares the correspondence between the arm64 architecture system call number and the system call function.

[0028] For different architectures, you need to parse different files in the kernel-devel package. In the x86_64 architecture, you need to parse include / linux / syscalls.h and arch / x86 / include / asm / unistd_64.h (or arch / x86 / include / generated / uapi / asm / unistd_64.h) files; in the arm64 architecture, you need to parse include / linux / syscalls.h and include / uapi / asm-generic / unistd.h files to obtain the definition of system calls.

[0029] 3. For different files of different architectures, use the corresponding regular expressions to parse the data needed in the two kernel-devel packages before and after the migration, so as to obtain the complete system call definition. The system call definition includes the system call number, system call name, system call function name, parameter list, and return value. Use the above information to construct the system call definition list of two different kernel versions.

[0030] Taking the kernel version 3.10.0-1160.el7.x86_64 corresponding to centos7.9 as an example, the system call interface definition "asmlinkage long sys_pkey_alloc(unsigned long flags,unsigned long init_val)" in the include / linux / syscalls.h file of the x86_64 architecture; its meaning is the function sys_pkey_alloc modified by asmlinkage, its return value is long, the function name is sys_pkey_alloc, and the parameter list is unsigned longflags and unsigned long init_val. According to this rule, the regular parsing method of the include / linux / syscalls.h file is defined to implement the parsing of the above parameters, and four items are obtained: return value list, system call name pkey_alloc, system call function name, and parameter list. In the arch / x86 / include / generated / uapi / asm / unistd_64.h file of the x86_64 architecture, the system call interface definition is “#define __NR_pkey_alloc 330”, where __NR_pkey_alloc is the system call number definition corresponding to the system call name pkey_alloc, and its system call number value is 330. Thus, the system call number, system call name, system call function name, parameter list, and return value can be obtained.

[0031] The above example uses the x86_64 architecture, and the same example applies to the arm64 architecture.

[0032] 4. Traverse the system call definition lists of two different versions, and analyze the system call number, system call interface name, parameter list length and type, and return value type of each system call definition. If the definition is inconsistent in the two versions of the kernel, it means that there are differences in the definition. Combine these different system call definitions into a system call difference data set and output the data set.

[0033] S2. parse the application software system call interface to obtain a system call number list.

[0034] The process at this stage is as follows Figure 3 As shown, including: 1. Obtain the application software to be evaluated; 2. Determine whether the application software is in the format of a file or a directory; If it is a file, the type of application software is determined by checking the file MIME type. If the application software is a tar package, gzip compressed package, zip compressed package, or rpm package, all files are extracted to a temporary directory, the directory is traversed, and the ELF (Executable and Linkable Format) file in the software package is obtained according to the MIME type of the file in the software package. If the file type is not one of the above types, an exception is returned with a prompt "Unsupported application software package type, please manually decompress it into a directory and specify the directory for evaluation"; If it is a directory, it directly traverses the software package and obtains the ELF (Executable and Linkable Format) file in the software package according to the MIME type of the file in the software package; 3. Use the objdump tool to disassemble each ELF file and get the corresponding assembly code.

[0035] 4. Split the assembly code obtained by disassembling each ELF file into lines, and parse it in reverse order from the last line of assembly code. In reverse order, first find the definition of the system call, and then search the register corresponding to the system call number in reverse order from the definition position. The system call identifier in the assembly language and the corresponding register for storing the system call number are as follows:

[0036] After the source code is compiled into a binary program, its assembly code, like the source code, first defines the system call number, and then executes the system call. For example, the system call number defined by syscall_number=39 is used during execution. The assembly code mov $39, %%rax; assigns the system call number first, and then executes syscall to trigger the system call. The assembly order obtained by disassembly is consistent with the source code, both of which are defined first and then called. However, in order to identify the system call, it is necessary to search forward from the last line of the assembly code to find the location of the call first, such as the assembly code callq 401050<syscall@plt> , then find the register corresponding to the system call number and the value corresponding to the register, such as mov $0x27,%edi, where<syscall@plt> The system call identifier is identified. 0x27 is the hexadecimal representation of the system call number, which is 39 when converted to decimal.

[0037] 5. According to the parsed system call identifier and the register storing the system call number, use a regular expression to parse out the system call number corresponding to the register and output a list of system call numbers.

[0038] For example, "mov $0x27,%edi", "mov -0x4(%rbp),%eax", "mov $0x27,-0x4(%rbp)" are all assembly codes corresponding to registers containing system call numbers, and the assembly code containing -0x4(%rbp) is special, which is an assembly call method that uses stack address to pass values. By defining the regular expression mov\s+$(0x\d+),%edi, we can get the system call number 0x27 corresponding to the assembly statement mov$0x27,%edi; by defining the regular expression mov\s+(-0x\d+\(%rbp\)),%eax, we can get the register stack address -0x4(%rbp) corresponding to the assembly statement mov -0x4(%rbp),%eax, and then by using the regular expression mov\s+$(0x\d+),-0x4(%rbp), we can get the system call number 0x27 corresponding to the register stack address.

[0039] S3. Analyze the compatibility of application software system calls based on the system call difference data set and the system call number list.

[0040] The process at this stage is as follows Figure 4 As shown, including: 1. Check whether the system call difference data set and the system call number list included in the application software are empty sets respectively. If either one is an empty set, the evaluation conclusion of the application software is compatible; 2. If the system call numbers contained in the system call difference data set and the application software are not empty, then the system call numbers are traversed to check whether each system call number is in the system call difference data set; If one or more system call numbers are in the system call difference data set, the compatibility of the item is incompatible, and the evaluation conclusion of the application software is incompatible; If none of the system call numbers included in the application software is in the system call difference data set, the evaluation conclusion of the application software is compatible; 3. According to the compatibility conclusion, mark the compatibility status of each system call number, generate a compatibility data set, and set the compatibility status of the application software; 4. Gather the system call definition lists of the two versions, the system call difference data set, the system call numbers contained in the application software, the compatibility data set and the final compatibility conclusion to generate a compatibility analysis and evaluation report in HTML format.

[0041] The system call-based application software compatibility assessment method proposed in this embodiment 1 has the following core innovations.

[0042] (1) Evaluation method for system call interface compatibility in application software: The method for evaluating the compatibility of the system call interface in the application software proposed in this method can analyze the compatibility of the application software from the kernel level, making the application software compatibility evaluation more comprehensive and greatly improving the accuracy of the application software compatibility evaluation.

[0043] (2) System call parsing and identification method based on disassembly technology: This method uses the assembly language obtained by disassembling the ELF file in the application software to identify the system call instructions in the assembly language of different architectures and the register that transmits the system call number, and traverses to find the system call number, thereby realizing the identification of the ELF file system call interface.

[0044] Embodiment 2: This embodiment proposes a device for evaluating the compatibility of a system call interface in application software, comprising: Kernel analysis module: analyzes the kernel system call interface of the operating system before and after application software migration to obtain a system call difference data set; Software parsing module: parses the application software system call interface to obtain a list of system call numbers; Compatibility assessment module: Analyzes the compatibility of application software system calls based on the system call difference data set and system call number list.

[0045] The kernel analysis module includes: Kernel acquisition unit: obtains the kernel-devel software package of the corresponding kernel according to the operating system version and system architecture before and after the application software migration; Interface parsing unit: parses the system call interfaces in the two kernel-devel packages before and after the migration and obtains the system call definitions; Call definition list unit: Use regular expressions to parse the data used in the two kernel-devel software packages before and after the migration, obtain the complete system call definition, and construct the system call definition list of the two different kernel versions before and after the migration; Difference dataset unit: traverses two system call definition lists and analyzes each system call definition. The different system call definitions are combined into a system call difference dataset. The software parsing modules include: Acquisition unit: acquires application software to be migrated; File unit: determines whether the format of the application software is a file or a directory, and obtains an ELF file; Disassembly unit: disassemble each ELF file to get the corresponding assembly code; Reverse parsing unit: parses the assembly code in reverse order to obtain a system call identifier and a corresponding register; Call number list unit: according to the system call identifier and the corresponding register, parse the system call number corresponding to the register using a regular expression, and output the system call number list.

[0046] The compatibility assessment modules include: Empty set unit: if the system call number list or the system call difference data set has an empty set, the evaluation conclusion is compatible; if there is no empty set, the evaluation unit is transferred; Evaluation unit: traverses the system call numbers in the system call number list, and evaluates the compatibility according to whether each system call number is in the system call difference data set.

[0047] The device for evaluating the compatibility of system call interfaces in application software proposed in this embodiment can implement the method for evaluating the compatibility of system call interfaces in application software proposed in Embodiment 1, and has the same technical effect as Embodiment 1.

[0048] The above-mentioned embodiments are only preferred implementations of the present invention, and are only used to help understand the method and core ideas of the present application. The protection scope of the present invention is not limited to the above-mentioned embodiments. All technical solutions under the idea of ​​the present invention belong to the protection scope of the present invention. It should be pointed out that for ordinary technicians in this technical field, some improvements and modifications without departing from the principle of the present invention should also be regarded as the protection scope of the present invention.

Claims

1. A method for evaluating the compatibility of a system call interface in an application software, characterized in that: include: S1. Analyze the kernel system call interface of the operating system before and after the application software migration to obtain a system call difference data set; S2, parsing the application software system call interface to obtain a system call number list; S3. Analyze the compatibility of application software system calls based on the system call difference data set and the system call number list.

2. The method for evaluating the compatibility of system call interfaces in application software according to claim 1, characterized in that: Step S1 specifically includes: S101, obtaining a kernel-devel software package of a corresponding kernel according to the versions and system architecture of the operating system before and after the application software is migrated; S102, parsing the system call interfaces in the two kernel-devel software packages before and after the migration, and obtaining the system call definition; S103, using regular expressions to parse out the data used in the two kernel-devel software packages before and after the migration, obtaining a complete system call definition, and constructing a system call definition list of two different kernel versions before and after the migration; S104, traverse the two system call definition lists and analyze each system call definition, and combine the different system call definitions into a system call difference data set.

3. The method for evaluating the compatibility of system call interfaces in application software according to claim 1, characterized in that: Step S2 specifically includes: S201, obtaining application software to be migrated; S202, determining whether the format of the application software is a file or a directory, and obtaining an ELF file; S203, each ELF file is disassembled to obtain corresponding assembly code; S204, parsing the assembly code in reverse order to obtain a system call identifier and a corresponding register; S205. According to the system call identifier and the corresponding register, a system call number corresponding to the register is parsed using a regular expression, and a system call number list is output.

4. The method for evaluating the compatibility of system call interfaces in application software according to claim 1, characterized in that: Step S3 specifically includes: S301, if the system call number list or the system call difference data set has an empty set, the evaluation conclusion is compatible; if there is no empty set, go to step S302; S302 , traverse the system call numbers in the system call number list, and evaluate the compatibility according to whether each system call number is in the system call difference data set.

5. A device for evaluating compatibility of system call interfaces in application software, characterized in that: include: Kernel analysis module: analyzes the kernel system call interface of the operating system before and after application software migration to obtain a system call difference data set; Software parsing module: parses the application software system call interface to obtain a list of system call numbers; Compatibility assessment module: Analyzes the compatibility of application software system calls based on the system call difference data set and system call number list.

6. The device for evaluating compatibility of system call interfaces in application software according to claim 5, characterized in that: Kernel analysis modules include: Kernel acquisition unit: obtains the kernel-devel software package of the corresponding kernel according to the operating system version and system architecture before and after the application software migration; Interface parsing unit: parses the system call interfaces in the two kernel-devel packages before and after the migration and obtains the system call definitions; Call definition list unit: Use regular expressions to parse the data used in the two kernel-devel software packages before and after the migration, obtain the complete system call definition, and construct the system call definition list of the two different kernel versions before and after the migration; Difference data set unit: traverses two system call definition lists and analyzes each system call definition, and the system call definitions with differences are separately combined into a system call difference data set.

7. The device for evaluating compatibility of system call interfaces in application software according to claim 5, characterized in that: The software parsing modules include: Acquisition unit: acquires application software to be migrated; File unit: determines whether the format of the application software is a file or a directory, and obtains an ELF file; Disassembly unit: disassemble each ELF file to get the corresponding assembly code; Reverse parsing unit: parses the assembly code in reverse order to obtain a system call identifier and a corresponding register; Call number list unit: according to the system call identifier and the corresponding register, parse the system call number corresponding to the register using a regular expression, and output the system call number list.

8. The device for evaluating compatibility of system call interfaces in application software according to claim 5, characterized in that: The compatibility assessment modules include: Empty set unit: if the system call number list or the system call difference data set has an empty set, the evaluation conclusion is compatible; if there is no empty set, the evaluation unit is transferred; Evaluation unit: traverses the system call numbers in the system call number list, and evaluates the compatibility according to whether each system call number is in the system call difference data set.

9. A computer-readable storage medium storing a computer program, characterized in that: The computer program is used to execute the method for evaluating the compatibility of the system call interface in the application software as described in any one of claims 1 to 4.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the method for evaluating the compatibility of a system call interface in application software as described in any one of claims 1 to 4 is implemented.

Images