Secure starting method and device for embedded equipment

Abstract

The invention relates to the technical field of safe starting, in particular to a safe starting method and device for embedded equipment. The method comprises the following steps: dividing a processor in a target system architecture into a non-secure world and a secure world; establishing a trust chain guided by the Arm trusted firmware, and verifying the trust chain step by step by taking a BootROM read-only memory as a trust root of a starting process; in the secure world, verifying the Kernel kernel mirror image, and after the verification of the Kernel kernel mirror image is passed, creating a vroot virtual device through an auxiliary system mirror image in the Kernel kernel mirror image; and mounting the vroot virtual device to the virtual rootfs partition, switching to the actual rootfs partition after mounting is completed, and executing the initialization process of the operating system. According to the scheme, it is ensured that the embedded device is started in a safe and verified environment, and the starting reliability is enhanced.

Description

Technical Field

[0001] The present invention relates to the technical field of secure booting, and in particular to a secure booting method and device for an embedded device. Background Art

[0002] Secure boot means that during the boot process of an embedded device, a series of verification mechanisms are used to ensure the integrity and authenticity of the boot code, operating system, and key applications, thereby preventing the intrusion of malicious software.

[0003] In recent years, with the rapid development of science and technology and the growing demand of consumers, the functionality and complexity of embedded devices (such as smartphones, smart home devices, and in-vehicle devices) have reached unprecedented heights. In order to meet these diverse needs, embedded devices often need to run operating systems with rich feature sets, such as Linux and Android systems, which not only provide powerful software support, but also enable embedded devices to perform more complex tasks. However, with the continuous increase in the amount of operating system and application code, potential security vulnerabilities have also increased. These vulnerabilities may be exploited by malicious attackers to steal sensitive information, undermine system stability, or perform other malicious behaviors. In addition, with the popularization of technologies such as online upgrades (OTA Over-The-Air), although it has brought convenience to users, it has also provided new channels for the spread of malware, making the security threats faced by embedded devices increasingly severe.

[0004] Therefore, there is an urgent need for a secure boot method that verifies the booting of an embedded device and improves the security of the embedded device. Summary of the invention

[0005] In view of this, the present invention provides a secure startup method and apparatus for an embedded device to solve the problem of increased potential security vulnerabilities and poor security when the embedded device is started.

[0006] In a first aspect, the present invention provides a secure boot method for an embedded device, which divides a processor in a target system architecture into a non-secure world and a secure world;

[0007] Establish a trust chain guided by the Arm trusted firmware, and use the BootROM read-only memory as the trust root of the boot process to verify the trust chain step by step;

[0008] In the secure world, the Kernel image is verified, and after the Kernel image passes the verification, a vroot virtual device is created through the auxiliary system image in the Kernel image;

[0009] The vroot virtual device is mounted to the virtual rootfs partition, and after the mounting is completed, it is switched to the actual rootfs partition to execute the initialization process of the operating system.

[0010] The above solution divides the processor into a non-secure world and a secure world to achieve hardware-level security isolation, establishes a trust chain guided by the Arm trusted firmware, and uses the BootROM read-only memory as the trust root of the boot process, ensuring the credibility and integrity of the boot process, thereby preventing malware or unauthorized modifications from entering the system. Only after the Kernel kernel image passes the verification will the vroot virtual device be created, ensuring the integrity and correctness of the operating system core and preventing unauthorized or damaged software from affecting the stability and security of the system. By creating a vroot virtual device and mounting it to the virtual rootfs partition, the maintainability and scalability of the system can be enhanced, while reducing the dependence on the actual hardware partition, making the system easier to update and maintain. After mounting the vroot virtual device to the virtual rootfs partition, switch to the actual rootfs partition and execute the initialization process of the operating system, ensuring that the embedded device can be started in a secure and verified environment, which not only enhances the reliability of the embedded device, but also improves the efficiency and stability of the embedded device when it starts.

[0011] In an optional implementation, the step of establishing a trust chain guided by the Arm trusted firmware and using the BootROM read-only memory as the trust root of the startup process to verify the trust chain step by step includes:

[0012] After enabling secure boot on the embedded device, establishing a trust chain guided by the Arm trusted firmware;

[0013] The BootROM read-only memory is used as the trust root of the startup process to establish the starting link of the trust chain, and the integrity of each startup component in the trust chain is verified step by step.

[0014] The above scheme can effectively prevent malware or unauthorized modifications from entering the system by verifying the integrity of each startup component in the trust chain step by step. The verification at each startup stage ensures that only verified components can continue to execute, thereby reducing the risk of the system being attacked or tampered with.

[0015] In an optional implementation, the startup components include an SPL secondary program loader, a U-Boot universal boot loader, an SML security monitor loader, and a TOS trusted operating system.

[0016] In an optional implementation, the verifying the Kernel image includes:

[0017] Perform integrity check on the Kernel kernel image and related components; the related components include the dtb device tree binary file, the dtbo device tree overlay binary file and the recovery image.

[0018] The above solution verifies the integrity of the Kernel image and related components, ensuring that the Kernel image and its related components are not tampered with or damaged during the startup process, preventing malware injection or unauthorized modification, and can effectively reduce the security threats faced by the system.

[0019] In an optional implementation, the creating a vroot virtual device by using the auxiliary system image in the Kernel kernel image includes:

[0020] During the booting process of the Kernel kernel image, the kernel loads and mounts the auxiliary system image, and creates a virtual device in the auxiliary system image;

[0021] Mounting the auxiliary system image in the virtual device file of the Kernel kernel image;

[0022] Execute the verified Kernel image and check the creation status of the target device node in the auxiliary system image;

[0023] If the target device node has been created, a vroot virtual device is created in the actual rootfs partition through the target device node.

[0024] The above solution creates a vroot virtual device through the auxiliary system image in the Kernel kernel image, which can improve system flexibility and security while simplifying management and maintenance work, effectively utilizing resources, and supporting stable system operation and rapid response to demand changes.

[0025] In an optional implementation, mounting the vroot virtual device to a virtual rootfs partition includes:

[0026] When the vroot virtual device is created, verifying the actual rootfs partition;

[0027] After the actual rootfs partition passes the verification, the vroot virtual device is mounted to the virtual rootfs partition corresponding to the actual rootfs partition.

