Method, device and equipment for simulating automatic installation board card drive in real time and medium

Abstract

The invention relates to a method, device and equipment for simulating an automatic installation board card driver in real time and a medium, and the method comprises the steps: obtaining a configuration file carried by an automatic installation board card command; according to the configuration file, obtaining a corresponding equipment hardware ID set from the drive metadatabase; an installation hardware ID of the inserted board card is obtained, and if the installation hardware ID exists in the equipment hardware ID set, the installation hardware ID is transmitted to the drive metadatabase; obtaining target driver packet information in a driver metadatabase according to the installation hardware ID, and obtaining a target driver packet in a driver warehouse according to the target driver packet information; obtaining a kernel module corresponding to the target driver package, and performing GPG signature verification and kernel module compatibility verification on the kernel module; and if the verification is passed, installing the target driver package. In the whole process, by accurately matching the hardware ID and strictly verifying the safety and compatibility of the driver, accurate and automatic installation of the board card driver in real-time simulation is achieved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computers, and in particular to a method and device for automatically installing a board card driver in real-time simulation, a computer device, a storage medium, and a computer program product. BACKGROUND

[0002] In many critical fields such as industrial automation, aerospace, and energy and power systems, hardware-in-the-loop (HIL) simulation software plays an indispensable role. It can combine actual hardware with virtual simulation models to provide an efficient and reliable experimental environment for the research, testing, and verification of complex systems. In a HIL simulation system, a board card serves as a key bridge connecting actual hardware and simulation software, and its normal operation depends on the corresponding hardware driver. Only when the board card driver is correctly installed and configured can the HIL simulation system accurately obtain data from the actual hardware, realize seamless interaction between the real physical process and the virtual simulation model, and thus ensure the accuracy and effectiveness of the entire simulation experiment.

[0003] Currently, there are mainly two traditional methods for installing hardware drivers in a HIL simulation system. One is to rely on kernel module loading, such as loading a.ko file through the modprobe command to install and enable the driver. The other is for the user to manually install a third-party RPM package, which requires the user to search for a suitable driver package from various channels, download it to the local computer, and then possibly face complex operations such as compilation. However, these traditional installation methods have many serious problems. On the one hand, the driver version must match the kernel version, and once the kernel is upgraded, the originally compatible driver will be disabled, causing the board card to malfunction and seriously affecting the continuity and stability of the HIL simulation system. On the other hand, the process of manually searching for, downloading, compiling, and installing the driver is tedious and prone to errors, not only consuming a lot of time and effort, but also providing a poor user experience. In addition, the installation methods of drivers from different manufacturers vary greatly, and there is a lack of a unified standardized automatic installation process, further increasing the difficulty and complexity of driver installation.

[0004] Due to the various drawbacks of the above traditional driver installation methods, it is difficult to achieve automatic installation of the board card driver in actual applications. SUMMARY

[0005] Therefore, it is necessary to provide a method and device for automatically installing a board card driver in real-time simulation, a computer device, a computer readable storage medium, and a computer program product to solve the above technical problems.

[0006] In a first aspect, the present application provides a method for automatically installing a board card driver in real-time simulation. The method comprises: obtaining a configuration file carried by an automatic installation board card command; Based on the configuration file, obtain the corresponding set of device hardware IDs from the driver metadata database; Obtain the installation hardware ID of the inserted board; if the installation hardware ID exists in the device hardware ID set, then pass the installation hardware ID to the driver metadata database. Based on the installed hardware ID, obtain the target driver package information from the driver metadata database, and then obtain the target driver package from the driver repository based on the target driver package information. Obtain the kernel module corresponding to the target driver package, and perform GPG (GNU PrivacyGuard) signature verification and kernel module compatibility verification on the kernel module; If the verification passes, then install the target driver package.

[0007] In one embodiment, obtaining the kernel module corresponding to the target driver package includes: Detect whether the target driver package contains a kernel module; If not included, the compilation script corresponding to the kernel module will be executed to generate the kernel module; If it is included, the target driver package is parsed to obtain the corresponding kernel module.

[0008] In one embodiment, obtaining the corresponding set of device hardware IDs from the driver metadata database according to the configuration file includes: Parse the configuration file to obtain the device identifier; The corresponding set of device hardware IDs is obtained from the driver metadata database based on the device identifier.

[0009] In one embodiment, performing GPG signature verification on the kernel module includes: Install the RPM (RPM Package Manager) tool and the GPG tool to obtain the target RPM package for the kernel module; In response to the command to generate a GPG key pair, the GPG tool is invoked, and a GPG key pair is generated according to the custom configuration information; Configure the RPM tool to bind the generated GPG key pair for use in signing operations; Import the public key of the GPG key pair into the RPM database; The target RPM packet is signed using the private key of the GPG key pair to generate a signed packet file; Verify the validity of the signed package file.

[0010] In one embodiment, compatibility verification of the kernel module includes: Get the current system kernel version; Extract the dependency version field from the kernel module; Compatibility verification is performed based on the current system kernel version and the dependent version fields.

