An Executable File Integrity Verification Method Based on the Linux Kernel Binfmt Framework

Abstract

The present invention relates to an executable file integrity verification method based on a Linux kernel binfmt framework, comprising: registering a verification module in the Linux kernel binfmt framework; the verification module is executed before loading a module of an ELF executable file, and the verification module determines whether the executable file is complete by detecting the content of the .signature segment of the ELF executable file; by adding an fs / binfmt_elf_integrity module, registering before binfmt_elf, reusing the kernel's integrity verification logic for a driver, i.e., a kernel module, adding a .signature to-be-verified segment for ELF format extension, and verifying the integrity of all ELF files using a kernel certificate chain. The entire process is completely carried out in the kernel space, reusing a mature kernel encryption and decryption algorithm framework and a certificate-based integrity verification framework, without the assistance of an external user space verification program, getting rid of the performance bottleneck of going back and forth between the kernel state and the user state, and being weakly related to other functional modules of the operating system, and convenient for transplantation.

Description

Technical Field

[0001] The present invention relates to the field of file integrity verification, and particularly to an executable file integrity verification method based on the Linux kernel binfmt framework. Background Art

[0002] Existing methods for verifying the integrity of executable files in the Linux operating system are usually implemented by adding hooks in the Linux kernel, usually working in the call chain of opening files in the file system, and usually the verification function is performed in user space. The entire verification process requires user space calls for loading, pre-loading process before the kernel space hook, user space integrity check, post-loading process after the kernel space hook, and user space program execution. Since the switching cost between the kernel state and the user state of the operating system is relatively high, it adds at least two round trips between the kernel state and the user state compared to ordinary opening operations, resulting in a bottleneck in verification efficiency.

[0003] Since the Linux kernel already has a complete integrity verification function and framework based on certificate signatures, and it has been used to verify the integrity of drivers, i.e., kernel modules, and has been verified in the large-scale applications of several Linux operating systems over several years. The behavior of adding hooks in the kernel and performing verification in user space actually bypasses the entire certificate chain system of the kernel, making the trust source not unique, and due to the vulnerability of user space processes, the integrity verification of executable files may be damaged by high-privilege attacks. Summary of the Invention

[0004] In view of the technical problems existing in the prior art, the present invention provides an executable file integrity verification method based on the Linux kernel binfmt framework to achieve pure kernel state integrity protection for ELF executable files.

[0005] According to a first aspect of the present invention, there is provided an executable file integrity verification method based on the Linux kernel binfmt framework, including:

[0006] Registering a verification module in the Linux kernel binfmt framework;

[0007] The verification module is executed before the module for loading the ELF executable file, and the verification module determines whether the executable file is complete by detecting the content of the.signature segment of the ELF executable file.

[0008] Based on the above technical solutions, the present invention can also be improved as follows.

[0009] Optionally, the process of the verification module determining whether the executable file is complete includes:

[0010] Analyze the ELF header information to determine whether the ELF executable file contains a valid.signature section. If not, it is determined that the executable file is incomplete.

[0011] Optionally, the process by which the verification module determines whether the executable file is complete includes:

[0012] Generate an ELF executable file image from the ELF executable file containing a valid.signature section and read it into memory. Set all bytes in the.signature section of the ELF executable file image to 0 to obtain the ELF file to be signed, and sign the ELF file to be signed using the certificate chain in the kernel.

[0013] Verify the ELF file to be signed according to the certificate chain in the kernel. When the.signature section is not in a signature format recognizable by the kernel signature authentication module, the signature certificate used is not in the kernel certificate chain, or the signature hash value does not match the expected value of the certificate public key, it is determined that the executable file is incomplete.

[0014] Optionally, use the signelf tool generated by modifying the Linux kernel source code script / sign-file.c to sign the ELF file to be signed.

[0015] The signature process of the signelf tool includes: adding an empty file of the same size as expected for.signature to the ELF executable file image through objcopy --add-section.signature= to generate the ELF file to be signed, generating a detached signature for the ELF file to be signed using the same signature method as the kernel module, and incorporating the detached signature into the ELF file to be signed in the way of objcopy --add-sectionsignature=.

