A secure boot verification method, apparatus, device and medium

Abstract

The application discloses a secure boot verification method and device, equipment and medium, applied to the technical field of system boot, comprising: obtaining first data from the data bus of the secure boot module and writing into the first data cache; the secure boot module obtains the first data and decrypts in the secure boot process; the first data comprises secondary program loader program data obtained from the first target memory and universal boot loader data obtained from the second target memory; obtaining second data from the data bus of the first target memory and the second target memory and writing into the second data cache; the first target memory is used for storing secondary program loader program data read from the target boot medium, and the second target memory is used for storing universal boot loader data read from the target boot medium; comparing the first data and the second data. In this way, the secure boot verification can be efficiently performed, and the problem can be located in time.

Description

TECHNICAL FIELD

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

[0002] Prototype verification can verify the system on chip before tape-out, and in the prototype verification stage, the function of the system on chip can be repeatedly verified many times to improve development efficiency and reduce cost. If there is a problem in the process of secure startup of the system on chip, it will cause the system startup to fail.

[0003] How to efficiently perform secure startup verification and ensure timely problem positioning is a problem to be solved by those skilled in the art. SUMMARY

[0004] Therefore, the purpose of the present application is to provide a secure startup verification method, device, equipment and medium, which can efficiently perform secure startup verification and ensure timely problem positioning. The specific scheme is as follows:

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

[0006] obtaining first data from the data bus of a secure startup module and writing the first data into a first data cache; wherein the secure startup module obtains the first data in the secure startup process and decrypts the first data; the first data includes, in turn, secondary program loader program data obtained from a first target memory and universal bootloader data obtained from a second target memory;

[0007] obtaining second data from the data bus 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 secondary program loader program data read from a target startup medium, and the second target memory is used to store universal bootloader data read from the target startup medium;

[0008] comparing the first data and the second data to perform data verification in the secure startup process.

[0009] Optionally, the comparison of the first data and the second data to perform data verification in the secure startup process comprises:

[0010] when the depth of the first data cache reaches a preset depth condition, reading the first data from the first data cache and the second data from the second data cache;

[0011] Comparing the first data and the second data, if the first data and the second data are inconsistent, generating error indication information, if the first data and the second data are consistent, indicating normal, to realize data checking in the secure boot process.

[0012] Optionally, further comprising:

[0013] If the data bus data width of the first target memory, the second target memory and the secure boot module is inconsistent, before writing the first data cache or the second data cache, merging the first data or the second data with lower data width than the highest data width, so that the data width of the data in the first data cache and the second data cache is consistent.

[0014] Optionally, further comprising:

[0015] Determining a target boot medium based on the medium secure boot configuration information, and reading the secondary program loader program data from the target boot medium to the first target memory;

[0016] Judging whether to enable the secure boot mode based on a secure enable signal, wherein when the secure enable signal is a first preset value, it represents that the secure boot mode is not enabled, and when the secure enable signal is a second preset value, it represents that the secure boot mode is enabled;

[0017] In the case of enabling the secure boot mode, reading the secondary program loader program data from the first target memory to the secure boot module, to decrypt the secondary program loader program data by using the secure boot module, to obtain the secondary program loader program data plaintext, and writing the secondary program loader program data plaintext back to the first target memory;

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

[0019] Reading the universal boot loader data from the second target memory to the secure boot module, to decrypt the universal boot loader data by using the secure boot module, to obtain the universal boot loader data plaintext, and writing the universal boot loader data plaintext back to the second target memory;

[0020] Executing the universal boot loader data plaintext in the second target memory, to complete the secure boot.

[0021] Optionally, the media secure boot configuration information comprises a media configuration value, the target booting media is a booting media corresponding to the current media secure boot configuration information in a plurality of booting media, and different booting media correspond to different media configuration values.

[0022] Optionally, the secondary program loader program data is decrypted to obtain secondary program loader program data plaintext, and the method comprises:

[0023] The decryption algorithm and the key are determined based on the register configuration information.

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

[0025] Optionally, the method further comprises:

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

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

[0028] A first data acquisition module is configured to 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 in a secure boot process and decrypts the first data, and the first data comprises secondary program loader program data acquired from a first target memory and general boot loader program data acquired from a second target memory in sequence.

[0029] A second data acquisition module is configured to 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 configured to store secondary program loader program data read from a target booting media, and the second target memory is configured to store general boot loader program data read from the target booting media.

[0030] A data comparison module is configured to compare the first data and the second data to perform data checking in a secure boot process.

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

[0032] A memory is configured to store a computer program.

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

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

[0035] In a fifth aspect, the present application discloses a computer program product, comprising computer programs / instructions, which, when executed by a processor, implement the steps of the aforementioned secure boot verification method.

[0036] According to the above scheme, the present application provides a secure boot verification method, comprising: 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 in a secure boot process and decrypts the first data; the first data comprises, in sequence, secondary program loader program data obtained from a first target memory and general boot loader program data obtained from a second target memory; obtaining second data from 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 secondary program loader program data read from a target boot medium, and the second target memory is used to store general boot loader program data read from the target boot medium; and comparing the first data and the second data to perform data verification in the secure boot process.

[0037] It can be seen that, in the secure boot process, the secondary program loader program data read from the target boot medium is sequentially stored into the first target memory, and the general boot loader program data is sequentially stored into the second target memory; the secure boot module sequentially obtains the secondary program loader program data from the first target memory and the general boot loader program data from the second target memory for decryption; the data verification process comprises obtaining data from the data bus of the secure boot module, storing the data into the corresponding data cache, obtaining data from the data buses of the first target memory and the second target memory, storing the data into the corresponding data cache, and comparing the data in the two data caches. In this way, in the secure boot process, data errors can be found in time, and problems can be analyzed, so that the secure boot verification can be efficiently performed, and problems can be located in time. BRIEF DESCRIPTION OF DRAWINGS

[0038] In order to more clearly illustrate the embodiments of the present application, the drawings needed in the embodiments will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative effort.

[0039] Figure 1 A security start verification method flow chart provided for the embodiment of the present application;

[0040] Figure 2 A system on chip structure schematic diagram provided for the embodiment of the present application;

[0041] Figure 3 A security start flow chart provided for the embodiment of the present application;

[0042] Figure 4 A security start verification schematic diagram provided for the embodiment of the present application;

[0043] Figure 5 A security start verification device structure schematic diagram provided for the embodiment of the present application;

[0044] Figure 6 An electronic device structure diagram provided for the embodiment of the present application. DETAILED DESCRIPTION

[0045] The technical solutions in the embodiments of the present application will be described clearly and completely below with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all the other embodiments obtained by those skilled in the art without creative work fall within the protection scope of the present application.

[0046] The terms “include” and “have” in the specification and the above-mentioned drawings of the present application, as well as any variants of “include” and “have”, are intended to cover the inclusions without the exclusions. 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 can include steps or units not listed.

[0047] In order to make the person in the technical field better understand the present application scheme, the present application will be further described in detail below with the accompanying drawings and specific embodiments.

[0048] Firstly, the terms involved in the present application 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 the server hardware and system, with its own minimum system, with its own processor, memory and storage, so as to run independently of the server's main processor.

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

[0052] SoC: System on Chip, system-level chip, also known as system on chip, with CPU processor inside the chip;

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

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

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

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

[0057] Hash: generally translated as hash, hash, or transliteration as hash, is to convert any length of input into fixed length output through hash algorithm, the output is hash value. Common Hash algorithms include MD4, MD5, SHA-1, etc.

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

[0059] AHB bus: Advanced High-performance Bus bus is an advanced high-performance bus architecture, a high-speed bus standard, used to connect processors, memories, peripherals and other functional modules.

