A secure boot method of an embedded Linux system

Abstract

The application provides a secure boot method of an embedded Linux system, and realizes runtime file system integrity protection by constructing a complete trust chain from a hardware root of trust to a file system. The scheme adopts a FIT firmware format in a booting stage, each level of firmware is embedded with a public key and verifies a signature step by step, and can be compared with a public key hash in an OTP / eFuse, so that the firmware is ensured to be credible. After the kernel is started, a read-only virtual block device is created based on dm-verity as an underlayer of a root file system, and a writable partition is mounted as an upper layer, and the root file system is mounted by overlayfs. In runtime, the dm-verity performs real-time block-level integrity verification on file access of the underlayer, so that the system core file is ensured not to be tampered; and the overlayfs supports user data writing through a copy-on-write mechanism, and takes into account read-only protection and read-write requirements. The scheme does not need to traverse the whole file system in the booting stage, so that the booting time is significantly shortened, and meanwhile, the scheme has good platform universality, and can effectively prevent runtime attacks.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a secure boot method for an embedded Linux system. Background Technology

[0002] The typical boot process for embedded devices is: bootrom → SPL → uboot → Linux → application. The bootrom is the boot code embedded in the chip by the chip manufacturer, while the SPL, uboot, and Linux images are stored in Flash memory.

[0003] To ensure system security, existing technologies employ the Secure Boot mechanism, using a public / private key encryption system to verify firmware signatures. The specific method is as follows: 1. Digitally sign each firmware level using a private key.

[0004] 2. Attach the signature and public key to the firmware.

[0005] 3. Write the hash value of the public key into the chip's OTP or eFuse.

[0006] 4. During startup, the validity of the firmware signature is verified step by step.

[0007] Existing verification schemes mainly include the FIT (Flattened Image Tree) scheme and the AVB (Android Verified Boot) scheme.

[0008] For the root file system (rootfs), the traditional approach is to perform a one-time integrity check at startup and then mount and use it directly.

[0009] However, the aforementioned existing technologies still have the following shortcomings in practical applications: 1. Lack of runtime file system integrity protection Traditional solutions perform a one-time verification of the root filesystem (FS) at startup, mounting it in read-write mode once the verification is successful. This one-time verification only guarantees integrity at the moment of startup and cannot defend against runtime attacks. During long-term system operation, attackers may bypass the one-time startup verification by directly modifying the filesystem content on the storage medium through other means (such as another system in a hybrid deployment, DMA attacks, etc.).

[0010] 2. Large-capacity file system startup verification time is too long. Traditional methods employ a full verification mechanism, which requires traversing the entire file system to complete the verification. However, for large rootfs (typically hundreds of MB or even GB in size), a full verification at startup requires reading the entire partition and calculating the hash value, resulting in a significant increase in startup time (usually 10-30 seconds).

[0011] 3. Unable to simultaneously meet the requirements of system integrity protection and data writability. Integrity protection requires the file system to be read-only, but in practical applications, the system needs to store writable content such as runtime data, log files, configuration information, and upgrade files. Traditional solutions cannot simultaneously meet read-only protection and read-write requirements within the same file system.

[0012] 4. High platform adaptation costs Existing secure boot solutions are usually deeply coupled with the hardware characteristics and vendor solutions of specific chip platforms. They rely on the hardware security modules, boot processes and verification mechanisms of specific platforms, lack universality, and require a lot of adaptation work when ported to different platforms, resulting in long development cycles and high costs. Summary of the Invention

[0013] In view of the above problems, the present invention is proposed to provide a secure boot method for an embedded Linux system that overcomes or at least partially solves the above problems.

[0014] This invention discloses a secure boot method for an embedded Linux system, the method comprising: During the bootloader phase, firmware at each level is verified and loaded step by step until the Linux system kernel is started. After the Linux system kernel starts, a virtual block device based on dm-verity is created during the kernel initialization phase. The virtual block device is used as the lower read-only layer of the overlayfs file system. At the same time, a writable storage partition is designated as the upper writable layer of the overlayfs file system, and the overlayfs file system is mounted as the root file system. During system operation, the dm-verity mechanism performs real-time integrity verification for file access to the lower read-only layer, and the upper writable layer of the overlayfs file system enables modification operations on the file system.