[0016] Optionally, when the verification module determines that the executable file is complete, it returns skip, allowing the binfmt framework to proceed to the subsequent module for loading the ELF executable file to execute normally. Otherwise, it returns an error and blocks the binfmt framework.

[0017] Optionally, the creation process of the verification module includes:

[0018] Write binfmt_elf_integrity.c under the fs of the Linux kernel source code of the target operating system or write it separately outside the Linux kernel source code, and set the option indicating whether the verification module can be unloaded.

[0019] According to a second aspect of the present invention, there is provided an executable file integrity verification system based on the Linux kernel binfmt framework, including: a verification module registered in the Linux kernel binfmt framework;

[0020] The verification module is executed before the module for loading the ELF executable file, and the verification module determines whether the executable file is complete by detecting the content of the.signature segment of the ELF executable file.

[0021] According to a third aspect of the present invention, there is provided an electronic device, including a memory and a processor, and when the processor executes a computer management program stored in the memory, the steps of an executable file integrity verification method based on the Linux kernel binfmt framework are implemented.

[0022] According to a fourth aspect of the present invention, there is provided a computer-readable storage medium, on which a computer management program is stored, and when the computer management program is executed by a processor, the steps of an executable file integrity verification method based on the Linux kernel binfmt framework are implemented.

[0023] An executable file integrity verification method, system, electronic device and storage medium based on the Linux kernel binfmt framework provided by the present invention, the entire verification process is carried out in the binfmt framework of the original exec call chain for the Linux kernel to execute the ELF executable file, without registering hooks in the open process additionally, and without causing obvious performance impact on the exec and open system calls; the verification logic is based on the existing kernel certificate chain and kernel module (driver) signature verification logic, and runs entirely in the kernel space, saving multiple round trips between the kernel state and the user state. When the module is compiled as built-in to the kernel, the verification logic cannot be removed by high-privilege users in the user space, avoiding the problem that the verification work is easily damaged by high-privilege attackers when progressing in the user state. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 It is a flowchart of an embodiment of an executable file integrity verification method based on the Linux kernel binfmt framework provided by the present invention;

[0025] Figure 2 It is a logical schematic diagram for generating a signature for an ELF executable file provided by the present invention and adding a.signature signature segment to be verified;

[0026] Figure 3 It is a logical schematic diagram for the release of a certificate and a signed ELF after signing the ELF with a certificate private key provided by an embodiment of the present invention;

[0027] Figure 4Schematic diagram of the hardware structure of a possible electronic device provided by the present invention;

[0028] Figure 5 Schematic diagram of the hardware structure of a possible computer-readable storage medium provided by the present invention. Detailed implementation manners

[0029] The principles and features of the present invention will be described below with reference to the accompanying drawings. The examples given are only used to explain the present invention and are not intended to limit the scope of the present invention.

[0030] Figure 1 Flowchart of an embodiment of an executable file integrity verification method based on the Linux kernel binfmt framework provided by the present invention, as Figure 1 shown, the verification method includes:

[0031] Register a verification module in the Linux kernel binfmt framework.

[0032] The verification module is executed before the module that loads the ELF executable file. The verification module determines whether the executable file is complete by detecting the content of the.signature section of the ELF executable file.

[0033] ELF is the most common and widely used executable file format in current Unix-like operating systems, that is, the only executable file format adopted in current mainstream Linux operating systems. In recent years, on Linux-based operating systems, almost all executable files are either ELF executable files or script files executed by ELF executable files. The ELF file contains a file header with relatively fixed fields, several sections with different definitions, and a section table. Since the ELF is executed after loading the offsets of several sections into memory, adding or deleting sections to the ELF will not affect this loading process, so it will not damage the functions of the ELF itself.