[0011] In one embodiment, the above-described method for automatically installing board drivers using real-time simulation further includes: Obtain the security verification status code generated during GPG signature verification and kernel module compatibility verification; If the security verification status code indicates successful verification, then the preset installation script is executed to install the target driver package; If the security verification status code indicates a kernel module compatibility failure, the kernel module is compiled based on the current system kernel version; once compilation is complete, a preset installation script is executed to install the target driver package. If the security verification status code indicates that the verification has failed, an installation failure message will be returned.

[0012] In one embodiment, the above-described method for automatically installing board drivers using real-time simulation further includes: If GPG verification fails, a GPG verification failure log will be generated and reported. If the installation test fails, an installation failure log will be generated and reported.

[0013] Secondly, this application also provides a device for real-time simulation and automatic installation of board drivers. The device includes: The configuration file retrieval module is used to retrieve the configuration file carried by the automatic installation board command; The hardware ID set query module is used to obtain the corresponding device hardware ID set from the driver meta database according to the configuration file. The query module is used to obtain the installation hardware ID of the inserted board. If the installation hardware ID exists in the device hardware ID set, the installation hardware ID is passed to the driver meta database. The target driver package information is obtained from the driver meta database based on the installation hardware ID, and the target driver package is obtained from the driver repository based on the target driver package information. The verification module is used to obtain the kernel module corresponding to the target driver package, and to perform GPG signature verification and kernel module compatibility verification on the kernel module. The installation module is used to install the target driver package when the verification is successful.

[0014] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps: Retrieve the configuration file carried by the automatic board installation command; Based on the configuration file, obtain the corresponding set of device hardware IDs from the driver metadata database; Obtain the installation hardware ID of the inserted board; if the installation hardware ID exists in the device hardware ID set, then pass the installation hardware ID to the driver metadata database. Based on the installed hardware ID, obtain the target driver package information from the driver metadata database, and then obtain the target driver package from the driver repository based on the target driver package information. Obtain the kernel module corresponding to the target driver package, and perform GPG signature verification and kernel module compatibility verification on the kernel module; If the verification passes, then install the target driver package.

[0015] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps: Retrieve the configuration file carried by the automatic board installation command; Based on the configuration file, obtain the corresponding set of device hardware IDs from the driver metadata database; Obtain the installation hardware ID of the inserted board; if the installation hardware ID exists in the device hardware ID set, then pass the installation hardware ID to the driver metadata database. Based on the installed hardware ID, obtain the target driver package information from the driver metadata database, and then obtain the target driver package from the driver repository based on the target driver package information. Obtain the kernel module corresponding to the target driver package, and perform GPG signature verification and kernel module compatibility verification on the kernel module; If the verification passes, then install the target driver package.

[0016] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps: Retrieve the configuration file carried by the automatic board installation command; Based on the configuration file, obtain the corresponding set of device hardware IDs from the driver metadata database; Obtain the installation hardware ID of the inserted board; if the installation hardware ID exists in the device hardware ID set, then pass the installation hardware ID to the driver metadata database. Based on the installed hardware ID, obtain the target driver package information from the driver metadata database, and then obtain the target driver package from the driver repository based on the target driver package information. Obtain the kernel module corresponding to the target driver package, and perform GPG signature verification and kernel module compatibility verification on the kernel module; If the verification passes, then install the target driver package.

[0017] The aforementioned method, apparatus, computer equipment, storage medium, and computer program product for real-time simulation automatic installation of board drivers involve: obtaining the configuration file carried by the automatic board installation command; retrieving the corresponding set of device hardware IDs from the driver metadata database based on the configuration file; obtaining the installation hardware ID of the inserted board, and if the installation hardware ID exists in the set of device hardware IDs, passing the installation hardware ID to the driver metadata database; retrieving the target driver package information from the driver metadata database based on the installation hardware ID, and retrieving the target driver package from the driver repository based on the target driver package information; obtaining the kernel module corresponding to the target driver package, and performing GPG signature verification and kernel module compatibility verification on the kernel module; and installing the target driver package if the verification passes. Throughout this process, precise automatic installation of board drivers in real-time simulation is achieved by accurately matching hardware IDs and rigorously verifying driver security and compatibility. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating a method for real-time simulation of automatic installation of board drivers in one embodiment; Figure 2 This is a flowchart illustrating a method for real-time simulation of automatic installation of board drivers in another embodiment; Figure 3 This is a schematic diagram of a sub-process for GPG signature verification of a kernel module in one embodiment; Figure 4 A flowchart illustrating a real-time simulation method for automatically installing board drivers in a specific application example. Figure 5 This is a structural block diagram of a device for real-time simulation of automatic installation of board drivers in one embodiment; Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0020] The real-time simulation automatic installation method for board drivers provided in this application can be applied to a hardware-in-the-loop (HIL) simulation system framework. It specifically comprises the following parts: a user interaction module, middleware, an automatic board driver installation module, a simulation engine, and the device. The automatic board driver installation module primarily receives the device type provided by the user interaction module (UI interface), thereby generating hardware detection, automatic board installation, and other behaviors, and feeding back the installation results to the user interaction module and the simulation engine. The real-time simulation automatic installation method for board drivers is applied to the aforementioned HIL simulation system framework. The entire system obtains the configuration file carried by the automatic board installation command; based on the configuration file, it retrieves the corresponding set of device hardware IDs from the driver metadata database; it obtains the installation hardware ID of the inserted board; if the installation hardware ID exists in the set of device hardware IDs, it passes the installation hardware ID to the driver metadata database; based on the installation hardware ID, it retrieves the target driver package information from the driver metadata database; based on the target driver package information, it retrieves the target driver package from the driver repository; it obtains the kernel module corresponding to the target driver package and performs GPG signature verification and kernel module compatibility verification on the kernel module; if the verification passes, the target driver package is installed.