[0028] In an optional implementation, the process of switching to the actual rootfs partition to execute the initialization of the operating system includes:

[0029] Switch to the actual rootfs partition and execute the init initialization program in the actual rootfs partition to start the system initialization process.

[0030] The above scheme verifies the actual rootfs partition when creating the vroot virtual device, which can ensure its integrity and security before mounting the virtual device, prevent unauthorized changes or damage to the actual rootfs partition, and improve the overall security of the system. After mounting the vroot virtual device to the virtual rootfs partition, switching to the actual rootfs partition to perform the initialization process can optimize the startup process of the embedded device.

[0031] In a second aspect, the present invention provides a secure booting device for an embedded device, the device comprising:

[0032] A secure world partition module, used to partition the processor in the target system architecture into a non-secure world and a secure world;

[0033] A trust chain verification module is used to establish a trust chain guided by the Arm trusted firmware, and use the BootROM read-only memory as the trust root of the startup process to verify the trust chain step by step;

[0034] A vroot virtual device creation module, used to verify the Kernel image in the secure world, and after the Kernel image passes the verification, create a vroot virtual device through the auxiliary system image in the Kernel image;

[0035] The rootfs partition execution module is used to mount the vroot virtual device to the virtual rootfs partition, and after the mounting is completed, switch to the actual rootfs partition to execute the initialization process of the operating system.

[0036] In a third aspect, the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to execute a secure startup method for an embedded device according to the first aspect or any corresponding embodiment thereof.

[0037] In a fourth aspect, the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute a method for securely booting an embedded device according to the first aspect or any corresponding embodiment thereof.

[0038] In a fifth aspect, the present invention provides a computer program product, including computer instructions, which are used to enable a computer to execute a secure startup method for an embedded device according to the first aspect or any corresponding embodiment thereof.

[0039] The technical solution provided by the present invention may include the following beneficial effects:

[0040] The present invention divides the processor into a non-secure world and a secure world, realizes hardware-level security isolation, establishes a trust chain guided by the Arm trusted firmware, and uses the BootROM read-only memory as the trust root of the boot process, thereby ensuring the credibility and integrity of the boot process, thereby preventing malicious software or unauthorized modifications from entering the system. Only after the Kernel kernel image passes the verification, the vroot virtual device will continue to be created, ensuring the integrity and correctness of the operating system core, and preventing unauthorized or damaged software from affecting the stability and security of the system. By creating a vroot virtual device and mounting it to a virtual rootfs partition, the maintainability and scalability of the system can be enhanced, while reducing the dependence on the actual hardware partition, making the system easier to update and maintain. After the vroot virtual device is mounted to the virtual rootfs partition, it is switched to the actual rootfs partition and the initialization process of the operating system is executed, ensuring that the embedded device can be started in a safe and verified environment, not only enhancing the reliability of the embedded device, but also improving the efficiency and stability of the embedded device when it is started. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0042] Figure 1 is a flow chart of a secure boot method for an embedded device according to an embodiment of the present invention;

[0043] Figure 2 is a schematic diagram of a secure boot verification process according to an embodiment of the present invention;

[0044] Figure 3 is a flow chart of another secure boot method for an embedded device according to an embodiment of the present invention;

[0045] Figure 4 is a flowchart of another secure boot method for an embedded device according to an embodiment of the present invention;

[0046] Figure 5 is a flowchart of a secure boot method for an embedded device according to another embodiment of the present invention;

[0047] Figure 6 is a schematic diagram of a verification process of an auxiliary system image according to an embodiment of the present invention;

[0048] Figure 7 is a structural block diagram of a secure booting device for an embedded device according to an embodiment of the present invention;

[0049] Figure 8 It is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0050] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0051] It should be noted that, firstly, since the secure boot method of the relevant technology lacks hardware-level security isolation, the system is vulnerable to malicious attacks and software vulnerabilities, and the security is greatly reduced. Secondly, the verification process of secure boot is vulnerable to malicious attacks and tampering, the credibility of the signature is difficult to guarantee, and the system is vulnerable to attacks by forged signatures, with low security and prone to various security risks. In addition, the risk of vulnerability exploitation also increases, and malware is more likely to invade the system and cause damage.

[0052] Moreover, for Linux vehicle-mounted embedded devices, if the rootfs (Root File System) is not verified or only individual key applications in the rootfs (Root File System) are verified, once the application with root access is maliciously controlled and used, the following problems will occur: the integrity of the system is threatened, which may cause the system to be unstable or unable to start, and malicious applications may implant malicious code or backdoors to monitor user activities, steal sensitive information or remotely control devices; the system is vulnerable to unauthorized access or attack because the unverified file system may be tampered with to exploit security vulnerabilities; for vehicle-mounted embedded devices, it is easy to cause abnormal behavior in the vehicle system, and may even pose a threat to the safety and stability of the vehicle. The present invention is based on the Armv8 architecture device that supports TrustZone technology, uses ATF (ARM Trusted Firmware) as a security solution, and combines dm-verity technology to chain the signature image to ensure that only trusted images can be loaded and executed, thereby effectively improving the security of embedded devices and effectively preventing various potential threats.

[0053] The following describes some key terms in the present invention:

[0054] TrustZone technology: TrustZone technology is a hardware-level security extension that exists in Armv8 architecture processors. It provides hardware-level security by creating secure and non-secure execution environments in the processor to isolate sensitive data and critical system functions.

[0055] ARM Trusted Firmware (ATF): ATF is an open source firmware provided by ARM that is used to start and initialize the TrustZone environment and provide a secure boot process. ATF ensures the security and trustworthiness of system startup through a series of components.

[0056] dm-verity technology: dm-verity technology is a function in the Linux kernel that is used to check the integrity of data blocks in the file system. It verifies whether the file system has been tampered with by calculating the hash value of the data block and comparing it with the pre-stored hash value.

[0057] According to an embodiment of the present invention, an embodiment of a secure boot method for an embedded device is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0058] In this embodiment, a secure boot method for an embedded device is provided. Figure 1 is a flow chart of a secure boot method for an embedded device according to an embodiment of the present invention. Figure 1 As shown, the process includes the following steps:

[0059] Step S101, dividing the processor in the target system architecture into a non-secure world and a secure world.

[0060] Furthermore, this embodiment divides the execution environment of the processor in the target system architecture into a logically isolated non-secure world (Normal World) and a secure world (Secure World) based on the hardware security characteristics of the processor. The target system architecture may be an ARMv8 architecture, and the processor may be a processor based on the ARMv8 architecture and supporting TrustZone technology. The non-secure world is used to run standard operating systems and applications, while the secure world is used to run code that requires a higher level of security, such as security-sensitive operations, key management, etc. The division method of this embodiment ensures that even if the code in the non-secure world is attacked or tampered with, the data and code in the secure world can remain secure, providing a hardware foundation for the secure startup of the entire system and embedded devices (the operating system is the basis of the software architecture of the embedded device, so the secure startup of the system also ensures the secure startup of the embedded device).

[0061] Step S102, establish a trust chain guided by the Arm trusted firmware, and use the BootROM read-only memory as the trust root of the startup process to verify the trust chain step by step.

[0062] Furthermore, the boot process of this embodiment starts from BootROM (Basic Input Output System Read Only Memory), which is the root of trust for the entire boot process. BootROM contains the initial code of the boot system, which is responsible for loading and verifying the integrity of the next level components. The entire verification process forms a trust chain, and each level of components in the trust chain depends on and verifies the upper level components. The trust chain includes the SPL secondary program loader, the U-Boot universal boot loader, the SML security monitor loader, and the TOS trusted operating system.

[0063] Arm trusted firmware, namely the above-mentioned ATF (ARM Trusted Firmware), is responsible for executing in the secure world and verifying the integrity and authenticity of subsequently loaded components (such as U-Boot, Kernel, etc.). The step-by-step verification mechanism in this embodiment ensures that only authorized and untampered code can be executed.

[0064] Step S103: in the secure world, verify the Kernel image, and after the Kernel image passes the verification, create a vroot virtual device through the auxiliary system image in the Kernel image.

[0065] Furthermore, in the secure world, this embodiment first verifies the Kernel image to ensure its integrity and authenticity, and the verification may include checking digital signatures, hash values, etc. Once the Kernel image passes the verification, the system will continue to execute the code in the Kernel image. The Kernel image contains an auxiliary system image, which is a spare system image or copy, used to provide a spare operating environment during the startup process. In this embodiment, the auxiliary system image is used to create a vroot virtual device, which is used to indicate the physical device or partition where the rootfs (root file system) is located. This embodiment creates a vroot virtual device to perform verification and mounting operations without directly accessing the physical device, thereby improving security. The above steps gradually ensure the secure startup of the system and embedded devices from the BootROM read-only memory at the hardware level to the Kernel image at the operating system level.

[0066] Step S104, mount the vroot virtual device to the virtual rootfs partition, and after the mounting is completed, switch to the actual rootfs partition to execute the initialization process of the operating system.

[0067] Furthermore, after creating and verifying the vroot virtual device, this embodiment mounts it to the virtual rootfs partition. This mounting process allows the system to access the content of the rootfs without directly accessing the physical storage medium. After that, this embodiment switches to the actual rootfs partition and starts to execute the initialization process of the operating system, which includes starting system services, loading drivers, initializing the network, etc., and finally brings the system into an operational state.

[0068] In summary, this embodiment is based on a CPU processor of the Armv8 architecture that supports TrustZone technology. TrustZone is implemented by dividing the CPU into two virtual processors, one called the non-secure world (Non-secure World) and the other called the secure world (Secure World). In the non-secure world, the CPU runs traditional applications and operating systems, which can only access limited CPU resources and functions; while in the secure world, the CPU runs highly secure applications and operating systems, which can access the functions and resources of the entire CPU, so that the programs and data in the secure world are protected. Even if the programs in the non-secure world are attacked or tampered with, it will not affect the security of the programs and data in the secure world. Therefore, in addition to the SPL (Secondary Program Loader) booted by ATF (Arm Trusted Firmware), U-Boot universal boot loader, SML (Secure Monitor Layer), and TOS (TrustZone Operating System), the Kernel image, dtb (Device Tree Blob), dtbo (DeviceTree Blob Overlay) and recovery image need to be verified in the secure world. After the verification, the Kernel image will verify the rootfs root file system.

[0069] This embodiment packages the programs and scripts related to the rootfs root file system verification into an auxiliary system image, and then packages it into the Kernel kernel image. After the Kernel kernel image is loaded and executed, it will be transferred to the auxiliary system to execute the functions specified in this embodiment. In this auxiliary system, the creation and association of the virtual device of the block device partition where the rootfs root file system is located can be completed. After verifying the integrity of the rootfs root file system, the rootfs partition is mounted (the vroot virtual device is mounted), and then the actual rootfs partition is transferred to perform the init initialization operation.

[0070] That is to say, the embedded device based on TrustZone technology in this embodiment adopts the embedded secure boot method integrating ATF (Arm Trusted Firmware) security solution and dm-verity technology, which provides comprehensive security protection for embedded devices. Through the secure boot verification process, the system verifies the integrity of images such as boot loader and rootfs during the startup process to prevent malware implantation and data tampering, and ensure the security and reliability of the system. At the same time, TrustZone technology provides hardware-level security isolation to ensure the separation of the secure world and the non-secure world to prevent unauthorized access. In the ATF (Arm Trusted Firmware) solution, the BootROM read-only memory serves as the trust root of secure boot and establishes the starting link of the trust chain. The integrity of each level of image is verified by the upper image to prevent malicious tampering and ensure the overall security of the system. The dm-verity technology effectively detects the integrity of data by verifying the Hash of rootfs, ensuring the accuracy of the file system during system operation. In summary, the invention provides comprehensive security protection for the system and protects the integrity of user data and the system.

[0071] The content of the above embodiment is explained below through a simple example:

[0072] Taking UIS7716 as an example, its secure boot verification process is as follows Figure 2 As shown, including:

[0073] After enabling secure boot, the SPL (Secondary Program Loader), U-Boot universal boot loader, and Kernel kernel image will be verified level by level after power-on, and the subsequent loading process will be entered after passing the verification.