[0034] Due to the variability of Unix executable files, in order to extend compatibility with various current and even future different executable file formats, and even executable file formats that are not native to the local architecture, the Linux kernel uses the binfmt framework defined in several fs / binfmt_xxx files. In the binfmt framework, a registered binfmt module can return three results for the target of an exec(): execute it, skip it, or reject it. When the user requests to call exec() to open an ELF executable file, the kernel polls all binfmt modules in the registration order. Since binfmt_elf recognizes and allows execution, the subsequent loading and execution operations are handed over to the built-in module binfmt_elf of the binfmt framework for execution. The binfmt framework has strong extensibility, and all binfmt frameworks built into the Linux kernel are pure kernel logic, with only one exception, which is binfmt_misc. It provides a hook that allows registration to the user space, and is often used to allow the user space to register other opening methods. The most common use is to implement the operation of qemu-user-static to open other files as if opening an executable file of the local architecture.

[0035] In the open-source native Linux kernel, for the necessary exec() operation on an ELF executable file, it can be simply understood that after the exec() in fs / exec.c checks that the corresponding file permission bits allow execution and open(), it calls each preparatory function, and then polls the binfmt hooks registered in the kernel one by one until the member.load_binary function load_elf_binary() in the elf_format of struct linux_binfmt registered in fs / binfmt_elf.c processes and judges the ELF header and considers it to be an ELF file that can be executed by binfmt_elf, and then executes it.

[0036] An executable file integrity verification method based on the Linux kernel binfmt framework provided by the present invention. The entire verification process is carried out in the binfmt framework of the original exec call chain when the Linux kernel executes the ELF executable file. No additional hooks are registered in the open process, and there is no obvious performance impact on the exec and open system calls; the verification logic is based on the existing kernel certificate chain and kernel module (driver) signature verification logic, and runs entirely in the kernel space, saving multiple round trips between the kernel state and the user state. When the module is compiled into the kernel, the verification logic cannot be removed by high-privilege users in the user space, avoiding the problem that the verification work is easily damaged by high-privilege attackers when progressing in the user state.

[0037] Example 1

[0038] Example 1 provided by the present invention is an example of an executable file integrity verification method based on the Linux kernel binfmt framework provided by the present invention. As can be seen from Figure 1 it, the embodiments of this verification method include:

[0039] Register a verification module in the Linux kernel binfmt framework.

[0040] The verification module is executed before the module that loads the ELF executable file. The verification module determines whether the executable file is complete by detecting the content of the.signature section of the ELF executable file.

[0041] In specific implementation, the verification module is defined as the binfmt_elf_integrity module, and the module that loads the ELF executable file is the binfmt_elf or binfmt_misc module.

[0042] In a possible embodiment, the process by which the verification module determines whether the executable file is complete includes:

[0043] Analyze the ELF header information to determine whether the ELF executable file contains a valid.signature section. If it does not, it is determined that the executable file is incomplete.

[0044] The specific processing process includes: rejecting the execution of all ELF executable files without a.signature section, returning an error, and blocking the binfmt framework from proceeding to the binfmt_elf module.

[0045] In a possible embodiment, the process by which the verification module determines whether the executable file is complete includes:

[0046] Generate an ELF executable file image from the ELF executable file containing a valid.signature section and read it into memory. Set all the bytes in the.signature section of the ELF executable file image to 0 to obtain a file to be signed. Sign the file to be signed using the certificate chain in the kernel.

[0047] Verify the file to be signed according to the certificate chain in the kernel. When the.signature section is not in a signature format recognizable by the kernel signature authentication module, the signature certificate used is not in the kernel certificate chain, or the signature hash value does not match the expected value of the certificate public key, it is determined that the executable file is incomplete.

[0048] Copy the.signature section, then empty the.signature section. Reuse the kernel verification driver's function for checking the integrity of the kernel module in the memory image. The original data segment is the ELF image with the.signature section emptied, and the signature information is the original information of the.signature section. Perform verification according to the certificate chain in the kernel. When and only when the.signature section exists, is valid, and is issued by a certificate in the kernel certificate chain.

