Chip secure boot method and related device

Abstract

The present application provides a chip secure boot method and a related device, used for reducing ROM space required for secure boot. The method comprises performing hash verification on a second-level boot program on the basis of a first-level boot program in a ROM; if the hash verification of the second-level boot program succeeds, performing signature verification on a third-level boot program and an OS program level by level on the basis of the second-level boot program; and if the hash verification of the second-level boot program fails, entering exception processing.

Description

A secure boot method for a chip and related equipment

[0001] This application claims priority to Chinese Patent Application No. 202410807989.0, filed on June 20, 2024, entitled "A Secure Startup Method for a Chip and Related Devices", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of computers, and in particular to a secure boot method for a chip and related equipment. Background Technology

[0003] Secure boot, also known as verified boot, is the foundation for ensuring the trustworthiness of a hardware system. Typically, secure boot starts from the root of trust in the hardware and follows the boot order of the basic input / output system (BIOS), operating system (OS), and application (APP). It uses public key certificates to verify the code at each level, ensuring that only trusted code is loaded and run during system startup.

[0004] In related technical solutions, the first-level boot program is embedded in the chip. When the second-level boot program is verified for secure boot using the first-level boot program, an asymmetric signature verification algorithm is used, which requires a large read-only memory (ROM) space. For chips with limited ROM space, it may be impossible to achieve secure booting of the chip within the ROM. Summary of the Invention

[0005] This application provides a secure boot method and related equipment for a chip, which reduces the ROM space required for secure boot.

[0006] In a first aspect, this application provides a secure boot method for a chip, comprising:

[0007] The first-level boot program used for hash verification is stored in the ROM. The processor performs hash verification on the second-level boot program based on the first-level boot program. If the hash verification of the second-level boot program passes, the processor performs signature verification on the third-level boot program and the OS program sequentially, based on the second-level boot program. "Sequentially" here refers to performing signature verification in the order of the third-level boot program and the OS program. If the hash verification of the second-level boot program fails, the processor enters an exception handling procedure. The specific content of the exception handling depends on the chip type; different chips have different exception handling procedures, which are not limited here.

[0008] As explained above, in this application, the hash verification and signature verification programs used during the secure boot process of the chip are located in different locations. Specifically, the ROM only needs to store the first-level boot program for hash verification and does not need to store the second-level boot program for signature verification, thus reducing the ROM space required for secure boot. This also means that during the chip design phase, only the first-level boot program in the ROM needs to be verified, reducing the ROM verification workload and the risk of ROM fabrication.

[0009] In some optional implementations of the first aspect, the second-level boot program includes a main program and at least one backup program. The hash verification of the second-level boot program can then be performed in a primary / backup order. That is, the main program is hash verified first; if the hash verification of the main program fails, the backup program is hash verified; if the hash verification of the main program passes, the hash verification of the second-level boot program is considered successful. In the scheme of hash verification of backup programs, at least one backup program is hash verified sequentially until the hash verification of the target backup program passes, or until the hash verification of all backup programs fails. In simpler terms, the hash verification of the main program and at least one backup program included in the second-level boot program is performed in a primary / backup order until one of the programs passes, or until the hash verification of all programs fails.

[0010] In this application, the second-level boot program includes a main program and at least one backup program. Even if the hash verification of the main program fails, the hash verification of the backup program can still be performed, thereby increasing the probability of successful hash verification and further improving the chance of secure boot.

[0011] In one possible implementation of the first aspect, the hash verification of the second-level boot program passes, including: the hash verification of the main program passes, or the hash verification of the target backup program in at least one backup program passes. The hash verification of the second-level boot program fails, including: the hash verification of both the main program and at least one backup program fails.

[0012] In one possible implementation of the first aspect, the storage location of the verified second-level boot program can be varied, including storage in flash memory or in the chip; no specific limitation is made here.

[0013] In this application, the storage location of the second-level boot program can be varied, which enriches the implementation methods and application scenarios of the technical solution of this application.

[0014] In one possible implementation of the first aspect, the initial storage location of the second-level boot program is contained in flash memory. In a scheme where the flash memory is located external to the chip, this means the initial storage location of the second-level boot program is not on the chip. Before performing hash verification on the second-level boot program, the processor loads the second-level boot program from flash memory into the chip's internal space, excluding ROM. Therefore, when performing hash verification on the second-level boot program based on the first-level boot program, it is actually performed on the second-level boot program within the chip. That is, the second-level boot program being verified is stored on the chip.