[0074] After entering the Kernel image, the startup script determines whether the current / dev / mapper / control device node has been created. The virtual device vroot created during rootfs verification is created through the / dev / mapper / control device node.

[0075] In addition, due to the protection of the secure boot function, malicious attackers cannot inject code into the auxiliary system to tamper with the rootfs image, which can ensure the integrity of the rootfs partition mounted after the system starts.

[0076] In summary, the present invention divides the processor into a non-secure world and a secure world to achieve hardware-level security isolation, establishes a trust chain guided by Arm trusted firmware, and uses BootROM read-only memory as the trust root of the boot process, ensuring the credibility and integrity of the boot process, thereby preventing malicious software or unauthorized modifications from entering the system. Only after the Kernel kernel image is verified will the vroot virtual device continue to be created, ensuring the integrity and correctness of the operating system core, and preventing unauthorized or damaged software from affecting the stability and security of the system. By creating a vroot virtual device and mounting it to a virtual rootfs partition, the maintainability and scalability of the system can be enhanced, while reducing the dependence on the actual hardware partition, making the system easier to update and maintain. After mounting the vroot virtual device to the virtual rootfs partition, switch to the actual rootfs partition and execute the initialization process of the operating system, ensuring that the embedded device can be started in a safe and verified environment, not only enhancing the reliability of the embedded device, but also improving the efficiency and stability of the embedded device when it is started.

[0077] In this embodiment, another secure boot method for an embedded device is provided. Figure 3 is a flow chart of another secure boot method for an embedded device according to an embodiment of the present invention. Figure 3 As shown, the process includes the following steps:

[0078] Step S301: divide the processors in the target system architecture into a non-secure world and a secure world. Figure 1 Step S101 of the illustrated embodiment will not be described in detail here.

[0079] Step S302, after enabling secure boot on the embedded device, establishing a trust chain guided by the Arm trusted firmware.

[0080] For further information, see Figure 4A flowchart of another secure boot method for an embedded device is shown. In a normal boot process, SPL, U-Boot, SML, and TOS guided by ATF (Arm Trusted Firmware) are all guided by ATF (ARM Trusted Firmware). After the device is powered on, the BootROM read-only memory will verify the SPL. The SPL image contains the signature, public key and other information of the SPL image. The BootROM read-only memory takes out the public key and calculates the hash value, which is compared with the public key hash of the SPL image verified from the OTP area (a one-time writable area, and the hash value area is only read by the BootROM read-only memory). If the comparison is inconsistent, the secure boot fails. If the comparison is consistent, it means that the public key in the SPL image is credible, and the public key can be used to verify the SPL image. If the signature verification fails, it means that the secure boot fails. If the signature verification succeeds, the SPL is executed to verify the lower-level image.

[0081] When SPL is executed, the SML, TOS, and U-Boot images are copied to the SDRAM synchronous dynamic random access memory (Synchronous Dynamic Random Access Memory). It is a type of dynamic random access memory (DRAM), but compared with traditional DRAM, it adds a synchronous interface, which enables it to verify the public keys and signature information in these three images in turn. The public keys used by these three images are consistent, and their public key hashes are stored in the SPL image, which is ensured by the SPL image to be tamper-proof. When all three images are verified, SPL notifies the BootROM read-only memory to hand over CPU control to SML by triggering the security monitoring mode call. SML determines whether TOS needs to be loaded by parsing whether there is an entry function pointer of TOS in a specific segment. After TOS is started, it will execute the built-in TA, which is used for subsequent signature verification of Kernel, dtb, dtbo, and recovery images, and then trigger the security monitoring mode call to re-enter SML to continue execution. SML obtains the next image file U-Boot to be executed by querying the linked list, and sets the CPU status and operating environment when U-Boot is running, and then exits EL3 (the highest privilege level, responsible for processing security functions and tasks in the system) and enters U-Boot for execution.

[0082] Under U-Boot execution, the TOS interface is called to verify the kernel, dtb, dtbo, and recovery images. After the verification is completed, the kernel starts to execute. Before loading the init script, the kernel needs to mount the rootfs first, and then execute the init in the rootfs. "Init" is the first process (initialization process) started by the kernel. It is the parent process of all processes. The PID (process ID) of the init process is always 1, and this process will continue to exist until the device stops running.

[0083] The image structure of SPL, U-Boot, SML, and TOS includes image information, image payload, image key information, public key, and signature. Among them, the image information description contains other information such as specific characters of the image logo, that is, the specific logo and other metadata describing the image; the image payload is the actual image content; the image key information contains other important information such as the public key hash value of the lower-level image to ensure the integrity and credibility of each image in the chain; the public key and signature are the signature verification public key to be used by the image and the signature to be verified, which are used to verify the signature of the image to ensure that it has not been tampered with. Except for the public key and signature, the rest of the content is considered to be signed as a whole.

[0084] That is to say, in the normal boot process of this embodiment, the secure boot process of the embedded device goes through multiple stages, and each stage is responsible for verifying and starting the image of the next stage. The process includes:

[0085] After the embedded device is powered on, the BootROM (read-only memory) is executed to verify the SPL (Secondary Program Loader); the verification process includes extracting the public key from the SPL image (i.e., the SPL secondary program loader), calculating its hash value, and comparing it with the public key hash value stored in the OTP area (one-time writable area). If the hash values ​​are consistent, it is considered that the SPL image has not been tampered with, and the public key is used to continue to verify the SPL image; otherwise, the secure boot fails.

[0086] After SPL is verified, it starts to execute. SPL copies SML (Secure Monitor Layer), TOS (Trusted Operating System), U-Boot and other images to SDRAM (Synchronous Dynamic Random Access Memory). SPL then verifies the public keys and signature information of SML, TOS, and U-Boot in turn to ensure the integrity and reliable source of these images.

[0087] After the verification is completed, SPL notifies BootROM to hand over CPU control to SML through the secure monitoring mode call. SML checks whether TOS needs to be loaded (based on whether there is an entry function pointer of TOS in a specific segment). If necessary, TOS will execute the built-in TA (Trusted Applications), which is responsible for verifying the signature of subsequent system images (such as Kernel, dtb, dtbo, recovery).