[0049] As Figure 2 shown is the logical schematic diagram of generating a signature for the ELF executable file provided by the present invention and adding a.signature section to be verified. Combining Figure 1 and Figure 2 it can be known that the signature certificate used by the ELF file to be signed and all its parent certificates are stored in the kernel certificate chain; the signature certificate is the same as or different from the signature certificate used by the kernel module. When the signature certificate is different from the signature certificate used by the kernel module, itself or its parent certificate is set to CONFIG_SYSTEM_TRUSTED_KEYS during the kernel compilation stage, and if the certificate pre-imported into the kernel second certificate chain by being set to CONFIG_SYSTEM_TRUSTED_KEYS during the kernel compilation stage is not itself, then it must be imported into the kernel second certificate chain by executing sudo keyctl padd asymmetric "" %:.secondary_trusted_keys <[os-elf.cert.der] (where [os-elf.cert.der] is an X.509 certificate file in DER format) after the kernel starts. Otherwise, similar to the kernel module signature verification logic, the ELF signed by a certificate not in the kernel certificate chain will be considered untrusted and will be rejected from execution.

[0050] The signature certificate adopted is an internationally common X.509 certificate already in use for kernel module signature. The present invention does not impose additional restrictions on the hash algorithm and key format of the certificate itself. Any X.509 certificate hash algorithm and key format accepted by the Linux kernel module signature can be used.

[0051] The binfmt_elf_integrity module must include the signature of an ELF with the same size and an empty signature (with all bits in.signature set to 0) using the certificate in the kernel certificate chain. The signature is generated in the same way as the kernel's signature for drivers (i.e., kernel modules), using the sign-elf tool modified from the kernel source tree script / sign-file.c. The logic of this sign-elf tool is as follows: First, an empty file with the same expected size as.signature is added to the ELF using objcopy --add-section.signature= to generate the ELF to be signed. Then, a detached signature is generated for this ELF to be signed using the same signature method as the kernel module. Finally, this detached signature is incorporated back into the ELF to be signed using objcopy --add-section signature=. When verifying, the entire ELF is read into memory, the.signature section in it is copied in memory, and then all bits in the.signature section of the ELF in memory are set to 0 to obtain the ELF to be verified. Then, using the same logic, signature format requirements, and certificate chain as the kernel module signature verification, the hash of this ELF is calculated and compared with the kernel certificate chain.

[0052] In a possible embodiment, the signelf tool generated by modifying the Linux kernel source code script / sign-file.c is used to sign the ELF file to be signed.

[0053] The signature process of the signelf tool includes: adding an empty file with the same expected size as.signature to the ELF executable file image using objcopy --add-section.signature= to generate the ELF file to be signed, generating a detached signature for the ELF file to be signed using the same signature method as the kernel module, and incorporating the detached signature into the ELF file to be signed using objcopy --add-section signature=.

[0054] In a specific implementation, it is required that the pre-generated, non-embedded ELF detached signature adopt the same signature generation format as the Linux kernel module, namely the CMS or PKCS7 format. However, since the final ELF signature needs to be embedded as the.signature section, while the kernel module signature is appended at the end, when signing the ELF, the same tool script / sign-file.c used for generating the kernel module signature is not used. Instead, signelf.c modified based on this is required, and its logic is used to generate and embed the signature.

[0055] The signelf tool supports the X.509 private key + certificate single PEM file or DER file with the same format and specifications as the kernel module signature certificate as input, and also supports separate X.509 private key PEM files or DER files and X.509 certificate PEM files or DER files as input. In all combination cases, it is required that the private key corresponds one-to-one with the public key contained in the certificate.

[0056] The signelf tool is used to generate signatures for ELF files without a.signature section. It cannot be used to regenerate and replace signatures for ELF files that already have a.signature section. That is, it can only be used for initial signature release and cannot be used to republish binary files that are considered final products.

[0057] In a possible embodiment, the verification module returns skip when it determines that the executable file is complete, allowing the binfmt framework to proceed to the subsequent module for loading the ELF executable file to execute normally. Otherwise, it returns an error and blocks the binfmt framework.

