A method and system for kernel boot measurement and trusted verification based on U-Boot

Abstract

The application discloses a kind of kernel start-up measurement and trusted verification method and system based on U-Boot, it is related to embedded system security technical field.In the initialization safety check module after U-Boot starts, establish initial trusted root and empty PCR register;Determine execution address range by loading kernel image and by decompression, relocation, according to kernel, start parameter and device tree data, hierarchically calculate first, second, third type of measurement value, extended write soft PCR register;After operating system kernel starts, extract measurement result and pass to kernel, compare with preset trusted reference value, any item mismatch triggers safety strategy, start blocking, limited mode, multi-dimensional alarm.The application constructs safety check module by software TPM and software PCR, without relying on hardware trusted module can realize kernel start-up whole process trusted protection, and measurement range is comprehensive, safety mechanism is perfect and strong universality, with wide application value.

Description

Technical Field

[0001] This invention relates to the field of embedded system security technology, specifically to an operating system kernel boot phase integrity measurement and trust verification technology based on the U-Boot bootloader, applicable to kernel boot security protection scenarios for embedded devices, industrial control equipment, and general computing platforms without a dedicated hardware trusted module (TPM). Background Technology

[0002] With the deep integration of embedded technology with the Internet of Things (IoT) and the Industrial Internet, embedded systems and general-purpose computing platforms have been widely applied in key areas such as industrial control, smart terminals, and automotive electronics. Kernel boot security directly affects the operational stability and data confidentiality of the entire system, becoming a core issue in information security. Trusted boot solutions based on the U-Boot bootloader, due to their advantages such as cross-architecture compatibility, high customizability, and adaptability to various storage media, have become the mainstream technology for ensuring kernel boot security. To address increasingly complex cyberattack threats, the industry has publicly disclosed several related technical solutions to enhance the integrity and trustworthiness of the kernel boot process.

[0003] Chinese patent (publication number CN118503979A) discloses a method, apparatus, and device for trusted booting of domestically produced embedded systems. By reading the U-Boot boot file and kernel file in segments and comparing them with preset hash values ​​to achieve boot measurement, the trusted boot efficiency is improved while ensuring security. However, this method only measures the U-Boot file and kernel file in segments and does not include boot parameters and the corrected and merged device tree data in the measurement scope. Tampering with these two types of data can directly lead to abnormal kernel boot or malicious hijacking, which poses a security vulnerability.

[0004] Chinese patent (publication number CN104951316B) discloses a kernel trusted boot method and apparatus, which uses the bootloader to measure the PCR partition and kernel code, and builds a trusted chain through a bidirectional measurement mechanism to further improve boot security. However, this method uses a single hash calculation method and lacks reinforcement mechanisms such as hierarchical hashing and weighted hash chains, resulting in limited anti-tampering and anti-collision capabilities. At the same time, the measurement results are not securely encapsulated and transmitted, making them vulnerable to replay attacks. Furthermore, the read and write permissions of the PCR register lack strict isolation and control, resulting in insufficient trustworthiness of the stored measurement values.

[0005] In addition, some technical solutions rely on dedicated trusted modules for verification, which increases hardware deployment costs and cannot be adapted to scenarios such as embedded devices and old industrial control equipment without hardware trusted modules, thus limiting their versatility.

[0006] In view of the shortcomings of the existing technologies, there is an urgent need for a kernel boot measurement and trust verification system based on U-Boot that does not rely on dedicated hardware trusted modules, has a comprehensive measurement range, a sound security mechanism, and strong versatility, so as to solve the technical bottlenecks of existing solutions and improve the security and adaptability of the entire kernel boot process. Summary of the Invention

[0007] To address the aforementioned technical issues, this application discloses a kernel boot measurement and trust verification method and system based on U-Boot, specifically including:

[0008] A security verification module is constructed, which is composed of software TPM and software PCR in collaboration.

[0009] After the system is powered on or reset, U-Boot initializes the security verification module, establishes the initial root of trust for the TPM, and clears the PCR register.

[0010] After initialization, U-Boot reads the operating system kernel image and loads it into memory. After decompression, relocation, and address adjustment, it obtains the execution address range of the system kernel in memory.

[0011] Based on the execution address range, a hierarchical digest calculation is performed on the kernel image content within the address range to generate the first metric value; the boot parameters and device tree data passed to the kernel are collected synchronously, and the second and third metric values ​​are obtained after digesting them respectively. The three metric values ​​are then written into the PCR register.

[0012] Based on three metrics, U-Boot extracts at least one metric result from the PCR register and passes it to the operating system kernel;

[0013] Based on the transmitted measurement results, after the operating system kernel starts, it compares and verifies them one by one with the preset trusted measurement values. If any measurement result is inconsistent with the trusted measurement value, the preset security control policy is triggered.

[0014] Preferably, the security verification module specifically comprises: software TPM providing an isolated secure execution environment and initial trusted root construction capability, and software PCR serving as a metric storage and expansion carrier;

[0015] During kernel boot metrics, the software TPM isolates and controls read and write permissions for the software PCR, allowing only the U-Boot bootloader to operate on the software PCR register via extended writes.

[0016] Preferably, the initial trusted root of the TPM is established as follows: the software TPM first performs a self-integrity check, and after confirming that it has not been tampered with by comparing it with the preset TPM self-digest value, it initializes the secure execution context, including configuring the cryptographic algorithm engine, establishing an isolated memory execution region, and initializing the read and write control logic of the soft PCR register; at the same time, the soft PCR module is initialized to complete the register number allocation and storage area locking operations, providing an anti-hijacking isolation environment for subsequent metric calculation and storage;

[0017] Based on the soft TPM module that has passed integrity verification, an initial root of trust is anchored. The baseline digest value of the soft TPM is used as the core anchor point of the root of trust to generate an initial trust status identifier, which is used for the trust tracing of all subsequent measurement operations.

[0018] Preferably, the execution address range of the system kernel in memory is obtained as follows: U-Boot reads the operating system kernel image file according to the preset storage medium path and loads it into the temporary storage area of ​​memory;

[0019] Parse the kernel image header information to determine the image type. If it is a compressed image, call the built-in decompression algorithm to decompress the compressed kernel image to the transition area of ​​memory and restore it to the executable kernel raw data. If it is an uncompressed image, skip the decompression step and retain the raw kernel data loaded in memory.