[0015] Optionally, during the bootloader stage, firmware at each level is verified and loaded sequentially until the Linux system kernel is started, including: When verifying the next level of firmware, each firmware level extracts public key information from the device tree description embedded in the current firmware and uses the public key information to verify the digital signature of the next level of firmware.

[0016] Optionally, verifying the digital signature of the next-level firmware using the public key information includes: Extract the digital signature and firmware content from the next level of firmware to be verified; The digital signature is decrypted using the public key information to obtain the first hash value; The firmware content is hashed to obtain a second hash value; The first hash value is compared with the second hash value. If they match, the verification is successful; otherwise, the startup process is terminated.

[0017] Optionally, before the step of verifying the digital signature of the next-level firmware using the public key information, the method further includes: Calculate the hash value of the public key information and read the pre-stored public key hash value from the chip's OTP or eFuse; The calculated hash value is compared with the pre-stored public key hash value. If they match, the public key is confirmed to be trustworthy; if they do not match, the public key is confirmed to be untrustworthy.

[0018] Optionally, a dm-verity-based virtual block device is created, including: The root hash value, hash algorithm, data partition, and hash partition location information are passed to the kernel. The kernel then builds a virtual block device based on dm-verity according to the root hash value, hash algorithm, data partition, and hash partition location information.

[0019] Optionally, the dm-verity mechanism is used to perform real-time integrity verification for file access to the lower read-only layer, including: When reading a data block, the dm-verity-based virtual block device calculates the hash value of the data block and verifies it layer by layer up the hash tree according to the data block index until it matches the root hash value. The verified data block is then returned to the application.

[0020] Optionally, modifications to the file system can be implemented through a writable layer above the overlayfs file system, including: When a write operation is performed on a file in the lower read-only layer, the overlayfs file system copies the file from the lower layer to the upper writable layer and modifies the copied file in the upper writable layer.

[0021] Optionally, the method further includes: When the bootloader verifies the firmware, it selects to use either the verification scheme provided by the chip manufacturer or the FIT scheme based on the hardware characteristics of the chip platform.

[0022] Optionally, the method further includes: The dm-verity-based virtual block device, which serves as the lower read-only layer of the overlayfs file system, is divided into multiple read-only partitions; each read-only partition is used to store different functional modules.

[0023] Optionally, the method further includes: When dm-verity verification fails, a verification failure log is recorded, and automatic recovery is performed according to a preset strategy.

[0024] This invention has the following advantages: This invention provides a secure boot method for embedded Linux systems. By constructing a complete trust chain from the hardware root of trust to the file system, it achieves runtime file system integrity protection. During the boot phase, the scheme employs the FIT firmware format, with each firmware level embedding a public key and verifying signatures at each level. Optional comparison with the public key hash in OTP / eFuse ensures firmware trustworthiness. After kernel boot, a read-only virtual block device is created based on dm-verity as the lower layer of the root file system, and a writable partition is mounted as the upper layer, jointly mounted as the root file system via overlayfs. At runtime, dm-verity performs real-time block-level integrity verification on lower-level file accesses, ensuring that core system files are not tampered with; overlayfs supports user data writing through a copy-on-write mechanism, balancing read-only protection and read / write requirements. This scheme eliminates the need to traverse the entire file system at boot, significantly shortening boot time, while also possessing good platform versatility and effectively defending against runtime attacks. Attached Figure Description

[0025] Figure 1 This is a flowchart of the secure boot method for the embedded Linux system of the present invention; Figure 2 This is a schematic diagram of the FIT firmware structure of the present invention; Figure 3 This is a layered architecture diagram of the secure rootfs file system of the present invention; Figure 4 This is a schematic diagram illustrating an example of a hash tree structure according to the present invention. Detailed Implementation

[0026] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0027] This invention proposes a method for implementing trusted system boot, establishing a complete trust chain from firmware to file system, and achieving runtime file system integrity protection.

[0028] Reference Figure 1 The complete process of the secure boot method for the embedded Linux system of the present invention is as follows: Step 1: The bootrom is verified and loaded with SPL using the chip manufacturer's solution.

