Secure startup verification method, device and equipment and medium

By obtaining and decrypting data from the data bus of the secure boot module during the secure booting process of the on-chip system, and executing a secondary program loader and a general boot loader in the target memory, the problem of how to efficiently perform secure boot verification is solved, and the security and reliability of system startup is achieved.

CN119987879AActive Publication Date: 2025-05-13SHANDONG YUNHAI GUOCHUANG CLOUD COMPUTING EQUIP IND INNOVATION CENT CO LTD
View PDF 8 Cites 0 Cited by

Patent Information

Application Number
CN202510198698.0
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-02-21
Publication Date
2025-05-13
Estimated Expiration
2045-02-21

AI Technical Summary

Technical Problem

During the secure startup of the system on chip, how to efficiently verify and timely position the problem to ensure the safety and reliability of system startup.

Method used

By obtaining data from the data bus of the secure startup module and writing it to the cache, decrypting and comparing, ensuring data verification during the secure startup process. The specific steps include reading the secondary program loader and general bootloader data from the target memory, decrypting and writing back to the memory, and finally executing these programs in the memory to complete a secure startup.

Benefits of technology

It realizes efficient data verification during the secure startup process, timely discovers and locates data errors, and ensures the safety and reliability of system startup.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119987879A_ABST
    Figure CN119987879A_ABST
Patent Text Reader

Abstract

The invention discloses a secure startup verification method, device and equipment and a medium, which are applied to the technical field of system startup, and comprise the following steps: acquiring first data from a data bus of a secure startup module, and writing the first data into a first data cache; the safe starting module obtains the first data and decrypts the first data in the safe starting process; the first data comprises secondary program loader program data acquired from the first target memory and universal boot loader program data acquired from the second target memory; acquiring second data from a data bus of the first target memory and a data bus of the second target memory, and writing the second data into a second data cache; the first target memory is used for storing secondary program loader program data read from a target starting medium, and the second target memory is used for storing universal boot loader data read from the target starting medium; and comparing the first data with the second data. In this way, safe starting verification can be efficiently carried out, and timely problem positioning is guaranteed.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the technical field of system startup, and in particular to a secure startup verification method, device, equipment and medium. Background Art

[0002] Prototype verification can verify the system on chip before tape-out, and during the prototype verification stage, the functions of the system on chip can be repeatedly verified to improve development efficiency and reduce costs. Among them, if there is a problem during the secure boot process of the system on chip, the system will fail to boot.

[0003] How to efficiently perform secure boot verification and ensure timely location of problems is a problem that technical personnel in this field need to solve. Summary of the invention

[0004] In view of this, the purpose of the present invention is to provide a secure boot verification method, device, equipment and medium, which can efficiently perform secure boot verification and ensure timely location of problems. The specific scheme is as follows:

[0005] In a first aspect, the present invention discloses a secure boot verification method, comprising:

[0006] Acquire first data from a data bus of a secure boot module, and write the first data into a first data cache; wherein the secure boot module acquires the first data during a secure boot process, and decrypts the first data; the first data sequentially includes secondary program loader program data acquired from a first target memory and universal boot loader program data acquired from a second target memory;

[0007] Acquire second data from data buses of the first target memory and the second target memory, and write the second data into a second data cache; wherein the first target memory is used to store secondary program loader program data read from a target boot medium, and the second target memory is used to store universal boot loader program data read from the target boot medium;

[0008] The first data and the second data are compared to perform data verification during a secure boot process.

[0009] Optionally, comparing the first data and the second data to perform data verification in a secure boot process includes:

[0010] When the depth of the first data cache reaches a preset depth condition, first data is read from the first data cache and second data is read from the second data cache;

[0011] The first data and the second data are compared. If the first data and the second data are inconsistent, an error indication message is generated. If the first data and the second data are consistent, it indicates that it is normal, so as to realize data verification in the safe startup process.

[0012] Optionally, also include:

[0013] If the data bit widths of the data buses of the first target memory, the second target memory, and the secure boot module are inconsistent, the first data or the second data whose data bit width is lower than the highest data bit width is merged before writing into the first data cache or the second data cache so that the data bit widths of the data in the first data cache and the second data cache are consistent.

[0014] Optionally, also include:

[0015] Determine a target boot medium based on the medium security boot configuration information, and read the secondary program loader program data from the target boot medium to the first target memory;

[0016] Determining whether to enable the safe boot mode based on the safety enable signal, wherein when the safety enable signal is a first preset value, it indicates that the safe boot mode is not enabled, and when the safety enable signal is a second preset value, it indicates that the safe boot mode is enabled;

[0017] When the secure boot mode is enabled, reading the secondary program loader program data from the first target memory to a secure boot module, decrypting the secondary program loader program data using the secure boot module to obtain the secondary program loader program data in plain text, and writing the secondary program loader program data in plain text back to the first target memory;