[0020] U-Boot performs relocation operations based on the system hardware configuration and the link address information of the kernel image;

[0021] After relocation and address adjustment are completed, U-Boot extracts the start and end addresses of each executable segment and data segment of the kernel by parsing the program header table and segment table information of the kernel image.

[0022] Preferably, the three metrics are written into the PCR register, specifically as follows:

[0023] Based on the determined kernel execution address range, a hierarchical summary calculation is performed on the kernel image actually executed in memory, the first metric is calculated and written to the soft PCR register in an extended manner;

[0024] Simultaneously collect all boot parameters that U-Boot intends to pass to the kernel, calculate the second metric value, and perform PCR writing;

[0025] For the device tree data corrected and merged by U-Boot, calculate the third metric and perform PCR writing;

[0026] After completing the PCR writing of the three metrics, U-Boot reads the current value of each target PCR register through the soft TPM interface to verify whether it is consistent with the theoretical calculation value.

[0027] Preferably, the first metric is calculated and written to the soft PCR register in an expanded manner, specifically as follows:

[0028] kernel execution address range According to the size of the fixed block Divide into N consecutive data blocks, i.e. ,in , · It is a rounding function;

[0029] Perform a CRC32 pre-check on each data block to ensure that there are no transmission errors during data reading. The formula is as follows:

[0030]

[0031] in, For the first The CRC32 checksum of each data block. For the first One data block, This is a pre-check function that proceeds to subsequent digest calculations only if all CRC32 checksums of all data blocks are non-zero.

[0032] The first metric is calculated using a hierarchical calculation logic of block hashing, layer hashing, and root hashing, with the following formula:

[0033]

[0034]

[0035]

[0036] in, for block hash, For hash operation, This is a string concatenation operation. Grouping data strings for the intermediate layer, Grouping indexes for intermediate tiers, As a grouping factor, For block hash index, This represents the total number of kernel data blocks. For string length calculation, For the first One kernel data block The block hash value, for Layer hash, This is the root hash, i.e., the first metric.

[0037] Preferably, the second metric is: let the set of startup parameters be... Sort by ASCII code , Assign weights The formula for calculating the standardized parameter block is:

[0038]

[0039] in, For standardized parameter blocks, Convert weighted floating-point numbers to byte strings;

[0040] The weighted hash chain calculates the second metric using the following formula:

[0041]

[0042]

[0043]

[0044] in, For the first The weighted hash value of each standardized startup parameter. The aggregated value is an ordered weighted hash chain. for.

[0045] Preferably, the third metric is: device tree data Break it down by node level Data blocks Calculate the type identifier for each block Then, the third metric is calculated through a hierarchical hash chain, using the following formula:

[0046]

[0047]

[0048]

[0049] in, The hash value of the leaf node. For the hash value of the child node, This represents the number of child nodes. For non-leaf node hash values, This is the root hash, i.e., the third metric. For the root node hash, For device tree version byte string, This is the original checksum.

[0050] The preferred security control strategy is as follows:

[0051] After the operating system kernel completes the basic startup initialization, it reads the transmitted metric set through memory addressing, decapsulates and splits it, and then performs data packet anti-tampering verification to verify the uniqueness and consistency of the encapsulation factor.

[0052] After the kernel completes packet parsing and verification, it retrieves its own preset set of trusted metrics stored in a read-only encrypted partition. ,in: For kernel trust benchmark values, To establish a reliable benchmark metric for startup parameters, This is the trusted baseline metric for the device tree.

[0053] The extracted metric set is compared and verified item by item with the trusted benchmark set. If any item does not match, a security policy is triggered, the kernel initialization process is forcibly terminated, the allocated memory resources are released, and the system remains in a standby and unresponsive state. Then, it switches to a restricted running mode, the kernel shuts down non-basic hardware drivers and non-core system services, and only retains minimal running resources. The metric anomaly alarm information is output synchronously through hardware indicator lights, serial port logs, and network management ports, carrying the index of the mismatched metric value and the deviation characteristics.

[0054] The aforementioned kernel boot measurement and trusted verification system based on U-Boot includes a U-Boot boot loading module, a security verification module, a kernel loading measurement module, a measurement result transmission module, a kernel verification module, and a trusted benchmark storage module. These modules work together to implement measurement and trusted verification throughout the entire kernel boot process, specifically:

[0055] The U-Boot bootloader module is used to start the system after power-on or reset, triggering the initialization process of the security verification module, and providing basic support for memory access, storage medium reading and writing, kernel image decompression, and relocation.

[0056] The security verification module is composed of a soft TPM submodule and a soft PCR submodule. The soft TPM submodule is used to perform self-integrity verification, establish the initial trusted root of TPM, provide an isolated secure execution context and cryptographic algorithm engine support. The soft PCR submodule is used to store the measurement values ​​of the kernel, boot parameters and device tree data, and only allows the U-Boot bootloader module to operate in the extended write mode to ensure the immutability of the stored measurement values.

[0057] The kernel loading metric module, integrated into the U-Boot bootloader module, is used to read the operating system kernel image and load it into memory through the U-Boot bootloader module. After decompression, relocation, and address adjustment, the execution address range of the kernel in memory is determined. The address range is split into multiple data blocks of fixed block size and pre-verification is performed. The first metric value of the kernel image is calculated through hierarchical hash chain logic. The boot parameters to be passed to the kernel and the corrected and merged device tree data are collected synchronously. The second and third metric values ​​are calculated through weighted hash chain and node-level hash logic, respectively. The three metric values ​​are stored in the corresponding registers of the software PCR submodule in an extended write manner.

[0058] The measurement result transmission module is used to extract at least one measurement result stored in the soft PCR submodule and then transmit the trusted data packet to the operating system kernel through a device tree preset read-only node or a software and hardware isolated shared memory partition.

[0059] The trusted benchmark storage module uses a read-only encrypted partition to store a preset set of trusted metrics, which includes trusted benchmark values ​​corresponding to three metrics. The trusted benchmark values ​​are pre-calculated and generated before the system leaves the factory based on a trusted kernel image, compliant startup parameters and standard device tree data, and cannot be rewritten after being solidified.

