A method and apparatus for loading a driver of a real-time operating system

Abstract

The application provides a kind of real-time operating system's drive loading method and device, receive drive program loading request;With the pre-defined device drive symbol table format extraction the security head of the drive program;Wherein, the security head is generated in the compilation process of the drive program, and contains the verification parameter of the drive program;The security head is attached to the head of the drive program;The drive program is obtained by pre-compiling with the matching compilation environment of the real-time operating system;The verification parameter is transmitted to the preset trusted world, and through the preset trusted world, the verification parameter is verified using the pre-set verification program;In the case where verification is passed, the drive program is normally loaded.The application faces RTOS drive, and provides a lightweight, end-to-end security enhancement mechanism from multi-dimensional such as compilation trusted chain, integrity protection, authority control, version anti-rollback and device binding.

Description

Technical Field

[0001] This invention belongs to the field of information technology, specifically relating to a driver loading method and apparatus for a real-time operating system. Background Technology

[0002] Real-time operating systems (RTOS), with their deterministic task scheduling, low interrupt latency, and lightweight kernel architecture, are widely used in safety-critical fields such as industrial control, automotive terminals, and smart IoT devices. Drivers, as the core carrier of interaction between the RTOS and hardware devices, directly determine the operational stability of the hardware devices and the system's security boundaries.

[0003] Taking RTEMS as an example, RTEMS is an open-source real-time operating system (RTOS) with excellent real-time performance and comprehensive functional modules. RTEMS is widely used in embedded devices in aerospace, industrial control, and medical equipment. Due to its highly streamlined and stable characteristics, it adopts a static loading approach for its device driver management model, meaning it is compiled into the final binary image along with the operating system source code. Device driver loading and initialization are included in the overall system initialization process and cannot be dynamically implemented. Because device drivers are tightly integrated into the operating system image, there is no need to verify driver integrity; therefore, RTEMS lacks a security verification mechanism for drivers.

[0004] In other similar real-time operating systems, some implement dynamic driver loading. However, their principle still relies on pre-compiling all drivers supported by the hardware device into the system image, and then selecting and loading the matching driver based on the actual hardware device. Compared to RTEMS' implementation, it only adds the process of dynamically matching drivers according to the program flow. If an unsupported hardware device appears, or if the driver needs to be updated, the system image still needs to be recompiled and repackaged. Due to the special nature of real-time operating systems, most do not support a process model, so there is no dynamic loading of device drivers outside the system image, nor is there a security verification mechanism. Summary of the Invention

[0005] The purpose of this invention is to provide a method and apparatus for dynamic loading of drivers for a real-time operating system, providing a lightweight, end-to-end security verification mechanism for RTOS drivers.

[0006] To achieve the above objectives, the technical solution of the present invention is as follows: A driver loading method for a real-time operating system includes: Receive driver loading request; The security header of the driver is extracted using a predefined device driver symbol table format; The security header is generated during the compilation process of the driver and contains the verification parameters of the driver; the security header is attached to the header of the driver; the driver is compiled in advance using a compilation environment that matches the real-time operating system. The verification parameters are transmitted to a preset trusted world, and the verification parameters are verified by a pre-set verification program through the preset trusted world. If the verification passes, the driver is loaded normally.

[0007] Furthermore, the safety head is generated in the following manner: When the compilation client of the driver starts compilation, it sends a driver compilation request to the compilation server; wherein, the driver compilation request carries the driver source code and the device cluster ID of this compilation task; the driver compilation request is signed with a private key pre-allocated to the compilation client; the compilation server is the compilation server that compiles the real-time operating system; After the signature verification is passed, the compilation server performs at least one of the following verifications on the driver source code: integrity verification, static screening of sensitive instructions, kernel symbol compliance verification, and static extraction of hardware behavior to obtain a first verification result; The built-in whitelist of legitimate device clusters is called, and the device cluster IDs of this compilation task are compared with the legality of the ID number, the authorization status, and the adaptation permissions to obtain the second verification result. If both the first verification result and the second verification result pass the verification, the compilation client compiles the driver source code to obtain the driver program and uploads the driver program to the compilation server. The compilation server executes a preset verification algorithm on the driver program, generates corresponding verification parameters, signs the verification parameters, and generates a standardized security header by combining all verification parameters and the signature. The compilation client receives the standardized security header and appends it to the driver header.

[0008] Furthermore, it also includes: During the compilation process of the compilation server to generate the system image of the real-time operating system, the verification rule information of the driver is written into an encrypted file in advance; During the initialization of the real-time operating system, the encrypted file is decrypted, the verification rule information is read, and written to the preset secure storage area of ​​the preset trusted world; and During the compilation of the preset trusted world, the verification program is compiled; The verification parameters are verified using a pre-set verification procedure within the preset trusted world, including: Negotiate a communication method with the preset trusted world and establish a communication connection according to the negotiation result; Based on the communication connection, the driver program and its verification parameters are sent to the preset trusted world; The preset trusted world is triggered to call the verification program, which verifies the corresponding verification parameters through the verification rule information.

[0009] Furthermore, the verification parameters include: a hybrid hash base; the verification rule information includes: a hybrid hash threshold; The verification program is invoked to verify the corresponding verification parameters using the verification rule information, including: The verification program is invoked to read the segmented data of the driver program and synthesize a real-time hybrid hash to obtain a real-time hybrid hash. The hybrid hash benchmark is compared with the real-time hybrid hash. If the comparison result is not greater than the hybrid hash threshold, the verification is deemed successful. The hybrid hash benchmark is calculated in advance by the compilation server using the same hash algorithm for each segmented data of the driver program. and: The verification parameters include: segment length baseline; the verification rule information includes: segment length deviation threshold; The verification program is invoked to verify the corresponding verification parameters using the verification rule information, including: The verification program is invoked to calculate the length of each segment of the driver data in real time using a pre-stored standard length weighting matrix, thus obtaining the real-time segment length. The length deviation between the segment length benchmark and the real-time segment length is compared with a segment length deviation threshold. If the length deviation is not greater than the segment length deviation threshold, the verification is deemed successful. The segment length benchmark is calculated in advance by the compilation server using the same standard length weighting matrix for each segment of the driver data. and: The verification parameters include: kernel call symbol overlap benchmark; the verification rule information includes: kernel symbol overlap threshold; The verification program is invoked to verify the corresponding verification parameters using the verification rule information, including: The verification program is invoked to count the set of external symbols referenced by the driver and calculate the overlap with a pre-stored trusted kernel symbol whitelist to obtain a real-time overlap. The real-time overlap is compared with the kernel call symbol overlap benchmark. If the comparison result indicates that the real-time overlap is not less than the kernel call symbol overlap benchmark, the verification is deemed successful. The kernel call symbol overlap benchmark is obtained by the compilation server in advance by calculating the overlap between the counted set of external symbols applied by the driver and the global trusted symbol whitelist.