[0018] executing the secondary program loader program data plaintext in the first target memory and reading universal boot loader program data from the target boot medium to the second target memory;

[0019] Reading the universal boot loader program data from the second target memory to the secure boot module, decrypting the universal boot loader program data by using the secure boot module to obtain the universal boot loader program data in plain text, and writing the universal boot loader program data in plain text back to the second target memory;

[0020] The universal boot loader data plaintext is executed in the second target memory to complete secure booting.

[0021] Optionally, the medium security boot configuration information includes a medium configuration value, and the target boot medium is a boot medium corresponding to the current medium security boot configuration information among multiple boot media, and different boot media correspond to different medium configuration values.

[0022] Optionally, decrypting the secondary program loader program data to obtain the secondary program loader program data plaintext includes:

[0023] Determine a decryption algorithm and a key based on the register configuration information;

[0024] The secondary program loader program data is decrypted using the decryption algorithm and the key to obtain the secondary program loader program data plain text.

[0025] Optionally, also include:

[0026] The register information of each module of the system on chip is transmitted to the debugging terminal based on a preset bus debugging interface connected to the bus arbitration module, so that the debugging terminal performs secure boot verification based on the register information.

[0027] In a second aspect, the present invention discloses a secure boot verification device, comprising:

[0028] A first data acquisition module, configured to acquire first data from a data bus of the secure boot module and write the first data into a first data cache; wherein the secure boot module acquires the first data during the secure boot process and decrypts the first data; the first data sequentially includes secondary program loader program data acquired from the first target memory and universal boot loader program data acquired from the second target memory;

[0029] a second data acquisition module, configured to acquire second data from the data buses of the first target memory and the second target memory, and write the second data into a second data cache; wherein the first target memory is used to store the secondary program loader program data read from the target boot medium, and the second target memory is used to store the universal boot loader program data read from the target boot medium;

[0030] The data comparison module is used to compare the first data and the second data to perform data verification during the safe startup process.

[0031] In a third aspect, the present invention discloses an electronic device, comprising:

[0032] Memory for storing computer programs;

[0033] A processor is used to execute the computer program to implement the steps of the aforementioned secure boot verification method.

[0034] In a fourth aspect, the present invention discloses a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the aforementioned secure boot verification method are implemented.

[0035] In a fifth aspect, the present invention discloses a computer program product, including a computer program / instruction, which implements the steps of the aforementioned secure boot verification method when executed by a processor.

[0036] It can be seen from the above scheme that the present invention provides a secure boot verification method, including: obtaining first data from a data bus of a secure boot module, and writing the first data into a first data cache; wherein the secure boot module obtains the first data during the secure boot process and decrypts the first data; the first data sequentially includes secondary program loader program data obtained from a first target memory and universal boot loader program data obtained from a second target memory; obtaining second data from the data buses of the first target memory and the second target memory, and writing the second data into a second data cache; wherein the first target memory is used to store the secondary program loader program data read from a target boot medium, and the second target memory is used to store the universal boot loader program data read from the target boot medium; comparing the first data and the second data to perform data verification during the secure boot process.

[0037] It can be seen that the beneficial effects of the present invention are: in the process of secure booting, the secondary program loader program data read from the target boot medium is sequentially read to the first target memory, and the universal boot loader program data is sequentially read to the second target memory. The secure boot module sequentially obtains the secondary program loader program data from the first target memory and the universal boot loader program data from the second target memory for decryption. The data verification process is to obtain data from the data bus of the secure boot module, store it in the corresponding data cache, and obtain data vertically from the data of the first target memory and the second target memory, store it in the corresponding data cache, and compare the data in the two data caches. In this way, in the process of secure booting, data errors are discovered in time, and then the problems are analyzed, so that secure boot verification can be performed efficiently to ensure timely location of problems. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0039] Figure 1 A flow chart of a secure boot verification method provided by an embodiment of the present invention;

[0040] Figure 2 A schematic diagram of a system-on-chip structure provided by an embodiment of the present invention;

[0041] Figure 3 A safe startup flow chart provided by an embodiment of the present invention;

[0042] Figure 4 A schematic diagram of a secure boot verification provided by an embodiment of the present invention;

[0043] Figure 5 A schematic diagram of the structure of a secure boot verification device provided by an embodiment of the present invention;

[0044] Figure 6 A structural diagram of an electronic device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0045] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only 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 ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0046] The terms "including" and "having" in the specification of the present invention and the above-mentioned drawings, as well as any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device including a series of steps or units is not limited to the listed steps or units, but may include steps or units that are not listed.

[0047] In order to enable those skilled in the art to better understand the solution of the present invention, the present invention is further described in detail below in conjunction with the accompanying drawings and specific implementation methods.

