A method and device for evaluating the compatibility of system call interfaces in application software

Abstract

The present invention provides a method and device for evaluating the compatibility of system call interfaces in application software, including: S1, analyzing the kernel system call interfaces of the operating system before and after the migration of the application software to obtain a system call difference data set; S2, parsing the system call interfaces of the application software to obtain a system call number list; S3, analyzing the system call compatibility of the application software based on the system call difference data set and the system call number list. The present invention does not require the provision of source code, does not require the running of a program, and directly performs system call compatibility analysis on the application software binary file, solving the problem of incomplete compatibility coverage caused by the lack of an evaluation method at the kernel level in the existing application software compatibility evaluation solutions in the market.

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:

[0005] 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.

[0006] 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

[0007] 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.

[0008] Due to the coding habits of developers and the uses of application software, application programs such as C, C++, and ASM that can be compiled into ELF (Executable and Linkable Format) files will directly interact with system calls in 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 within a major kernel version, but when migrating application software across major versions, it is necessary to consider whether the definition of system calls has changed.

[0009] The definition of system calls includes 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, the number and type of parameters in the parameter list, or the type of the return value will affect compatibility.

[0010] The main purpose of system call compatibility evaluation is to analyze the system calls included in binary application programs 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 migration of the application software. If a change occurs and there are system calls used by the application software, after the migration of the application software, it will cause the application software to execute errors or pose unpredictable operation risks due to system call incompatibility.

[0011] Based on the above principles, the technical solution of the present invention is as follows:

[0012] A method for evaluating the compatibility of system call interfaces in application software, including:

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

[0014] S2. Parse the system call interfaces of the application software to obtain a system call number list;

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

[0016] Further, step S1 specifically includes:

[0017] S101. Obtain the corresponding kernel's kernel-devel software package according to the versions and system architectures of the operating system before and after the migration of the application software;

[0018] S102. Analyze the system call interfaces in the two kernel - devel software packages before and after migration, and obtain the system call definitions;

[0019] S103. Use regular expressions to parse the data used in the two kernel - devel software packages before and after migration, obtain the complete system call definitions, and construct the system call definition lists for the two different kernel versions before and after migration;

[0020] S104. Traverse the two system call definition lists and analyze each system call definition. The system call definitions with differences are combined separately into a system call difference data set.

[0021] Further, step S2 specifically includes:

[0022] S201. Obtain the application software to be migrated;

[0023] S202. Determine whether the format of the application software is a file or a directory, and obtain the ELF file;

[0024] S203. Disassemble each ELF file to obtain the corresponding assembly code;

[0025] S204. Reverse - order parse the assembly code to obtain the system call identifier and the corresponding register;

[0026] S205. According to the system call identifier and the corresponding register, use regular expressions to parse the system call number corresponding to the register, and output the system call number list.

[0027] Further, step S3 specifically includes:

[0028] S301. If the system call number list or the system call difference data set is an empty set, the evaluation conclusion is compatible; if it is not an empty set, go to step S302;

[0029] 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.

[0030] On the other hand, the present invention also proposes an evaluation device for the compatibility of system call interfaces in application software, including:

[0031] Kernel analysis module: Analyze the kernel system call interfaces of the operating system before and after the migration of the application software to obtain a system call difference data set;

[0032] Software parsing module: Parse the system call interfaces of the application software to obtain a system call number list;

[0033] Compatibility Evaluation Module: Analyze the system call compatibility of the application software based on the system call difference dataset and the system call number list.

[0034] Furthermore, the kernel analysis module includes:

[0035] Kernel Acquisition Unit: Obtain the kernel-devel software package corresponding to the kernel according to the versions and system architectures of the operating systems before and after the migration of the application software;

[0036] Interface Parsing Unit: Parse the system call interfaces in the two kernel-devel software packages before and after migration to obtain the system call definitions;

[0037] Call Definition List Unit: Use regular expressions to parse the data used in the two kernel-devel software packages before and after migration, obtain the complete system call definitions, and construct the system call definition lists for the two different kernel versions before and after migration;

[0038] Difference Dataset Unit: Traverse the two system call definition lists and analyze each system call definition. The system call definitions with differences are separately combined into a system call difference dataset.

[0039] Furthermore, the software parsing module includes:

[0040] Acquisition Unit: Obtain the application software to be migrated;

[0041] File Unit: Determine whether the format of the application software is a file or a directory, and obtain the ELF file;

[0042] Disassembly Unit: Disassemble each ELF file to obtain the corresponding assembly code;