[0010] and: The verification parameters include: the driver-specific minimum version number; the verification rule information includes: the global minimum version number; The verification program is invoked to verify the corresponding verification parameters using the verification rule information, including: The verification program is invoked to read the actual version number of the driver and compare it with the pre-stored global minimum version number and the driver-specific minimum version number to obtain the comparison result. If the actual version number is not less than the driver-specific minimum version number and not less than the global minimum version number, the verification is deemed to have passed. The driver-specific minimum version number and the global minimum version number are both determined based on the latest version number of the real-time operating system. and: The verification parameters include: a secure header signature; the verification rule information includes: the compiler server's public key; The verification program is invoked to verify the corresponding verification parameters using the verification rule information, including: The verification program is invoked to verify the security header signature using the compilation server's public key; wherein, the security header signature is the signature of the generated security header by the compilation server using its private key.

[0011] Furthermore, the verification parameters include: driver-specific hardware resource boundaries; the verification rule information includes: a global hardware resource blacklist; The verification program is invoked to verify the corresponding verification parameters using the verification rule information, including: The verification program is invoked to scan the driver to obtain the driver's real-time access boundaries. The real-time access boundaries are compared with the driver-specific hardware resource boundaries and the global hardware resource blacklist. If the real-time access boundary belongs to the driver-specific hardware resource boundaries and has no intersection with the global hardware resource blacklist, the verification is deemed successful. The driver-specific hardware resource boundaries are a matrix of legal resource access boundaries specific to the driver, generated by the compilation server after pre-scanning the driver and extracting all memory access and peripheral register read / write behaviors. This matrix describes the memory range and peripheral address range that the driver is allowed to access. and: The verification parameters include: a driver-specific port bitmap; the verification rule information includes: a globally disabled port bitmap; The verification program is invoked to verify the corresponding verification parameters using the verification rule information, including: The verification program is invoked to scan the driver program to obtain the actual pin information used by the driver program, and a real-time pin operation bitmap is generated. The driver-specific port bitmap is inverted bit by bit and ANDed with the real-time pin operation bitmap. The real-time pin operation bitmap is also ANDed with the globally prohibited port bitmap. If all operation results are zero, the verification is deemed successful. The driver-specific port bitmap is generated by the compilation server after pre-counting the legal pins in the driver program. In all port bitmaps, the bits corresponding to allowed pins are marked as 1, and the bits corresponding to prohibited pins are marked as 0. and: The verification parameters include: standard behavior hash value; the verification rule information includes: hash deviation threshold; The verification program is invoked to verify the corresponding verification parameters using the verification rule information, including: The verification program is invoked to read the driver program. Using preset instruction filtering rules and hash calculation logic, hardware access instructions in the current driver program are captured, and a real-time behavior hash value is calculated. The real-time behavior hash value is compared with the standard behavior hash value to obtain a hash deviation value. If the hash deviation value is not greater than the hash deviation threshold, the verification is deemed successful. The standard behavior hash value is generated by the compilation server pre-scanning the driver program, using preset instruction filtering rules to determine compliant instruction sequences, and using the hash calculation logic to calculate a digest of the filtered compliant instruction sequences. The compliant instruction sequences include at least one of the following: memory read / write instructions, peripheral register operation instructions, and GPIO control instructions.

[0012] Furthermore, the verification parameters correspond to the version of the system; The method further includes: In the event of a real-time operating system version update, during the compilation process, relevant parameters for generating the security header and verification rule information stored in the trusted world are generated corresponding to the updated real-time operating system version.

[0013] Furthermore, negotiating a communication method with the preset trusted world and establishing a communication connection according to the negotiation result includes: Negotiate a temporary key with the preset trusted world for transmitting the driver and its verification parameters; Sending the driver and its verification parameters to the preset trusted world based on the communication connection includes: The driver program and its verification parameters are encrypted using the temporary key, and the encrypted driver program and its verification parameters are sent to the preset trusted world through a communication interface directly connected to the preset trusted world.

[0014] Furthermore, if the verification passes, the driver is loaded normally, including: If the verification passes, the driver is loaded into the reserved MMU configuration area; wherein the MMU configuration area is reserved during the initialization of the real-time operating system.

[0015] Furthermore, it also includes: If the verification fails, the system receives a rejection credential from the preset trusted world and terminates the loading of the driver.

[0016] In another aspect, the present invention provides a driver loading device for a real-time operating system, comprising: Request receiving module: Receives driver loading requests; Security Header Extraction Module: Extracts the security header of the driver program using a predefined device driver symbol table format; wherein, the security header is generated during the compilation process of the driver program and contains the verification parameters of the driver program; the security header is appended to the header of the driver program; the driver program is pre-compiled using a compilation environment that matches the real-time operating system; Verification module: Transmits the verification parameters to a preset trusted world, and verifies the verification parameters using a pre-set verification program through the preset trusted world; Loading module: If the verification passes, the driver program is loaded normally.

[0017] Compared with the prior art, the present invention has the following beneficial effects: This disclosure provides a driver loading method for a real-time operating system (RTOS). It designs a loading process for the dynamic loading of drivers in an RTOS and provides a security verification mechanism during the dynamic loading process. Specifically, a security header is set for the dynamically loaded driver and attached to the driver header. The security header is generated during the driver compilation process and contains verification parameters for the driver. Correspondingly, a verification program is pre-set in a preset trusted world of the RTOS to verify the verification parameters. After receiving a driver loading request, the security header of the driver is extracted, and the verification parameters are verified by the pre-set verification program in the preset trusted world. Only if the driver verification passes can the driver be loaded normally. The driver loading method for a real-time operating system provided by this disclosure offers a lightweight, end-to-end security solution for the dynamic loading scheme of RTOS drivers. Attached Figure Description

[0018] Figure 1 This is a flowchart of the driver loading process for the real-time operating system in an embodiment of the present invention; Figure 2 This is a flowchart of RTOS driver compilation in an embodiment of the present invention; Figure 3 This is a schematic diagram of the drive loading device structure in an embodiment of the present invention. Detailed Implementation

[0019] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0020] The design concept of this invention is to construct a driver end-to-end secure loading mechanism with the compilation server as the root of trust and TrustZone as the core of hardware isolation and verification. Through pre-compile-time compliance screening, solidification of security baseline parameters, lightweight multi-layer verification during runtime, and hierarchical update control of system version iterations, it achieves full-process secure management of drivers from source code compilation and driver generation to device loading and operation.