[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-write address line. The data address of FIFO is automatically incremented by 1 by internal read-write pointers, so it is very simple to use.

[0061] SRAM: Static Random-Access Memory, a kind of static random access memory, which is composed of 6 transistors, is used in CPU cache, embedded systems, network devices and consumer electronics, etc.

[0062] AXI bus: Advanced eXtensible Interface bus is a kind of on-chip system interconnection standard for high performance, low power consumption, scalability and reliability. It is used to connect processor core, memory controller, peripheral and various interconnection modules on chip.

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

[0064] Next, a kind of security start verification method provided by the embodiment of the application is introduced in detail. Figure 1 The flow chart of the security start verification method provided by the embodiment of the application, the security start verification method comprises:

[0065] Step S11: obtain first data from the data bus of the security start module, and write the first data into the first data cache;Wherein, the security start module obtains the first data in the security start process, and decrypts the first data;The first data includes the secondary program loader program data obtained from the first target memory and the universal boot loader data obtained from the second target memory in turn.

[0066] Among them, the security start module is the module for decrypting data in the security start process of the system on chip, and the data bus of the security start module can be AHB bus, in the security start process, the secondary program loader program data, SPL program data, is decrypted first, and then the universal boot loader data, uboot program data, is decrypted. The first data cache can be FIFO. The first target memory can be SRAM, and the second target memory can be DDR.

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

[0068] In the embodiment of the present application, if the data bus of the first target memory, the data bus of the second target memory and the data bus of the security starting module are inconsistent in data bit width, the first data or the second data with a lower data bit width than the highest data bit width is merged before being written into the first data cache or the second data cache, so that the data bit width of the data in the first data cache and the second data cache is consistent.

[0069] The data bus of the first target memory can be an AHB bus, and the data bus of the second target memory can 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. In order to match, the data on the AHB bus is merged into a group of 128 data every four groups of data and written into the FIFO.

[0070] In the embodiment of the present application, the security starting process can include: determining a target starting medium based on the medium security starting configuration information, and reading the secondary program loader program data from the target starting medium to the first target memory; judging whether to enable the security starting mode based on a security enabling signal, wherein when the security enabling signal is a first preset value, it represents that the security starting mode is not enabled, and when the security enabling signal is a second preset value, it represents that the security starting mode is enabled; in the case of enabling the security starting mode, reading the secondary program loader program data from the first target memory to the security starting module, so as to decrypt the secondary program loader program data by using the security starting module to obtain the secondary program loader program data in plaintext, and writing the secondary program loader program data in plaintext back to the first target memory; executing the secondary program loader program data in plaintext in the first target memory, and reading the universal boot loader program data from the target starting medium to the second target memory; reading the universal boot loader program data from the second target memory to the security starting module, so as to decrypt the universal boot loader program data by using the security starting module to obtain the universal boot loader program data in plaintext, and writing the universal boot loader program data in plaintext back to the second target memory; executing the universal boot loader program data in plaintext in the second target memory to complete the security starting.

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

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

[0073] Further, the decryption algorithm and the key are determined based on the register configuration information, and the secondary program loader program data is decrypted using the decryption algorithm and the key to obtain the secondary program loader program data in plaintext.

[0074] Further, the decryption algorithm and the key are determined based on the register configuration information, and the secondary program loader program data is decrypted using the decryption algorithm and the key to obtain the secondary program loader program data in plaintext.

[0075] That is, the secondary program loader program data and the general boot loader program data are decrypted accurately by configuring the register.

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

[0077] In an embodiment, the data is read from the first target memory first and then from the second target memory by configuring different bits in the target register. That is, the data is read from the SRAM first and then from the DDR. For example, one bit is 1 to indicate that the data is read from the first target memory, and another bit is 1 to indicate that the data is read from the second target register, and 0 indicates that it is not enabled. One bit corresponds to the first read memory, and the other bit corresponds to the second read memory. In another embodiment, the target register can include a first register and a second register, the first register corresponds to the first read memory, and the second register corresponds to the second read memory. The preset bit in the first register is 1 to indicate that the data is read from the first memory, and the preset bit in the second register is 1 to indicate that the data is read from the second memory, and 0 indicates that it is not enabled.

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

[0079] It should be noted that the above steps S11 to S13 do not limit the execution order of the steps.

[0080] The embodiment of the present application can read first data from the first data cache and read second data from the second data cache when the depth of the first data cache reaches the preset depth condition; compare the first data and the second data, and if the first data and the second data are inconsistent, generate error indication information, and if the first data and the second data are consistent, indicate normal, so as to realize data checking in the secure boot process. For example, the depth of the first cache is set to 32, and when the depth of the first data cache reaches 24. The error indication information can be a lighted indicator.

[0081] Further, the embodiment of the present application can transmit register information of each module in the system on chip to a debugging terminal based on the preset bus debugging interface connected with the bus arbitration module, so that the debugging terminal performs secure boot verification based on the register information. In addition, data in the memory in the system on chip can also be transmitted to the debugging terminal based on the preset bus debugging interface connected with the bus arbitration module. The debugging terminal can be a PC, and the debugging terminal can read the register information of each module and the data in the memory, such as the ciphertext and plaintext of the secondary program loader program data and the general boot loader data, at any stage in the secure boot process through the preset bus debugging interface connected with the bus arbitration module. Verification is performed by comparing the correct register value saved by the debugging terminal, or comparing the ciphertext and plaintext. If they are inconsistent, there is a problem. Alternatively, based on the encryption or decryption algorithm recorded by the debugging terminal, the ciphertext or plaintext is decrypted or encrypted, and then compared with the plaintext or ciphertext recorded by the debugging terminal to check. By comparing whether the original ciphertext data is correct, whether the register configuration is appropriate, and whether the decrypted plaintext data is consistent, and other ways, the problem can be analyzed layer by layer, so as to quickly locate the boot problem.

[0082] Further, referring to Figure 2 shown, Figure 2 is a system on chip structure schematic diagram provided by the embodiment of the present application. 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, the CPU module: SoC chip main processor, running uboot / kernel system; FMC: flash controller, external flash chip storage firmware image file, which can be unencrypted plaintext data, or encrypted ciphertext data, one of the boot media; bus arbitration module: responsible for the 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 the SoC chip, used for system startup and data caching during system running; SRAM: on-chip storage in the SoC chip, used for system startup and data caching; WDT module: watchdog module in the SoC chip, preventing system lock; uart serial port module: serial port module in the SoC chip, used for serial input and output, information debugging and display, etc., and also one of the boot media; M33: small core processor, used for processing modules with slow transmission rate in the SoC system, used as multi-media and secure boot; ROM: read-only module, used for storing boot program; SD / eMMC module: SD / eMMC controller, external SD / eMMC chip, used as the hard disk of the SoC system, 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 processing during secure boot.

[0084] In the embodiment of the application, the multi-media secure boot configuration can include: sec_op[1:0]: secure boot enable signal, 00 for disabling secure boot, and 01 for enabling secure boot mode; boot_mode[2:0]: multi-media selection signal, 000: starting from flash; 001: starting from SD card; 010: starting from eMMC; 011: starting from serial port.

[0085] Further, referring to Figure 3 , it can be seen that Figure 3A safe starting flow chart is provided for the embodiment of the present application. The M33 small core processor starts, the starting guide program in the ROM starts to run, the starting medium is selected according to the boot_mode, the SPL program is read from the starting medium to the SRAM, in the case of safe starting, the data is read from the SRAM to the safe starting module according to the configuration, the decryption is performed according to the register configuration, the decryption is written back to the SRAM, the SPL program is executed, the data is read from the DDR to the safe starting module according to the configuration, the decryption is performed according to the register configuration, the decryption is written back to the DDR, the uboot program is executed, and the system starts. In the case of unsafe starting, the SPL program is executed, the uboot program is read to the DDR, the uboot program is executed, the system starts, and the SPL program and the uboot program are both plaintexts. The configuration for determining whether the data is read from the SRAM or the DDR refers to the setting in the register, for example, in the address selection register [31:0], Bit0: the encryption and decryption module bus address read and write DDR enable: 1 enables, 0 does not enable; Bit1: the Hash module bus address read and write DDR enable: 1 enables, 0 does not enable; Bit2~31: reserved. Hash is an algorithm used in the SoC related to safety, therefore, the Hash module is involved. The register configuration: including encryption and decryption mode, algorithm, key, etc., the encryption and decryption mode refers to encryption or decryption. The function of the starting guide program is to guide the execution of the SPL, the SPL executes to guide the execution of the uboot program.

[0086] From the foregoing start-up procedure, there are two times of encrypted data to the secure start module, the first time is read from SRAM, and the second time is read from DDR. According to the configuration, it is determined from where to read. The embodiment of the present application can increase a data check module, which obtains data from the secure start module data bus AHB Master and writes the data into a data cache FIFO_0 (i.e. the first data cache), the data being the original encrypted data written into the secure start module, and the module also obtains data from the SRAM data bus AHB Master and the DDR module AXI bus respectively and writes the data into a data cache FIFO_1 (i.e. the second data cache), and compares whether the two data are consistent. According to the start-up procedure, there is a sequence from SRAM and DDR, thus, a piece of 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 do matching, the data on the AHB bus is merged into a group of 128 data every four groups of data and written into the FIFO. The depth of the FIFO is set to 32, when the depth of the FIFO_0 reaches 24, the data in the FIFO_0 and the FIFO_1 is read, and the data is XORed, if the result is 0, it indicates that the data written into the secure start module and the data source are consistent, if the result is 1, it indicates that the data is wrong, and the LED lamp on the hardware circuit board is lit as an indicator lamp. According to this information, it is analyzed and judged that it is possible that the source module read is wrong. For example, according to the procedure, the first time is read from SRAM, and the second time is read from DDR. If the configuration is incorrect, then the second time of reading can be from SRAM, at this time, the data in the two FIFOs is not the same.

[0087] In addition, referring to Figure 4 as shown, Figure 4 A secure start verification schematic diagram provided by the embodiment of the present application, the embodiment of the present application also increases a bus debugging interface IP connected to the bus arbitration module, supports the user side to read the data in the registers and the decrypted memory, and the encrypted data. When reading, the script file is read on the test PC side. Through this operation, any register of the module can be read, only the address of the register is needed. Through this operation, the data in the memory can also be read into the file, such as reading the decrypted data and comparing the original unencrypted firmware image file. By reading the registers and comparing the files, the problem is analyzed and located, such as whether the key is correct, whether the decryption algorithm is consistent with the encryption algorithm, etc. The debugging secure start prototype verification method provided by the present application can compare whether the original ciphertext data is correct, whether the register configuration is appropriate, and whether the decrypted plaintext data is consistent, etc. in a layer-by-layer progressive manner, which is helpful for problem analysis, so as to quickly locate the start-up problem.

[0088] The scheme provided by the embodiment of the application can avoid the problem that when serial port debugging is used, the operation command under the uboot / kernel system is not the same as the command specified by the serial port debugging module, the command help function is not supported, and the operation is inconvenient. In addition, the problem that the operation command is artificially wrong, no error is reported, and the problem checking complexity is increased is avoided. The registers or data in each state can be obtained, the problem that the operation can only obtain the registers or data in the current state and the data before the state cannot be obtained is avoided. The problem can be directly and quickly located without system simulation and other assisted positioning, and the debugging time is reduced.

[0089] The embodiment of the application adopts FPGA prototype verification, uses an FPGA prototype verification platform, and transplants corresponding RTL code into an FPGA for function verification. FPGA verification can reduce cost, and in the prototype verification stage, verification can be repeated multiple times. FPGA prototype verification can accelerate simulation speed and realize soft and hardware collaborative development verification before chip tape-out. System startup of a SoC chip is the first door of application, and safety, reliability and stability of system startup must be ensured. Some SoC chips support multi-medium safe startup, such as a management controller. A decryption module is used for safe startup, and decryption algorithms in the decryption module support multiple types, such as Hash, ECCRSA, and national encryption and decryption algorithms. Therefore, for prototype verification of multi-medium safe startup, the number and types of test cases are very large, and the embodiment of the application can efficiently complete the verification and quickly check and locate problems in the verification.

[0090] The management controller is a SoC chip, and the management controller is used for management control and is used in a server system to monitor and control system hardware. Safety of the management controller is crucial, and if the management controller is attacked by the outside world, the management controller will work abnormally, and even the entire server system cannot normally operate. Therefore, safety and reliability of the chip are an important index. In the prototype verification stage, sufficient and complete soft and hardware collaborative verification is needed. Therefore, prototype verification of safe startup of the management controller is very important. The embodiment of the application can verify the management controller. The management controller can be one of a BMC (Baseboard Management Controller), an integrated light-out (iLO) system, an integrated Dell remote access control (IDRAC), or a processing chip.

[0091] The application provides a scheme for quickly positioning a security start problem, and solves the problem of quickly checking and positioning an abnormal start in a security start process of an SoC chip, and can be popularized to debugging of quickly positioning problems in other FPGA prototype verification.

[0092] Referring to Figure 5 The application embodiment provides a security start verification device, which comprises:

[0093] A first data acquisition module 51 is configured to acquire first data from a data bus of a security start module and write the first data into a first data cache, wherein the security start module acquires the first data in a security start process and decrypts the first data, and the first data comprises, in sequence, secondary program loader program data acquired from a first target memory and universal boot loader program data acquired from a second target memory;

[0094] A second data acquisition module 52 is configured to 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 configured to store secondary program loader program data read from a target start medium, and the second target memory is configured to store universal boot loader program data read from the target start medium;

[0095] A data comparison module 53 is configured to compare the first data and the second data to perform data checking in the security start process.

[0096] The data comparison module 53 is specifically configured to read first data from the first data cache and read second data from the second data cache when a depth of the first data cache reaches a preset depth condition, compare the first data and the second data, generate error indication information if the first data and the second data are inconsistent, and indicate normality if the first data and the second data are consistent, so as to perform data checking in the security start process.

[0097] The device is further configured to:

[0098] If data bit widths of the data buses of the first target memory, the second target memory and the security start module are inconsistent, the first data or the second data with a data bit width lower than a highest data bit width is merged before being written 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 security start process can comprise:

[0100] determine a target booting medium based on the medium security booting configuration information, and read second-stage program loader program data from the target booting medium to a first target memory;

[0101] determine whether to enable the security booting mode based on a security enable signal, wherein the security booting mode is not enabled when the security enable signal is a first preset value, and the security booting mode is enabled when the security enable signal is a second preset value;

[0102] read the second-stage program loader program data from the first target memory to a security booting module when the security booting mode is enabled, to decrypt the second-stage program loader program data by using the security booting module, obtain second-stage program loader program data plaintext, and write the second-stage program loader program data plaintext back to the first target memory;

[0103] execute the second-stage program loader program data plaintext in the first target memory, and read general-purpose boot loader program data from the target booting medium to a second target memory;

[0104] read the general-purpose boot loader program data from the second target memory to the security booting module, to decrypt the general-purpose boot loader program data by using the security booting module, obtain general-purpose boot loader program data plaintext, and write the general-purpose boot loader program data plaintext back to the second target memory;

[0105] execute the general-purpose boot loader program data plaintext in the second target memory, to complete the security booting.

[0106] The medium security booting configuration information includes a medium configuration value, the target booting medium is a booting medium corresponding to current medium security booting configuration information in a plurality of booting media, and different booting media correspond to different medium configuration values.

[0107] The security booting module can be configured to determine a decryption algorithm and a key based on register configuration information, and decrypt the second-stage program loader program data by using the decryption algorithm and the key to obtain second-stage program loader program data plaintext.

[0108] The apparatus is further configured to:

[0109] transmit register information of each module in the system on chip to a debugging terminal based on a preset bus debugging interface connected to a bus arbitration module, so that the debugging terminal performs security booting verification based on the register information.

[0110] It can be seen that, in the secure starting process, the secondary program loader program data is read from the target starting medium to the first target memory, and the general boot loader program data is read to the second target memory in sequence, the secure starting module decrypts the secondary program loader program data from the first target memory and the general boot loader program data from the second target memory in sequence, the data checking process is to obtain data from the data bus of the secure starting module, store the data to the corresponding data buffer, and obtain data from the data bus of the first target memory and the second target memory, store the data to the corresponding data buffer, and compare the data in the two data buffers. In this way, in the secure starting process, data errors can be found in time, and problems can be analyzed, so that efficient secure starting verification can be performed, and problems can be located in time.

[0111] Figure 5 The features of the corresponding embodiments can be seen from the above description of the embodiments. Figure 1 The related description of the corresponding embodiments will not be repeated here.

[0112] Figure 6 A structural diagram of an electronic device provided by the embodiments of the present application is shown in FIG. 1. Figure 6 The electronic device includes a memory 60 for storing a computer program.

[0113] A processor 61 for executing the computer program to implement the steps of the secure starting verification method of the above-described embodiments.

[0114] The processor 61 can 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 of a hardware form of a Digital Signal Processing (DSP), a Field-Programmable Gate Array (FPGA), and a Programmable Logic Array (PLA). The processor 61 can also include a main processor and a coprocessor. The main processor is a processor for processing data in a wake-up state, also known as a Central Processing Unit (CPU). The coprocessor is a low-power processor for processing data in a standby state. In some embodiments, the processor 61 can be integrated with a Graphics Processing Unit (GPU). The GPU is used to render and draw the content required to be displayed by the display screen. In some embodiments, the processor 61 can also include an Artificial Intelligence (AI) processor. The AI processor 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 high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 60 is used to store at least the following computer program 601, which, after being loaded and executed by the processor 61, is capable of implementing the relevant steps of the secure boot verification method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 60 may also include an operating system 602 and data 603, and the storage method may be temporary or permanent storage. The operating system 602 may include Windows, Unix, Linux, etc. The data 603 may include, but is not limited to, program data.

[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 structures shown do not constitute a limitation on electronic devices and may include more or fewer components than those shown.

[0118] It is understood that if the secure boot verification method in the above embodiments 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 the present invention, in essence, or the part that contributes to the current technology, 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 executes all or part of the steps of the methods in the various embodiments of the present invention. The aforementioned storage medium includes: USB flash drive, mobile hard drive, 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 capable of storing program code.

[0119] Based on this, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the secure boot verification method described above.

[0120] The following describes a computer program product provided by an embodiment of the present invention. The computer program product described below can be referred to in conjunction with other embodiments described herein.

[0121] A computer program product comprising computer programs / instructions which, when executed by a processor, implement the steps of the secure boot verification method disclosed above.

[0122] The secure boot verification method, device, equipment and medium provided by the embodiments of the present application are described in detail above. Each embodiment in the specification is described in a progressive manner, and each embodiment mainly describes the difference from other embodiments. The same or similar parts of each embodiment can be understood by mutual reference. For the device disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple, and the relevant parts can be understood by referring to the method part.

[0123] The skilled person can further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized by electronic hardware, computer software or a combination of both. In order to clearly show the interchangeability of hardware and software, the composition and steps of each example have been described in the above description. Whether the functions are realized in hardware or software depends on the specific application and design constraints of the technical solution. The skilled person can use different methods to realize the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0124] The secure boot verification method, device, equipment and medium provided by the embodiments of the present application are described in detail above. The principles and implementation modes of the present application are described by applying specific examples in this paper. The above description of the embodiments is only used to help understand the method of the present application and its core idea. It should be pointed out that for ordinary skilled person in the technical field, some improvements and modifications can be made to the present application without departing from the principles of the present application. These improvements and modifications also fall within the protection scope of the claims of the present application.

Claims

1. A secure boot verification method, characterized in that, include: During the secure boot process, the secondary program loader program data is sequentially read from the target boot medium to the first target memory, and the general boot loader data is sequentially read to the second target memory. The secure boot module then sequentially retrieves the secondary program loader program data from the first target memory and the general boot loader data from the second target memory for decryption. The first data is obtained from the data bus of the secure boot module and written into the 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 the first target memory and general boot loader data obtained from the second target memory; the first data is the original encrypted data written to the secure boot module; Second data is obtained from the data buses of the first target memory and the second target memory respectively, and the second data is written into the 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 general boot loader data read from the target boot medium; The first data and the second data are compared to perform data verification during the secure boot process.

2. The secure boot verification method according to claim 1, characterized in that, The comparison of the first data and the second data to perform data verification during the secure boot process includes: 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. 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 secure startup process.

3. The secure boot verification method according to claim 1, characterized in that, Also includes: If the data bus widths of the first target memory, the second target memory, and the secure boot module are inconsistent, the first or second data with a data bus width lower than the highest data bus width will be merged before writing to the first or second data cache, so that the data bus 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: The target boot medium is determined based on the media security boot configuration information, and the secondary program loader program data is read from the target boot medium into the first target memory; Whether to enable the secure startup mode is determined based on the security enable signal, wherein when the security enable signal is a first preset value, it indicates that the secure startup mode is not enabled, and when the security enable signal is a second preset value, it indicates that the secure startup mode is enabled. When the secure boot mode is enabled, the secondary program loader program data is read from the first target memory to the secure boot module, and the secure boot module is used to decrypt the secondary program loader program data to obtain the plaintext of the secondary program loader program data, and then the plaintext of the secondary program loader program data is written back to the first target memory. The plaintext of the secondary program loader program data is executed in the first target memory, and the generic boot loader data is read from the target boot medium into the second target memory; The generic bootloader data is read from the second target memory and sent to the secure boot module. The secure boot module is then used to decrypt the generic bootloader data to obtain the plaintext generic bootloader data, and the plaintext generic bootloader data is written back to the second target memory. The generic bootloader data plaintext is executed in the second target memory to complete a secure boot.

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

6. The secure boot verification method according to claim 4, characterized in that, The secondary program loader program data is decrypted to obtain the plaintext of the secondary program loader program data, including: The decryption algorithm and key are determined based on register configuration information; The decryption algorithm and the key are used to decrypt the secondary program loader program data to obtain the plaintext of the secondary program loader program data.

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

8. A safe start verification device, characterized in that, include: A first data acquisition module is used to acquire 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 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 a first target memory and general boot loader data acquired from a second target memory; the first data is the original encrypted data written to the secure boot module; during the secure boot process, the secondary program loader program data is sequentially read from the target boot medium into the first target memory, and the general boot loader data is sequentially read into the second target memory, and the secure boot module sequentially acquires the secondary program loader program data from the first target memory and the general boot loader data from the second target memory and decrypts them; The second data acquisition module is used to acquire second data from the data buses of the first target memory and the second target memory respectively, and write the second data into the 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 general boot loader 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 secure boot process.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the secure boot verification method as described 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 that, when executed by a processor, implements the steps of the secure boot verification method as described in any one of claims 1 to 7.

Images