[0043] Inverse Parsing Unit: Inversely parse the assembly code to obtain the system call identifier and the corresponding register;

[0044] Call Number List Unit: According to the system call identifier and the corresponding register, use regular expressions to parse the system call number corresponding to the register and output the system call number list.

[0045] Furthermore, the compatibility evaluation module includes:

[0046] Empty Set Unit: If the system call number list or the system call difference dataset is an empty set, the evaluation conclusion is compatible; if there is no empty set, transfer to the evaluation unit;

[0047] Evaluation Unit: 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 dataset.

[0048] On the other hand, the present invention also provides a computer-readable storage medium storing a computer program for executing the above method for evaluating the compatibility of system call interfaces in application software.

[0049] On the other hand, the present invention also provides a computer program product including a computer program which, when executed by a processor, implements the above method for evaluating the compatibility of system call interfaces in application software.

[0050] Compared with the prior art, the present invention has the following beneficial effects:

[0051] 1. The method for evaluating the compatibility of system call interfaces in application software proposed by the present invention can analyze the compatibility of application software at the kernel level, making the evaluation of application software compatibility more comprehensive. At the same time, it greatly improves the accuracy of the evaluation of application software compatibility, and solves the problem of incomplete compatibility coverage caused by the lack of evaluation methods at the kernel level in existing application software compatibility evaluation schemes.

[0052] 2. The present invention disassembles the ELF file in the application software to obtain the assembly language, and identifies the system call instructions and the registers for passing the system call number in the assembly languages of different architectures, and traverses to find out the system call numbers, thereby realizing the identification of the system call interfaces of the ELF files. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Figure 1 is a schematic flow chart of the method according to Embodiment 1 of the present invention;

[0054] Figure 2 is a schematic flow chart of the analysis of the kernel system call interface according to Embodiment 1 of the present invention;

[0055] Figure 3 is a schematic flow chart of the parsing of the application software system call interface according to Embodiment 1 of the present invention;

[0056] Figure 4 is a schematic flow chart of the evaluation of the compatibility of the system call interface according to Embodiment 1 of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

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

[0058] The present invention will be specifically described below with reference to specific embodiments and the accompanying drawings.

[0059] Embodiment 1:

[0060] This embodiment provides a method for evaluating the compatibility of the system call interface of an application software, as Figure 1As shown in the figure, it is divided into the following three major stages S1 - S3.

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

[0062] The process of this stage is as Figure 2 shown, including:

[0063] 1. Obtain the corresponding kernel-devel software package according to the operating system version and system architecture before and after the migration of the application software.

[0064] 2. Parse the system call interfaces in the two kernel-devel software packages. The kernel-devel package contains the definitions of system calls, which involve the following files:

[0065] (1) The file include / linux / syscalls.h declares the function definitions of system calls, including the function name, return value, and parameter list, starting with the modifier asmlinkage. The system call interfaces of different architectures are declared in this file.

[0066] (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 above 2.x) declare the correspondence between the system call numbers and system call function functions for the x86_64 architecture.

[0067] (3) The file include / uapi / asm-generic / unistd.h declares the correspondence between the system call numbers and system call function functions for the arm64 architecture.

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

[0069] 3. For different files with different architectures, use the corresponding regular expressions to parse the data required in the two kernel-devel packages before and after migration, so as to obtain the complete system call definitions. The system call definitions include system call numbers, system call names, system call function names, parameter lists, and return values. Use the above information to construct system call definition lists for two different kernel versions.

[0070] Taking the corresponding kernel version 3.10.0-1160.el7.x86_64 of centos7.9 as an example, in the include / linux / syscalls.h file of the x86_64 architecture, the system call interface is defined as "asmlinkage long sys_pkey_alloc(unsigned long flags,unsigned long init_val)"; its meaning is that 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 long flags, unsigned long init_val. According to this rule, define the regular parsing method of the include / linux / syscalls.h file to implement the parsing of the above parameters, and obtain four items: the return value list, the system call name pkey_alloc, the system call function name, and the parameter list. In the arch / x86 / include / generated / uapi / asm / unistd_64.h file of the x86_64 architecture, the system call interface is defined as "#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.

[0071] The above is an example of the x86_64 architecture, and the arm64 architecture is the same as this example.

[0072] 4. Traverse the system call definition lists of the two different versions, and analyze the system call numbers, system call interface names, lengths and types of parameter lists, and types of return values of each system call definition. If this definition is inconsistent in the kernels of the two versions, it means that there are differences in its definition. Combine these system call definitions with differences into a system call difference data set and output this data set.