[0021] Based on the above design concept, the present invention will be further described below with reference to specific embodiments and accompanying drawings.

[0022] This disclosure provides a driver loading method for a real-time operating system, such as... Figure 1 As shown, it includes the following steps: S101, Receive driver loading request; S102. Extract the security header of the driver program using a predefined device driver symbol table format; The security header is generated during the compilation process of the driver and contains the verification parameters of the driver; the security header is attached to the header of the driver; the driver is compiled in advance using a compilation environment that matches the real-time operating system. S103. Transmit the verification parameters to a preset trusted world, and verify the verification parameters using a pre-set verification program through the preset trusted world. S104. If the verification passes, the driver is loaded normally.

[0023] In this embodiment, the execution entity can be a real-time operating system (RTOS). Addressing the technical deficiency of ROS which only supports static loading and lacks a dynamic driver loading process, a dynamic driver loading process is designed. After the ROS completes initialization and the image file is running on the hardware device, it can receive driver loading requests at any time and extract the driver's security header using a predefined device driver symbol table format. The predefined device driver symbol table format defines the meaning of each part of the compiled binary driver (e.g., code segment, data segment, security header, etc.). The security header is generated during the driver compilation process. The ROS is compiled through a compilation server, and the driver is compiled through a compilation client matched with the compilation server. Here, the matched compilation client is a client authorized by the compilation server. The compilation server provides a compilation environment for the compilation client, enabling the driver compiled by the compilation client to run on the ROS compiled by the compilation server.

[0024] During the compilation process, the client needs to communicate with the compilation server to generate a security header. This security header can be attached to the driver header so that the real-time operating system can extract it for security verification when it receives a driver load request.

[0025] The security header carries verification parameters for driver validation. The real-time operating system can transmit these parameters to a pre-defined TrustZone and pre-configure a verification program for it. Upon receiving the verification parameters, the TrustZone will initiate the pre-configured program to validate the parameters. If the validation passes, the driver will load normally.

[0026] The driver loading method for a real-time operating system disclosed herein not only designs a driver loading process for a real-time operating system to dynamically load drivers, but also provides a security verification mechanism for the secure loading of drivers.

[0027] In yet another embodiment provided in this disclosure, the security header is generated in the following manner: Step 1: When the driver compilation client starts the compilation process, it sends a driver compilation request to the compilation server. The driver compilation request carries the driver source code and the device cluster ID for this compilation task; the driver compilation request is signed with a private key pre-allocated to the compilation client; the compilation server is a compilation server that compiles the real-time operating system. Step 2: After the signature verification is passed, the compilation server performs at least one of the following verifications on the driver source code: integrity verification, static screening of sensitive instructions, kernel symbol compliance verification, and static extraction of hardware behavior to obtain the first verification result; Step 3: Call the built-in legal device cluster whitelist and compare it with the device cluster ID of this compilation task to check the number legality, authorization status and adaptation permissions to obtain the second verification result; Step 4: If both the first verification result and the second verification result pass the verification, the compilation client compiles the driver source code to obtain the driver program and uploads the driver program to the compilation server. Step 5: The compilation server executes a preset verification algorithm on the driver program, generates corresponding verification parameters, signs the verification parameters, and generates a standardized security header by combining all verification parameters and the signature. Step 6: Compile the client to receive the standardized security header and append it to the driver header.

[0028] In this embodiment, the compilation process of the RTOS driver and the structural design of the security header are described in detail: RTOS driver compilation is part of the compilation phase, which is completed through the collaborative execution of the compilation client and compilation server. The process is as follows: Figure 2 As shown, it includes: 1.1 Compilation request initiation and authentication: The driver compilation client sends a driver compilation request to the compilation server, carrying the device cluster ID and driver source code. The driver compilation request is signed with a private key pre-allocated to the compilation client. The device cluster ID refers to the identifier ID of the target device cluster to which the driver will be loaded and run.

[0029] The compilation server refers to the server that compiles the real-time operating system. During the compilation process of generating the system image of the real-time operating system, a preset trusted world is compiled. During the compilation of the preset trusted world, a verification program for the drivers is pre-set. Additionally, the driver verification rules are pre-written into an encrypted file. By providing the verification rules in the encrypted file to the preset trusted world, the driver's verification parameters are verified. The driver verification rules do not need to be updated during regular business version iterations; they are only updated during system upgrades when the underlying security policies, kernel rules, and hardware resource definitions of the real-time operating system change.

[0030] After receiving the driver compilation request, the compilation server completes two-way authentication through client key verification and cluster whitelist verification to intercept illegal compilation requests.

[0031] 1.2 Static code compliance verification: After the signature verification is passed, the compilation server performs at least one of the following verifications on the driver source code: integrity verification, static screening of sensitive instructions, kernel symbol compliance verification, and static extraction of hardware behavior to obtain a first verification result; The integrity verification of source code is primarily to prevent man-in-the-middle attacks, packet loss, or malicious replacement of source code files during the network link from the client to the compilation server, ensuring that the code parsed by the compilation server is completely consistent with the original source code submitted by the developer. In implementation, the compilation client can read the complete driver source code file, calculate the original global digest value of the source code using a pre-defined hash algorithm, and upload it along with the compilation request message. The compilation server receives all text data of the source code, removes the additional headers and padding bytes from the transmission protocol, and recalculates the local source code digest using the exact same hash algorithm. The locally calculated digest is then compared with the digest uploaded by the client. If the two hash digests are completely identical, the integrity verification passes; if the digests do not match, the source code transmission is considered abnormal, the compilation is terminated, and the received source code file is discarded.

[0032] Static screening of sensitive instructions is primarily designed to proactively intercept unauthorized privileged operations, high-risk hardware operations, and system core resource erasure / read / write logic in the source code. This prevents developers from embedding backdoors, maliciously scanning the kernel, or stealing device security data. Examples include raw register write instructions, high-risk system operation instructions, and illegal memory traversal instructions. During implementation, the compilation server has a built-in library of sensitive instructions and high-risk code features. Based on lexical and syntactic analysis, it traverses the driver source code line by line, matching keywords, inline assembly fragments, and function call characteristics. Once any high-risk feature is matched, the line number of the violating code and the risk type are recorded. If no sensitive or high-risk instructions are matched in the source code, the screening passes; if any sensitive instruction is found, the source code is deemed to pose a risk of malicious hardware / system operation, and compilation is rejected.