[0021] In one embodiment, such as Figure 1 As shown, a method for real-time simulation and automatic installation of board drivers is provided, including the following steps: S100: Obtain the configuration file carried by the automatic installation board command.

[0022] The automatic board driver installation module is in standby mode, ready to receive automatic board installation commands from external sources. These commands can be triggered in various ways, such as by the user manually clicking the install button on a specific interface, or automatically generated based on a preset scheduled task. The configuration file carried in the command is a structured data set. The configuration file contains key information closely related to board installation, such as board type information and a list of supported devices.

[0023] S200: Based on the configuration file, retrieve the corresponding set of device hardware IDs from the driver metadata database.

[0024] The driver metadata database is a large, pre-built and maintained database that stores a large number of device hardware IDs and their related detailed information. This information covers various types and models of boards and is a crucial basis for driver matching. The automatic board driver installation module sends the configuration file to the hardware detection module. Upon receiving the configuration file, the hardware detection module activates a dedicated parsing module to parse the file, extracting key information such as the board type and the list of supported devices. Then, the hardware detection module generates a specific query statement based on this information and uses database query technology to perform a precise search in the driver metadata database. Through this search method, the hardware detection module can obtain the set of device hardware IDs corresponding to the board type specified in the configuration file. This set contains all hardware identifiers that may be applicable to that type of board.

[0025] S300: Obtain the installation hardware ID of the inserted board. If the installation hardware ID exists in the device hardware ID set, then pass the installation hardware ID to the driver metadata database.

[0026] Specifically, the hardware detection module can interact with the computer hardware interface to obtain the installation hardware ID of the inserted board in real time. The hardware detection mechanism relies on the hardware detection interface and driver provided by the automatic board installation driver module. These interfaces and drivers can identify newly inserted hardware devices and obtain their unique identification information, i.e., the installation hardware ID. After obtaining the installation hardware ID, the hardware detection module compares it with the set of device hardware IDs obtained in step S200. If the installation hardware ID exists in the set of device hardware IDs, it means that the inserted board is a device preset supported by the automatic board installation driver module. At this time, the hardware detection module will pass the installation hardware ID to the driver metadata database. The passing method can be either temporary storage and passing through a specific data structure established in memory, or writing the installation hardware ID into the relevant record in the driver metadata database through a database update operation. Here, it is confirmed whether the inserted board is an object that the automatic board installation driver module can process. Only successfully matched boards will enter the subsequent driver installation process, avoiding invalid operations on unsupported devices.

[0027] S400: Retrieves the target driver package information from the driver metadata database based on the installed hardware ID, and retrieves the target driver package from the driver repository based on the target driver package information.

[0028] The driver metadata database not only stores device hardware IDs but also records detailed driver package information corresponding to each hardware ID. This driver package information includes the driver package version number, storage location, and dependencies. The version number identifies the update level of the driver package; different versions may differ in terms of functional optimization and compatibility improvements. The storage location specifies the exact path where the driver package is stored in the driver repository, facilitating quick system location and retrieval. Dependencies indicate other software components or library files required for the driver package to function correctly. In short, the driver metadata database stores the mapping relationship between hardware IDs and driver packages, and the mapping relationship between device identifiers and hardware IDs. Specifically, it provides the relevant hardware ID based on the board type and the relevant driver package information based on the hardware ID. Based on the installed hardware ID passed in step S300, the system initiates a new round of query operations in the driver metadata database, quickly locating the record corresponding to that installed hardware ID through an indexing mechanism, thereby obtaining the target driver package information. After obtaining the target driver package information, the system extracts the corresponding target driver package from the driver repository according to the specified storage location. The driver repository serves to centrally store various driver RPM packages, categorized by manufacturer name, driver version, and kernel version. Its specific function is to provide RPM files and hardware IDs.

[0029] S500: Obtain the kernel module corresponding to the target driver package, and perform GPG signature verification and kernel module compatibility verification on the kernel module.

[0030] The system extracts the corresponding kernel module from the target driver package. A kernel module is part of the operating system kernel; it can be dynamically loaded and unloaded, providing additional functional support to the operating system. Extracting the kernel module typically involves decompressing the driver package file and locating the kernel module file according to a specific file format specification. Then, the system performs GPG signature verification. GPG is an open-source software tool for encryption and signing, using public-key cryptography to ensure data integrity and authenticity. When the driver package is released, the developer signs the kernel module using their private key, generating a unique digital signature. During verification, the system uses a pre-stored developer's public key to decrypt and verify the kernel module's signature. If the decrypted signature matches the kernel module's content, and the public key is trusted, the kernel module's origin is considered reliable and it has not been tampered with. Simultaneously, the system performs kernel module compatibility verification. Kernel module compatibility verification primarily considers the compatibility of the kernel module's required kernel versions, hardware architecture, and other factors with the current system's operating environment. The system reads relevant information from the kernel module, such as kernel version requirements and supported CPU architectures, and compares this information with the kernel version and hardware architecture currently running on the system. If the two completely match or meet certain compatibility rules, the kernel module is considered compatible with the current system. Here, GPG signature verification and kernel module compatibility verification are performed to ensure the security of the kernel module and its adaptability to the current system, preventing system failures caused by using insecure or incompatible kernel modules.