[0015] In this application, the processor can load the second-level boot program from the external flash memory to the internal space of the chip, excluding ROM. Since the security inside the chip is higher than that outside the chip, the second-level boot program is not easy to be attacked, thus improving the security of the technical solution of this application.

[0016] In one possible implementation of the first aspect, where the initial storage location of the second-level boot program is located in flash memory, and the flash memory is located outside the chip, the second-level boot program stored in the flash memory may not need to be loaded into the chip. In this technical solution, based on the first-level boot program, the verified second-level boot program is located in the flash memory.

[0017] In one possible implementation of the first aspect, the flash memory is located inside the chip, and the second-level boot program is stored in the flash memory. It can be understood that in this technical solution, the second-level boot program is also located inside the chip. This means that both the initial storage location of the second-level boot program and its storage location during verification are located in the flash memory. Since the flash memory is located inside the chip, it can also be understood that both the initial storage location of the second-level boot program and its storage location during verification are located within the chip.

[0018] In this application, the positional relationship between the flash memory storing the second-level boot program and the chip can be varied, and can be flexibly set according to the needs of actual applications, thereby improving the flexibility of the technical solution of this application.

[0019] In one possible implementation of the first aspect, the first-level boot program in the ROM is either embedded in the ROM chip or imported into the ROM via a ROM patch. That is, the first-level boot program can be hard-coded into the ROM during the chip design phase. Alternatively, for existing chips that do not support secure boot or whose ROMs are unavailable, the first-level boot program can be imported into the ROM via a ROM patch, enabling the ROM to implement the secure boot functionality provided in this application.

[0020] In this application, the source of the first-level boot program in the ROM can be multiple, which enriches the implementation methods and application scenarios of the technical solution of this application and further enhances the flexibility of the technical solution.

[0021] Secondly, this application provides a secure boot device for a chip, including a processing unit for:

[0022] The second-level boot program is hash-verified based on the first-level boot program in the ROM.

[0023] If the hash verification of the second-level boot program passes, then the signature verification of the third-level boot program and the OS program is performed level by level based on the second-level boot program.

[0024] If the hash check of the second-level boot program fails, exception handling will be initiated.

[0025] The secure boot device of the chip is used to implement the method shown in the first aspect or any possible implementation of the first aspect, and its beneficial effects are as described above, and will not be repeated here.

[0026] Thirdly, this application provides a chip including at least one processor and a communication interface, the communication interface and the at least one processor being interconnected via a circuit. The communication interface in the chip can be an input / output interface, pins, or circuits, etc. The at least one processor is used to run computer programs or instructions to perform the methods shown in the first aspect, or any of the possible implementations of the first aspect.

[0027] Fourthly, this application provides a computer device including a processor and a memory, wherein the processor stores instructions that, when executed on the processor, implement the method shown in the first aspect or any possible implementation of the first aspect.

[0028] Fifthly, this application provides a computer-readable storage medium storing instructions that, when executed on a processor, implement the method shown in the first aspect or any possible implementation of the first aspect.

[0029] Sixthly, this application provides a computer program product that, when executed on a processor, implements the method shown in the first aspect or any possible implementation of the first aspect.

[0030] The beneficial effects shown in any of the fourth to sixth aspects are similar to those of the first aspect or any possible implementation of the first aspect, and will not be repeated here. Attached Figure Description

[0031] Figure 1 is a schematic diagram of a system architecture provided in an embodiment of this application;

[0032] Figure 2 is a schematic diagram of another system architecture provided in an embodiment of this application;

[0033] Figure 3 is a flowchart illustrating a secure boot method for a chip provided in an embodiment of this application.

[0034] Figure 4 is another flowchart illustrating the secure boot method for a chip provided in an embodiment of this application.

[0035] Figure 5 is a schematic diagram of a secure boot method for a chip provided in an embodiment of this application.

[0036] Figure 6 is another flowchart illustrating the secure boot method for a chip provided in an embodiment of this application.

[0037] Figure 7 is another flowchart illustrating the secure boot method for a chip provided in an embodiment of this application.

[0038] Figure 8 is a structural schematic diagram of a secure boot device for a chip provided in an embodiment of this application;

[0039] Figure 9 is a structural schematic diagram of a computer device provided in an embodiment of this application;

[0040] Figure 10 is another structural schematic diagram of the computer device provided in an embodiment of this application. Detailed Implementation

[0041] This application provides a secure boot method and related equipment for a chip, which reduces the ROM space required for secure boot.

[0042] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0043] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of units is not necessarily limited to those units, but may include other units not explicitly listed or inherent to those processes, methods, products, or apparatuses. Additionally, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can be expressed as: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0044] First, the relevant concepts and proper nouns involved in the embodiments of this application will be explained:

[0045] 1) Boot program:

[0046] The boot program, also known as the startup program, is a program that executes before the operating system runs. Its main functions include initializing hardware devices and establishing a memory space mapping table, thereby building the appropriate system software and hardware environment. In scenarios involving secure chip booting, the boot program is verified before the OS program.

[0047] 2) Secure boot of the chip:

[0048] Secure boot, also known as verified boot, is fundamental for ensuring the trustworthiness of hardware systems. Its core function is to use digital signatures to determine whether firmware and software are trusted, thereby guaranteeing information security during the boot phase. Furthermore, secure boot relies on a hardware infrastructure, often referred to as the root of trust, which is the consistently trusted source in a cryptographic system. Starting from the root of trust, secure boot verifies each level of the image to ensure the legitimacy of the next level, thus establishing a chain of trust and ultimately building the trustworthiness of the entire platform.

[0049] Please refer to Figures 1 and 2 below. Figures 1 and 2 are schematic diagrams of the system architecture provided in the embodiments of this application.

[0050] As shown in Figure 1, the system-on-a-chip (SOC) includes: a central processing unit (CPU), read-only memory (ROM), an electronic fuse (eFuse), a ROM patch, and peripherals. Flash memory is connected externally to the chip.

[0051] In this embodiment, the CPU executes programs in the ROM and flash memory to perform verifications during the secure boot process of the chip. The specific process will be described in detail later and will not be repeated here.

[0052] ROM is used to implement hash verification capabilities. ROM patch is used to modify or replace the code in the ROM; specifically, it refers to inputting the code burned into the electronic fuse into the ROM. Flash memory is used to boot the image, that is, to start the program after the first-level boot program.

[0053] Peripherals, also known as the basic peripherals of a chip, are used to ensure the chip's basic functions. These basic functions include communication or data transmission between the chip and external devices, and communication or data transmission between various modules within the chip. The basic peripherals required by a chip are related to its type; different types of chips may require different basic peripherals, and this application does not impose any limitations on this. Optionally, chip peripherals may include transceiver interfaces, circuits, pins, etc.

[0054] Unlike the embodiment shown in Figure 1, in the embodiment shown in Figure 2, the flash memory is located in the system-on-a-chip (SoC), meaning it is internal to the chip and not an external device. This also illustrates that the positional relationship between the flash memory and the chip is not limited in this application embodiment; the SoC may or may not include flash memory, thereby improving the flexibility of the technical solution.

[0055] The secure boot method for a chip provided in this application embodiment will be described in detail below. Please refer to Figure 3, which is a flowchart illustrating the secure boot method for a chip provided in this application embodiment.

[0056] 301. Perform hash verification on the second-level boot program based on the first-level boot program in the ROM.

[0057] After the chip powers on and the CPU is de-reset, the CPU begins executing the chip's secure boot process. First, a hash check is performed on the second-level boot program based on the first-level boot program.

[0058] The first-level boot program can be understood as the chip's secure boot code. It can be hard-coded into the chip's register transfer level (RTL) circuitry or programmed into the chip's eFuse, and then replaced with the original ROM code via a ROM patch. Specific implementation methods will be explained in detail later. In general, the first-level boot program can be understood as being embedded in the chip's ROM and does not require verification.

[0059] In this embodiment, the initial storage location of the second-level boot program is contained in flash memory, while the storage location of the verified second-level boot program can be varied, including storage in flash memory or on the chip itself; no specific limitation is made here. This means that the storage location of the second-level boot program may change from the initial state to the completion of verification. The possible scenarios are described below:

[0060] In some optional implementations, as shown in Figure 1, the flash memory is located external to the chip, and the second-level boot program is stored in the flash memory. This means that initially, the second-level boot program is also located external to the chip. Before hash verification of the second-level boot program, i.e., before step 301, the CPU can also load the second-level boot program from flash memory into the chip's internal space, excluding ROM. In other words, although the second-level boot program is loaded into the chip, it does not occupy ROM space. Therefore, when hash verification is performed on the second-level boot program, the actual second-level boot program being verified is located internal to the chip.

[0061] Optionally, the second-level boot program can be loaded from flash into the static random-access memory (SRAM) included in the chip.

[0062] In this application, the CPU can load the second-level boot program from external flash memory into the internal space of the chip, excluding ROM. Since the security inside the chip is higher than that outside, the second-level boot program is less vulnerable to attack, thus improving the security of the technical solution in this application. Furthermore, although the second-level boot program is loaded into the chip, it does not occupy ROM space, meaning that the ROM space used for secure chip boot will not increase as a result.