[0073] S2. Parse the system call interfaces of the application software to obtain a system call number list.

[0074] The process of this stage is as follows Figure 3 shown, including:

[0075] 1. Obtain the application software to be evaluated;

[0076] 2. Determine whether the format of the application software is a file or a directory;

[0077] If it is a file, determine the type of the application software by checking the file MIME type. If the type of the application software is a tar package, a gzip compressed package, a zip compressed package, or an rpm package, extract all files to a temporary directory, traverse the directory, and obtain the ELF (Executable and Linkable Format) files in the software package according to the MIME type of the files in the package; if the file type is not the above type, return an exception and prompt "Unsupported application software package type. Please manually decompress it into a directory and specify the directory for evaluation."

[0078] If it is a directory, directly traverse the software package and obtain the ELF (Executable and Linkable Format) files in the software package according to the MIME type of the files in the package;

[0079] 3. Use the objdump tool to disassemble each ELF file to obtain the corresponding assembly code.

[0080] 4. Split the assembly code obtained by disassembling each ELF file by line, and perform reverse parsing from the last line of the assembly code forward. In the reverse order, first find the definition of the system call, and then search backward from the defined position for the register storing the corresponding system call number. The system call identifiers and the corresponding registers storing the system call numbers in assembly language are as follows:

[0081]

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

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

[0084] Assembly code such as "mov $0x27,%edi", "mov -0x4(%rbp),%eax", "mov $0x27,-0x4(%rbp)" are all assembly codes corresponding to registers containing system call numbers. The assembly code containing -0x4(%rbp) is special and is an assembly call method using stack address passing values. By defining the regular expression mov\s+$(0x\d+),%edi, the system call number 0x27 corresponding to the assembly statement mov$0x27,%edi can be obtained; by defining the regular expression mov\s+(-0x\d+\(%rbp\)),%eax, the register stack address -0x4(%rbp) corresponding to the assembly statement mov -0x4(%rbp),%eax can be obtained, and then by using the regular expression mov\s+$(0x\d+),-0x4(%rbp), the system call number 0x27 corresponding to the register stack address can be obtained.

[0085] S3. Analyze the compatibility of the application software system calls based on the system call difference dataset and the list of system call numbers.

[0086] The process of this stage is as Figure 4 shown, including:

[0087] 1. Check whether the system call difference dataset and the list of system call numbers included in the application software are respectively empty sets. If any one of them is an empty set, the evaluation conclusion of the application software is compatible;

[0088] 2. If both the system call difference dataset and the system call numbers included in the application software are not empty, traverse the system call numbers and check whether each system call number is in the system call difference dataset;

[0089] If one or more system call numbers are in the system call difference dataset, the compatibility of this item is incompatible, and the evaluation conclusion of the application software is incompatible;

[0090] If none of the system call numbers included in the application software are in the system call difference dataset, the evaluation conclusion of the application software is compatible;

[0091] 3. According to the compatibility conclusion, mark the compatibility status for each system call number, generate a compatibility dataset, and set the compatibility status of the application software;

[0092] 4. Collect the system call definition lists of two versions, the system call difference dataset, the system call numbers included in the application software, the compatibility dataset, and the final compatibility conclusion, and generate a compatibility analysis and evaluation report in HTML format.

[0093] The method for evaluating the compatibility of application software based on system calls proposed in this Embodiment 1 has the following core innovations.

[0094] (1) Method for evaluating the compatibility of system call interfaces in application software:

[0095] The method for evaluating the compatibility of system call interfaces in application software proposed by this method can analyze the compatibility of application software from the kernel level, making the evaluation of application software compatibility more comprehensive and greatly improving the accuracy of the evaluation of application software compatibility.

[0096] (2) Method for parsing and identifying system calls based on disassembly technology:

[0097] For the assembly language obtained by disassembling the ELF file in the application software, this method traverses and finds out the system call numbers by identifying the system call instructions and the registers for passing system call numbers in the assembly languages of different architectures, so as to realize the identification of the system call interface of the ELF file.

[0098] Embodiment 2:

[0099] This embodiment proposes an apparatus for evaluating the compatibility of system call interfaces in application software, including:

[0100] Kernel analysis module: Analyze the kernel system call interfaces of the operating system before and after the migration of the application software to obtain a system call difference dataset;

[0101] Software parsing module: Parse the system call interfaces of the application software to obtain a list of system call numbers;

[0102] Compatibility evaluation module: Analyze the system call compatibility of the application software based on the system call difference data set and the system call number list.