[0031] S600: If the verification passes, install the target driver package.

[0032] Once the GPG signature verification and kernel module compatibility verification in step S500 are both passed, the system determines that the target driver package meets the installation requirements. At this point, the system will start the installation program and install the target driver package into the system according to the predetermined installation process. The installation process may involve loading the kernel module into the operating system kernel, creating relevant device files, configuring system parameters, and other operations. After installation, the system will check the installation results to ensure that the driver package can work normally and that the board can be correctly recognized and used by the system. The purpose of this step is to complete the installation of the board driver while ensuring the driver package is safe and compatible, so that the board can work normally and achieve the expected functions of the system.

[0033] The above-described method for automatically installing board drivers in real-time simulation involves: obtaining the configuration file carried by the automatic board installation command; retrieving the corresponding set of device hardware IDs from the driver metadata database based on the configuration file; obtaining the installation hardware ID of the inserted board, and if the installation hardware ID exists in the set of device hardware IDs, passing the installation hardware ID to the driver metadata database; retrieving the target driver package information from the driver metadata database based on the installation hardware ID, and retrieving the target driver package from the driver repository based on the target driver package information; obtaining the kernel module corresponding to the target driver package, and performing GPG signature verification and kernel module compatibility verification on the kernel module; if the verification passes, installing the target driver package. Throughout this process, by accurately matching the hardware ID and rigorously verifying driver security and compatibility, accurate and automatic installation of board drivers in real-time simulation is achieved.

[0034] In one embodiment, such as Figure 2 As shown, obtaining the kernel module corresponding to the target driver package and performing GPG signature verification and kernel module compatibility verification on the kernel module includes: S520: Detects whether the target driver package contains a kernel module.

[0035] Based on the specific file format (e.g., .ko format) and common storage paths of kernel module files within driver packages, a comprehensive scan and analysis of the target driver package is performed. By examining file lists and header information, it is determined whether files matching the characteristics of kernel modules exist within the target driver package. This step clarifies the presence of kernel modules in the target driver package, providing a basis for subsequent operations. If a kernel module is detected, it means the driver package already contains a directly usable kernel module file; if not, it means further kernel module generation is required.

[0036] S540: If not included, execute the compilation script corresponding to the kernel module to generate the kernel module.

[0037] When step S520 indicates that the target driver package does not contain a kernel module, the system automatically triggers the execution of the compilation script. The compilation script is a pre-written set of instructions containing the compilation parameters, source file paths, and dependency library information required to generate the kernel module. Based on the configuration in the compilation script, the corresponding compilation tools can be called to compile the source files of the kernel module. During compilation, the compilation tools perform syntax analysis, code optimization, and linking on the source files according to the rules specified in the script, ultimately generating a compliant kernel module file (.ko file). Specifically, this process generates the required kernel module by compiling the source files when the target driver package lacks a kernel module, ensuring normal driver installation and use subsequently.

[0038] S560: If included, parse the target driver package and obtain the corresponding kernel module.

[0039] If step S520 detects that the target driver package contains a kernel module, the startup parsing process will decompress the target driver package using the corresponding unpacking algorithm based on the packaging format. Then, it will search and extract the kernel module file according to the naming rules and storage path of the kernel module file in the decompressed file. In this way, the corresponding kernel module file in the target driver package can be accurately obtained.

[0040] S580: Performs GPG signature verification and kernel module compatibility verification on kernel modules.

[0041] After obtaining the kernel module, the process begins with GPG signature verification and kernel module compatibility verification. Specifically, GPG signature verification uses a pre-stored valid public key to decrypt and verify the kernel module's digital signature. The digital signature, generated by the developer using their private key when releasing the kernel module, contains the module's unique identifier and integrity verification data. The signature is decrypted using the public key and compared to the actual content of the kernel module. If they match, the kernel module's origin is trustworthy and it has not been tampered with; if they do not match, the kernel module may pose a security risk and should not be used. During kernel module compatibility verification, metadata information within the kernel module can be read. This metadata contains crucial information such as the kernel versions required by the module and the hardware architecture. Simultaneously, the kernel version and hardware architecture information of the currently running system can also be obtained. Then, the kernel module's metadata information is compared in detail with the current system information to determine compatibility. For example, it checks whether the kernel version required by the kernel module is lower than or equal to the current system's kernel version, and whether the hardware architecture is consistent with the current system. Only when the kernel module is fully compatible with the current system can it be ensured that it can load and run correctly.

[0042] In one embodiment, retrieving the corresponding set of device hardware IDs from the driver metadata database according to the configuration file includes: Step 1: Parse the configuration file to obtain the device identifier.

[0043] The configuration file is parsed line by line or according to a specific structure. The configuration file typically stores device identification information in specific fields or identifiers. The hardware detection module identifies these pre-defined fields or identifiers to accurately locate and extract the device identification number. The device identification number is key information used to uniquely identify a specific type of device; it may be numbers, letters, or a combination thereof, accurately reflecting the device's category, model, and other characteristics.