[0060] The kernel verification module, integrated into the operating system kernel, is used to read and parse the trusted data packet during the initial kernel startup, perform secondary anti-tampering verification, and perform a cryptographic equality comparison between the parsed metric set and the trusted benchmark storage module. If any metric value is inconsistent with the corresponding trusted benchmark value, a preset security control policy is triggered. If all metric values ​​match, the kernel is allowed to continue to complete the startup process.

[0061] Compared with the prior art, the technical solution of this application has the following technical effects:

[0062] This invention implements the core security functions of TPM and PCR through software simulation, without the need for additional hardware chip deployment. It effectively controls the deployment costs of embedded devices and outdated industrial control equipment, while being compatible with computing platforms of different architectures and storage media. This solves the technical pain point of limited universality of existing solutions and broadens the application scope of trusted boot solutions.

[0063] This invention incorporates kernel image, boot parameters, and corrected and merged device tree data into the measurement scope. It designs hierarchical hash chains, weighted hash chains, and node-level hash logic for the three types of data respectively. Compared with the limitations of existing technologies that only measure the kernel or boot files, this invention forms a comprehensive measurement of the kernel, boot parameters, and device tree, which can accurately detect tampering of any key data and block the risk of kernel boot hijacking from the source.

[0064] This invention employs a composite computing mechanism of block pre-verification and layered hashing, combined with PCR extended write and read / write permission isolation control strategies. It also securely encapsulates and transmits measurement results through startup timestamps and one-time random numbers, effectively resisting replay attacks, hash collision attacks, and measurement value tampering attacks. Compared with the existing technology's single hash and simple storage methods, it significantly improves the anti-interference capability of the measurement logic and the reliability of the measurement results.

[0065] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the preferred embodiments of this application are described in detail below with reference to the accompanying drawings.

[0066] The above and other objects, advantages and features of this application will become more apparent to those skilled in the art from the following detailed description of specific embodiments in conjunction with the accompanying drawings. Attached Figure Description

[0067] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In all drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0068] Based on the description of the figures and their corresponding technical content in the document, the titles of the figures are as follows:

[0069] Figure 1 This is a flowchart of a kernel boot measurement and trust verification method based on U-Boot.

[0070] Figure 2 This is a diagram of the overall architecture of a kernel boot measurement and trusted verification system based on U-Boot.

[0071] Figure 3 This is an experimental architecture diagram of an embodiment of this application;

[0072] Figure 4 This is a diagram of the U-Boot interface PCR data and address data in an embodiment of this application;

[0073] Figure 5 This is a comparison chart of integrity test data for various methods in the embodiments of this application;

[0074] Figure 6This is a comparison chart of the anti-attack capability test data of various methods in the embodiments of this application;

[0075] Figure 7 A comparison chart of security test data storage for various methods in the embodiments of this application;

[0076] Figure 8 This is a comparison chart of startup performance test data for various methods in the embodiments of this application. Detailed Implementation

[0077] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. In the following description, specific details such as specific configurations and components are provided merely to help fully understand the embodiments of this application. Therefore, those skilled in the art should understand that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. In addition, for clarity and brevity, descriptions of known functions and structures are omitted in the embodiments.

[0078] It should be understood that the phrase "an embodiment" or "this embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "an embodiment" or "this embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

[0079] Furthermore, reference numerals and / or letters may be repeated in different examples within this application. Such repetition is for the purpose of simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or settings discussed.

[0080] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, B exists alone, and A and B exist simultaneously. The term " / and" in this article describes another type of relationship between related objects, indicating that two relationships can exist. For example, A / and B can mean: A exists alone, and A and B exist alone. In addition, the character " / " in this article generally indicates that the related objects before and after it are in an "or" relationship.

[0081] In this article, the term "at least one" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, "at least one of A and B" can mean: A exists alone, A and B exist simultaneously, or B exists alone.

[0082] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion.

[0083] Example 1 describes a kernel boot measurement and trust verification method and system based on U-Boot. Figure 1 As shown, it specifically includes:

[0084] A security verification module is constructed, which is composed of software TPM and software PCR in collaboration.

[0085] After the system is powered on or reset, U-Boot initializes the security verification module, establishes the initial root of trust for the TPM, and clears the PCR register.

[0086] After initialization, U-Boot reads the operating system kernel image and loads it into memory. After decompression, relocation, and address adjustment, it obtains the execution address range of the system kernel in memory.

[0087] Based on the execution address range, a digest of the kernel image content within that address range is calculated to generate the first metric value;

[0088] The startup parameters and device tree data passed to the kernel are collected synchronously, and the second and third metrics are obtained after the digest is calculated. The three metrics are then written into the PCR register.

[0089] U-Boot extracts at least one metric result from the PCR register and passes it to the operating system kernel;

[0090] Based on the transmitted measurement results, after the operating system kernel starts, it compares and verifies them one by one with the preset trusted measurement values. If any measurement result is inconsistent with the trusted measurement value, the preset security control policy is triggered.

[0091] Furthermore, the security verification module specifically consists of: the software TPM providing an isolated secure execution environment and the ability to build an initial root of trust, and the software PCR serving as a storage and expansion carrier for metrics;

[0092] During kernel boot metrics, the software TPM isolates and controls read and write permissions for the software PCR, allowing only the U-Boot bootloader to operate on the software PCR register via extended writes.

[0093] Furthermore, the initialization process involves U-Boot first calling the pre-integrated soft TPM module, reading the soft TPM's own code segment, configuration parameters, and core logic data, and comparing them with a preset benchmark digest value to confirm that the soft TPM module has not been tampered with (to avoid the subsequent process failing due to the untrustworthy verification tool itself).

[0094] After the soft TPM passes its own verification, the secure execution context of the soft TPM is initialized, including: configuring the cryptographic algorithm engine for subsequent metric calculation, establishing an isolated memory execution region to prevent the metric process from being hijacked, initializing the read and write control logic of the soft PCR register, and only granting legitimate operation permissions to U-Boot; at the same time, the soft PCR module is initialized to complete register number allocation and storage area locking operations.

[0095] Based on the soft TPM module that has passed integrity verification, the initial root of trust is anchored, and the baseline digest value of the soft TPM is used as the core anchor point of the root of trust to generate an initial trust status identifier. This identifier is used for the trust tracing of all subsequent measurement operations.