[0048] First, the terms involved in the present invention are explained:

[0049] FPGA: Field-Programmable Gate Array, field programmable gate array;

[0050] BMC: Baseboard Management Controller is an embedded microcontroller, usually integrated on the server motherboard, used to monitor, manage and maintain server hardware and systems. It has its own minimum system with its own processor, memory and storage so that it can run independently of the server's main processor.

[0051] CPU: Central Processing Uint, central processing unit;

[0052] SoC: System on Chip, also known as system on chip, has a CPU processor inside the chip;

[0053] DDR: Double Date Rate, double rate storage, used as memory;

[0054] Flash: Flash memory, a non-volatile storage device that stores the firmware program of the SoC system;

[0055] SD card: Secure Digital, secure digital card;

[0056] eMMC: Embedded Multi Media Card, is a standard specification for embedded memory established by the MMC Association, mainly for products such as mobile phones or tablets. eMMC integrates a controller in the package, provides a standard interface and manages flash memory, allowing mobile phone manufacturers to focus on other parts of product development and shorten the time to market.

[0057] Hash: Generally translated as hash, hash, or transliterated as hash, it is to transform an input of any length into an output of fixed length through a hash algorithm. The output is the hash value. Commonly used hash algorithms include MD4, MD5, SHA-1, etc.

[0058] SPL: Secondary program loader, secondary program loader.

[0059] AHB bus: Advanced High-performance Bus is an advanced high-performance bus architecture and a high-speed bus standard used to connect various functional modules such as processors, memory, and peripheral devices.

[0060] FIFO: First In First Out, a first-in-first-out data buffer. The difference from ordinary memory is that there is no external read and write address line. The data address of FIFO is automatically completed by the internal read and write pointer plus 1, so it is very simple to use.

[0061] SRAM: Static Random-Access Memory, is a static random access memory consisting of 6 transistors and is used in CPU cache, embedded systems, network equipment, consumer electronics and other fields.

[0062] AXI bus: Advanced eXtensible Interface bus is an on-chip system interconnection standard for high performance, low power consumption, scalability and reliability. It is used to connect processor cores, memory controllers, peripherals and various on-chip interconnection modules.

[0063] JTAG (Joint Test Action Group) is an international standard test protocol, mainly used for internal chip testing.

[0064] Next, a secure boot verification method provided by an embodiment of the present invention is described in detail. Figure 1 A flow chart of a secure boot verification method provided by an embodiment of the present invention, the secure boot verification method comprising:

[0065] Step S11: Obtain first data from the data bus of the secure boot module and write the first data into a first data cache; wherein the secure boot module obtains the first data during the secure boot process and decrypts the first data; the first data sequentially includes the secondary program loader program data obtained from the first target memory and the universal boot loader program data obtained from the second target memory.

[0066] The secure boot module is a module for decrypting data during the secure boot process of the system on chip. The data bus of the secure boot module can be an AHB bus. During the secure boot process, the secondary program loader program data, namely the SPL program data, is first decrypted, and then the universal boot loader program data, namely the uboot program data, is decrypted. The first data cache can be a FIFO. The first target memory can be an SRAM, and the second target memory can be a DDR.

[0067] Step S12: Obtain second data from the data buses of the first target memory and the second target memory, and write the second data into a second data cache; wherein the first target memory is used to store the secondary program loader program data read from the target boot medium, and the second target memory is used to store the universal boot loader program data read from the target boot medium.

[0068] In an embodiment of the present invention, if the data bit widths of the data buses of the first target memory, the second target memory, and the secure boot module are inconsistent, the first data or the second data whose data bit width is lower than the maximum data bit width is merged before writing into the first data cache or the second data cache, so that the data bit widths of the data in the first data cache and the second data cache are consistent.

[0069] The data bus from the first target memory may be an AHB bus, and the data bus from the second target memory may be an AXI bus. The data bit width of the AHB bus is 32, and the data bit width of the AXI bus is 128. For matching, every four groups of data on the AHB bus are merged into a group of 128 data and written into the FIFO.

[0070] In an embodiment of the present invention, a secure boot process may include: determining a target boot medium based on medium secure boot configuration information, and reading secondary program loader program data from the target boot medium to a first target memory; judging whether to enable a secure boot mode based on a secure enable signal, wherein when the secure enable signal is a first preset value, it indicates that the secure boot mode is not enabled, and when the secure enable signal is a second preset value, it indicates that the secure boot mode is enabled; when the secure boot mode is enabled, reading the secondary program loader program data from the first target memory to a secure boot module, so as to use the secure boot module to decrypt the secondary program loader program data to obtain the secondary program loader program data. The method comprises the steps of: reading the plaintext of the secondary program loader program data from the target boot medium, and writing the plaintext of the secondary program loader program data back to the first target memory; executing the plaintext of the secondary program loader program data in the first target memory, and reading the universal boot loader program data from the target boot medium to the second target memory; reading the universal boot loader program data from the second target memory to the secure boot module, decrypting the universal boot loader program data by using the secure boot module to obtain the plaintext of the universal boot loader program data, and writing the plaintext of the universal boot loader program data back to the second target memory; executing the plaintext of the universal boot loader program data in the second target memory to complete the secure boot.