[0044] Step 2: Retrieve the corresponding set of device hardware IDs from the driver metadata database based on the device identifier.

[0045] After successfully obtaining the device identifier, a connection is established with the driver metadata database. The driver metadata database stores a large number of device hardware IDs and their related detailed information, which is categorized and indexed according to the device identifier. Using the device identifier obtained in step 1 as a query condition, database query technology is employed to perform a precise retrieval in the driver metadata database. The corresponding record is quickly located based on the device identifier, and the device hardware IDs from these records are extracted and combined into a device hardware ID set. This device hardware ID set contains all hardware identifiers that match the device type represented by the device identifier; these identifiers are a crucial foundation for subsequently determining the specific board driver to install.

[0046] In one embodiment, such as Figure 3 As shown, GPG signature verification of the kernel module includes: Step 1: Install RPM and GPG tools to obtain the target RPM package for the kernel module.

[0047] Before performing GPG signature verification, ensure the system has the necessary tools and target files. First, check if the RPM and GPG tools are installed on the system by executing the commands "rpm --version" and "gpg --version" in the system command line. If not, install them according to the system's package management method (e.g., use yuminstall or dnfinstall for RPM-based systems). After installation, prepare the target RPM package corresponding to the kernel module to be signed. This target RPM package is a package format file containing the kernel module and related information; it is the foundation for subsequent signing operations.

[0048] Step 2: Respond to the command to generate a GPG key pair, invoke the GPG tool, and generate a GPG key pair based on the custom configuration information.

[0049] When GPG signature verification is required, the system will respond with a command to generate a GPG key pair. Invoke the GPG tool and use the command "gpg --full-generate-key" to start the key pair generation process. During the generation process, complete the configuration information as prompted by the system. Specifically, set the key type to RSA and RSA, which offers high security and versatility; set the key length to 4096, as a longer key length provides stronger encryption; the validity period can be set to 0 (indicating permanent validity) or a specific time can be specified to meet different usage needs; the name is set to "AutodevicesRPMXXXkey" to identify the key's purpose; the email address is set to "XXX@mycompany.com" for convenient key management and communication; and the comment is set to "RPMXXXKey" to further clarify the key's purpose. Simultaneously, set a strong password to protect the private key and prevent unauthorized use. After configuration, the GPG tool will generate a GPG key pair based on this information. Upon successful generation, it will return a prompt containing key-related information, such as "Realname:AutodevicesRPMXXXkey," which is used for subsequent key identification and operations.

[0050] Step 3: Configure the RPM tool to bind the generated GPG key pair to perform signing operations using the GPG key pair.

[0051] To enable the RPM tool to use the generated GPG key pair for signing operations, the tool needs to be configured accordingly. Create and edit the configuration file using the command "vim ~ / .rpmmacros". Add the following content to the file: "%_signaturegpg" indicates that GPG is used for signing; "%_gpg_nameAutodevicesRPMXXXkeyXXX@mycompany.com" specifies the name and email address of the GPG key pair used for signing; "%_gpg_path ~ / .gnupg" specifies the storage path for the GPG key pair. During configuration, ensure that the key ID, path, and other information entered are completely consistent with the GPG key pair generated in step 2. This will guarantee that the RPM tool can correctly recognize and use the key pair for signing operations.

[0052] Step 4: Import the public key of the GPG key pair into the RPM database.

[0053] To verify RPM packets signed using the GPG key pair, the public key of the GPG key pair needs to be imported into the RPM database. First, use the command `gpg --export -aAutodevicesRPMXXXkey` to export the public key. This command outputs the public key in ASCII format to standard output, which can be saved to a file, such as `RPM-GPG-KEY-mycompany`, by redirection. Then, use the command `sudo rpm --import RPM-GPG-KEY-mycompany` to import the exported public key into the RPM database. After importing, verify the public key's success using the command `rpm -q gpg-pubkey --qf'%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n'`. If the import is successful, the command will return information similar to `gpg-pubkey-ABCD1234-efgh5678gpg(AutodevicesRPMXXXkeyXXX@mycompany.com)`, which includes the public key's identification information.

[0054] Step 5: Sign the target RPM packet using the private key of the GPG key pair to generate a signed packet file.

[0055] After completing the above configuration and importing the public key, use the private key of the generated GPG key pair to sign the target RPM package. Execute the command "rpm --addsign *.rpm", which will invoke the RPM tool and use the GPG key pair specified in the configuration file (i.e., the key pair generated in step 2) to sign all RPM packages in the current directory. During the signing process, the RPM tool uses the private key to encrypt the contents of the RPM package, generates corresponding signature information, and adds this signature information to the RPM package, thus generating a signed package file. The signed package file contains the original RPM package content and the signature information generated using the private key. This information can be used for subsequent verification operations to ensure the integrity and trustworthiness of the RPM package's origin.

[0056] Step 6: Verify the validity of the signed package file.