[0063] In some alternative implementations, as shown in Figure 1, the flash memory is located external to the chip, and the second-level boot program is stored in the flash memory. In the scheme where the flash memory is external to the chip, that is, where the initial storage location of the second-level boot program is external to the chip, the second-level boot program in the flash memory may not need to be loaded into the chip; instead, hash verification can be performed directly on the externally located second-level boot program. In other words, the second-level boot program verified based on the first-level boot program is located in the flash memory. In this scheme, there is no need to load the second-level boot program into the chip, simplifying the operation and making the scheme simpler to operate.

[0064] In some alternative implementations, such as the architecture shown in Figure 2, the flash memory is located inside the chip. In this implementation, the flash memory stores the second-level boot program, which is also located inside the chip. This means that both the initial storage location of the second-level boot program and its storage location during verification are located in the flash memory. Since the flash memory is located inside the chip, it can also be understood that both the initial storage location of the second-level boot program and its storage location during verification are located within the chip, specifically in the chip's flash memory. In this implementation, the CPU directly performs hash verification on the second-level boot program.

[0065] In this application embodiment, the storage location of the second-level boot program can be varied, enriching the implementation methods and application scenarios of the technical solution of this application.

[0066] In addition, in this embodiment of the application, the second-level boot program includes a main program and at least one backup program. Then, the hash verification of the second-level boot program includes: performing hash verification on the main program and at least one backup program based on the main / backup order until the hash verification passes, or until all program hash verifications fail.

[0067] For example, suppose the second-level boot program includes a main program, backup program 1, and backup program 2. Then, when performing hash verification on the second-level boot program, the hash verification is performed in the order of main program, backup program 1, and backup program 2. When a program's hash verification passes, subsequent programs are no longer verified, and the hash verification of the second-level boot program is considered successful. If the hash verification of all programs fails, then the hash verification of the second-level boot program is considered unsuccessful.

[0068] Specifically, in the aforementioned example, the CPU first verifies the main program. If the hash verification of the main program passes, then the hash verification of the second-level boot program is confirmed to have passed. If the hash verification of the main program fails, then a hash verification is performed on backup program 1. If the hash verification of backup program 1 passes, then the hash verification of the second-level boot program is confirmed to have passed. If the hash verification of backup program 1 fails, then a hash verification is performed on backup program 2. If the hash verification of backup program 2 passes, then the hash verification of the second-level boot program is confirmed to have passed. If the hash verification of backup program 2 also fails, then the hash verification of the second-level boot program is confirmed to have failed.

[0069] In addition, the CPU performs hash verification on the second-level boot program, including: calculating the hash value of the second-level boot program and obtaining the base hash value written in the eFuse. The hash value of the second-level boot program is compared with the base hash value; if they match, the hash verification passes. If they do not match, the hash verification fails.

[0070] Specifically, calculating the hash value of the second-level boot program refers to calculating the hash value of the program currently being verified. For example, if the program being verified is the main program included in the second-level boot program, the CPU calculates the hash value of that main program. Then, the hash value of the main program is compared with the base hash value. Furthermore, the technical solutions used to calculate the hash value of a program are similar to related technical solutions, such as using hash functions or hash algorithms, etc., and will not be elaborated further here.

[0071] The base hash value programmed in eFuse can be set at the chip factory, a preset value, or a value determined when the second-level boot program is released; the specific method is not limited here. As mentioned earlier, the purpose of the base hash value is to verify the hash value of the second-level boot program.

[0072] In summary, a successful hash check of the second-level boot program includes: a successful hash check of the main program included in the second-level boot program, or a successful hash check of the target backup program in at least one of the backup programs included in the second-level boot program. A failed hash check of the second-level boot program includes: a failed hash check of both the main program and at least one backup program included in the second-level boot program.

[0073] As can be seen from the foregoing description, in the implementation of this application, the second-level boot program includes a main program and at least one backup program. Even if the hash verification of the main program fails, the CPU can still perform hash verification on the backup program, thereby increasing the probability of successful hash verification and further improving the chance of secure boot.

[0074] 302. If the hash verification of the second-level boot program passes, then the signature verification of the third-level boot program and the OS program is performed level by level according to the second-level boot program.

[0075] If the hash verification of the second-level boot program passes, it means that the second-level boot program has not been tampered with and is a trustworthy program. Therefore, the system jumps to the second-level boot program to further verify the signatures of the third-level boot program and the OS program at each level. In other words, the second-level boot program is used for signature verification, and the CPU performs signature verification based on the second-level boot program.