[0071] Among them, the media security boot configuration information includes a media configuration value, and the target boot medium is the boot medium corresponding to the current media security boot configuration information among multiple boot media, and different boot media correspond to different media configuration values. That is, the system on chip can include multiple boot media, such as FMC, uart serial port module, SD / eMMC module, etc. For example, the configuration value: 000: boot from flash, 001: boot from SD card, 010: boot from eMMC, 011: boot from serial port.

[0072] In the embodiment of the present invention, the boot program can select the boot medium as the target boot medium based on the medium security boot configuration information, and read the secondary program loader program data from the target boot medium to the first target memory.

[0073] Furthermore, the embodiment of the present invention can determine a decryption algorithm and a key based on register configuration information; use the decryption algorithm and the key to decrypt the secondary program loader program data to obtain the secondary program loader program data plain text.

[0074] Furthermore, the embodiment of the present invention can determine a decryption algorithm and a key based on the register configuration information; and use the decryption algorithm and the key to decrypt the universal boot loader program data to obtain the universal boot loader program data in plain text.

[0075] That is, the embodiment of the present invention can ensure accurate decryption of the secondary program loader program data and the universal boot loader program data by configuring the register.

[0076] In addition, the embodiment of the present invention can also determine to read data from the first target memory first and then read data from the second target memory based on the configuration of the target register. The target register can be an address selection register.

[0077] In one embodiment, different bit configurations are used in the target register to sequentially read data from the first target memory first and then from the second target memory. That is, data is read from SRAM and then from DDR. For example, a certain bit is 1 to indicate that data is read from the first target memory, another bit is 1 to indicate that data is read from the second target register, and 0 indicates that it is not enabled. A certain bit corresponds to the memory read first, and another bit corresponds to the memory read later. In another embodiment, the target register may include a first register and a second register, the first register corresponds to the memory read first, the second register corresponds to the memory read later, the preset bit in the first register is 1, indicating that reading from the first memory is enabled, the preset bit in the second register is 1, indicating that reading from the second memory is enabled, and 0 indicates that it is not enabled.

[0078] Step S13: Compare the first data and the second data to perform data verification during the secure boot process.

[0079] It should be noted that the above steps S11 to S13 do not limit the order in which the steps are executed.

[0080] In the embodiment of the present invention, when the depth of the first data cache reaches a preset depth condition, the first data is read from the first data cache and the second data is read from the second data cache; the first data and the second data are compared, and if the first data and the second data are inconsistent, an error indication message is generated, and if the first data and the second data are consistent, it indicates that it is normal, so as to implement data verification in the secure boot process. For example, the depth of the first cache is set to 32, when the depth of the first data cache reaches 24. The error indication message can be an indicator light.

[0081] Further, the embodiment of the present invention can transmit the register information of each module in the system on chip to the debug terminal based on the preset bus debug interface connected to the bus arbitration module, so that the debug terminal performs secure boot verification based on the register information. In addition, the data in the memory of the system on chip can also be transmitted to the debug terminal based on the preset bus debug interface connected to the bus arbitration module. The debug terminal can be a PC, and the debug terminal can read the register information of each module and the data in the memory at any stage in the secure boot process through the preset bus debug interface connected to the bus arbitration module, such as the ciphertext and plaintext of the secondary program loader program data, and the universal boot loader program data. By comparing the correct register value saved by the debug terminal, or comparing the ciphertext and the plaintext for verification, there is a problem if it is inconsistent. Alternatively, based on the encryption or decryption algorithm recorded in the debug terminal, the ciphertext or plaintext is decrypted or encrypted, and then compared with the plaintext or ciphertext recorded in the debug terminal for verification. By comparing whether the original ciphertext data is correct, whether the register configuration is appropriate, and whether the decrypted plaintext data is consistent, etc., it is helpful to analyze the problem layer by layer, so as to quickly locate the startup problem.

[0082] For further information, see Figure 2 As shown, Figure 2 This is a schematic diagram of a system-on-chip structure provided by an embodiment of the present invention. Other modules in the system are not drawn, and the secure boot architecture of the minimum SoC system is used to illustrate:

[0083] Among them, CPU module: SoC chip main processor, running uboot / kernel system; FMC: flash controller, external flash chip storage firmware image file, can be unencrypted plaintext data or encrypted ciphertext data, one of the boot media; bus arbitration module: responsible for arbitration of buses of different types, different bit widths, and different clock domains, connecting the buses of all modules in the SoC system, including register configuration bus and data transmission bus, such as AXI bus, AHB bus, APB bus, etc.; DDR memory: memory in SoC chip, used for system startup and data cache during system operation; SRAM: on-chip storage in SoC chip, used for system startup and data cache Storage; WDT module: the watchdog module in the SoC chip to prevent the system from locking; UART serial port module: the serial port module in the SoC chip, used for serial port input and output, information debugging and display, etc., and is also one of the boot media; M33: a small-core processor used to process modules with slow transmission rates in the SoC system, used as multi-media and secure boot; ROM: a read-only module used to store the boot program; SD / eMMC module: an SD / eMMC controller, an external SD / eMMC chip, used as a SoC system hard disk, and can also store firmware image files, which can be unencrypted plaintext data or encrypted ciphertext data, one of the boot media; secure boot module: responsible for data encryption and decryption during secure boot.

[0084] In an embodiment of the present invention, the multi-media secure boot configuration may include: sec_op[1:0]: secure boot enable signal, when it is 00, secure boot is not enabled, and when it is 01, secure boot mode is enabled; boot_mode[2:0]: multi-media selection signal, 000: boot from flash; 001: boot from SD card; 010: boot from eMMC; 011: boot from serial port.

[0085] For further information, see Figure 3 As shown, Figure 3A secure boot flow chart provided for an embodiment of the present invention. The M33 small core processor is started, the boot program in the ROM starts running, the boot medium is selected according to boot_mode, the SPL program is read from the boot medium to the SRAM, in the case of secure boot, data is read from the SRAM to the secure boot module according to the configuration, decrypted according to the register configuration, written back to the SRAM after decryption, the SPL program is executed, data is read from the DDR to the secure boot module according to the configuration, decrypted according to the register configuration, written back to the DDR after decryption, the uboot program is executed, and the system starts. In the case of unsecure boot, the SPL program is executed, and the uboot program is read to the DDR, the uboot program is executed, the system starts, and both the SPL program and the uboot program are plain text. The configuration determines whether to read data from the SRAM or from the DDR according to the configuration. The configuration refers to the settings in the register, for example, in the address selection register [31:0], Bit0: Encryption and decryption module bus address read and write DDR enable: 1 enables, 0 disables; Bit1: Hash module bus address read and write DDR enable: 1 enables, 0 does not enable; Bit2~31: Reserved. Hash is a security-related algorithm used in SoC, so the Hash module is involved. Register configuration: including encryption and decryption mode, algorithm, key, etc. Encryption and decryption mode refers to encryption or decryption. The role of the bootloader is to guide the execution of SPL, and after SPL is executed, the uboot program is executed.

[0086] It can be seen from the above startup process that there will be two encrypted data to the secure boot module, the first is read from SRAM, and the second is read from DDR. Determine where to read according to the configuration. In the embodiment of the present invention, a data verification module can be added, which obtains data from the secure boot module data bus AHB Master and writes it into the data cache FIFO_0 (i.e., the first data cache). The data is the original encrypted data written into the secure boot module. The module also obtains data from the SRAM data bus AHBMaster and the DDR module AXI bus and writes it into the data cache FIFO_1 (i.e., the second data cache) to compare whether the two data are consistent. According to the startup process, there is a sequence from SRAM and DDR, so a FIFO can be shared. The data bit width of the AHB bus is 32, and the data bit width of the AXI bus is 128. In order to match, every four groups of data on the AHB bus are merged into a group of 128 data and written into the FIFO. The depth of FIFO is set to 32. When the depth of FIFO_0 reaches 24, the data in FIFO_0 and FIFO_1 are read and XORed. If the result is 0, it means that the data written to the secure boot module is consistent with the data source. If the result is 1, it means that the data is wrong and the LED on the hardware circuit board is lit as an indicator. According to this information, it is possible that the source module read is wrong. For example, according to the process, the first read is from SRAM and the second read is from DDR. If the configuration is incorrect, the second read may be from SRAM. At this time, the data in the two FIFOs is different.