[0057] After signing, the validity of the signed package file needs to be verified. Execute the command “rpm --checksigyour-package-1.0.0-1.el7.x86_64.rpm” (replace “your-package-1.0.0-1.el7.x86_64.rpm” with the actual signed package file name). This command checks the signature information in the signed package file. The verification process includes decrypting the signature information using the public key imported into the RPM database, and then comparing it with the content of the RPM package to determine if the signature is valid and if the RPM package has been tampered with. If the verification passes, the command will return information similar to “your-package-1.0.0-1.el7.x86_64.rpm:rsasha1(md5)pgpmd5OK”, indicating that the signed package file is valid, its content has not been tampered with, and its source is trustworthy. If the verification fails, it will return corresponding error information, indicating that the signature is invalid or the RPM package may have a problem.

[0058] In one embodiment, compatibility verification of the kernel module includes: Step 1: Obtain the current system kernel version.

[0059] In a system environment, the kernel version is one of the key factors determining whether kernel modules can function correctly. To obtain the current system kernel version, the standard command-line tool provided by the system is used. By executing the `uname -r` command in the terminal, this command sends a query request to the system kernel, which then returns the currently running kernel version information. For example, the returned result might be "5.15.0-86-generic," which precisely identifies the kernel version currently used by the system, including the major version number, minor version number, revision number, and some specific build identifiers.

[0060] Step 2: Extract the dependency version field from the kernel module.

[0061] Kernel modules contain various types of information, among which the dependency version field is crucial for determining their compatibility with the current system. To extract this field, a dedicated module information viewing tool, `modinfo`, is used. By executing the command `modinfoxxx.ko` (where "xxx.ko" is the filename of the kernel module to be verified), the `modinfo` tool reads the metadata information from the kernel module file and displays it in a structured manner. This displayed information includes several compatibility-related fields. For example, the "version" field may display the module's own version number, such as "535.00"; the "vermagic" field contains key information such as the kernel version identifier the module depends on, SMP (Symmetric Multiprocessing) support, preemption mode, and module unload support, such as "5.15.0-86-genericSMPpreemptmod_unload" in the example.

[0062] Step 3: Perform compatibility verification based on the current system kernel version and dependency version fields.

[0063] After obtaining the current system kernel version and the dependency version fields of the kernel modules, compatibility verification is performed. This process mainly involves a detailed comparison and analysis of two aspects of information. First, the current system kernel version (e.g., "5.15.0-86-generic") is precisely matched with the kernel version identifier (e.g., "5.15.0-86-generic") in the kernel module's "vermagic" field. If they match perfectly, it indicates that from the perspective of kernel version, the kernel module is compatible with the current system. Second, other feature information in the "vermagic" field needs to be considered, such as SMP support, preemption mode, and module unloading support. For example, if the current system has SMP enabled, but the kernel module's "vermagic" field does not indicate SMP support, the module may fail to load properly or run unstablely. By comprehensively comparing this information, it is determined whether the kernel module can be safely loaded and run stably in the current system environment. If the verification passes, it indicates that the kernel module is compatible with the current system and can be loaded safely; if the verification fails, it indicates a compatibility issue, and loading the kernel module may cause system crashes or other instability. In this case, loading the module should be avoided.

[0064] In one embodiment, the above-described method for automatically installing board drivers using real-time simulation further includes: Step 1: Obtain the security verification status code generated during GPG signature verification and kernel module compatibility verification.

[0065] In the board driver installation process, GPG signature verification ensures the legitimacy and integrity of the driver package, preventing malicious or tampered driver packages from being installed on the system. Kernel module compatibility verification determines whether the kernel modules in the target driver package are compatible with the current system kernel environment, avoiding system crashes due to incompatibility. After these two verification operations are completed, corresponding status information is generated based on the verification results. This status information is then integrated and processed to generate a security verification status code. This status code is an identifier that integrates multiple verification results. It uses a specific encoding format (such as hexadecimal encoding) to represent the overall verification status, providing crucial information for subsequent installation decisions.

[0066] Step 2: If the security verification status code indicates successful verification, execute the preset installation script to install the target driver package.

[0067] When the obtained security verification status code indicates that both GPG signature verification and kernel module compatibility verification are successful (e.g., status code 0x00), it means that the target driver package is reliable and compatible with the current system kernel, meeting the conditions for secure installation. At this point, a pre-written installation script is automatically invoked. This installation script is a pre-written program containing a series of installation instructions that can automatically handle various dependencies during the driver installation process, such as automatically installing required library files and configuring system parameters. By executing this installation script, the target driver package can be installed efficiently and accurately to the specified location, completing the board driver installation.

[0068] Step 3: If the security verification status code indicates that the kernel module compatibility has failed, then compile the kernel module based on the current system kernel version; once the compilation is complete, execute the preset installation script to install the target driver package.

[0069] When the security verification status code indicates that the kernel module compatibility verification failed (e.g., status code 0x02), it means that the kernel module in the target driver package is incompatible with the current system kernel and cannot be directly installed and used. To solve this problem, the kernel module can be recompiled based on the current system kernel version information. The compilation process is a process of converting the source code of the kernel module into a binary file that can run in the current system kernel environment. It performs targeted code generation and optimization based on the current kernel version characteristics, configuration options, etc. After compilation is complete, the compiled kernel module is checked again to see if it meets the compatibility requirements. If it is confirmed to be correct, the preset installation script will be executed. Similar to step 2, this script will automatically handle the dependencies during the installation process, install the compiled kernel module and other related files into the system, and complete the installation of the target driver package.

[0070] Step 4: If the security verification status code indicates that the verification has failed, an installation failure message will be returned.