[0096] According to the preset measurement strategy, U-Boot selects at least one soft PCR register to store the measurement values ​​of the subsequent kernel, boot parameters, and device tree, performs zeroing initialization, and resets the stored value of the target soft PCR register to the preset initial value through the security control interface of the soft TPM, while locking the zeroing result to prevent the intermediate state from being tampered with after zeroing and before the measurement value is written.

[0097] Furthermore, the specific execution address range of the system kernel in memory is as follows: U-Boot reads the operating system kernel image file according to the preset storage medium path and loads it into the temporary storage area of ​​memory;

[0098] Parse the kernel image header information to determine the image type. If it is a compressed image, call the built-in decompression algorithm to decompress the compressed kernel image to the transition area of ​​memory and restore it to the executable kernel raw data. If it is an uncompressed image, skip the decompression step and retain the raw kernel data loaded in memory.

[0099] Furthermore, U-Boot performs relocation operations based on the system hardware configuration and the link address information of the kernel image, calculates the offset between the actual kernel load address and the link address, corrects instructions in the kernel code segment that rely on absolute addresses, and ensures that the address references are accurate when the kernel is executed.

[0100] Adjust the memory distribution of the kernel data segment, mapping initialized data and uninitialized data to the corresponding areas of memory respectively, while avoiding the memory space occupied by U-Boot itself and the hardware reserved addresses.

[0101] After relocation and address adjustment are completed, U-Boot extracts the start and end addresses of each executable segment and data segment of the kernel by parsing the program header table and segment table information of the kernel image.

[0102] Furthermore, the three metrics are written into the PCR register, specifically:

[0103] Based on the determined kernel execution address range, a hierarchical summary calculation is performed on the kernel image actually executed in memory, the first metric is calculated and written to the soft PCR register in an extended manner;

[0104] Simultaneously collect all boot parameters that U-Boot intends to pass to the kernel, calculate the second metric value, and perform PCR writing;

[0105] For the device tree data corrected and merged by U-Boot, calculate the third metric and perform PCR writing;

[0106] After completing the PCR writing for the three metrics, U-Boot reads the current values ​​of each target PCR register via the soft TPM interface to verify whether they match the theoretical calculation values. The formula is as follows:

[0107]

[0108]

[0109] in, This is a three-dimensional linked hash. , , These are three measurement values, For pre-validation function, There are three PCR registers. For splicing, A one-time random number. This involves splicing the initial values ​​of the three PCR registers.

[0110] Furthermore, the first metric is calculated and written to the soft PCR register in an expanded manner, specifically as follows:

[0111] kernel execution address range According to the size of the fixed block Divide into N consecutive data blocks, i.e. ,in , · It is a rounding function;

[0112] Perform a CRC32 pre-check on each data block to ensure that there are no transmission errors during data reading. The formula is as follows:

[0113]

[0114] in, For the first The CRC32 checksum of each data block. For the first One data block, This is a pre-check function that proceeds to subsequent digest calculations only if all CRC32 checksums of all data blocks are non-zero.

[0115] The first metric is calculated using a hierarchical calculation logic of block hashing, layer hashing, and root hashing, with the following formula:

[0116]

[0117]

[0118]

[0119] in, for block hash, For hash operation, This is a string concatenation operation. Grouping data strings for the intermediate layer, Grouping indexes for intermediate tiers, As a grouping factor, For block hash index, This represents the total number of kernel data blocks. For the first One kernel data block The block hash value, for Layer hash, This is the root hash, i.e., the first metric.

[0120] Furthermore, the second metric is specifically: let the set of startup parameters be... Sort by ASCII code , Assign weights The formula for calculating the standardized parameter block is:

[0121]

[0122] in, For standardized parameter blocks, Convert weighted floating-point numbers to byte strings;

[0123] The weighted hash chain calculates the second metric using the following formula:

[0124]

[0125]

[0126]

[0127] in, For the first The weighted hash value of each standardized startup parameter. The aggregated value is an ordered weighted hash chain. for.

[0128] Furthermore, the third metric, specifically, is: the device tree data. Break it down by node level Data blocks Calculate the type identifier for each block Then, the third metric is calculated through a hierarchical hash chain, using the following formula:

[0129]

[0130]

[0131]

[0132] in, The hash value of the leaf node. For the hash value of the child node, This represents the number of child nodes. For non-leaf node hash values, This is the root hash, i.e., the third metric. For the root node hash, For device tree version byte string, This is the original checksum.

[0133] Furthermore, the formulas for writing each metric value are as follows:

[0134]

[0135]

[0136]

[0137] in, , , These are the initial values ​​for PCR. , , Write each metric value separately For symmetric key based The message authentication code.

[0138] Furthermore, U-Boot reads the valid value of the soft PCR register, which has undergone extended writing, through the secure access interface of the soft TPM. , , Perform a register data integrity pre-check, the formula is:

[0139]

[0140] in, For the integrity pre-verification formula, The kernel performs global verification of aggregated values ​​in blocks. The hash chain value for the startup parameters is the hash value of the root node of the device tree. If the verification passes, it confirms that the measurement results within the PCR have not been tampered with and can be extracted.

[0141] Extract at least one metric result to form a metric set to be transmitted, and encapsulate the metric set with the unique identifier factor of this launch in a trusted manner;

[0142] The encapsulated measurement data packet is written to a designated area through a preset trusted transmission channel. The transmission channel is either one of two and mutually exclusive: written to the memory address segment of a preset read-only node in the device tree; or written to a hardware-software isolated shared memory partition, which only the kernel has access to, ensuring that the transmission process is free from hijacking and tampering.

[0143] Furthermore, the security control strategy is as follows:

[0144] After the operating system kernel completes the basic startup initialization, it reads the transmitted metric set through memory addressing, decapsulates and splits it, and then performs data packet anti-tampering verification to verify the uniqueness and consistency of the encapsulation factor.

[0145] After the kernel completes packet parsing and verification, it retrieves its own preset set of trusted metrics stored in a read-only encrypted partition. ,in: For kernel trust benchmark values, To establish a reliable benchmark metric for startup parameters, This is the trusted baseline metric for the device tree.