[0088] TOS or SML hands over control to U-Boot, and U-Boot continues to perform initialization work. In U-Boot, by calling the TOS interface, the final verification of the kernel, dtb, dtbo, recovery and other images is performed.

[0089] After the verification is passed, the kernel starts to execute. The kernel first mounts the rootfs (root file system) and then executes the init script in the rootfs. The "init" process is the first process after the kernel is started, which is responsible for the initialization of the system and the startup of subsequent processes.

[0090] The entire process described above is designed to ensure that the images at each stage of the system startup process are verified and trusted, preventing malware or tampered images from threatening the security of the system.

[0091] Step S303, using the BootROM read-only memory as the trust root of the boot process, establishing the starting link of the trust chain, and verifying the integrity of each boot component in the trust chain step by step.

[0092] In an optional implementation, the startup components include an SPL secondary program loader, a U-Boot universal boot loader, an SML security monitor loader, and a TOS trusted operating system.

[0093] Step S304: perform integrity check on the kernel image and related components, including the dtb device tree binary file, the dtbo device tree overlay binary file, and the recovery image.

[0094] Furthermore, in this embodiment, in the embedded Linux device that starts disk verification, since the rootfs partition needs to be verified before mounting, the Kernel image cannot directly load init in the rootfs. At this time, an intermediate transition system is required. After the actual Kernel image is started, it will be transferred to the auxiliary system to perform the key functions of rootfs partition verification and virtual device creation. Please refer to Figure 5A flowchart of another secure boot method for an embedded device is shown. After the kernel image is loaded during normal secure boot, the auxiliary image system will be mounted to the / dev / ram0 virtual device file, and then transferred to the auxiliary system image for execution. This embodiment completes the signature verification of the auxiliary system image with the help of the signature verification of the kernel image, ensuring that the device boot process is safe, reliable and not tampered with.

[0095] Step S305: after the kernel image and related components are verified, a vroot virtual device is created through the auxiliary system image in the kernel image.

[0096] In an optional implementation, the step S305 includes:

[0097] During the boot process of the Kernel kernel image, the kernel loads and mounts the auxiliary system image, and creates a virtual device in the auxiliary system image; wherein the auxiliary system image is mounted to the root file system ( / ) as a temporary file system, that is, the files and directories in the auxiliary system image will be accessed as the root file system of the system, allowing the kernel and the startup script to access these files to complete the startup process;

[0098] Mount the auxiliary system image in the virtual device file of the Kernel kernel image;

[0099] Execute the verified Kernel image and check the creation of the target device node in the auxiliary system image;

[0100] If the target device node has been created, a vroot virtual device is created in the actual rootfs partition through the target device node.

[0101] For further information, see Figure 6The verification process diagram of the auxiliary system image is shown. After entering the auxiliary system in this embodiment, the program first determines whether the / dev / mapper / control device node (i.e. the above-mentioned target device node, which is the device node under the / dev / mapper / control directory) exists. The device node is used to communicate with the device mapper (Device Mapper) to allow advanced operations on block devices, such as the subsequent creation of a virtual device for the partition where the rootfs is located. If the current / dev / mapper / control device node does not exist, wait for the device mapper driver to load and create the device node within the specified time; if the device node exists, use the veritysetup command tool in the auxiliary image system to create a virtual device vroot for the partition where the rootfs is located. When vroot is created, the hashmap after the rootfs image and the hashroot in the init script will be used to verify the rootfs partition. When the verification is completed, the vroot device will be activated, otherwise the vroot device activation fails or the creation is unsuccessful. If the vroot virtual mapping device is successfully created, vroot is mounted. The vroot virtual mapping device actually maps the rootfs partition. After mounting, init in rootfs is executed.

[0102] That is to say, after verifying the trust chain step by step, this embodiment first loads the Kernel kernel image, and after checking the integrity, loads the auxiliary system image into the virtual device file / dev / ram0, and switches the execution environment to the auxiliary system. In the auxiliary system image, first check whether the / dev / mapper / control device node exists. The / dev / mapper / control device node is an interface for communicating with the device mapper, allowing advanced block device operations.

[0103] Use the veritysetup command tool in the auxiliary system image to create a virtual device corresponding to the rootfs partition in the vroot virtual device. When creating the vroot virtual device, the hashmap after the rootfs image and the hashroot in the init script will be used to verify the integrity of the rootfs partition.

[0104] After the verification is completed, if the verification is successful, the vroot virtual device will be activated. If the verification fails or the creation is unsuccessful, the activation of the vroot virtual device may fail. The successfully created and activated vroot virtual device will be used to map and mount the actual rootfs partition. After the mounting is completed, the init program in the rootfs is executed to start the normal system initialization and startup process. After the normal safe boot is completed, the Kernel kernel image is loaded. That is, this embodiment first mounts the auxiliary system image to the / dev / ram0 virtual device file; then executes the auxiliary system image, the safe boot process is transferred to the auxiliary system image, and the rootfs partition verification and virtual device creation are performed; then the Kernel kernel image signature verification operation is performed, and the signature verification result of the Kernel kernel image is used to complete the signature verification of the auxiliary system image to ensure the security and integrity of the startup process. After that, the target device node check operation is performed. After entering the auxiliary system, the program checks whether the / dev / mapper / control device node exists. If the / dev / mapper / control device node exists, the Device Mapper device mapper is used to communicate with it, and advanced block device operations are performed. The rootfs partition is verified using the veritysetup command tool and the hashmap of the rootfs image. After the verification passes, the vroot virtual device is created and activated. If the verification fails, the vroot virtual device activation fails or the creation is unsuccessful. After the vroot is successfully created, it is mounted to the rootfs partition and the init process in the rootfs is executed.

[0105] Furthermore, in the auxiliary system image above, init executes the veritysetup command tool to create a virtual device vroot for the rootfs partition. The whole process can be divided into user space state and kernel state. The rootfs verification needs to be implemented through initramfs (initialized memory file system):

[0106] User space state virtual mapping device creation and rootfs verification process (this embodiment uses the veritysetup command tool to create a virtual device vroot for the rootfs partition through initramfs):