[0033] Kernel symbol compliance verification primarily aims to restrict drivers to calling only vendor-authorized kernel exported interfaces, prohibiting drivers from privately calling internal kernel functions and security control interfaces, and preventing unauthorized calls that could create privilege escalation backdoors. The compilation server has a built-in symbol whitelist template, which records all legal kernel global symbols (kernel functions, global variables) allowed for driver calls in the current device cluster. During implementation, static lexical analysis is performed on all external (extern) references and kernel function calls in the source code, summarizing the set of all kernel symbols the source code depends on. This extracted symbol set is then compared with the symbol whitelist template, and the intersection and difference are calculated. Simultaneously, the minimum legal symbol overlap for the specific driver is calculated, serving as the runtime verification benchmark for subsequent security header writes. If all kernel symbols referenced in the source code are included in the symbol whitelist template and there are no private kernel symbols exceeding the authorized scope, the static kernel symbol verification passes. If an unknown kernel symbol not included in the template is found, the source code is directly deemed to have violated the permission rules, and compilation is rejected.

[0034] Static hardware behavior extraction is primarily used to statistically analyze all hardware access behaviors of the driver, pre-determining the allowed memory ranges, peripheral registers, and GPIO pins, thus limiting hardware operation boundaries and preventing the source code from hiding hardware read / write logic that exceeds business requirements. The extraction scope (source of compliant instruction sequences) only analyzes three types of hardware-related code; pure computation, branch jumps, and internal variable calculation code are all ignored: Memory access logic: read / write and addressing operations of business buffers and peripheral mapped memory; Peripheral register operations: configuration, read, and write code of peripheral registers such as on-chip timers, ADCs, and communication buses; GPIO control logic: pin direction configuration, level output, and input status acquisition related functions and instructions. During implementation, the source code is statically traversed, all hardware access-related code is filtered, and irrelevant computational logic is stripped away to form a driver-specific compliant instruction sequence. Based on the compliant instruction sequence, statistics are obtained on the hardware access address range and the set of GPIO pins used. A unified hash algorithm is used to operate on the compliant instruction sequence to generate a standard behavior hash, which is then uniformly stored in the security header. If the extracted hardware access addresses and GPIO pins do not intersect with the server's built-in global hardware blacklist or globally disabled GPIO bitmap, the static hardware behavior extraction verification passes; if the source code directly involves confidential hardware resources of the operating system, the compilation is rejected.

[0035] If all the above checks on the driver source code pass, the first check result is "passed"; otherwise, the first check result is "failed".

[0036] Furthermore, the built-in whitelist of legitimate device clusters is invoked, and the device cluster IDs of this compilation task are compared for number validity, authorization status, and adaptation permissions to obtain the second verification result; If both the first and second verification results pass, the compilation client compiles the driver source code to obtain the driver program and uploads the driver program to the compilation server.

[0037] 1.3 Global Feature Extraction and Security Header Calculation: Due to the limited computing power of real-time operating systems, complex source code parsing, risk screening, and feature pre-calculation can be performed offline on the compilation server. The pre-defined trusted world only performs lightweight calculations such as same-origin rule reproduction verification, without adding complex analysis logic, and only replicates a unified screening standard, without undertaking heavy tasks such as screening, judgment, and correction. During implementation, based on the uploaded driver, the compilation server executes a pre-defined verification algorithm to generate corresponding verification parameters. All verification parameters in the security header are strongly bound to the driver image. Whenever a new version of the driver is released, all parameters are forcibly rescanned, recalculated, and refreshed, with no reuse of old parameters.

[0038] 1.4 Safety head signature verification: A standardized security header is generated based on all verification parameters, and a unique authentication signature is generated by signing all verification parameters of the standardized security header with a private key.

[0039] 1.5 Driver generation and ledger retention: The compilation client receives a standardized security header, appends it to the driver header, and generates a complete driver with the security header. The compilation server stores compilation logs and security ledgers in the cloud to achieve traceability and control.

[0040] This embodiment ensures that the security header parameters are uniquely generated by the driver, preventing individual tampering of the security header to bypass verification and eliminating one-sided tampering attacks. It also ensures that unauthorized clients without legitimate compilation keys and cluster authorization cannot access the compilation service to generate compliant security headers and signatures. Multi-layer source code screening during the compilation process can intercept malicious source code in advance, eliminating the risk of unauthorized compilation of backdoor drivers from the source.

[0041] In yet another embodiment provided in this disclosure, the following steps are also included: Step 1: During the compilation process of the real-time operating system system image generated by the compilation server, the verification rule information of the driver is written into an encrypted file in advance; Step 2: During the initialization of the real-time operating system, the encrypted file is decrypted, the verification rule information is read, and written to the preset secure storage area of ​​the preset trusted world; and Step 3: During the compilation of the preset trusted world, the verification program is compiled; Then, step S103 above, "verifying the verification parameters using the preset trusted world and a pre-set verification program," can be implemented as follows: Step 1: Negotiate a communication method with the preset trusted world and establish a communication connection according to the negotiation result; Step 2: Based on the communication connection, send the driver and its verification parameters to the preset trusted world; Step 3: Trigger the preset trusted world to call the verification program, and verify the corresponding verification parameters through the verification rule information.

[0042] In this embodiment, the compilation server generates corresponding verification parameters for the driver by executing a preset verification algorithm. Since the driver is ultimately loaded and verified by the real-time operating system (RTOS), the compilation server needs to write the driver's verification rules into an encrypted file during the generation of the ROS system image. These verification rules are the rules used by the ROS to verify the driver's verification parameters. During initialization, the ROS decrypts the encrypted file and writes the read verification rule information into a pre-defined secure area, specifically a preset secure storage area within the preset TrustZone. A verification program is also set up for the preset TrustZone to handle the verification process. When the driver's dynamic loading process is triggered, the security verification process begins, triggering the verification program to perform a security verification of the driver using the verification rules.

[0043] The following section provides a detailed explanation of TrustZone's driver security loading verification scheme on the device side.

[0044] The real-time operating system negotiates a communication method with the preset trusted world and establishes a communication connection according to the negotiation result; based on the communication connection, it sends the driver and its verification parameters to the preset trusted world.

[0045] When the driver is loaded, the preset trusted world is triggered to call the verification program, which verifies the corresponding verification parameters through the verification rule information.

[0046] All verification operations are performed before driver loading; verification is not repeated during driver runtime, balancing security and real-time performance. TrustZone's verification process reads the driver's code segment, data segment, and security header data, scanning and parsing according to rules identical to those of the compilation server, extracting real-time features for comparison, and ensuring that the computational logic at both ends is consistent and unified.