[0058] In a specific implementation, the binfmt_elf_integrity module operates in the binfmt framework before binfmt_elf and binfmt_misc. Only when it detects that the ELF integrity is good will it return a skip prompt - ENOEXEC, allowing the binfmt framework to continue to execute downward to the binfmt_elf module (executing native architecture ELF files) or the binfmt_misc module (executing non-native architecture ELF files through the binfmt hook of qemu). Otherwise, it will return an error result - EBADMSG, etc., and will not allow the binfmt framework to continue execution, blocking the exec operation; for non-ELF files, it will also return a skip prompt - ENOEXEC, allowing the binfmt framework to continue to execute downward to the binfmt_script module (executing text files with a #! header, such as Shell scripts, Python scripts, etc.).

[0059] When the loaded ELF does not contain a.signature section, return -EBADMSG, do not allow the binfmt framework to continue execution, and block the exec operation; when the.signature section in the loaded ELF is not in a signature format recognizable by the kernel signature authentication module, return -EBADMSG, do not allow the binfmt framework to continue execution, and block the exec operation; when the signature certificate used by the.signature in the loaded ELF is not in the kernel certificate chain, return -EBADMSG, do not allow the binfmt framework to continue execution, and block the exec operation; when the signature hash value of the.signature in the loaded ELF does not match the expected public key of the certificate, return -EBADMSG, do not allow the binfmt framework to continue execution, and block the exec operation.

[0060] In a possible embodiment, the creation process of the verification module includes:

[0061] Write binfmt_elf_integrity.c under fs in the Linux kernel source code of the target operating system or separately outside the Linux kernel source code, and set the option of whether the verification module can be unloaded.

[0062] In a specific implementation, the binfmt_elf_integrity module is implemented by directly writing binfmt_elf_integrity.c under fs in the Linux kernel source code of the target operating system, and modifying fs / Kconfig.binfmt and fs / Makefile to add corresponding build options for the kernel. When the build option is set to y, the module will be built into the kernel and cannot be unloaded, and the integrity of all ELF executable files will be checked; when the build option is set to m, the module can be dynamically loaded, and the integrity of all ELF executable files will be checked only after it is loaded.

[0063] When the binfmt_elf_integrity module is implemented by separately writing binfmt_elf_integrity.c outside the Linux kernel source code of the target operating system, it is compiled into a module alone or with DKMS and can be loaded on demand. The integrity of all ELF executable files will be checked only after it is loaded. The module can be dynamically loaded, and the integrity of all ELF executable files will be checked only after it is loaded.

[0064] Such as Figure 3 shown is the release logic schematic diagram of the certificate and the signed ELF after using the certificate private key to sign the ELF provided by the embodiment of the present invention. Combining Figure 3It can be known that for the certificate, private key, ELF to be signed, and signed ELF, their interaction and release logic is as follows: The system or application developer holds the certificate and private key, uses signelf to sign the ELF to be signed, and generates the signed ELF; the developer releases the certificate and the signed ELF; the user can only use the developer's certificate to verify the signed ELF and perform the execution operation, but cannot modify the signature by themselves using the same certificate.

[0065] The beneficial effects of the present invention are as follows: The entire verification process is carried out in the binfmt framework of the original exec call chain for the Linux kernel to execute the ELF executable file, without registering hooks in the open process additionally, and without causing obvious performance impacts on the exec and open system calls; the verification logic is based on the existing kernel certificate chain and kernel module (driver) signature verification logic, and runs completely in the kernel space, saving multiple round trips between the kernel state and the user state. When the module is compiled as an in-kernel module, the verification logic cannot be removed by high-privilege users in the user space, avoiding the problem that the verification work is easily damaged by high-privilege attackers when progressing in the user state.

[0066] An embodiment of the present invention proposes an executable file integrity verification method based on the Linux kernel binfmt framework. The entire verification process is carried out in the binfmt framework of the original exec call chain for the Linux kernel to execute the ELF executable file, without registering hooks in the open process additionally, and without causing obvious performance impacts on the exec and open system calls; the verification logic is based on the existing kernel certificate chain and kernel module (driver) signature verification logic, and runs completely in the kernel space, saving multiple round trips between the kernel state and the user state. When the module is compiled as an in-kernel module, the verification logic cannot be removed by high-privilege users in the user space, avoiding the problem that the verification work is easily damaged by high-privilege attackers when progressing in the user state.

[0067] Embodiment 2

[0068] Embodiment 2 provided by the present invention is an embodiment of an executable file integrity verification system based on the Linux kernel binfmt framework. The embodiment of this verification system includes: a verification module registered in the Linux kernel binfmt framework.

[0069] The verification module executes before the module that loads the ELF executable file. The verification module determines whether the executable file is complete by detecting the content of the.signature section of the ELF executable file.

[0070] It can be understood that an executable file integrity verification system based on the Linux kernel binfmt framework provided by the present invention corresponds to the executable file integrity verification method based on the Linux kernel binfmt framework provided in the foregoing embodiments. The relevant technical features of the executable file integrity verification system based on the Linux kernel binfmt framework can refer to the relevant technical features of the executable file integrity verification method based on the Linux kernel binfmt framework, and will not be elaborated here.

[0071] Please refer to Figure 4 , Figure 4 which is a schematic diagram of an embodiment of an electronic device provided by an embodiment of the present invention. As Figure 4 shown, an embodiment of the present invention provides an electronic device, including a memory 1310, a processor 1320, and a computer program 1311 stored on the memory 1310 and executable on the processor 1320. When the processor 1320 executes the computer program 1311, the following steps are implemented: registering a verification module in the Linux kernel binfmt framework; the verification module is executed before the module for loading the ELF executable file, and the verification module determines whether the executable file is complete by detecting the content of the.signature section of the ELF executable file.

[0072] Please refer to Figure 5 , Figure 5 which is a schematic diagram of an embodiment of a computer-readable storage medium provided by the present invention. As Figure 5 shown, this embodiment provides a computer-readable storage medium 1400, on which a computer program 1411 is stored. When the computer program 1411 is executed by a processor, the following steps are implemented: registering a verification module in the Linux kernel binfmt framework; the verification module is executed before the module for loading the ELF executable file, and the verification module determines whether the executable file is complete by detecting the content of the.signature section of the ELF executable file.

[0073] In order to overcome the problems of existing Linux ELF executable file integrity protection technologies, which require adding hooks to the critical kernel call chain and multiple round trips between the kernel state and the user state, resulting in performance bottlenecks, and to overcome the problems that it is difficult to ensure the integrity of the user-space verification program itself and to deal with high-privilege attackers' destruction, and to overcome the problem of different trust sources for the certificate chains in the kernel state and the user state, an executable file integrity verification method based on the Linux kernel binfmt framework provided by the present invention adds the fs / binfmt_elf_integrity module, registers it before binfmt_elf, reuses the kernel's integrity verification logic for drivers, i.e., kernel modules, adds a.signature section to be verified for the ELF format extension, and verifies the integrity of all ELF files using the kernel certificate chain. The entire process is completely carried out in the kernel space, reusing the mature kernel encryption and decryption algorithm framework and the certificate-based integrity verification framework, without the assistance of an external user-space verification program, getting rid of the performance bottleneck of round trips between the kernel state and the user state, and being weakly related to other functional modules of the operating system, making it easy to transplant.

[0074] An executable file integrity verification method, system, electronic device, and storage medium based on the Linux kernel binfmt framework provided by an embodiment of the present invention.

[0075] It should be noted that in the above embodiments, the descriptions of each embodiment have their own emphases. For parts not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0076] Those skilled in the art should understand that the embodiments of the present invention can be provided as a method, system, or computer program product. Therefore, the present invention can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memories, CD-ROMs, optical memories, etc.) containing computer-usable program codes.