[0076] In summary, the second-level boot program indicates that the signature verification order is the third-level boot program → OS program, and also indicates that the verification performed on these programs is signature verification. The technical solution used by the CPU for signature verification is similar to related technical solutions, and will not be elaborated here.

[0077] It's important to note that performing signature verification on the third-level boot program and then the OS program sequentially does not mean that both the third-level boot program and the OS program must be signed. Rather, it indicates that the signature verification order starts with the third-level boot program. Whether it's necessary to verify the OS program's signature depends on the result of the third-level boot program's signature verification.

[0078] Specifically, during the signature verification process, if the signature verification of the third-level boot program passes, the CPU then verifies the signature of the OS program. If the signature verification of the third-level boot program fails, it means that the third-level boot program may have been attacked or tampered with, the chip will not be securely booted, and the CPU enters an exception handling process. In this case, it is unnecessary to perform signature verification on the OS program. Similarly, if the signature verification of the OS program fails, it means that the OS program may have been attacked or tampered with, the chip will also not be securely booted, and the CPU will enter an exception handling process.

[0079] In summary, the CPU will only control the chip to boot securely if both the third-level boot program and the OS program pass signature verification. Secure boot in this scheme includes the secure boot of the OS of the device hosting the chip. If either the third-level boot program or the OS program fails signature verification, the chip will not boot securely, and the CPU will enter an exception handling process.

[0080] The specific details of the exception handling process vary depending on the chip type. Different chip types may have different exception handling procedures, which are set based on the actual application requirements and are not limited here. For example, exception handling can also be referred to as software post-processing, including resetting the chip and cleaning up memory.

[0081] 303. If the hash check of the second-level boot program fails, then enter exception handling.

[0082] If the hash verification of the second-level boot program fails, it indicates that the second-level boot program is untrusted and may have been attacked or tampered with. In this case, the chip will not be safely booted, and the CPU will enter the exception handling process. The exception handling process is similar to the exception handling process shown in step 302 above, and will not be repeated here.

[0083] Additionally, it should be noted that during a secure boot process, steps 302 and 303 are executed selectively. That is, a secure boot process will either include steps 301 and 302, or steps 301 and 303; steps 302 and 303 will not appear simultaneously in a single secure boot.

[0084] As described above, the secure boot scheme for the chip provided in this application embodiment divides the security verification required during the secure boot process into hash verification and signature verification, and the programs used for verification are located in different memories. For clarity, please refer to Figure 4, which is a flowchart illustrating the secure boot method for the chip provided in this application embodiment.

[0085] As shown in Figure 4, the base hash value of the second-level boot program is burned into the eFuse of the chip, and the ROM is also embedded in the chip. The second-level boot program, the third-level boot program, and the OS program are stored in flash memory. As can be seen from the explanations in Figures 1 and 2 above, the flash memory can be located inside or outside the chip. However, it is always outside the ROM and does not occupy ROM space.

[0086] During the secure boot process of the chip, step ① is executed first, based on the first-level boot program in ROM, to perform hash verification on the second-level boot program. If the hash verification of the second-level boot program passes, step ② is executed, based on the second-level boot program, to perform signature verification on the third-level boot program. If the signature verification of the third-level boot program passes, step ③ is executed, based on the third-level boot program, to perform signature verification on the OS program.

[0087] The second-level boot program, third-level boot program, and OS program are all initially stored in flash memory. In practical applications, before performing hash verification on the second-level boot program, it can be loaded into the chip's space excluding ROM, or it can be left unloaded. The specific implementation method has been described in the relevant explanation of step 301 above and will not be repeated here. Similarly, before performing signature verification on the third-level boot program or OS program, it can be loaded into the chip's space excluding ROM, or it can be left unloaded; there is no limitation here.

[0088] Furthermore, based on the aforementioned descriptions of Figures 3 and 4, it can be seen that the principle of the secure boot method for the chip provided in this application embodiment is to separate hash verification and signature verification, which are implemented through ROM and flash respectively. Please refer to Figure 5, which is a schematic diagram of the principle of the secure boot method for the chip provided in this application embodiment.

[0089] As shown by the left arrow in Figure 5, in related technical solutions, the ROM implements signature verification capabilities, including verification of boot programs and OS programs at all levels. As shown by the right arrow in Figure 5, in this embodiment, the aforementioned capabilities of the ROM are split into two parts: only the hash verification capability is implemented in the ROM, while the signature verification capability is separated into the second-level boot program.