[0087] Also, see Figure 4 As shown, Figure 4 A schematic diagram of secure boot verification provided by an embodiment of the present invention, wherein the embodiment of the present invention further adds a bus debugging interface IP connected to a bus arbitration module, and supports the user side to read the registers of each module and the data in the memory after decryption, encrypted data, etc. When reading, it is read through a script file on the test PC side. Through this operation, any register of the module can be read, and only the address of the register is required. Through this operation, the data in the memory can also be read into a file, such as reading the decrypted data and comparing it with the original unencrypted firmware image file. By reading the registers and comparing the files, analysis is performed to locate the problem, such as whether the key is correct, whether the decryption algorithm is consistent with the encryption algorithm, etc. A prototype verification method for debugging secure boot provided by the present invention can be progressive layer by layer by comparing whether the original ciphertext data is correct, whether the register configuration is appropriate, and whether the decrypted plaintext data is consistent, etc., which is helpful for problem analysis, thereby quickly locating the startup problem.

[0088] The solution provided by the embodiment of the present invention can avoid the problem that when using serial port debugging, the operation commands are different from those under the uboot / kernel system, and the operation needs to be performed according to the instructions specified by the serial port debugging module, the command help function is not supported, and the operation is inconvenient. In addition, it can avoid the problem that human errors in operation commands will not be reported, but there will be no response, which increases the complexity of troubleshooting. It can obtain registers or data in each state, avoiding the problem that the operation can only obtain registers or data in the current state, and the data before the state cannot be obtained. It can locate the problem intuitively and quickly, without the need for system simulation and other assistance in positioning, and the debugging time is reduced.

[0089] The embodiment of the present invention adopts FPGA prototype verification, uses the FPGA prototype verification platform, and transplants the corresponding RTL code into the FPGA for functional verification. FPGA verification can reduce costs, and can be repeatedly verified many times during the prototype verification stage. FPGA prototype verification can accelerate the simulation speed and realize the collaborative development verification of software and hardware before chip tape-out. The system startup of the SoC chip is the first door to the application, and the security, reliability and stability of the system startup must be guaranteed. Some SoC chips support multi-media secure startup, such as management controllers. The secure startup is implemented using an encryption and decryption module. The encryption and decryption algorithms in the encryption and decryption module support multiple types, such as Hash, ECCRSA, national encryption and decryption algorithms, etc. Therefore, for the prototype verification of multi-media secure startup, the number and types of test cases are very large, and the embodiment of the present invention can efficiently complete the verification and quickly troubleshoot and locate problems that occur during verification.

[0090] Among them, the management controller is a SoC chip, which is used for management and control. It is used in the server system to monitor and control the system hardware. The security of the management controller is very important. If it is attacked by the outside world, it will cause the management controller to work abnormally, and even cause the entire server system to fail to operate normally. Therefore, the security and reliability of the chip is one of the important indicators. In the prototype verification stage, it is necessary to undergo sufficient and complete hardware and software collaborative verification. Therefore, the prototype verification of the secure startup of the management controller is very important. The embodiment of the present invention can verify the management controller. The management controller can be a BMC (i.e., Baseboard Management Controller), an Integrated Light-Out (iLO) system, an Integrated Dell Remote Access Control (IDRAC), or one of the processing chips.

[0091] The present invention provides a solution for quickly locating security boot problems, which solves the problem of quickly troubleshooting and locating abnormal startup during the security boot process of a SoC chip, and can be extended to debugging for quickly locating problems in other FPGA prototype verifications.

[0092] See also Figure 5 As shown, an embodiment of the present invention provides a secure boot verification device, including:

[0093] A first data acquisition module 51 is used to acquire first data from a data bus of the secure boot module and write the first data into a first data cache; wherein the secure boot module acquires the first data during the secure boot process and decrypts the first data; the first data sequentially includes secondary program loader program data acquired from the first target memory and universal boot loader program data acquired from the second target memory;

[0094] A second data acquisition module 52, configured to acquire second data from the data buses of the first target memory and the second target memory, and write the second data into a second data cache; wherein the first target memory is used to store the secondary program loader program data read from the target boot medium, and the second target memory is used to store the universal boot loader program data read from the target boot medium;

[0095] The data comparison module 53 is used to compare the first data and the second data to perform data verification during the safe startup process.

[0096] Among them, the data comparison module 53 is specifically used to read the first data from the first data cache and the second data from the second data cache when the depth of the first data cache reaches a preset depth condition; compare the first data and the second data, if the first data and the second data are inconsistent, generate an error indication information, if the first data and the second data are consistent, it indicates normal, so as to realize data verification in the safe startup process.

[0097] The device is also used for:

[0098] If the data bit widths of the data buses of the first target memory, the second target memory, and the secure boot module are inconsistent, the first data or the second data whose data bit width is lower than the highest data bit width is merged before writing into the first data cache or the second data cache so that the data bit widths of the data in the first data cache and the second data cache are consistent.

[0099] The secure boot process may include:

[0100] Determine a target boot medium based on the medium security boot configuration information, and read the secondary program loader program data from the target boot medium to the first target memory;