[0047] In another embodiment provided in this disclosure, the verification parameters include: a hybrid hash benchmark; the verification rule information includes: a hybrid hash threshold; Step three above, "calling the verification program and verifying the corresponding verification parameters using the verification rule information," is implemented as follows: The verification program is invoked to read the segmented data of the driver program and synthesize a real-time hybrid hash to obtain the real-time hybrid hash. The hybrid hash benchmark is compared with the real-time hybrid hash. If the comparison result is not greater than the hybrid hash threshold, the verification is deemed successful. The hybrid hash benchmark is calculated by the compilation server in advance using the same hash algorithm for each segment of the driver data.

[0048] This verification is a hybrid hash integrity check, used to detect anomalies such as full-segment data tampering, partial injection, and byte replacement in the driver. During the compilation phase, the compilation server generates a hybrid hash base based on the driver's segment data, including the driver code segment, data segment, read-only segment, relocation segment, and symbol segment data, using a fixed hash algorithm. Store in the security header.

[0049] When TrustZone loads, it scans the complete driver image, calls the aforementioned verification program, reads data from each segment of the driver, and calculates the real-time hash value using the same hash algorithm. Based on the mixed hash threshold in TrustZone's built-in verification rule information The comparison is complete, and the judgment formula is as follows: .

[0050] In another embodiment provided in this disclosure, the verification parameters include: a segment length benchmark; the verification rule information includes: a segment length deviation threshold; Step three above, "calling the verification program and verifying the corresponding verification parameters using the verification rule information," is implemented as follows: The verification program is invoked to perform real-time calculations on the lengths of each segment of the driver data using a pre-stored standard length weighting matrix, thereby obtaining the real-time segment length. The length deviation between the reference segment length and the real-time segment length is compared with the segment length deviation threshold. If the length deviation is not greater than the segment length deviation threshold, the verification is deemed successful. The segment length benchmark is calculated by the compilation server in advance using the same standard length weighting matrix for each segment of the driver data.

[0051] This verification is a segment structure length compliance check, used to defend against attacks such as driver packing, redundant padding, code trimming, and malformed repackaging. During the compilation phase, the compilation server calculates the segment length benchmark for each segment of the driver's data using a pre-stored standard length weighted matrix. Write it into the security header.

[0052] TrustZone scans the driver's segment data and calculates the real-time segment length. Combined with the segment length deviation threshold in TrustZone's built-in verification rules information Determine structural compliance, if This ensures compliance and effectively blocks illegal drivers with altered structures.

[0053] In another embodiment provided in this disclosure, the verification parameters include: a kernel call symbol overlap benchmark; the verification rule information includes: a kernel symbol overlap threshold. Step three above, "calling the verification program and verifying the corresponding verification parameters using the verification rule information," is implemented as follows: The verification program is invoked to count the set of external symbols referenced by the driver and calculate the overlap with a pre-stored trusted kernel symbol whitelist to obtain the real-time overlap. The real-time overlap is compared with the kernel call symbol overlap benchmark. If the comparison result indicates that the real-time overlap is not less than the kernel call symbol overlap benchmark, the verification is deemed successful. The kernel call symbol overlap benchmark is obtained by the compilation server pre-calculating the overlap between the statistical set of external symbols used by the driver and the global trusted symbol whitelist.

[0054] This verification is a kernel call symbol compliance check, used to manage driver kernel interface call permissions and prevent unauthorized calls and backdoor function injection. During the compilation phase, the compilation server uses the aforementioned symbol whitelist template to scan the driver source code symbol set and calculate the driver-specific kernel call symbol overlap benchmark. Write it into the security header.

[0055] TrustZone has a built-in global whitelist of trusted symbols. Scan driver image to extract real-time symbol set Calculate real-time overlap The final verification condition is: This ensures that driver kernel call behavior is compliant and controllable. The kernel symbol overlap threshold in TrustZone's built-in verification rules serves as a reserved security condition, usable when further tightening of security policies is required. TrustZone contains a complete set of reserved verification rules, including a global kernel symbol overlap threshold. The regular driver loading verification process only calls the dedicated minimum overlap stored in the driver security header to complete compliance determination; the kernel symbol overlap threshold is not involved in verification by default. This preset parameter serves as a dynamically activated security condition for scenarios where the system needs to globally tighten security policies: when a high-risk vulnerability is exposed in the kernel interface, multiple batches of drivers have the risk of unauthorized symbol calls, or the overall system security level is upgraded, this kernel symbol overlap threshold constraint can be activated through an underlying system firmware update. After activation, the driver must simultaneously meet the requirement that the real-time symbol overlap is not lower than the driver-specific threshold. The design meets two conditions: first, the kernel symbol overlap threshold must be met. This design allows for full device permission tightening without recompiling or batch updating all driver firmware, balancing daily business compatibility with emergency security hardening capabilities.

[0056] In another embodiment provided in this disclosure, the verification parameters include: a driver-specific minimum version number; the verification rule information includes: a global minimum version number; Step three above, "calling the verification program and verifying the corresponding verification parameters using the verification rule information," is implemented as follows: The verification program is invoked to read the actual version number of the driver and compare it with the pre-stored global minimum version number and the driver-specific minimum version number to obtain the comparison result. If the actual version number is not less than the driver-specific minimum version number and not less than the global minimum version number, the verification is deemed successful. The driver-specific minimum version number and the global minimum version number are both determined based on the latest version number of the real-time operating system. This verification employs a two-layer version rollback prevention mechanism, using a global baseline plus a driver-specific threshold to eliminate version downgrade vulnerabilities. The lowest global version number is used in TrustZone's built-in verification rules. As a universal security threshold for all drivers; the security header stores the current driver's specific minimum version. A customized safety baseline is provided for single-drive systems.

[0057] TrustZone reads the actual release version from the driver image. It must meet the following conditions simultaneously. , Two conditions must be met for version verification to pass: no idle parameters and no verification bypass.

[0058] In another embodiment provided in this disclosure, the verification parameters include: a secure header signature; the verification rule information includes: a compilation server public key; Step three above, "calling the verification program and verifying the corresponding verification parameters using the verification rule information," is implemented as follows: The verification program is invoked to verify the secure header signature using the public key of the compilation server; The security header signature is a signature performed by the compilation server on the generated security header using its private key.

[0059] This verification is a server signature authentication verification, used to ultimately confirm the legitimacy of the driver source. During the compilation phase, the compilation server generates a secure header signature by salting a temporary challenge random number and signing all verification parameters of the secure header with the private key. .

[0060] TrustZone relies on the compiler server's public key in the verification rules information. Complete the entire trial visa; if the entire trial visa is completed... If the verification passes, it indicates that the driver is officially compiled and generated, and illegal drivers that are privately packaged or have forged security headers are blocked.