[0146] Perform a full, item-by-item comparison verification between the extracted metric set and the trusted benchmark set, using the following formula:

[0147]

[0148] in, Let be a logical decision function, satisfying and Returns True if the hash values ​​are identical byte-by-byte; otherwise, returns False. For global verification results, only when all participating metrics match the trusted benchmark value, If V is True, and any comparison item does not match, then V is directly determined to be False, the kernel initialization process is forcibly terminated, the allocated memory resources are released, and the system remains in a standby and unresponsive state; then it switches to restricted running mode, the kernel closes non-basic hardware drivers and non-core system services, retains only minimal running resources, and synchronously outputs measurement anomaly alarm information through hardware indicator lights, serial port logs, and network management ports, carrying the index of the mismatched measurement value and the deviation characteristics.

[0149] This embodiment details a kernel boot measurement and trust verification method and system based on U-Boot. After U-Boot boots, the security verification module is initialized, an initial root of trust is established, and the PCR register is cleared. The execution address range is determined by loading the kernel image and decompressing and relocating it. Based on the kernel, boot parameters, and device tree data, the first, second, and third types of measurement values ​​are calculated hierarchically and written to the soft PCR register. After the operating system kernel boots, the measurement results are extracted and passed to the kernel for comparison with the preset trust benchmark value. If any value does not match, a security policy is triggered, including boot blocking, restricted mode, and multi-dimensional alarms.

[0150] Example 2, based on Example 1, describes in detail a kernel boot measurement and trust verification system based on U-Boot, such as... Figure 2 The system architecture diagram shown includes the U-Boot bootloader module, security verification module, kernel loading measurement module, measurement result transmission module, kernel verification module, and trusted benchmark storage module. These modules work together to implement measurement and trusted verification throughout the entire kernel boot process, specifically:

[0151] The U-Boot bootloader module is used to start the system after power-on or reset, triggering the initialization process of the security verification module. It also provides basic support for memory access, storage medium reading and writing, kernel image decompression and relocation, and provides an execution environment for full-process measurement and verification.

[0152] The security verification module is composed of a soft TPM submodule and a soft PCR submodule. The soft TPM submodule is used to perform self-integrity verification, establish the initial trusted root of TPM, provide an isolated secure execution context and cryptographic algorithm engine support. The soft PCR submodule is used to store the measurement values ​​of the kernel, boot parameters and device tree data, and only allows the U-Boot bootloader module to operate in the extended write mode to ensure the immutability of the stored measurement values.

[0153] The kernel loading metric module is integrated into the U-Boot bootloader module. It is used to read the operating system kernel image and load it into memory through the U-Boot bootloader module. After decompression, relocation and address adjustment, the execution address range of the kernel in memory is determined. The address range is split into multiple data blocks according to a fixed block size and pre-verification is performed. The first metric value of the kernel image is calculated through hierarchical hash chain logic. The boot parameters to be passed to the kernel and the corrected and merged device tree data are collected synchronously. The second and third metric values ​​are calculated through weighted hash chain and node-level hash logic, respectively. The three metric values ​​are stored in the corresponding registers of the software PCR submodule in an extended write manner.

[0154] The measurement result transmission module is used to extract at least one measurement result stored in the soft PCR submodule, encapsulate it into a trusted data packet containing a startup timestamp, a one-time random number and an integrity check value, and transmit the trusted data packet to the operating system kernel through a device tree preset read-only node or a shared memory partition isolated by software and hardware.

[0155] The trusted benchmark storage module uses a read-only encrypted partition to store a preset set of trusted metrics, which includes trusted benchmark values ​​corresponding to three metrics. The trusted benchmark values ​​are pre-calculated and generated before the system leaves the factory based on a trusted kernel image, compliant startup parameters and standard device tree data, and cannot be rewritten after being solidified.

[0156] The kernel verification module is integrated into the operating system kernel. It is used to read and parse the trusted data packet at the beginning of kernel startup, perform secondary anti-tampering verification, and perform cryptographic equality comparison with each value in the trusted benchmark storage module. If any value does not match the corresponding trusted benchmark value, a preset security control policy is triggered. If all values ​​match, the kernel is allowed to continue to complete the startup process.

[0157] Example 3, based on Example 1 or 2, describes in detail the experiment of measuring and verifying the entire kernel boot process of a TPM industrial control terminal using the technical solution of this application, such as... Figure 3 The experimental architecture diagram shown shows that the TPM industrial control terminal is an embedded Linux system, adapted to the ARM Cortex-A53 architecture processor. The software is built on U-Boot 2023.04 and Linux kernel version 5.15, integrating software TPM, software PCR and measurement algorithm modules.

[0158] A custom security verification module is integrated into the U-Boot source code, enabling the SHA-3-512 hash algorithm, CRC32 checksum algorithm, and CSPRNG secure random number generator. The software TPM submodule has a built-in self-verification baseline digest value, and the secure execution context memory isolation range is 0x00200000-0x00300000. The software PCR submodule is configured with three dedicated registers: PCR[KERNEL] corresponds to the kernel metric, PCR[BOOTARGS] corresponds to the boot parameter metric, and PCR[DTB] corresponds to the device tree metric. The initial value InitVal is set to 32 bytes of all zeros, and only U-Boot extended write permissions are enabled. Figure 4 The U-Boot interface shown in the figure prints the corresponding PCR metric values ​​synchronously after writing, which are: PCR[KERNEL]=3a1f78bc127c0b65ef812a9e71deb326713f2c91ff613ddf919e8b866e4154e4, PCR[BOOTARGS]=1139dc2cf1d1b9912bcc46c0f4c489b9fc7e82be8664dcd5e72e19f3bc5daa68, PCR[DTB]=3b234be2412c9d1c2e79eb3cb4af57365ef5751cef5b387f676456605a1765d7;

[0159] Set data block size Hierarchical hash grouping factor The weights for memory allocation parameters are 0.3, hardware configuration parameters are 0.2, and other general parameters are 0.05.

[0160] In the read-only encrypted trusted benchmark storage partition, three types of trusted benchmark metrics are pre-stored based on trusted state data before the system leaves the factory. The first metric is the hash value of the layered hash root of the trusted Linux kernel image, the second metric is the root hash value after the weighted hash chain aggregation of the compliant boot parameter set, and the third metric is the hash value of the node-level hash root of the standard device tree data. The length of all metrics is set to 64 bytes.