[0107] 1. Create the / dev / device-mapper / vroot virtual mapping device, pass in the logical partition name and randomly generated uuid parameters (call the kernel ioctl command DM_DEV_CREATE_CMD). That is, in this embodiment, under the initramfs environment, the veritysetup command will first call the user space interface of the Linux device mapper (Device Mapper) to request the kernel to create a virtual mapping device named / dev / device-mapper / vroot. The request is sent to the kernel through the ioct1 system using the DM_DEV_CREATE_CMD command call, and the logical partition name, randomly generated UUID and other parameters are passed in. After receiving the request, the kernel will check the validity of the request and create the corresponding virtual device file in the / dev / device-mapper directory.

[0108] 2. Load the verity table, which contains the parameters used in the final verification calculation process, such as the starting position of the HashMap device, the Hash algorithm, RootHash, salt and other information. This information is calculated when the HashMap is generated during the rootfs construction phase, and is stored in a fixed position in the rootfs image. The verity table is passed to the kernel by calling the kernel ioctl command DM_TABLE_LOAD_CMD. That is, the veritysetup of this embodiment loads a verity table (verity table), which contains all the information required for integrity verification, such as the location of the HashMap device, the Hash algorithm used, RootHash (root hash value), salt (salt value), etc. This information is pre-calculated and embedded in the image when the rootfs image is built. After that, the DM_TABLE_LOAD_CMD command is called through ioct1 to pass the verity table to the kernel, which parses the verity table and prepares for subsequent verification work.

[0109] 3. Activate the / dev / device-mapper / vroot virtual mapping device and call the kernel ioctl command DM_DEV_SUSPEND_CMD to activate the virtual mapping device vroot. That is, in this embodiment, after the verity table is loaded and prepared, veritysetup will send an activation command to the kernel to start the verification process of the virtual mapping device vroot; after the kernel receives the activation command, it will start the verification process, including reading the rootfs image and HashMap data, using the specified Hash algorithm to calculate the verification value, and comparing it with RootHash. If the verification passes, the rootfs is considered to be complete and can be safely mounted and used; if the verification fails, appropriate recovery measures may need to be taken.

[0110] Step S306: When the vroot virtual device is created, the actual rootfs partition is verified.

[0111] Furthermore, the vroot virtual device creation and rootfs verification process includes:

[0112] 1. According to the parameters transmitted by the ioctl interface (DM_DEV_CREATE_CMD) provided by the kernel to the user space, the dev_create function in the dm-ioctl.c file is used to create the corresponding mapped device structure. This process is very simple. It mainly applies to the kernel for necessary memory resources, including the mapped device and the memory pool pre-applied for IO operations, and registers the request queue dm_request corresponding to the mapped device through the blk_queue_make_request function provided by the kernel. And the mapped device is registered in the kernel as a disk block device. That is, the user space of this embodiment sends a request to the kernel through the ioctl interface DM_DEV_CREATE_CMD, and the kernel responds to this request and creates a mapped device structure in the dev_create function in the dm-ioctl.c file. This process includes allocating memory resources, registering the request queue (dm_request) and registering the device as a disk block device.

[0113] 2. Call dm_hash_insert to insert the created mapped device into a global hash table in the device mapper, which stores all the mapped devices currently created in the kernel. That is, this embodiment calls dm_hash_insert to insert the created mapped device into the global device mapping table, which maintains all the mapped devices currently created in the kernel.

[0114] 3. The user space command calls the table_load function through the ioctl interface (DM_LOAD_TABLE_CMD), which builds the mapping table and the mapped target device of the specified mapped device according to the parameters sent by the user space. The function first builds the corresponding dm_table and dm_target structures, then calls the dm_table_add_target function in dm-table.c to initialize these structures according to the parameters passed in by the user, and calls the corresponding target type construction function ctr according to the target type specified by the parameters to build the structure corresponding to the target device in the memory, and then updates the B tree maintained in the dm_table according to the established dm_target structure. After the above process is completed, the established dm_table is added to the hash_cell structure corresponding to the global hash table of the mapped device. That is, the user space of this embodiment calls the table_load function through the ioctl interface DM_LOAD_TABLE_CMD to build the mapping table and target device of the specified mapped device. The table_load function builds the dm_table and dm_target structures according to the passed in parameters and initializes these structures. Then, according to the specified target type, the corresponding construction function is called to create the structure of the target device in the kernel. Finally, the constructed dm_table is added to the hash_cell structure corresponding to the global mapping table of the mapped device.

[0115] 4. Finally, the do_resume function is called through the ioctl interface (DM_DEV_SUSPEND_CMD) to establish the binding relationship between the mapped device and the mapping table. In fact, this process is to assign the current dm_table structure pointer value to the corresponding map field of the mapped_device through the dm_swap_table function, and then modify the field of the mapped_device indicating the current state. That is, this embodiment calls the do_resume function through the ioctl interface DM_DEV_SUSPEND_CMD to establish the binding relationship between the mapped device and the mapping table, and then uses the dm_swap_table function to assign the current dm_table structure pointer to the map field of the mapped device, and finally modifies the state field of the mapped device to indicate that the device is ready.

[0116] Through the above four main steps, the device mapper establishes a mapped device logical block device in the kernel that can be provided to users, ensuring that the integrity of the rootfs can be effectively verified when the system starts, thereby ensuring the security and reliability of the system.

[0117] Step S307, after the actual rootfs partition passes the verification, the vroot virtual device is mounted to the virtual rootfs partition corresponding to the actual rootfs partition.

[0118] Step S308, after the mounting is completed, switch to the actual rootfs partition and execute the init initialization program in the actual rootfs partition to start the system initialization process.

[0119] Furthermore, after the rootfs corresponding virtual device vroot is mounted, when the system is executed, if the rootfs partition file is read, the verification process of the block where the file is located in this embodiment is as follows:

[0120] 1. The user space program calls the read system call, which enters the kernel space through the system call interface. The VFS (virtual file system) in the kernel space processes the file read request and calls the read_pages of the corresponding file system (here is ext4). The read_pages function reads the data block through the block device driver of the file system. That is, the user space program in this embodiment sends a file read request through the read system call, the virtual file system (VFS) in the kernel space receives the request, and calls the read_pages function of the corresponding file system to process it.