[0061] In another embodiment provided in this disclosure, the verification parameters include: driver-specific hardware resource boundaries; the verification rule information includes: a global hardware resource blacklist. Step three above, "calling the verification program and verifying the corresponding verification parameters using the verification rule information," is implemented as follows: The verification program is invoked to scan the driver and obtain the driver's real-time access boundaries; The real-time access boundary is compared with the driver-specific hardware resource boundary and the global hardware resource blacklist, respectively. If the real-time access boundary belongs to the driver-specific hardware resource boundary and has no intersection with the global hardware resource blacklist, the verification is deemed successful. The driver-specific hardware resource boundary is a legal resource access boundary matrix generated by the compilation server after pre-scanning the driver and extracting all memory access and peripheral register read / write behaviors. It is used to describe the memory range and peripheral address range that the driver is allowed to access. This verification is a hardware resource boundary verification, employing a two-layer control model of authorization and blacklisting. The security header stores the driver-specific hardware resource boundary matrix generated by the compilation server during the compilation phase. This includes a whitelist of memory and peripheral addresses that the current driver can legally access. The driver-specific hardware resource boundary is a legal resource access boundary matrix generated by the compilation server after pre-scanning the driver and extracting all memory access and peripheral register read / write behaviors. It describes the memory range and peripheral address range that the driver is allowed to access.

[0062] TrustZone's built-in verification rule information includes a global hardware resource blacklist. It contains all highly sensitive resources that are restricted from access by the driver, such as security registers, key areas, and OTPs. TrustZone scans drivers to obtain the real-time access set. It must meet the following conditions simultaneously. , This prevents unauthorized access to hardware.

[0063] In another embodiment provided in this disclosure, the verification parameters include: a driver-specific port bitmap; the verification rule information includes: a globally disabled port bitmap; Step three above, "calling the verification program and verifying the corresponding verification parameters using the verification rule information," is implemented as follows: The verification program is invoked to scan the driver program to obtain the actual pin information used by the driver program, and a real-time pin operation bitmap is generated. Invert the bitmap of the driver-specific port and perform an AND operation with the bitmap of the real-time pin operation. Perform a bitwise AND operation between the real-time pin operation bitmap and the global disabled port bitmap; If all calculation results are zero, the verification is considered successful. The driver-specific port bitmap is generated by the compilation server after pre-counting the legal pins in the driver program; and in all port bitmaps, the bits corresponding to the allowed pins are marked as 1, and the bits corresponding to the prohibited pins are marked as 0.

[0064] This verification is for GPIO port permissions. All GPIO-related parameters are in pin bitmap structure, with each bit uniquely corresponding to a physical pin; setting it to 1 indicates that the corresponding status is active. The security header stores the driver's dedicated port bitmap. The current driver's dedicated port bitmap is marked with a valid and usable pin for the current driver service. This bitmap is generated by the compilation server during the compilation phase after pre-counting the valid pins in the driver program; and in all port bitmaps, the bits corresponding to allowed pins are marked as 1, and the bits corresponding to prohibited pins are marked as 0. Globally blocked port bitmap in TrustZone's built-in verification rule information Mark the security reserved pins that are disabled throughout the system. TrustZone scans the driver image to generate a real-time pin operation bitmap. The verification is completed through two bitwise operations: ; ; This indicates that the bitmap of the driver's dedicated port is inverted. Therefore, the former of the two formulas verifies that the driver does not use pins outside the authorized range, and the latter verifies that it does not touch system-disabled pins. Both conditions must be met for the driver to be compliant.

[0065] In another embodiment provided in this disclosure, the verification parameter includes: a standard behavior hash value; the verification rule information includes: a hash deviation threshold; Step three above, "calling the verification program and verifying the corresponding verification parameters using the verification rule information," is implemented as follows: The verification program is invoked to read the driver program. Using preset instruction filtering rules and hash calculation logic, hardware access instructions in the current driver program are captured, and the real-time behavior hash value is calculated. The real-time behavior hash value is compared with the standard behavior hash value to obtain the hash deviation value; If the hash deviation value is not greater than the hash deviation threshold, the verification is deemed successful. The standard behavior hash value is generated by the compilation server pre-scanning the driver, determining the compliant instruction sequence using preset instruction filtering rules, and calculating a digest of the filtered compliant instruction sequence using the hash calculation logic; the compliant instruction sequence includes at least one of the following: memory read / write instructions, peripheral register operation instructions, and GPIO control instructions.

[0066] This verification is a driver behavior hash verification. Behavior hash is used to lock the driver's operating mode and prevent instruction tampering and abnormal behavior injection.

[0067] In this embodiment, the compliant instruction sequence includes three categories of hardware-related instructions necessary for driving business operations: memory read / write instructions, peripheral register operation instructions, and GPIO control instructions. Irrelevant instructions such as pure numerical operations, branch jumps, function calls, and stack operations are excluded. During the compilation phase, the compilation server uses preset instruction filtering rules to filter the compliant instruction sequence and calculates the standard behavior hash value through hash calculation logic. Store in the security header.

[0068] TrustZone uses the same filtering rules and calculation logic algorithm to scan and drive the image to calculate real-time behavioral hashes. Combined with the hash deviation threshold in the built-in verification rule information Determine the reasonableness of the deviation and meet the requirements. If so, the behavior is compliant.

[0069] As can be seen, the driver verification mechanism provided in this disclosure only performs lightweight bit operations, difference comparison and set judgment on the device side trusted world. The algorithm complexity is O(1), without time-consuming disassembly and large number operations, which fully meets the requirements of RTOS hard real-time operation.

[0070] In yet another embodiment provided in this disclosure, the verification parameter corresponds to the version of the system; The method further includes: In the event of a real-time operating system version update, during the compilation process, relevant parameters for generating the security header and verification rule information stored in the trusted world are generated corresponding to the updated real-time operating system version.

[0071] Typically, when compiling an operating system image, a file system image is also generated to store the operating system binary files. Since driver verification parameters are updated with each operating system version (e.g., a forced driver update is required due to an operating system upgrade), the corresponding verification parameters need to be updated each time the operating system requires a forced driver upgrade. For example, the compilation server generates verification parameters for the current version update (such as vendor public and private keys, driver behavior whitelists, etc.), encrypts these parameters, and packages them into the operating system image. The corresponding verification rule information is also updated accordingly.

[0072] In another embodiment provided in this disclosure, step one above, "negotiating a communication method with the preset trusted world and establishing a communication connection according to the negotiation result," can be implemented as follows: Negotiate a temporary key with the preset trusted world for transmitting the driver and its verification parameters; Step two above, "sending the driver and its verification parameters to the preset trusted world based on the communication connection," can be implemented as follows: The driver program and its verification parameters are encrypted using the temporary key, and the encrypted driver program and its verification parameters are sent to the preset trusted world through a communication interface directly connected to the preset trusted world.