[0161] After the system powers on, the processor first executes the U-Boot bootloader, triggering the security verification module initialization process. The software TPM reads its own code segment (0x00000000-0x00080000) and configuration parameters, and calculates the actual digest value using a formula. The comparison with the pre-stored trusted Linux kernel image passed the verification.

[0162] Using H as the anchor point, generate an RTM trusted identifier, initialize the secure execution context, configure the SHA-3-512 engine, and lock the isolated memory region; clear the PCR[KERNEL], PCR[BOOTARGS], and PCR[DTB] registers to InitVal, lock the storage region, and configure read and write permissions.

[0163] The compressed Linux kernel image is read from the eMMC kernel partition, loaded into a temporary memory area, and decompressed using the gzip algorithm to restore it to an executable image. Relocation is performed based on the link address. The kernel address mapping relationship with the device tree is adjusted by combining the initial device tree address 0x4000000 and the load address 0x1FFE1000. The kernel execution address range is determined by parsing the program header table [M=0x00900000, M=0x04000000].

[0164] according to Divide the kernel address range and calculate the total number of blocks. For each block, perform a CRC32 check and calculate... Globally validate aggregate value ,verify ;

[0165] Stratified calculation of the first metric Block hash Generates 8448 block hash values; layer hash Grouped into 1056 groups in total. , Root hash This yields a 64-byte first metric value.

[0166] First metric value Extended PCR writing, the writing formula is as follows: ,in This is a Unix millisecond-level timestamp (1718000000000). 32-byte random number generated for CSPRNG The built-in symmetric key for U-Boot is written; after writing, the first metric value is printed as 3a1f78bc127c0b65ef812a9e71deb326713f2c91ff613ddf919e8b866e4154e4.

[0167] Calculate the second metric. Collect startup parameter set It contains 8 parameters. Sort by ASCII code Standardized parameter block ,calculate Iterative generation , Extended writing After writing, the second metric value is printed as 1139dc2cf1d1b9912bcc46c0f4c489b9fc7e82be8664dcd5e72e19f3bc5daa68.

[0168] Calculate the third metric value Read device tree data And corrected, split into For each node data block, calculate the type identifier for each block. Leaf node hash Non-leaf node hash Root node hash ,get Extended writing After writing, the printed measurement value is 3b234be2412c9d1c2e79eb3cb4af57365ef5751cef5b387f676456605a1765d7;

[0169] Read Current value, verification The verification passed, confirming that the stored metric value is valid.

[0170] U-Boot Extraction Forming a metric set Encapsulated as Write to the shared memory partition (0x20000000-0x20001000).

[0171] During the initial Linux kernel startup, data is read from shared memory and decapsulated. ,calculate ,verify Within the startup time window, Confirm the data is valid;

[0172] Retrieve trusted benchmark set Compare item by item and Through formula ,get All are identical matches, but This leads to the global verification result. The U-Boot location mismatch is in the startup parameters. This immediately triggers the preset security control policy.

[0173] Upon executing the security policy, the kernel immediately executes the initialization process termination instruction, releasing the allocated memory resources (kernel load address range and Ramdisk area 0x1FFF2000-0x1FFFFBB9), and the system remains in a standby, unresponsive state. It then switches to restricted operation mode, disabling Ethernet and non-core GPIO peripheral drivers, retaining only the serial port and basic monitoring modules. GPIO indicator lights flash at a 1Hz frequency as an alarm, and the serial port outputs an exception log, including startup parameter measurement mismatches and indexes. This corresponds to PCR[BOOTARGS], and its tampering characteristics include: an abnormal root partition address. At the same time, it reports alarm information to the management terminal through a reserved network port, which helps maintenance personnel locate the problem.

[0174] After checking the startup parameters altered This causes changes in the weighted hash chain aggregation value, which in turn causes H2 to deviate from the baseline value, thus verifying the effectiveness and accuracy of this method.

[0175] This embodiment describes in detail the experiment of measuring and verifying the entire kernel boot process of a TPM industrial control terminal using the technical solution of this application. During the process, the measurement of this method covers the kernel, boot parameters, and device tree, and can detect any key data tampering. Moreover, the entire process of trust verification is completed only through software modules, which reflects the comprehensiveness, effectiveness and versatility of this method.

[0176] Example 4, based on Example 1 or 2, details multiple rounds of testing conducted on the method under a controlled laboratory environment. The tests simultaneously compared the method with commonly used existing methods such as the Segmented Hash Metrics Method (SHMS) and the Bidirectional Metric Trusted Chain Method (BMTC). The focus was on testing the metric integrity, attack resistance, storage security, and startup performance of each method. The specific testing process is as follows:

[0177] The test used an x86 architecture Intel Xeon E3-1230v5 processor. All three solutions used the same basic software configuration, with only the measurement and verification modules being deployed differently. The operating systems used were U-Boot 2023.04, Linux kernel 5.15, and CentOS 8. QEMU 7.2 was used to simulate the kernel boot environment, Wireshark was used to capture network attack packets, KernelShark was used to analyze kernel boot performance, custom attack scripts were used to generate parameters for modification, and attack test cases were replayed.

[0178] The segmented hash measurement method (SHMS method) integrates segmented measurement modules for U-Boot files and kernel files in U-Boot according to its technical logic, and presets the trusted hash values ​​of the two types of files.

[0179] The Bidirectional Metric Trusted Chain (BMTC) method integrates the Bootloader metric module with the bidirectional metric trusted chain, uses a single hash to calculate kernel code and PCR partition data, and transmits metric results directly in plaintext.

[0180] This method involves: integrating a soft TPM / soft PCR security verification module and configuring block parameters. Start parameter weighting rules, trusted benchmark set It is embedded in a read-only encrypted partition, enabling the encapsulation and delivery of measurement results and isolating them from PCR permissions.

[0181] Four rounds of testing were designed, covering four dimensions: metric integrity, attack resistance, storage security, and startup performance. Each round of testing was repeated 50 times, and the test cases covered normal startup, malicious tampering, and attack injection scenarios. The data obtained are shown in Tables 1-4 below:

[0182] Table 1 Results of the Measurement Integrity Test

[0183]

[0184] According to Table 1 and Figure 5 As shown in the integrity test data graphs of each method, SHMS and BMTC can only cover kernel measurements, and the detection rate of boot parameters and device tree tampering is 0%, which poses a fatal security vulnerability. Our method achieves a 100% detection rate for all three types of tampering and a 100% accuracy rate in anomaly localization. It achieves full-range measurement of the kernel, boot parameters, and device tree, and its integrity and accuracy are significantly better than existing solutions, which fully verifies the stability of our method.

[0185] Table 2 Results of Anti-Attack Capability Test

[0186]

[0187] According to Table 2 and Figure 6 The comparison chart of the anti-attack capabilities of various methods shows that SHMS and BMTC, due to the lack of enhanced hashing mechanisms and secure encapsulation, have hash collision attack bypass rates of 42% and 38% respectively, and replay attack success rates as high as 92% and 98%, indicating weak anti-attack capabilities. Our method, through layered hashing, weighted hash chains, and encapsulation mechanisms, achieves a 100% interception rate for both types of attacks, with no false interceptions, demonstrating a significant breakthrough in anti-attack capabilities.

[0188] Table 3 Storage security test results

[0189]

[0190] According to Table 3 and Figure 7The comparison chart of storage security test data for each method shows that in 50 tampering tests, SHMS, lacking a PCR storage mechanism, could not achieve reliable storage of metrics, and the source of the metric data could not be traced in any instance; BMTC, due to the lack of access control for PCR, had a 78.6% success rate in illegally reading PCR data; this method aggregates values ​​through soft TPM access control and integrity verification. Verification showed that all 50 attempts at tampering were successfully intercepted, and the consistency of PCR data remained 100%, overcoming the core defects of existing solutions.

[0191] Table 4 Startup performance test results

[0192]

[0193] According to Table 4 and Figure 8 The performance test data comparison chart of each method shows that, according to the average of 50 sample tests, although the time consumption of this method is increased due to the addition of soft TPM verification, hierarchical hash calculation and encapsulation and transmission steps, the time consumption is only slightly higher than SHMS, and the time consumption fluctuation coefficient of 1.41% is close to that of SHMS and BMTC, indicating that the performance loss of this method is controllable and the operation is stable.

[0194] This embodiment details multiple rounds of testing conducted on the proposed method and existing comparative methods under a controlled laboratory environment. The test results fully verify that the proposed method achieves 100% interception of collision and replay attacks through layered / weighted hashing and secure encapsulation mechanisms, with complete metric coverage and strong anti-attack capabilities. Furthermore, the soft TPM permission control and integrity verification prevent metric value tampering, ensuring storage security meets standards. At the same time, under the premise of full-scale security enhancement, performance loss is controllable.

[0195] The above are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. For those skilled in the art, the present invention can have various modifications and variations. Any changes, modifications, substitutions, integrations, and parameter changes made to these embodiments within the spirit and principles of the present invention, without departing from the principles and spirit of the present invention, through conventional substitutions or to achieve the same function, fall within the scope of protection of the present invention.

Claims

1. A kernel boot measurement and trust verification method based on U-Boot, characterized in that, include: A security verification module is constructed, which is composed of software TPM and software PCR in collaboration. After the system is powered on or reset, U-Boot initializes the security verification module, establishes the initial root of trust for the TPM, and clears the PCR register. After initialization, U-Boot reads the operating system kernel image and loads it into memory. After decompression, relocation, and address adjustment, it obtains the execution address range of the system kernel in memory. Based on the execution address range, a hierarchical summary calculation is performed on the kernel image content within that address range to generate the first metric value; The startup parameters and device tree data passed to the kernel are collected synchronously, and the second and third metrics are obtained after the digest is calculated. The three metrics are then written into the PCR register. Based on three metrics, U-Boot extracts at least one metric result from the PCR register and passes it to the operating system kernel; Based on the transmitted measurement results, after the operating system kernel starts, it compares and verifies them one by one with the preset trusted measurement values. If any measurement result is inconsistent with the trusted measurement value, the preset security control policy is triggered.

2. The kernel boot measurement and trust verification method based on U-Boot according to claim 1, characterized in that, The security verification module specifically comprises: software TPM providing an isolated secure execution environment and initial trusted root construction capability, and software PCR serving as a metric storage and expansion carrier; During kernel boot metrics, the software TPM isolates and controls read and write permissions for the software PCR, allowing only the U-Boot bootloader to operate on the software PCR register via extended writes.

3. The kernel boot measurement and trust verification method based on U-Boot according to claim 1, characterized in that, The establishment of the initial trusted root of TPM is specifically as follows: the software TPM first performs a self-integrity check, and after confirming that it has not been tampered with by comparing the preset TPM self-digest value, it initializes the secure execution context, including configuring the cryptographic algorithm engine, establishing an isolated memory execution region, and initializing the read and write control logic of the soft PCR register. Simultaneously, the soft PCR module is initialized to complete register number allocation and storage area locking operations, providing an anti-hijacking isolation environment for subsequent metric calculation and storage; Based on the soft TPM module that has passed integrity verification, an initial root of trust is anchored. The baseline digest value of the soft TPM is used as the core anchor point of the root of trust to generate an initial trust status identifier, which is used for the trust tracing of all subsequent measurement operations.

4. The kernel boot measurement and trust verification method based on U-Boot according to claim 1, characterized in that, Specifically, obtaining the execution address range of the system kernel in memory involves U-Boot reading the operating system kernel image file according to a preset storage medium path and loading it into a temporary storage area in memory. Parse the kernel image header information to determine the image type. If it is a compressed image, call the built-in decompression algorithm to decompress the compressed kernel image to the transition area of ​​memory and restore it to the executable kernel raw data. If it is an uncompressed image, skip the decompression step and retain the raw kernel data loaded in memory. U-Boot performs relocation operations based on the system hardware configuration and the link address information of the kernel image; After relocation and address adjustment are completed, U-Boot extracts the start and end addresses of each executable segment and data segment of the kernel by parsing the program header table and segment table information of the kernel image.