[0101] Determining whether to enable the safe boot mode based on the safety enable signal, wherein when the safety enable signal is a first preset value, it indicates that the safe boot mode is not enabled, and when the safety enable signal is a second preset value, it indicates that the safe boot mode is enabled;

[0102] When the secure boot mode is enabled, reading the secondary program loader program data from the first target memory to a secure boot module, decrypting the secondary program loader program data using the secure boot module to obtain the secondary program loader program data in plain text, and writing the secondary program loader program data in plain text back to the first target memory;

[0103] executing the secondary program loader program data plaintext in the first target memory and reading universal boot loader program data from the target boot medium to the second target memory;

[0104] Reading the universal boot loader program data from the second target memory to the secure boot module, decrypting the universal boot loader program data by using the secure boot module to obtain the universal boot loader program data in plain text, and writing the universal boot loader program data in plain text back to the second target memory;

[0105] The universal boot loader data plaintext is executed in the second target memory to complete secure booting.

[0106] The medium security boot configuration information includes a medium configuration value, and the target boot medium is a boot medium corresponding to the current medium security boot configuration information among multiple boot media, and different boot media correspond to different medium configuration values.

[0107] The secure boot module can be used to: determine a decryption algorithm and a key based on register configuration information; and use the decryption algorithm and the key to decrypt the secondary program loader program data to obtain the secondary program loader program data in plain text.

[0108] The device is also used for:

[0109] The register information of each module of the system on chip is transmitted to the debugging terminal based on a preset bus debugging interface connected to the bus arbitration module, so that the debugging terminal performs secure boot verification based on the register information.

[0110] It can be seen that in the secure boot process of the embodiment of the present invention, the secondary program loader program data read from the target boot medium is sequentially read to the first target memory, and the universal boot loader program data is sequentially read to the second target memory. The secure boot module sequentially obtains the secondary program loader program data from the first target memory and the universal boot loader program data from the second target memory for decryption. The data verification process is to obtain data from the data bus of the secure boot module, store it in the corresponding data cache, and obtain data from the data of the first target memory and the second target memory vertically, store it in the corresponding data cache, and compare the data in the two data caches. In this way, in the secure boot process, data errors are discovered in time, and then the problems are analyzed, so that secure boot verification can be performed efficiently to ensure timely location of problems.

[0111] Figure 5 The description of the features in the corresponding embodiments can be found in Figure 1 The relevant descriptions of the corresponding embodiments will not be repeated here one by one.

[0112] Figure 6 A structural diagram of an electronic device provided by an embodiment of the present invention, such as Figure 6 As shown, the electronic device includes: a memory 60 for storing a computer program;

[0113] The processor 61 is used to implement the steps of the secure boot verification method of the above embodiment when executing a computer program.

[0114] Among them, the processor 61 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 61 can be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), and programmable logic array (PLA). The processor 61 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a central processing unit (CPU); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 61 may be integrated with a graphics processing unit (GPU), and the GPU is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 61 may also include an artificial intelligence (AI) processor, which is used to process computing operations related to machine learning.

[0115] The memory 60 may include one or more computer-readable storage media, which may be non-transitory. The memory 60 may also include a high-speed random access memory, and a non-volatile memory, such as one or more disk storage devices, flash memory storage devices. In this embodiment, the memory 60 is at least used to store the following computer program 601, wherein the computer program, after being loaded and executed by the processor 61, can implement the relevant steps of the secure boot verification method disclosed in any of the aforementioned embodiments. In addition, the resources stored in the memory 60 may also include an operating system 602 and data 603, etc., and the storage method may be temporary storage or permanent storage. Among them, the operating system 602 may include Windows, Unix, Linux, etc. Data 603 may include, but is not limited to, program data, etc.

[0116] In some embodiments, the electronic device may further include a display screen 62 , an input / output interface 63 , a communication interface 64 , a power supply 65 , and a communication bus 66 .

[0117] Those skilled in the art will understand that Figure 6 The structure shown in the figure does not constitute a limitation on the electronic device, and may include more or fewer components than shown in the figure.

[0118] It is understandable that if the secure boot verification method in the above embodiment is implemented in the form of 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 the present invention is essentially or part of the contribution to the current technology or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium to execute all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), electrically erasable programmable ROM, register, hard disk, removable disk, CD-ROM, magnetic disk or optical disk and other media that can store program code.

[0119] Based on this, an embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above-mentioned secure boot verification method are implemented.

[0120] A computer program product provided by an embodiment of the present invention is introduced below. The computer program product described below can be referenced to other embodiments described in this document.

[0121] A computer program product includes a computer program / instruction, which implements the steps of the aforementioned disclosed secure boot verification method when executed by a processor.

[0122] The above is a detailed introduction to a secure boot verification method, device, equipment and medium provided by an embodiment of the present invention. The various embodiments in the specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same and similar parts between the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description.