[0073] In another embodiment provided in this disclosure, step S104 above, "if the verification passes, load the driver normally," includes: If the verification passes, the driver is loaded into the reserved Memory Management Unit (MMU) configuration area; wherein the MMU configuration area is reserved during the initialization of the real-time operating system.

[0074] In yet another embodiment provided in this disclosure, it further includes: If the verification fails, the system receives a rejection credential from the preset trusted world and terminates the loading of the driver.

[0075] In yet another embodiment provided in this disclosure, a driver loading device for a real-time operating system is also proposed, such as... Figure 3 As shown, it includes: Request receiving module: Receives driver loading requests; Security Header Extraction Module: Extracts the security header of the driver program using a predefined device driver symbol table format; wherein, the security header is generated during the compilation process of the driver program and contains the verification parameters of the driver program; the security header is appended to the header of the driver program; the driver program is pre-compiled using a compilation environment that matches the real-time operating system; Verification module: Transmits the verification parameters to a preset trusted world, and verifies the verification parameters using a pre-set verification program through the preset trusted world; Loading module: If the verification passes, the driver program is loaded normally.

[0076] The driver loading device for the real-time operating system can implement the aforementioned driver loading method for the real-time operating system and has the same beneficial effects.

[0077] The beneficial effects of this invention include: 1. This invention achieves full-dimensional anti-tampering protection for RTOS drivers: any modification to the driver code, structure, symbol calls, or hardware behavior will cause a mismatch between the real-time verification features and the security header benchmark; the security header parameters are uniquely generated by the driver, and it is impossible to tamper with the security header to bypass the verification, thus completely eliminating one-sided tampering attacks.

[0078] 2. This invention prevents unauthorized compilation and forgery of RTOS drivers: illegal clients without legitimate compilation keys and cluster authorization cannot access the compilation service to generate compliant security headers and signatures; multi-layer source code screening during the compilation process can intercept malicious source code in advance, eliminating the risk of unauthorized compilation of backdoor drivers from the source.

[0079] 3. This invention prevents RTOS driver version rollback and illegal porting: It effectively blocks the loading of old and vulnerable driver versions through a two-layer version verification mechanism; and it prevents illegal porting and theft of drivers across devices and clusters through cluster ownership verification and hardware binding mechanisms.

[0080] 4. The present invention is lightweight in performance: all complex parsing, feature extraction and benchmark calculation are completed offline on the compilation server. The trusted world on the device side only performs lightweight bit operations, difference comparison and set judgment. The algorithm complexity is O(1). There is no time-consuming disassembly and large number operation, which fully meets the requirements of RTOS hard real-time operation.

[0081] The above-described embodiments are merely preferred embodiments of the present invention and are only used to help understand the method and core ideas of this application. The scope of protection of the present invention is not limited to the above embodiments, and all technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A driver loading method for a real-time operating system, characterized in that, include: Receive driver loading request; The security header of the driver is extracted using a predefined device driver symbol table format; The security header is generated during the compilation process of the driver and contains the verification parameters of the driver; the security header is attached to the header of the driver; the driver is compiled in advance using a compilation environment that matches the real-time operating system. The verification parameters are transmitted to a preset trusted world, and the verification parameters are verified by a pre-set verification program through the preset trusted world. If the verification passes, the driver will load normally. The safety header is generated in the following manner: When the compilation client of the driver starts compilation, it sends a driver compilation request to the compilation server; wherein, the driver compilation request carries the driver source code and the device cluster ID of this compilation task; the driver compilation request is signed with a private key pre-allocated to the compilation client; the compilation server is the compilation server that compiles the real-time operating system; After the signature verification is passed, the compilation server performs at least one of the following verifications on the driver source code: integrity verification, static screening of sensitive instructions, kernel symbol compliance verification, and static extraction of hardware behavior to obtain a first verification result; The built-in whitelist of legitimate device clusters is called, and the device cluster IDs of this compilation task are compared with the legality of the ID number, the authorization status, and the adaptation permissions to obtain the second verification result. If both the first verification result and the second verification result pass the verification, the compilation client compiles the driver source code to obtain the driver program and uploads the driver program to the compilation server. The compilation server executes a preset verification algorithm on the driver program, generates corresponding verification parameters, signs the verification parameters, and generates a standardized security header by combining all verification parameters and the signature. The compilation client receives the standardized security header and appends it to the driver header.

2. The driver loading method for a real-time operating system according to claim 1, characterized in that, Also includes: During the compilation process of the compilation server to generate the system image of the real-time operating system, the verification rule information of the driver is written into an encrypted file in advance; During the initialization of the real-time operating system, the encrypted file is decrypted, the verification rule information is read, and written to the preset secure storage area of ​​the preset trusted world. as well as During the compilation of the preset trusted world, the verification program is compiled; The verification parameters are verified using a pre-set verification procedure within the preset trusted world, including: Negotiate a communication method with the preset trusted world and establish a communication connection according to the negotiation result; Based on the communication connection, the driver program and its verification parameters are sent to the preset trusted world; The preset trusted world is triggered to call the verification program, which verifies the corresponding verification parameters through the verification rule information.

3. The driver loading method for a real-time operating system according to claim 2, characterized in that, The verification parameters include: a hybrid hash base; the verification rule information includes: a hybrid hash threshold; The verification program is invoked to verify the corresponding verification parameters using the verification rule information, including: The verification program is invoked to read the segmented data of the driver program and synthesize a real-time hybrid hash. The hybrid hash benchmark is compared with the real-time hybrid hash. If the comparison result is not greater than the hybrid hash threshold, the verification is deemed successful. The hybrid hash benchmark is calculated in advance by the compilation server using the same hash algorithm for each segmented data of the driver program. and / or The verification parameters include: segment length baseline; the verification rule information includes: segment length deviation threshold; The verification program is invoked to verify the corresponding verification parameters using the verification rule information, including: The verification program is invoked to calculate the length of each segment of the driver data in real time using a pre-stored standard length weighting matrix, thus obtaining the real-time segment length. The length deviation between the segment length benchmark and the real-time segment length is compared with a segment length deviation threshold. If the length deviation is not greater than the segment length deviation threshold, the verification is deemed successful. The segment length benchmark is calculated in advance by the compilation server using the same standard length weighting matrix for each segment of the driver data. and / or The verification parameters include: kernel call symbol overlap benchmark; the verification rule information includes: kernel symbol overlap threshold; The verification program is invoked to verify the corresponding verification parameters using the verification rule information, including: The verification program is invoked to count the set of external symbols referenced by the driver and calculate the overlap with a pre-stored trusted kernel symbol whitelist to obtain a real-time overlap. The real-time overlap is compared with the kernel call symbol overlap benchmark. If the comparison result indicates that the real-time overlap is not less than the kernel call symbol overlap benchmark, the verification is deemed successful. The kernel call symbol overlap benchmark is obtained by the compilation server in advance by calculating the overlap between the counted set of external symbols applied by the driver and the global trusted symbol whitelist. and / or The verification parameters include: the driver-specific minimum version number; the verification rule information includes: the global minimum version number; The verification program is invoked to verify the corresponding verification parameters using the verification rule information, including: The verification program is invoked to read the actual version number of the driver and compare it with the pre-stored global minimum version number and the driver-specific minimum version number to obtain the comparison result. If the actual version number is not less than the driver-specific minimum version number and not less than the global minimum version number, the verification is deemed to have passed. The driver-specific minimum version number and the global minimum version number are both determined based on the latest version number of the real-time operating system. and / or The verification parameters include: a secure header signature; the verification rule information includes: the compiler server's public key; The verification program is invoked to verify the corresponding verification parameters using the verification rule information, including: The verification program is invoked to verify the security header signature using the compilation server's public key; wherein, the security header signature is the signature of the generated security header by the compilation server using its private key.