[0103] Among them, the kernel analysis module includes:

[0104] Kernel acquisition unit: Obtain the kernel-devel software package corresponding to the kernel according to the versions and system architectures of the operating systems before and after the migration of the application software;

[0105] Interface parsing unit: Parse the system call interfaces in the two kernel-devel software packages before and after migration to obtain the system call definitions;

[0106] Call definition list unit: Use regular expressions to parse the data used in the two kernel-devel software packages before and after migration to obtain the complete system call definitions, and construct the system call definition lists of the two different kernel versions before and after migration;

[0107] Difference data set unit: Traverse the two system call definition lists and analyze each system call definition. The system call definitions with differences are separately combined into a system call difference data set

[0108] The software parsing module includes:

[0109] Acquisition unit: Obtain the application software to be migrated;

[0110] File unit: Judge whether the format of the application software is a file or a directory, and obtain the ELF file;

[0111] Disassembly unit: Disassemble each ELF file to obtain the corresponding assembly code;

[0112] Inverse parsing unit: Inversely parse the assembly code to obtain the system call identifier and the corresponding register;

[0113] Call number list unit: According to the system call identifier and the corresponding register, use regular expressions to parse the system call number corresponding to the register, and output the system call number list.

[0114] The compatibility evaluation module includes:

[0115] Empty set unit: If there is an empty set in the system call number list or the system call difference data set, the evaluation conclusion is compatible; if there is no empty set, transfer to the evaluation unit;

[0116] Evaluation unit: 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.

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

[0118] The above-described embodiments are only the preferred embodiments of the present invention, which are only used to help understand the method and its core idea of the present application. The protection scope of the present invention is not limited to the above embodiments. All technical solutions falling within the idea of the present invention belong to the protection scope of the present invention. It should be noted that for those of ordinary skill in the art, several improvements and refinements made 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, analyzing the compatibility of application software system calls based on the system call difference data set and the system call number list; 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 the data used in the two kernel-devel software packages before and after the migration, obtain a complete system call definition, which includes a system call number, a system call name, a system call function name, a parameter list, and a return value, and construct a system call definition list of two different kernel versions before and after the migration; S104, traversing the two system call definition lists and analyzing the system call number, system call interface name, length and type of parameter list, and return value type of each system call definition, and combining different system call definitions into a system call difference data set; Step S2 specifically includes: S201, obtaining application software to be migrated; S202, determine whether the format of the application software is a file or a directory, and obtain an ELF file; if it is a file, determine the type of the application software by checking the file MIME type; if the type of the application software is a tar package, a gzip compressed package, a zip compressed package, or an rpm package, extract all files to a temporary directory, traverse the directory, and obtain the ELF file in the software package according to the MIME type of the files in the software package; if it is a directory, directly traverse the software package and obtain the ELF in the software package according to the MIME type of the files in the software package; S203, each ELF file is disassembled to obtain corresponding assembly code; S204, dividing the assembly code into lines, and parsing the assembly code in reverse order from the last line of the assembly code forward, first finding the location of the system call in reverse order, identifying the system call identifier, and then searching for the register corresponding to the storage system call number in reverse order from the call location; 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.

2. 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.

3. A device for evaluating the compatibility of a system call interface in an 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 evaluation module: analyzes the compatibility of application software system calls based on the system call difference data set and system call number list; 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, which includes the system call number, system call name, system call function name, parameter list, and return value, 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 the system call number, system call interface name, parameter list length and type, and return value type of each system call definition. The different system call definitions are combined into a system call difference data set. The software parsing modules include: Acquisition unit: acquires application software to be migrated; File unit: determine whether the format of the application software is a file or a directory, and obtain an ELF file; if it is a file, determine the type of the application software by checking the file MIME type. If the type of the application software is a tar package, a gzip compressed package, a zip compressed package, or an rpm package, extract all files to a temporary directory, traverse the directory, and obtain the ELF file in the software package according to the MIME type of the files in the software package; if it is a directory, directly traverse the software package and obtain the ELF in the software package according to the MIME type of the files in the software package; Disassembly unit: disassemble each ELF file to get the corresponding assembly code; The reverse parsing unit divides the assembly code into lines and performs reverse parsing from the last line of the assembly code forward, first finds the location of the system call in reverse order, identifies the system call identifier, and then searches for the register corresponding to the system call number in reverse order from the call location; 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.

4. The device for evaluating compatibility of system call interfaces in application software according to claim 3, 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.

5. 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-2.

6. 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 2 is implemented.

Images