[0029] Step 2: SPL extracts the public key from its own device tree, optionally verifies the public key hash, and then verifies and loads uboot.

[0030] Step 3: U-Boot extracts the public key from its own device tree, optionally verifies the public key hash, and then verifies and loads the boot firmware (kernel + ramdisk).

[0031] Step 4: The Linux kernel starts and executes the initialization script in the ramdisk.

[0032] Step 5: Initialize the script to create the dm-verity mapping device, specifying the data partition, hash partition, root hash, and hash algorithm.

[0033] Step 6: Mount the dm-verity device as a read-only lower layer.

[0034] Step 7: Mount a writable partition as the upper layer.

[0035] Step 8: Create overlayfs and mount it as the root file system.

[0036] Step 9: Switch to the new root file system and continue system startup.

[0037] Step 10: During system operation, file access is handled by overlayfs, and the integrity of lower-level file reading is verified in real time by dm-verity.

[0038] The principle behind building the trust chain is as follows: 1. Write the public key hash value into the chip OTP / eFuse (optional).

[0039] 2. All firmware versions use the same key pair for signing.

[0040] 3. Public key information is embedded in each firmware level to verify the next firmware level step by step.

[0041] 4. Form a complete trust chain from the hardware root of trust to the application layer.

[0042] Specifically, the secure boot process of this invention includes the following levels: 1. Firmware-level Trusted Boot (FIT Solution) (1) FIT firmware structure Referring to Figure 2, the FIT firmware consists of the following parts: ① Firmware image: Contains the actual executable code and data.

[0043] ② Device tree description: Use device tree syntax to describe image information and signature configuration.

[0044] ③ Public key information: Embedded in the signature node of the device tree.

[0045] ④ Digital signature: RSA signature of firmware content.

[0046] Multiple images (such as kernel, device tree, ramdisk) can be packaged into a single ITB format firmware.

[0047] (2) Public key acquisition mechanism When verifying uboot firmware: SPL extracts the embedded public key from its own device tree.

[0048] Optional: Read the public key hash value in OTP / eFuse to verify the validity of the extracted public key.

[0049] When verifying the boot firmware (kernel + ramdisk): uboot extracts the embedded public key from its own device tree.

[0050] Optional: Read the public key hash value in OTP / eFuse to verify the validity of the extracted public key.

[0051] (3) Firmware verification principle Firmware verification includes two levels: Level 1: Public Key Verification (Optional) ① Extract the public key from the device tree of the current firmware.

[0052] ② Calculate the hash value of the public key.

[0053] ③ Compare with the hash value stored in OTP / eFuse.

[0054] ④ After successful verification, the public key is confirmed to be trustworthy.

[0055] Because the device tree has already been verified by the previous level, the public key in the device tree does not need to be verified. This masks the differences in reading OTP / eFuse from different vendors.

[0056] Second level: Signature verification ① Extract the digital signature and firmware content from the firmware to be verified.

[0057] ② Use the verified public key to decrypt the digital signature and obtain the hash value Hash1 at the time of signing.

[0058] ③ Calculate the hash value of the firmware content to obtain Hash2.

[0059] ④ Compare Hash1 and Hash2; if they match, the verification is successful.

[0060] ⑤ If verification fails, the startup process is terminated; if verification succeeds, the next firmware level is loaded and executed.

[0061] 2. File system-level trusted boot (dm-verity + overlayfs solution) (1) Overall architecture Reference Figure 3 The secure rootfs file system uses a layered architecture: How overlayfs works: ①The lower layer is a read-only layer that stores the system's core files.

[0062] ②The upper layer is a writable layer that stores and modifies user data.

[0063] ③ When accessing a file, read from the upper level first; if the upper level does not exist, read from the lower level.

[0064] ④ When modifying lower-level files, use the COW mechanism to copy the file to the upper level before making modifications.

[0065] ⑤ Present a unified file system view to the outside world.

[0066] (2) dm-verity mechanism principle dm-verity is a mechanism in the Device Mapper framework that implements runtime block-level integrity verification by creating virtual block devices to provide verification services.

[0067] Architecture components: ①Mapping device: A virtual read-only block device provided to the outside world.

[0068] ② Data device: Stores actual file system data.