[0090] In this embodiment, the second-level boot program can also be referred to as the initial boot (IBB) image. The second-level boot program is contained in the flash memory. Furthermore, as mentioned above, the flash memory may also include the third-level boot program and OS program required for verification during the chip's secure boot process. It is understood that, typically, flash memory has more space resources than the ROM within the chip, thus allowing for a larger image to be stored in the flash memory.

[0091] As explained above, in this application, the hash verification and signature verification programs used during the secure boot process of the chip are located in different locations. Specifically, the ROM only needs to store the first-level boot program for hash verification; it does not need to store the second-level boot program for signature verification, nor does it need to store the programs at each level that require verification (e.g., the second-level boot program, the third-level boot program, and the OS program), thus reducing the ROM space required for secure boot of the chip. This also means that during the chip design phase, only the first-level boot program in the ROM needs to be verified, reducing the ROM verification workload and further reducing the risk of ROM fabrication.

[0092] In the aforementioned embodiments, verification continues up to the OS program. In practical applications, during the secure boot process of the chip, the device hosting the chip may also launch an application (APP). Therefore, after the OS program's signature verification in step 302, if the OS program's signature verification passes, the CPU also performs signature verification on the APP. If the APP's signature verification passes, it indicates that the APP is trustworthy, and only then will the device hosting the chip run the APP.

[0093] Similarly, in scenarios where the flash memory is located externally to the chip, the third-level boot program, OS program, and application are contained within the flash memory. Before verifying these programs, optionally, they can be loaded into the chip's internal space (excluding ROM) to improve verification security. Alternatively, these programs can be left unloaded to simplify the process and reduce complexity.

[0094] In some optional implementations, in schemes that verify the signatures of the second-level boot program, OS program, or APP, if the verification of a program fails, the CPU can also issue a prompt message to indicate that the program failed the verification. Optionally, the prompt message can be displayed in various ways, such as via a serial port or indicator light, or on a device containing the chip. The specific method is determined based on the needs of the actual application and is not limited here.

[0095] As mentioned in step 301 above, the first-level boot program can be programmed into the chip's eFuse, and then the original code in the ROM can be replaced by a ROM patch. This technical solution will be explained in detail below with reference to the schematic diagram. Please refer to Figure 6, which is a flowchart illustrating the secure boot method for a chip provided in this embodiment of the application.

[0096] In the embodiment shown in Figure 6, taking a chip that has already been fabricated as an example, when a vulnerability is found in the secure boot function implemented by the chip's ROM, or the algorithm used is compromised, resulting in a security risk, the original program in the ROM is replaced with the first-level boot program provided in this application embodiment through the ROM patch function.

[0097] Specifically, a first-level boot program is programmed into the chip's eFuse. This first-level boot program is used to perform hash verification on the IBB image. The IBB image mentioned in this application is also the second-level boot program. After the chip powers on and the CPU is de-reset, the chip's ROM patch function reads the first-level boot program from the eFuse. Then, the program in the ROM is replaced with the first-level boot program. During the chip's secure boot process, the CPU performs hash verification on the IBB image based on the first-level boot program in the ROM. The subsequent signature verification process is similar to the embodiment described above and will not be repeated here.

[0098] It is understandable that by replacing the original program in the ROM with the first-level boot program provided in this application embodiment through the ROM patch function, this solution can not only be applied to the scenario shown in Figure 6 where the ROM is found to be unusable or vulnerable after chip return, but also to existing chips that do not support secure boot. For the former scenario, secure boot capability is preserved, and the operation is simple. For the latter scenario, the ROM in the chip can be upgraded, enabling the chip to support secure boot capability.

[0099] In general, in the embodiments of this application, the first-level boot program in the ROM can be either set in the ROM during the design phase and the chip is placed in the ROM, or it can be input into the ROM through the ROM patch function. The specific method is not limited here.

[0100] In this application, the source of the first-level boot program in the ROM can be multiple, which enriches the implementation methods and application scenarios of the technical solution of this application and further enhances the flexibility of the technical solution.

[0101] In summary, the operational logic of the secure boot method for the chip provided in this application embodiment is shown in Figure 7. Please refer to Figure 7, which is a flowchart illustrating the secure boot method for the chip provided in this application embodiment. Figure 7 uses a second-level boot program (i.e., an IBB image) including a main program and N backup programs as an example.