[0071] When the security verification status code indicates GPG signature verification failure, or other situations leading to verification failure exist (e.g., status code 0x01), it indicates that the target driver package may have security risks or incompatibility issues. Installing the driver package in this case may damage the system. To ensure system security, the system will immediately stop the installation process and return an installation failure message to the user. This message will clearly inform the user of the reason for the installation failure, such as "GPG signature verification failed, driver package source is unreliable" or "kernel module compatibility verification failed and is still incompatible after compilation," so that the user understands the problem and takes appropriate measures, such as obtaining a legitimate driver package again or checking the system environment.

[0072] In one embodiment, the above-described method for automatically installing board drivers using real-time simulation further includes: Step 1: If GPG verification fails, generate a GPG verification failure log and report it.

[0073] When performing GPG verification, a series of operations, such as decryption and signature comparison, can be performed on the driver package using a pre-stored valid public key. If, during the verification process, the driver package's signature does not match a valid signature, or if decryption fails using the public key, the GPG verification is deemed a failure. At this point, a log generation mechanism is initiated to record detailed information related to the GPG verification failure, including but not limited to the specific time of the failure, the driver package's name and version number, and the error codes encountered during the verification process. After log generation, the log can be reported to a designated monitoring platform or administrator according to preset rules. Reporting can be done by sending the log file to a remote server via network transmission, or by triggering a specific notification mechanism on the local system, such as a pop-up notification window or sending an email.

[0074] Step 2: If the installation test fails, generate an installation failure log and report it.

[0075] After the installation script completes the driver package installation, the installation detection phase begins. This phase uses the modprobe tool to verify whether the driver has been successfully loaded and is running correctly. The modprobe tool attempts to load the target driver module and checks for errors during loading. It also checks whether the driver module can interact normally with other components in the system to achieve the expected functionality. If the driver module fails to load or exhibits functional abnormalities after loading, the installation detection is considered a failure. At this point, an installation failure log is generated, detailing the failure, such as the time of failure, the driver module name, and error messages encountered during loading. After generating the log, it can be sent to relevant monitoring or management personnel according to established reporting rules.

[0076] like Figure 4 As shown, in practical applications, the method for real-time simulation and automatic installation of board drivers in this application includes the following steps: Step 1: After receiving the execution command, the system will provide the file configuration to the hardware detection module.

[0077] Step 2: The hardware detection module reads the device identifier from the configuration file and retrieves the corresponding set of device hardware IDs from the driver metadata database based on the device identifier.

[0078] Step 3: If the hardware detection module detects the corresponding hardware ID, it transmits the hardware ID to the driver metadata database. If not, it logs the information and issues an alarm indicating that no board insertion has been detected.

[0079] Step 4: Retrieve driver package information from the driver metadata database based on the hardware ID.

[0080] Step 5: Obtain the driver package from the driver repository based on the driver package information.

[0081] Step 6: Check if the driver package contains a kernel module file (.ko).

[0082] Step 7: If present, skip this step and proceed directly to the next step; otherwise, execute the corresponding compilation script to generate the kernel module (.ko).

[0083] Step 8: The security verification module performs GPG signing and kernel module compatibility verification on the kernel module (.ko), and generates an installation verification code to be passed to the installation engine module.

[0084] Step 9: If GPG verification fails, end the installation process and report an alarm in the result log; otherwise, proceed to the next step.

[0085] Step 10: Install the engine module to install the driver.

[0086] Step 11: Install the engine module to perform driver installation detection. If it fails, log the process and issue an alarm, then end the installation process. If the installation is successful, pass the driver activation information to the simulation engine and end the installation process.

[0087] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0088] Based on the same inventive concept, this application also provides an apparatus for implementing the above-described method for automatically installing board drivers using real-time simulation. The solution provided by this apparatus is similar to the implementation described in the above method. Therefore, the specific limitations of one or more embodiments of the apparatus for automatically installing board drivers using real-time simulation provided below can be found in the limitations of the method for automatically installing board drivers using real-time simulation described above, and will not be repeated here.

[0089] In one embodiment, such as Figure 5 As shown, a device for real-time simulation and automatic installation of board drivers is provided, comprising: Configuration file acquisition module 100 is used to acquire the configuration file carried by the automatic installation board command; The hardware ID set query module 200 is used to obtain the corresponding device hardware ID set from the driver meta database according to the configuration file; The query module 300 is used to obtain the installation hardware ID of the inserted board. If the installation hardware ID exists in the device hardware ID set, the installation hardware ID is passed to the driver metadata database. The target driver package information is obtained from the driver metadata database based on the installation hardware ID, and the target driver package is obtained from the driver repository based on the target driver package information. Verification module 400 is used to obtain the kernel module corresponding to the target driver package and to perform GPG signature verification and kernel module compatibility verification on the kernel module. Install module 500, used to install the target driver package when verification is successful.

[0090] In one embodiment, the verification module 400 is further configured to detect whether the target driver package contains a kernel module; if not, it executes the compilation script corresponding to the kernel module to generate the kernel module; if it contains the kernel module, it parses the target driver package to obtain the corresponding kernel module.

[0091] In one embodiment, the query module 300 is further configured to parse the configuration file to obtain the device identifier; and obtain the corresponding set of device hardware IDs from the driver metadata database based on the device identifier.