[0121] 2. The block device driver calls the submit_bio function to pass the read request to the dm-verity driver module. That is, the read_pages function of the file system in this embodiment initiates a data block read request through the block device driver, and the block device driver uses the submit_bio function to pass the read request to the dm-verity driver module.

[0122] 3. After receiving the read request, the dm-verity driver module calls the dm_io_sync_vm function to perform I / O operations, and calls the dm_verity_io function to perform integrity verification. That is, after receiving the read request, the dm-verity driver module in this embodiment calls the dm_io_sync_vm function to perform I / O operations, and the dm-verity driver module uses the dm_verity_io function to perform integrity verification of the data block.

[0123] 4. The dm_verity_io function calculates the hash value of the data block according to the metadata information of dm-verity, and compares it with the hash value in the corresponding HashMap. If the verification is successful, the dm_verity_io function returns success, and the data block is passed back to the file system; if the verification fails. The dm_verity_io function returns failure, and the file system denies data access. That is, the dm_verity_io function in this embodiment calculates the hash value of the data block according to the dm-verity metadata information, and compares the calculated hash value with the hash value pre-stored in the HashMap. If the hash values ​​match, it means that the data block has passed the integrity check, the dm_verity_io function returns success, and the data block is passed back to the file system. If the hash values ​​do not match, it means that the data block may have been tampered with or damaged, the dm_verity_io function returns failure, and the file system denies data access.

[0124] The HashMap behind the rootfs image is calculated and attached during the image compilation and construction period. After the rootfs image is built, the rootfs.etx4 is aligned to 1M and offset to prevent the impact of bad blocks. Then the veritysetup tool is used to calculate the HashMap of the rootfs, and after it is appended to the rootfs image, the RootHash and HashOffset values ​​of its HashMap are written into the security.info file. When building the auxiliary system image, the RootHash and HashOffset in the security.info file are replaced with the corresponding variable values ​​in the init script of the auxiliary system. That is, in the process of building the rootfs image, the veritysetup tool is used to calculate the rootfs HashMap in this embodiment, and the HashMap contains the hash values ​​of each data block. RootHash is the root hash value of the entire rootfs image, which is used to verify the integrity of the entire image. HashOffset is the offset information of each data block in the rootfs image, ensuring that each data block is correctly located in the file system.

[0125] In the above scheme, the HashMap of the rootfs image is usually stored in the same partition as the rootfs image. However, in order to improve the security and reliability of the system, it is possible to store the rootfs image and its corresponding HashMap separately and place them in different Disks or different partitions of the same Disk. This embodiment has the following advantages:

[0126] First, storing the HashMap in a different location from the physical location of the rootfs image can increase the security of data integrity verification. If an attacker modifies the rootfs image data but cannot modify the HashMap content at the same time, the verification process will detect the data tampering, thereby preventing malicious attacks and data corruption. Secondly, storing the HashMap in different locations can also improve the reliability of verification. Even if a storage device fails and causes the rootfs image or HashMap to be lost, the system can still verify through the data in another location to ensure data integrity. In addition, if the device conditions permit, the HashMap can be stored in a faster access location, such as memory. This can reduce the impact of the verification process on the overall performance and improve the efficiency and response speed of the system. Therefore, storing the rootfs image and its corresponding HashMap separately is an important design strategy that comprehensively considers system security, reliability, and performance.

[0127] In summary, the present invention divides the processor into a non-secure world and a secure world to achieve hardware-level security isolation, establishes a trust chain guided by Arm trusted firmware, and uses BootROM read-only memory as the trust root of the boot process, ensuring the credibility and integrity of the boot process, thereby preventing malicious software or unauthorized modifications from entering the system. Only after the Kernel kernel image is verified will the vroot virtual device continue to be created, ensuring the integrity and correctness of the operating system core, and preventing unauthorized or damaged software from affecting the stability and security of the system. By creating a vroot virtual device and mounting it to a virtual rootfs partition, the maintainability and scalability of the system can be enhanced, while reducing the dependence on the actual hardware partition, making the system easier to update and maintain. After mounting the vroot virtual device to the virtual rootfs partition, switch to the actual rootfs partition and execute the initialization process of the operating system, ensuring that the embedded device can be started in a safe and verified environment, not only enhancing the reliability of the embedded device, but also improving the efficiency and stability of the embedded device when it is started.

[0128] In this embodiment, a secure boot device for an embedded device is also provided, which is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0129] This embodiment provides a secure boot device for an embedded device, such as Figure 7 As shown, including:

[0130] A secure world partitioning module 701 is used to partition the processor in the target system architecture into a non-secure world and a secure world;

[0131] A trust chain verification module 702 is used to establish a trust chain guided by the Arm trusted firmware, and use the BootROM read-only memory as the trust root of the startup process to verify the trust chain step by step;

[0132] The vroot virtual device creation module 703 is used to verify the Kernel image in the secure world, and after the Kernel image passes the verification, create a vroot virtual device through the auxiliary system image in the Kernel image;

[0133] The rootfs partition execution module 704 is used to mount the vroot virtual device to the virtual rootfs partition, and after the mounting is completed, switch to the actual rootfs partition to execute the initialization process of the operating system.

[0134] In some optional implementations, the trust chain verification module 702 includes:

[0135] After enabling secure boot on the embedded device, a chain of trust is established guided by the Arm trusted firmware;

[0136] The BootROM read-only memory is used as the trust root of the boot process to establish the starting link of the trust chain, and the integrity of each boot component in the trust chain is verified step by step.

[0137] In some optional implementations, the startup components include an SPL secondary program loader, a U-Boot universal boot loader, an SML security monitor loader, and a TOS trusted operating system.

[0138] In some optional implementations, the vroot virtual device creation module 703 is further used to:

[0139] Perform integrity check on the kernel image and related components; the related components include the dtb device tree binary file, the dtbo device tree overlay binary file, and the recovery image.

[0140] In some optional implementations, the vroot virtual device creation module 703 is further used to:

[0141] Mount the auxiliary system image in the virtual device file of the Kernel kernel image;

[0142] Execute the verified Kernel image and check the creation of the target device node in the auxiliary system image;

[0143] If the target device node has been created, a vroot virtual device is created in the actual rootfs partition through the target device node.

[0144] In some optional implementations, the rootfs partition execution module 704 is further used to:

[0145] When the vroot virtual device is created, the actual rootfs partition is verified;

[0146] After the actual rootfs partition passes the verification, the vroot virtual device is mounted to the virtual rootfs partition corresponding to the actual rootfs partition.

[0147] In some optional implementations, the rootfs partition execution module 704 is further used to:

[0148] Switch to the actual rootfs partition and execute the init initialization program in the actual rootfs partition to start the system initialization process.

[0149] In summary, the present invention divides the processor into a non-secure world and a secure world to achieve hardware-level security isolation, establishes a trust chain guided by Arm trusted firmware, and uses BootROM read-only memory as the trust root of the boot process, ensuring the credibility and integrity of the boot process, thereby preventing malicious software or unauthorized modifications from entering the system. Only after the Kernel kernel image is verified will the vroot virtual device continue to be created, ensuring the integrity and correctness of the operating system core, and preventing unauthorized or damaged software from affecting the stability and security of the system. By creating a vroot virtual device and mounting it to a virtual rootfs partition, the maintainability and scalability of the system can be enhanced, while reducing the dependence on the actual hardware partition, making the system easier to update and maintain. After mounting the vroot virtual device to the virtual rootfs partition, switch to the actual rootfs partition and execute the initialization process of the operating system, ensuring that the embedded device can be started in a safe and verified environment, not only enhancing the reliability of the embedded device, but also improving the efficiency and stability of the embedded device when it is started.

[0150] The further functional description of each of the above modules and units is the same as that of the above corresponding embodiments and will not be repeated here.

[0151] In this embodiment, a secure boot device of an embedded device is presented in the form of a functional unit, where the unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that executes one or more software or fixed programs, and / or other devices that can provide the above functions.

[0152] The embodiment of the present invention also provides a computer device having the above Figure 7 A secure boot device for an embedded device is shown.

[0153] See also Figure 8 , Figure 8 is a schematic diagram of the structure of a computer device provided by an optional embodiment of the present invention, such as Figure 8As shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in or on the memory to display the graphical information of the GUI on an external input / output device (such as, a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Figure 8 A processor 10 is taken as an example.

[0154] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic or any combination thereof.

[0155] The memory 20 stores instructions executable by at least one processor 10, so that the at least one processor 10 executes the method shown in the above embodiment.

[0156] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely arranged relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0157] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid state drive; the memory 20 may also include a combination of the above types of memory.

[0158] The computer device further comprises a communication interface 30 for the computer device to communicate with other devices or a communication network.

[0159] The embodiment of the present invention also provides a computer-readable storage medium. The method according to the embodiment of the present invention can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium through a network download, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0160] A part of the present invention may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present invention through the operation of the computer. Those skilled in the art should understand that the existence of the computer program instruction in a computer-readable medium includes, but is not limited to, a source file, an executable file, an installation package file, etc., and accordingly, the way in which the computer program instruction is executed by the computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium may be any available computer-readable storage medium or communication medium accessible to the computer.

[0161] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations are all within the defined scope.

Claims

1. A secure boot method for an embedded device, characterized in that: The method comprises: Partitioning the processors in the target system architecture into a non-secure world and a secure world; Establish a trust chain guided by the Arm trusted firmware, and use the BootROM read-only memory as the trust root of the boot process to verify the trust chain step by step; In the secure world, the Kernel image is verified, and after the Kernel image passes the verification, a vroot virtual device is created through the auxiliary system image in the Kernel image; The vroot virtual device is mounted to the virtual rootfs partition, and after the mounting is completed, it is switched to the actual rootfs partition to execute the initialization process of the operating system.

2. The method according to claim 1, characterized in that The trust chain guided by the Arm trusted firmware is established, and the BootROM read-only memory is used as the trust root of the startup process, and the trust chain is verified step by step, including: After enabling secure boot on the embedded device, establishing a trust chain guided by the Arm trusted firmware; The BootROM read-only memory is used as the trust root of the startup process to establish the starting link of the trust chain, and the integrity of each startup component in the trust chain is verified step by step.

3. The method according to claim 2, characterized in that The startup components include an SPL secondary program loader, a U-Boot universal boot loader, an SML security monitor loader and a TOS trusted operating system.

4. The method according to claim 1, characterized in that: The verification of the Kernel kernel image includes: Perform integrity check on the Kernel kernel image and related components; the related components include the dtb device tree binary file, the dtbo device tree overlay binary file and the recovery image.

5. The method according to claim 1, characterized in that The step of creating a vroot virtual device through the auxiliary system image in the Kernel kernel image includes: During the booting process of the Kernel kernel image, the kernel loads and mounts the auxiliary system image, and creates a virtual device in the auxiliary system image; Execute the verified Kernel image and check the creation status of the target device node in the auxiliary system image; If the target device node has been created, a vroot virtual device is created in the actual rootfs partition through the target device node.

6. The method according to claim 5, characterized in that Mounting the vroot virtual device to the virtual rootfs partition includes: When the vroot virtual device is created, verifying the actual rootfs partition; After the actual rootfs partition passes the verification, the vroot virtual device is mounted to the virtual rootfs partition corresponding to the actual rootfs partition.

7. The method according to any one of claims 1 to 6, characterized in that: The process of switching to the actual rootfs partition to execute the initialization of the operating system includes: Switch to the actual rootfs partition and execute the init initialization program in the actual rootfs partition to start the system initialization process.

8. A secure boot device for an embedded device, characterized in that: The device comprises: A secure world partition module, used to partition the processor in the target system architecture into a non-secure world and a secure world; A trust chain verification module is used to establish a trust chain guided by the Arm trusted firmware, and use the BootROM read-only memory as the trust root of the startup process to verify the trust chain step by step; A vroot virtual device creation module, used to verify the Kernel image in the secure world, and after the Kernel image passes the verification, create a vroot virtual device through the auxiliary system image in the Kernel image; The rootfs partition execution module is used to mount the vroot virtual device to the virtual rootfs partition, and after the mounting is completed, switch to the actual rootfs partition to execute the initialization process of the operating system.

9. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the secure startup method of an embedded device according to any one of claims 1 to 7 by executing the computer instructions.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute a secure startup method for an embedded device according to any one of claims 1 to 7.

Images