[0102] After the chip powers on and the CPU is reset, a hash verification is first performed on the IBB image. This includes calculating the hash value of the main program. If the hash value of the main program matches the base hash value, the hash verification of the IBB image is considered successful, and the process jumps to the IBB image to proceed to the signature verification process. If the hash value of the main program does not match the base hash value, the hash value of the i-th backup program is calculated, starting from the first backup program. If the hash value of any backup program matches the base hash value, the hash verification of the IBB image is considered successful, and the process jumps to the IBB image to proceed to the signature verification process. If the hash values ​​of all backup programs do not match the base hash value, the hash verification of the IBB image is considered failed, and the process enters the exception handling procedure.

[0103] In some alternative implementations, the flash memory is located external to the chip; that is, the main program and N backup programs included in the second-level boot program are located external to the chip. In this scheme, the CPU can perform multiple operations prior to hash verification.

[0104] Optionally, before calculating the hash value of the main program, the main program can be loaded from flash into the internal space of the chip, excluding ROM. If the hash verification of the main program fails, the backup program is loaded from flash into the internal space of the chip, excluding ROM, before calculating the hash value of the i-th backup program.

[0105] Optionally, before calculating the hash value of the main program, both the main program and the N backup programs can be loaded from flash memory into the chip's internal space, excluding ROM. For example, the aforementioned internal space excluding ROM can be SRAM.

[0106] Optionally, the aforementioned loading can be omitted, meaning the storage location of the second-level boot program can remain unchanged.

[0107] In the signature verification process, the signature of the third-level boot program is verified first. If the signature verification of the third-level boot program passes, the signature verification of the OS program is then performed. If the signature verification of the OS program also passes, the chip boots securely. If the signature verification of the third-level boot program fails, there is no need to verify the signature of the OS program, and the exception handling process begins.

[0108] It should be noted that the aforementioned embodiments all use a single ROM as an example. In practical applications, the processor can simultaneously process multiple sets of first-level boot programs in multiple ROMs, performing hash verification on the second-level boot program corresponding to each ROM. The method for performing hash verification on each second-level boot program is similar to the relevant descriptions above, and will not be repeated here.

[0109] Please refer to Figure 8 below, which illustrates a secure boot device for a chip according to an embodiment of this application. As shown in Figure 8, the secure boot device 800 for the chip includes a processing unit 801.

[0110] In some optional implementations, the processing unit 801 is configured to perform hash verification on the second-level boot program based on the first-level boot program in the ROM. If the hash verification of the second-level boot program passes, then the signature verification is performed on the third-level boot program and the OS program level by level based on the second-level boot program. If the hash verification of the second-level boot program fails, then exception handling is initiated.

[0111] In some optional implementations, the second-level boot program includes a main program and at least one backup program. The processing unit 801 is further configured to perform hash verification on the main program and at least one backup program in a primary / backup order until the hash verification passes, or until all program hash verifications fail.

[0112] In some optional implementations, a successful hash check of the second-level boot program includes: a successful hash check of the main program, or a successful hash check of the target backup program in at least one backup program. A failed hash check of the second-level boot program includes: both the hash checks of the main program and at least one backup program failing.

[0113] In some alternative implementations, the second-level boot program is stored in flash memory or on a chip.

[0114] In some alternative implementations, the initial storage location of the second-level boot program is contained in flash memory, which is located externally to the chip. Processing unit 801 is further configured to load the second-level boot program from the flash memory into a space within the chip that does not include ROM.

[0115] In some alternative implementations, the flash memory is located inside the chip.

[0116] In some alternative implementations, the first-level boot program in the ROM is either chipped into the ROM or input into the ROM via a ROM patch.

[0117] The secure boot device 800 for the chip is used to implement the operations performed by the processor in the embodiments shown in Figures 1 to 7 above, so as to realize the secure boot method of the chip provided in the embodiments of this application, as detailed above, and will not be repeated here.

[0118] This application also provides a chip, including a processing unit and a communication unit. The processing unit may be, for example, a processor, and the communication unit may be, for example, an input / output interface, pins, or circuits. The processing unit can execute computer execution instructions stored in a storage unit to implement the secure boot method of the chip described in the embodiments shown in Figures 1 to 7. Optionally, the chip architecture can be as shown in Figure 1 or Figure 2, as detailed above, and will not be repeated here.

[0119] Please refer to Figures 9 and 10, which are schematic diagrams of the structure of the computing device provided in the embodiments of this application.

[0120] As shown in Figure 9, the computer device 900 includes a chip 901, which is used to implement the secure boot method of the chip described in the embodiments shown in Figures 1 to 7. The chip architecture can be as shown in Figure 1 or Figure 2, as detailed above, and will not be repeated here.