[0069] ③ Hash device: A hash tree used for storage and verification.

[0070] Hash tree structure (using SHA256 algorithm and 4KB block size as an example, refer to...) Figure 4 ): Each hash value occupies 32 bytes, and each 4KB hash block can store 128 hash values. Therefore, the number of hash blocks in each layer is 1 / 128 of the number in the layer below. The top layer has only one hash block, and the hash value calculated for this block is the root hash.

[0071] (3) dm-verity verification principle Verification process when reading data blocks: ① The application initiates a read request, specifying the location of the data block.

[0072] ②dm-verity reads data blocks from the data device.

[0073] ③ Calculate the hash value of the data block.

[0074] ④ Based on the data block index, locate the corresponding hash value from Layer 0 and compare it.

[0075] ⑤ If the hash block of Layer 0 has not been verified, then recursively verify upwards: Calculate the hash value of Layer 0 hash block.

[0076] Locate and compare the corresponding hash value from Layer 1.

[0077] Repeat this process until Layer N.

[0078] Verify that the hash value of Layer N is consistent with the root hash.

[0079] ⑥ Verified hash blocks are added to the cache, so subsequent reads do not require repeated upward verification.

[0080] ⑦ If verification fails, return an IO error; if verification succeeds, return the data.

[0081] The root hash is calculated during firmware creation and passed to the kernel via the boot firmware, serving as the root of trust for verification.

[0082] In an optional embodiment of the present invention, SPL verification of uboot can select either the original manufacturer's solution or the FIT solution depending on the chip platform.

[0083] In one optional embodiment of the present invention, different hash algorithms (SHA256 / SHA384 / SHA512) can be selected according to the security strength requirements, and the hierarchical relationship and storage space of the hash tree can be adjusted accordingly.

[0084] In an optional embodiment of the present invention, the dm-verity block size can be adjusted to 2KB or 8KB according to performance requirements.

[0085] In one optional embodiment of the present invention, the overlayfs file system supports multiple read-only partitions, each storing different functional modules.

[0086] In an optional embodiment of the present invention, a verification failure log recording and an automatic recovery mechanism are added.

[0087] The present invention has the following technical effects: 1. Runtime file system integrity protection mechanism based on dm-verity This invention employs a hierarchical hash tree structure to perform real-time block-level verification on every read operation of the file system, effectively defending against direct tampering attacks on the storage medium during system operation. It overcomes the limitations of traditional one-time verification, providing continuous security protection. Simultaneously, through a hash caching mechanism, it makes repeated read performance approach that of a verification-free state and effectively defends against cross-system attacks in hybrid deployment scenarios.

[0088] 2. OverlayFS layered file system architecture This architecture divides the file system into a read-only protection layer and a read-write layer. The read-only layer is protected using dm-verity, while the read-write layer stores runtime data and remains transparent to the application layer through a joint mount. This design simultaneously satisfies the dual requirements of integrity protection and data writability, ensuring continuous protection of the system's core files (occupying over 90% of the space) while remaining completely transparent to existing applications without requiring code modifications.

[0089] 3. FIT-based Unified Firmware Verification Framework This framework uses device tree syntax to describe multi-image information, supports packaging multiple images into a single ITB file, and provides a unified signature verification interface. It simplifies the firmware signing and verification process to reduce development complexity, supports flexible image combinations to adapt to different platform requirements, and the signature verification time, based on the RSA2048 standard, can be controlled within 100ms.

[0090] 4. A complete trust chain from hardware to application This trust chain uses the chip OTP / eFuse as the hardware trust root. By verifying each level of firmware and file system, it forms an unbypassable trust transmission chain, achieving end-to-end security protection from the chip level to the application level. Any tampering with any link will lead to verification failure and termination of the startup process. At the same time, it can effectively defend against supply chain attacks and offline attacks.