[0077] The present invention is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, and the combination of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded computer, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate for implementing in the process Figure 1 one process or multiple processes and / or blocksFigure 1 means for the functions specified in one or more blocks.

[0078] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to work in a particular manner, such that the instructions stored in the computer-readable memory produce a manufacture including an instruction means that implements the functions specified in one Figure 1 process or more processes and / or blocks Figure 1 or more blocks.

[0079] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus, such that a series of operational steps are performed on the computer or other programmable apparatus to produce a computer-implemented process, so that the instructions executed on the computer or other programmable apparatus provide steps for implementing the functions specified in one Figure 1 process or more processes and / or blocks Figure 1 or more blocks.

[0080] Although the preferred embodiments of the present invention have been described, additional changes and modifications can be made by those skilled in the art once they learn of the basic inventive concept. Therefore, the appended claims are intended to be construed to include the preferred embodiments as well as all changes and modifications that fall within the scope of the present invention.

[0081] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalent technologies, the present invention is also intended to include these modifications and variations.

Claims

1. An executable file integrity verification method based on the Linux kernel binfmt framework, characterized in that The method includes: Registering a verification module in the Linux kernel binfmt framework; The verification module is executed before the module for loading the ELF executable file. The verification module determines whether the executable file is complete by detecting the content of the.signature section of the ELF executable file; The process by which the verification module determines whether the executable file is complete includes: Generating an ELF executable file image based on an ELF executable file containing a valid.signature section and reading it into memory. Setting all bytes in the.signature section of the ELF executable file image to 0 to obtain a to-be-signed ELF file, and using the certificate chain in the kernel to sign the to-be-signed ELF file; Verifying the to-be-signed ELF file according to the certificate chain in the kernel. When the.signature section is not in a signature format recognizable by the kernel signature authentication module, the signature certificate used is not in the kernel certificate chain, or the signature hash value does not match the expected value of the certificate public key, it is determined that the executable file is incomplete.