[0121] As shown in Figure 10, the computer device 1000 includes a processor 1001, a memory 1002, a communication interface 1003, and a bus 1004. The processor 1001, memory 1002, and communication interface 1003 communicate via the bus 1004, or via wireless transmission or other means. The memory 1002 stores program code, and the processor 1001 can call the program code stored in the memory 1002 to execute the secure boot method of the chip in the embodiments shown in Figures 1 to 7, which will not be described in detail here.

[0122] It should be understood that in the embodiments of this application, the processor 1001 may be a CPU, or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0123] The memory 1002 may include read-only memory and random access memory, and provides instructions and data to the processor 1001. The memory 1002 may also include non-volatile random access memory. For example, the memory 1002 may also store device type information.

[0124] The memory 1002 can be volatile memory or non-volatile memory, or it can include both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0125] In addition to the data bus, bus 1004 can also include a power bus, control bus, and status signal bus. However, for clarity, all buses are labeled as bus 1004 in the diagram. Bus 1040 can be a Peripheral Component Interconnect Express (PCIe) bus, or an Extended Industry Standard Architecture (EISA) bus, a unified bus (Ubus or UB), a compute express link (CXL), a cache coherent interconnect for accelerators (CCIX), etc. Bus 1040 can be divided into address bus, data bus, control bus, etc.

[0126] Computer device 1000 may also include one or more communication interfaces and one or more operating systems, such as Windows Server. TM Mac OS X TM Unix TM Linux TM FreeBSD TM wait.

[0127] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0128] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0129] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0130] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0131] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, magnetic disks, or optical disks.

Claims

1. A method of securely booting a chip, the method comprising: The method comprises: performing hash check on a second boot program according to a first boot program in a read-only memory (ROM); if the hash check on the second boot program passes, performing signature check on a third boot program and an operating system (OS) program according to the second boot program; if the hash check on the second boot program does not pass, entering exception processing.

2. The method of claim 1, wherein, The second boot program comprises a main program and at least one backup program. The hash check on the second boot program comprises: performing hash check on the main program and the at least one backup program in a main-backup order until the hash check passes or until hash checks on all programs do not pass.

3. The method of claim 2, wherein, The hash check on the second boot program passes comprises that hash check on the main program passes or hash check on a target backup program in the at least one backup program passes. The hash check on the second boot program does not pass comprises that hash checks on the main program and the at least one backup program do not pass.

4. The method according to any one of claims 1 to 3, characterized in that, The second boot program is stored in a flash memory or the chip.

5. The method of claim 4, wherein, The initial storage location of the second boot program is included in the flash memory, and the flash memory is located outside the chip. Before the hash check on the second boot program, the method further comprises: loading the second boot program from the flash memory to a space inside the chip excluding the ROM.

6. The method according to any one of claims 1 to 5, characterized in that, The first boot program in the ROM is inserted into the ROM or input into the ROM through a ROM patch.

7. A secure boot apparatus of a chip, characterized by comprising: The processing unit is configured to: perform hash check on a second boot program in a flash memory or the chip according to a first boot program in a ROM; if the hash check on the second boot program passes, perform signature check on a third boot program and an operating system (OS) program according to the second boot program; if the hash check on the second boot program does not pass, enter exception processing.

8. The apparatus of claim 7, wherein, The second boot program comprises a main program and at least one backup program. The processing unit is further configured to perform hash check on the main program and the at least one backup program in a main-backup order until the hash check passes or until hash checks on all programs do not pass.

9. The apparatus of claim 7 or 8, wherein, The second boot program is stored in a flash memory or the chip.

10. The apparatus of claim 9, wherein, The initial storage location of the second boot program is included in the flash memory, and the flash memory is located outside the chip. The processing unit is further configured to load the second boot program from the flash memory to a space inside the chip excluding the ROM.

11. The apparatus of any one of claims 7 to 10, wherein, The first boot program in the ROM is inserted into the ROM or input into the ROM through a ROM patch.

12. A chip, characterized by comprising a processor and a transceiver interface, which are connected to each other by a line, the processor being configured to execute the method according to any one of claims 1 to 6.

13. A computer device, comprising: comprising a processor, which is coupled to a memory; in the memory, instructions are stored, which, when executed on the processor, cause the communication device to implement the method according to any one of claims 1 to 6.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions, which, when executed on a processor, cause the method according to any one of claims 1 to 6 to be implemented.

15. A computer program product, characterised in that, The computer program product, when executed on a computer, causes the method according to any one of claims 1 to 6 to be implemented.

Images