[0091] 5. Universal Trusted Boot Based on Pure Software Except for the bootrom verification SPL step fixed by the chip manufacturer, all verification steps from SPL to the root file system are implemented using a pure software solution. This solution is built on the U-Boot open-source software and standard Linux kernel components, without relying on hardware security modules or vendor-specific solutions for any chip platform. It is adaptable to all U-Boot-supporting embedded platforms such as ARM, RISC-V, and MIPS. By embedding the public key used to verify the next-level firmware within the device tree of the current firmware level, the security of the public key is ensured, and there is no need to additionally read the chip's OTP or eFuse hardware storage for verification, thus shielding hardware differences between different manufacturers. This eliminates the need for deep adaptation to various hardware characteristics during platform porting, significantly shortening the development cycle; the unified software architecture facilitates maintenance and upgrades, avoiding the high costs of maintaining independent code branches for each platform; at the same time, the solution retains flexible configuration capabilities, allowing for a flexible balance between cost and security in enabling OTP / eFuse hardware verification based on project needs. With the help of a mature open-source solution, developers do not need to deeply understand the hardware security details of each chip platform, effectively lowering the technical threshold.

[0092] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0093] It should 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, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0094] The various embodiments in this specification are described in a related manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0095] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention are included within the scope of protection of the present invention.

Claims

1. A secure boot method for an embedded Linux system, characterized in that, The method includes: During the bootloader phase, firmware at each level is verified and loaded step by step until the Linux system kernel is started. After the Linux system kernel starts, a virtual block device based on dm-verity is created during the kernel initialization phase. The virtual block device is used as the lower read-only layer of the overlayfs file system. At the same time, a writable storage partition is designated as the upper writable layer of the overlayfs file system, and the overlayfs file system is mounted as the root file system. During system operation, the dm-verity mechanism performs real-time integrity verification for file access to the lower read-only layer, and the upper writable layer of the overlayfs file system enables modification operations on the file system.

2. The method according to claim 1, characterized in that, During the bootloader phase, firmware at each level is verified and loaded sequentially until the Linux system kernel is started, including: When verifying the next level of firmware, each firmware level extracts public key information from the device tree description embedded in the current firmware and uses the public key information to verify the digital signature of the next level of firmware.

3. The method according to claim 2, characterized in that, Verifying the digital signature of the next-level firmware using the public key information includes: Extract the digital signature and firmware content from the next level of firmware to be verified; The digital signature is decrypted using the public key information to obtain the first hash value; The firmware content is hashed to obtain a second hash value; The first hash value is compared with the second hash value. If they match, the verification is successful; otherwise, the startup process is terminated.

4. The method according to claim 2, characterized in that, Before the step of verifying the digital signature of the next-level firmware using the public key information, the following steps are also included: Calculate the hash value of the public key information and read the pre-stored public key hash value from the chip's OTP or eFuse; The calculated hash value is compared with the pre-stored public key hash value. If they match, the public key is confirmed to be trustworthy; if they do not match, the public key is confirmed to be untrustworthy.

5. The method according to claim 1, characterized in that, Creating a dm-verity-based virtual block device includes: The root hash value, hash algorithm, data partition, and hash partition location information are passed to the kernel. The kernel then builds a virtual block device based on dm-verity according to the root hash value, hash algorithm, data partition, and hash partition location information.

6. The method according to claim 1, characterized in that, The dm-verity mechanism performs real-time integrity verification for file access to the lower read-only layer, including: When reading a data block, the dm-verity-based virtual block device calculates the hash value of the data block and verifies it layer by layer up the hash tree according to the data block index until it matches the root hash value. The verified data block is then returned to the application.

7. The method according to claim 1, characterized in that, Modification operations on the file system are achieved through the writable layer above the overlayfs file system, including: When a write operation is performed on a file in the lower read-only layer, the overlayfs file system copies the file from the lower layer to the upper writable layer and modifies the copied file in the upper writable layer.

8. The method according to claim 1, characterized in that, The method further includes: When the bootloader verifies the firmware, it selects to use either the verification scheme provided by the chip manufacturer or the FIT scheme based on the hardware characteristics of the chip platform.

9. The method according to claim 1, characterized in that, The method further includes: The dm-verity-based virtual block device, which serves as the lower read-only layer of the overlayfs file system, is divided into multiple read-only partitions; each read-only partition is used to store different functional modules.

10. The method according to claim 1, characterized in that, The method further includes: When dm-verity verification fails, a verification failure log is recorded, and automatic recovery is performed according to the preset strategy.

Images