2. The method according to claim 1, wherein The process by which the verification module determines whether the executable file is complete includes: Analyzing the ELF header information to determine whether the ELF executable file contains a valid.signature section. If not, it is determined that the executable file is incomplete.

3. The method according to claim 1, wherein Using the signelf tool generated by modifying the Linux kernel source code script / sign-file.c to sign the to-be-signed ELF file; The signature process of the signelf tool includes: adding an empty file with the same expected size as.signature to the ELF executable file image through objcopy --add-section.signature= to generate a to-be-signed ELF file, generating a detached signature for the to-be-signed ELF file using the same signature method as the kernel module, and incorporating the detached signature into the to-be-signed ELF file in the way of objcopy --add-section.signature=.

4. The method according to claim 1 or 2, characterized in that When the verification module determines that the executable file is complete, it returns skip, allowing the binfmt framework to proceed to the subsequent normal execution of the module for loading the ELF executable file. Otherwise, it returns an error and blocks the binfmt framework.

5. The method according to claim 1, wherein The creation process of the verification module includes: Writing binfmt_elf_integrity.c under the fs of the Linux kernel source code of the target operating system or separately writing it outside the Linux kernel source code, and setting the option of whether the verification module can be unloaded.

6. An executable file integrity verification system based on the Linux kernel binfmt framework, characterized in that The system includes: a verification module registered in the Linux kernel binfmt framework; The verification module is executed before the module for loading the ELF executable file. The verification module determines whether the executable file is complete by detecting the content of the.signature section of the ELF executable file; The process by which the verification module determines whether the executable file is complete includes: Generate an ELF executable file image based on an ELF executable file containing a valid.signature section and read it into memory. Set all bytes in the.signature section of the ELF executable file image to 0 to obtain an ELF file to be signed, and sign the ELF file to be signed using the certificate chain in the kernel. Verify the ELF file to be signed according to the certificate chain in the kernel. When the.signature section is not in a signature format recognizable by the kernel signature authentication module, the signature certificate used is not in the kernel certificate chain, or the signature hash value does not match the expected value of the certificate public key, it is determined that the executable file is incomplete.

7. An electronic device, characterized in that, It includes a memory and a processor. When the processor executes a computer management program stored in the memory, it implements the steps of the executable file integrity verification method based on the Linux kernel binfmt framework as described in any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, A computer management program is stored thereon. When the computer management program is executed by a processor, it implements the steps of the executable file integrity verification method based on the Linux kernel binfmt framework as described in any one of claims 1-5.

Images