[0123] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0124] The above is a detailed introduction to a secure boot verification method, device, equipment and medium provided by the present invention. This article uses specific examples to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present invention, the present invention can also be improved and modified, and these improvements and modifications also fall within the scope of protection of the claims of the present invention.

Claims

1. A secure boot verification method, characterized in that: include: Acquire first data from a data bus of a secure boot module, and write the first data into a first data cache; wherein the secure boot module acquires the first data during a secure boot process, and decrypts the first data; the first data sequentially includes secondary program loader program data acquired from a first target memory and universal boot loader program data acquired from a second target memory; Acquire second data from data buses of the first target memory and the second target memory, and write the second data into a second data cache; wherein the first target memory is used to store secondary program loader program data read from a target boot medium, and the second target memory is used to store universal boot loader program data read from the target boot medium; The first data and the second data are compared to perform data verification during a secure boot process.

2. The secure boot verification method according to claim 1, characterized in that: The comparing the first data and the second data to perform data verification in a secure boot process includes: When the depth of the first data cache reaches a preset depth condition, first data is read from the first data cache and second data is read from the second data cache; The first data and the second data are compared. If the first data and the second data are inconsistent, an error indication message is generated. If the first data and the second data are consistent, it indicates that it is normal, so as to realize data verification in the safe startup process.

3. The secure boot verification method according to claim 1, characterized in that: Also includes: If the data bit widths of the data buses of the first target memory, the second target memory, and the secure boot module are inconsistent, the first data or the second data whose data bit width is lower than the highest data bit width is merged before writing into the first data cache or the second data cache so that the data bit widths of the data in the first data cache and the second data cache are consistent.

4. The secure boot verification method according to claim 1, characterized in that: Also includes: Determine a target boot medium based on the medium security boot configuration information, and read the secondary program loader program data from the target boot medium to the first target memory; Determining whether to enable the safe boot mode based on the safety enable signal, wherein when the safety enable signal is a first preset value, it indicates that the safe boot mode is not enabled, and when the safety enable signal is a second preset value, it indicates that the safe boot mode is enabled; When the secure boot mode is enabled, reading the secondary program loader program data from the first target memory to a secure boot module, decrypting the secondary program loader program data using the secure boot module to obtain the secondary program loader program data in plain text, and writing the secondary program loader program data in plain text back to the first target memory; executing the secondary program loader program data plaintext in the first target memory and reading universal boot loader program data from the target boot medium to the second target memory; Reading the universal boot loader program data from the second target memory to the secure boot module, decrypting the universal boot loader program data by using the secure boot module to obtain the universal boot loader program data in plain text, and writing the universal boot loader program data in plain text back to the second target memory; The universal boot loader data plaintext is executed in the second target memory to complete secure booting.

5. The secure boot verification method according to claim 4, characterized in that: The medium security boot configuration information includes a medium configuration value. The target boot medium is a boot medium corresponding to the current medium security boot configuration information among multiple boot media. Different boot media correspond to different medium configuration values.

6. The secure boot verification method according to claim 4, characterized in that: Decrypting the secondary program loader program data to obtain the secondary program loader program data plaintext includes: Determine a decryption algorithm and a key based on the register configuration information; The secondary program loader program data is decrypted using the decryption algorithm and the key to obtain the secondary program loader program data plain text.

7. The secure boot verification method according to claim 4, characterized in that: Also includes: The register information of each module of the system on chip is transmitted to the debugging terminal based on a preset bus debugging interface connected to the bus arbitration module, so that the debugging terminal performs secure boot verification based on the register information.

8. A secure boot verification device, characterized in that: include: A first data acquisition module, configured to acquire first data from a data bus of the secure boot module and write the first data into a first data cache; wherein the secure boot module acquires the first data during the secure boot process and decrypts the first data; the first data sequentially includes secondary program loader program data acquired from the first target memory and universal boot loader program data acquired from the second target memory; a second data acquisition module, configured to acquire second data from the data buses of the first target memory and the second target memory, and write the second data into a second data cache; wherein the first target memory is used to store the secondary program loader program data read from the target boot medium, and the second target memory is used to store the universal boot loader program data read from the target boot medium; The data comparison module is used to compare the first data and the second data to perform data verification during the safe startup process.

9. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to execute the computer program to implement the steps of the secure boot verification method as claimed in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the secure boot verification method according to any one of claims 1 to 7 are implemented.

Citation Information

Patent Citations

  • Signature verification method and system for file data content

    CN113868704A

  • Chip working method, system, equipment and medium

    CN114491556A

  • Safe starting method and device and related device

    CN116226872A

  • Method and device for safely starting bootstrap program for intelligent electric terminal

    CN116339852A

  • Controller trusted starting method and controller

    CN117170763A