5. The kernel boot measurement and trust verification method based on U-Boot according to claim 1, characterized in that, The process of writing the three metrics into the PCR register specifically involves: Based on the determined kernel execution address range, a hierarchical summary calculation is performed on the kernel image actually executed in memory, the first metric is calculated and written to the soft PCR register in an extended manner; Simultaneously collect all boot parameters that U-Boot intends to pass to the kernel, calculate the second metric value, and perform PCR writing; For the device tree data corrected and merged by U-Boot, calculate the third metric and perform PCR writing; After completing the PCR writing of the three metrics, U-Boot reads the current value of each target PCR register through the soft TPM interface to verify whether it is consistent with the theoretical calculation value.

6. The kernel boot measurement and trust verification method based on U-Boot according to claim 5, characterized in that, The calculation of the first metric and its writing to the soft PCR register in an expanded manner specifically involves: kernel execution address range According to the size of the fixed block Divide into N consecutive data blocks, i.e. ,in , · It is a rounding function; Perform a CRC32 pre-check on each data block to ensure that there are no transmission errors during data reading. The formula is as follows: in, For the first The CRC32 checksum of each data block. For the first One data block, This is a pre-check function that proceeds to subsequent digest calculations only if all CRC32 checksums of all data blocks are non-zero. The first metric is calculated using a hierarchical calculation logic of block hashing, layer hashing, and root hashing, with the following formula: in, for block hash, For hash operation, This is a string concatenation operation. Grouping data strings for the intermediate layer, Grouping indexes for intermediate tiers, Grouping factor For block hash index, This represents the total number of kernel data blocks. For string length calculation, For the first One kernel data block The block hash value, for Layer hash, This is the root hash, i.e., the first metric.

7. The kernel boot measurement and trust verification method based on U-Boot according to claim 5, characterized in that, The second metric is specifically: let the set of startup parameters be... Sort by ASCII code , Assign weights The formula for calculating the standardized parameter block is: in, For standardized parameter blocks, Convert weighted floating-point numbers to byte strings; The weighted hash chain calculates the second metric using the following formula: in, For the first The weighted hash value of each standardized startup parameter. The aggregated value is an ordered weighted hash chain. for.

8. The kernel boot measurement and trust verification method based on U-Boot according to claim 5, characterized in that, The third metric is specifically: the device tree data. Decomposed by node level Data blocks Calculate the type identifier for each block Then, the third metric is calculated through a hierarchical hash chain, using the following formula: in, The hash value of the leaf node. For the hash value of the child node, This represents the number of child nodes. For non-leaf node hash values, This is the root hash, i.e., the third metric. For the root node hash, For device tree version byte string, This is the original checksum.

9. A kernel boot measurement and trust verification method based on U-Boot according to claim 1, characterized in that, The security control strategy is as follows: After the operating system kernel completes the basic startup initialization, it reads the transmitted metric set through memory addressing, decapsulates and splits it, and then performs data packet anti-tampering verification to verify the uniqueness and consistency of the encapsulation factor. After the kernel completes packet parsing and verification, it retrieves its own preset set of trusted metrics stored in a read-only encrypted partition. ,in: For kernel trust benchmark values, To establish a reliable benchmark metric for startup parameters, This is the trusted baseline metric for the device tree. The extracted metric set is compared and verified item by item with the trusted benchmark set. If any item does not match, a security policy is triggered, the kernel initialization process is forcibly terminated, the allocated memory resources are released, and the system remains in a standby and unresponsive state. Then, it switches to a restricted running mode, the kernel shuts down non-basic hardware drivers and non-core system services, and only retains minimal running resources. The metric anomaly alarm information is output synchronously through hardware indicator lights, serial port logs, and network management ports, carrying the index of the mismatched metric value and the deviation characteristics.

10. A kernel boot measurement and trust verification system based on U-Boot, used to implement any of the methods described in claims 1-9, characterized in that, It includes the U-Boot bootloader module, security verification module, kernel loading measurement module, measurement result transmission module, kernel verification module, and trusted benchmark storage module. These modules work together to implement measurement and trusted verification throughout the entire kernel boot process, specifically: The U-Boot bootloader module is used to start the system after power-on or reset, triggering the initialization process of the security verification module, and providing basic support for memory access, storage medium reading and writing, kernel image decompression, and relocation. The security verification module is composed of a soft TPM submodule and a soft PCR submodule. The soft TPM submodule is used to perform self-integrity verification, establish the initial trusted root of TPM, provide an isolated secure execution context and cryptographic algorithm engine support. The soft PCR submodule is used to store the measurement values ​​of the kernel, boot parameters and device tree data, and only allows the U-Boot bootloader module to operate in the extended write mode to ensure the immutability of the stored measurement values. The kernel loading metric module, integrated into the U-Boot bootloader module, is used to read the operating system kernel image through the U-Boot bootloader module and load it into memory. After decompression, relocation and address adjustment, the execution address range of the kernel in memory is determined. The address range is split into multiple data blocks according to a fixed block size and pre-verification is performed. The first metric value of the kernel image is calculated through hierarchical hash chain logic. The startup parameters to be passed to the kernel and the corrected and merged device tree data are collected synchronously. The second and third metric values ​​are calculated by weighted hash chain and node-level hash logic, respectively. The three metric values ​​are stored in the corresponding registers of the soft PCR submodule in an extended write manner. The measurement result transmission module is used to extract at least one measurement result stored in the soft PCR submodule and then transmit the trusted data packet to the operating system kernel through a device tree preset read-only node or a software and hardware isolated shared memory partition. The trusted benchmark storage module uses a read-only encrypted partition to store a preset set of trusted metrics. The trusted benchmark value includes three corresponding metrics. The trusted benchmark value is pre-calculated and generated before the system leaves the factory based on a trusted kernel image, compliant startup parameters and standard device tree data. It cannot be rewritten after being solidified. The kernel verification and policy execution module, integrated into the operating system kernel, is used to read and parse the trusted data packet during the initial kernel startup, perform secondary anti-tampering verification, and perform a cryptographic equality comparison between the parsed metric set and the trusted benchmark storage module. If any metric value is inconsistent with the corresponding trusted benchmark value, a preset security control policy is triggered. If all metric values ​​match, the kernel is allowed to continue to complete the startup process.

Images