[0092] In one embodiment, the verification module 400 is further configured to install RPM tools and GPG tools, obtain the target RPM package of the kernel module; respond to the command to generate a GPG key pair, call the GPG tool, and generate a GPG key pair according to custom configuration information; configure the RPM tool to bind the generated GPG key pair for signing operations using the GPG key pair; import the public key of the GPG key pair into the RPM database; sign the target RPM package using the private key of the GPG key pair to generate a signature package file; and verify the validity of the signature package file.

[0093] In one embodiment, the verification module 400 is further configured to obtain the current system kernel version; extract the dependency version field from the kernel module; and perform compatibility verification based on the current system kernel version and the dependency version field.

[0094] In one embodiment, the installation module 500 is further configured to obtain a security verification status code generated during GPG signature verification and kernel module compatibility verification; if the security verification status code indicates successful verification, a preset installation script is executed to install the target driver package; if the security verification status code indicates kernel module compatibility failure, the kernel module is compiled based on the current system kernel version; once compilation is complete, the preset installation script is executed to install the target driver package; if the security verification status code indicates verification failure, an installation failure message is returned.

[0095] In one embodiment, the installation module 500 is further configured to generate and report a GPG verification failure log when GPG verification fails, and to generate and report an installation failure log when installation detection fails.

[0096] The modules in the aforementioned real-time simulation automatic installation device for board drivers can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device, or stored in the computer device's memory as software, so that the processor can call and execute the corresponding operations of each module.

[0097] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows:Figure 6 As shown, the computer device includes a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a real-time simulation method for automatically installing board drivers. The display screen can be an LCD screen or an e-ink display screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0098] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0099] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method for real-time simulation automatic installation of board drivers.

[0100] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the above-described method for real-time simulation and automatic installation of board drivers.

[0101] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the above-described method for automatically installing board drivers using real-time simulation.

[0102] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0103] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0104] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for real-time simulation and automatic installation of board drivers, characterized in that, The method includes: Retrieve the configuration file carried by the automatic board installation command; Based on the configuration file, obtain the corresponding set of device hardware IDs from the driver metadata database; Obtain the installation hardware ID of the inserted board; if the installation hardware ID exists in the device hardware ID set, then pass the installation hardware ID to the driver metadata database. Based on the installed hardware ID, obtain the target driver package information from the driver metadata database, and then obtain the target driver package from the driver repository based on the target driver package information. Obtain the kernel module corresponding to the target driver package, and perform GPG signature verification and kernel module compatibility verification on the kernel module; If the verification passes, then install the target driver package.

2. The method according to claim 1, characterized in that, Obtaining the kernel module corresponding to the target driver package includes: Detect whether the target driver package contains a kernel module; If not included, the compilation script corresponding to the kernel module will be executed to generate the kernel module; If it is included, the target driver package is parsed to obtain the corresponding kernel module.

3. The method according to claim 1, characterized in that, The step of obtaining the corresponding device hardware ID set from the driver metadata database according to the configuration file includes: Parse the configuration file to obtain the device identifier; The corresponding set of device hardware IDs is obtained from the driver metadata database based on the device identifier.

4. The method according to claim 1, characterized in that, GPG signature verification of the kernel module includes: Install the RPM and GPG tools to obtain the target RPM package for the kernel module; In response to the command to generate a GPG key pair, the GPG tool is invoked, and a GPG key pair is generated according to the custom configuration information; Configure the RPM tool to bind the generated GPG key pair for use in signing operations; Import the public key of the GPG key pair into the RPM database; The target RPM packet is signed using the private key of the GPG key pair to generate a signed packet file; Verify the validity of the signed package file.

5. The method according to claim 1, characterized in that, Compatibility verification of the kernel module includes: Get the current system kernel version; Extract the dependency version field from the kernel module; Compatibility verification is performed based on the current system kernel version and the dependent version fields.

6. The method according to claim 1, characterized in that, The method further includes: Obtain the security verification status code generated during GPG signature verification and kernel module compatibility verification; If the security verification status code indicates successful verification, then the preset installation script is executed to install the target driver package; If the security verification status code indicates a kernel module compatibility failure, the kernel module is compiled based on the current system kernel version; once compilation is complete, a preset installation script is executed to install the target driver package. If the security verification status code indicates that the verification has failed, an installation failure message will be returned.

7. The method according to claim 1, characterized in that, The method further includes: If GPG verification fails, a GPG verification failure log will be generated and reported. If the installation test fails, an installation failure log will be generated and reported.

8. A device for real-time simulation and automatic installation of board drivers, characterized in that, The device includes: The configuration file retrieval module is used to retrieve the configuration file carried by the automatic installation board command; The hardware ID set query module is used to obtain the corresponding device hardware ID set from the driver meta database according to the configuration file. The query module is used to obtain the installation hardware ID of the inserted board. If the installation hardware ID exists in the device hardware ID set, the installation hardware ID is passed to the driver meta database. The target driver package information is obtained from the driver meta database based on the installation hardware ID, and the target driver package is obtained from the driver repository based on the target driver package information. The verification module is used to obtain the kernel module corresponding to the target driver package, and to perform GPG signature verification and kernel module compatibility verification on the kernel module. The installation module is used to install the target driver package when the verification is successful.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images