4. The driver loading method for a real-time operating system according to claim 3, characterized in that, The verification parameters include: driver-specific hardware resource boundaries; the verification rule information includes: a global hardware resource blacklist. The verification program is invoked to verify the corresponding verification parameters using the verification rule information, including: The verification program is invoked to scan the driver to obtain the driver's real-time access boundaries. The real-time access boundaries are compared with the driver-specific hardware resource boundaries and the global hardware resource blacklist. If the real-time access boundary belongs to the driver-specific hardware resource boundaries and has no intersection with the global hardware resource blacklist, the verification is deemed successful. The driver-specific hardware resource boundaries are a matrix of legal resource access boundaries specific to the driver, generated by the compilation server after pre-scanning the driver and extracting all memory access and peripheral register read / write behaviors. This matrix describes the memory range and peripheral address range that the driver is allowed to access. and / or The verification parameters include: a driver-specific port bitmap; the verification rule information includes: a globally disabled port bitmap; The verification program is invoked to verify the corresponding verification parameters using the verification rule information, including: The verification program is invoked to scan the driver program to obtain the actual pin information used by the driver program, and a real-time pin operation bitmap is generated. The driver-specific port bitmap is inverted bit by bit and ANDed with the real-time pin operation bitmap. The real-time pin operation bitmap is also ANDed with the globally prohibited port bitmap. If all operation results are zero, the verification is deemed successful. The driver-specific port bitmap is generated by the compilation server after pre-counting the legal pins in the driver program. In all port bitmaps, the bits corresponding to allowed pins are marked as 1, and the bits corresponding to prohibited pins are marked as 0. and / or The verification parameters include: standard behavior hash value; the verification rule information includes: hash deviation threshold; The verification program is invoked to verify the corresponding verification parameters using the verification rule information, including: The verification program is invoked to read the driver program. Using preset instruction filtering rules and hash calculation logic, hardware access instructions in the current driver program are captured, and a real-time behavior hash value is calculated. The real-time behavior hash value is compared with the standard behavior hash value to obtain a hash deviation value. If the hash deviation value is not greater than the hash deviation threshold, the verification is deemed successful. The standard behavior hash value is generated by the compilation server pre-scanning the driver program, using preset instruction filtering rules to determine compliant instruction sequences, and using the hash calculation logic to calculate a digest of the filtered compliant instruction sequences. The compliant instruction sequences include at least one of the following: memory read / write instructions, peripheral register operation instructions, and GPIO control instructions.

5. The driver loading method for a real-time operating system according to claim 1, characterized in that, The verification parameters correspond to the version of the system; The method further includes: In the event of a real-time operating system version update, during the compilation process, relevant parameters for generating the security header and verification rule information stored in the trusted world are generated corresponding to the updated real-time operating system version.

6. The driver loading method for a real-time operating system according to claim 2, characterized in that, Negotiating a communication method with the preset trusted world and establishing a communication connection according to the negotiation result includes: Negotiate a temporary key with the preset trusted world for transmitting the driver and its verification parameters; Sending the driver and its verification parameters to the preset trusted world based on the communication connection includes: The driver program and its verification parameters are encrypted using the temporary key, and the encrypted driver program and its verification parameters are sent to the preset trusted world through a communication interface directly connected to the preset trusted world.

7. The driver loading method for a real-time operating system according to claim 1, characterized in that, If the verification passes, the driver is loaded normally, including: If the verification passes, the driver is loaded into the reserved MMU configuration area; wherein the MMU configuration area is reserved during the initialization of the real-time operating system.

8. The driver loading method for a real-time operating system according to claim 1, characterized in that, Also includes: If the verification fails, the system receives a rejection credential from the preset trusted world and terminates the loading of the driver.

9. A driver loading device for a real-time operating system, characterized in that, include: Request receiving module: Receives driver loading requests; Security Header Extraction Module: Extracts the security header of the driver program using a predefined device driver symbol table format; wherein, the security header is generated during the compilation process of the driver program and contains the verification parameters of the driver program; the security header is appended to the header of the driver program; the driver program is pre-compiled using a compilation environment that matches the real-time operating system; Verification module: Transmits the verification parameters to a preset trusted world, and verifies the verification parameters using a pre-set verification program through the preset trusted world; Loading module: If the verification passes, the driver program is loaded normally; In the security header extraction module, the security header is generated in the following manner: When the compilation client of the driver starts compilation, it sends a driver compilation request to the compilation server; wherein, the driver compilation request carries the driver source code and the device cluster ID of this compilation task; the driver compilation request is signed with a private key pre-allocated to the compilation client; the compilation server is the compilation server that compiles the real-time operating system; After the signature verification is passed, the compilation server performs at least one of the following verifications on the driver source code: integrity verification, static screening of sensitive instructions, kernel symbol compliance verification, and static extraction of hardware behavior to obtain a first verification result; The built-in whitelist of legitimate device clusters is called, and the device cluster IDs of this compilation task are compared with the legality of the ID number, the authorization status, and the adaptation permissions to obtain the second verification result. If both the first verification result and the second verification result pass the verification, the compilation client compiles the driver source code to obtain the driver program and uploads the driver program to the compilation server. The compilation server executes a preset verification algorithm on the driver program, generates corresponding verification parameters, signs the verification parameters, and generates a standardized security header by combining all verification parameters and the signature. The compilation client receives the standardized security header and appends it to the driver header.

Images