Solid State Drive (SSD) Boot Program Storage Methods and SSD Boot Methods

Abstract

This invention discloses a method for storing a boot program for a solid-state drive (SSD) and a method for booting a solid-state drive (SSD). The method for storing the boot program includes: obtaining a bootloader from the SSD and calculating a first hash value for the bootloader; storing the bootloader and the first hash value in a first NorFlash memory within the SSD controller chip; obtaining a boot program and boot data, and calculating a second hash value for the boot program and / or the boot data; generating a metric value based on the first hash value and the second hash value using a preset algorithm, and storing the metric value, the boot program, and the boot data in a second NorFlash memory outside the SSD controller chip. The solution of this invention establishes a trust chain using the first hash value of the loaded bootloader as a root of trust, thereby establishing and transmitting a trust chain for a trusted software system, which helps improve the security of SSD booting.

Description

Technical Field

[0001] This invention relates to the field of storage, and more particularly to a solid-state drive (SSD) boot program storage method and a solid-state drive boot method. Background Technology

[0002] Solid-state drives (SSDs), as a next-generation storage technology, have seen widespread adoption thanks to the development of technologies such as the internet and cloud computing. SSDs are powerful, with large amounts of firmware code, and require a lot of critical data during the boot process. Therefore, both firmware and data are stored in a large-capacity NorFlash (a type of non-volatile flash memory) located off-chip (not inside the controller chip). During the boot process, the SSD reads the firmware and critical data from this off-chip NorFlash. However, this off-chip device is easily modified by adversaries, potentially leading to the loading of illegal programs and data during the SSD boot process, posing a significant security risk. Summary of the Invention

[0003] In view of this, it is necessary to provide a solid-state drive (SSD) boot program storage method and an SSD boot method to address the above technical issues.

[0004] According to a first aspect of the present invention, a method for storing a bootable solid-state drive (SSD) is provided, the method comprising:

[0005] Obtain the bootloader of the solid-state drive and calculate the first hash value of the bootloader;

[0006] The bootloader and the first hash value are stored in the first NorFlash within the solid-state drive controller chip;

[0007] Obtain the startup program and startup data, and calculate the second hash value of the startup program and / or the startup data;

[0008] A metric value is generated based on the first hash value and the second hash value using a preset algorithm, and the metric value, the startup program, and the startup data are stored in the second NorFlash outside the solid-state drive controller chip.

[0009] In some embodiments, the boot program includes a patch segment, a secondary boot segment, and a firmware segment, and the boot data includes first key data and second key data, wherein the first key data represents the data required before firmware boot, and the second key data represents the data required during firmware boot.

[0010] In some embodiments, the step of obtaining the startup program and startup data, and calculating a second hash value of the startup program and / or the startup data includes:

[0011] Obtain the patch segment and calculate its hash value;

[0012] Obtain the secondary bootstrap segment and calculate its hash value;

[0013] Obtain the firmware segment and calculate the hash value of the firmware segment;

[0014] Obtain the first key data and calculate the hash value of the first key data;

[0015] Obtain the second key data and calculate the hash value of the second key data.

[0016] In some embodiments, the step of generating a metric value based on the first hash value and the second hash value using a preset algorithm, and storing the metric value, the boot program, and the boot data in a second NorFlash outside the solid-state drive controller chip includes:

[0017] The first hash value and the hash value of the patch segment are concatenated to obtain the first metric value;

[0018] The first metric value and the hash value of the secondary bootstrap segment are concatenated to obtain the second metric value;

[0019] The hash value of the second metric and the hash value of the first key data are concatenated to obtain the third metric;

[0020] The third metric value and the hash value of the firmware segment are concatenated to obtain the fourth metric value;

[0021] The hash value of the fourth metric and the second key data are concatenated to obtain the fifth metric.

[0022] The first metric value, the second metric value, the third metric value, the fourth metric value, and the fifth metric value are added to the patch segment, the secondary boot segment, the firmware segment, the first key data, and the second key data according to preset rules, and stored in the second NorFlash.

[0023] According to a second aspect of the present invention, a solid-state drive (SSD) boot method is also provided. The SSD has a boot program, which is stored using the SSD boot program storage method described above. The SSD boot method includes:

[0024] Read the bootloader and the first hash value from the first NorFlash in the solid-state drive controller chip, and run the bootloader;

[0025] The boot program and boot data are read from the second NorFlash outside the solid-state drive controller chip, and the third hash value of the boot program and boot data is calculated.

[0026] A metric value to be verified is generated based on the first hash value and the third hash value using a preset algorithm.

[0027] The measurement value is read from the second NorFlash outside the solid-state drive controller chip and compared with the measurement value to be verified;

[0028] If the comparison is successful, the boot process is executed based on the boot program and boot data; otherwise, the solid-state drive is powered off to terminate the boot process.

[0029] In some embodiments, the boot program includes a patch segment, a secondary boot segment, and a firmware segment, and the boot data includes first key data and second key data, wherein the first key data represents the data required before firmware boot, and the second key data represents the data required during firmware boot.

[0030] In some embodiments, the step of reading the boot program and boot data from the second NorFlash outside the solid-state drive controller chip, and calculating the third hash value of the boot program and boot data, includes:

[0031] Read the patch segment from the second NorFlash and calculate the hash value of the read patch segment;

[0032] Read the secondary boot segment from the second NorFlash and calculate the hash value of the read secondary boot segment;

[0033] Read the firmware segment from the second NorFlash and calculate the hash value of the read firmware segment;

[0034] Read the first key data from the second NorFlash and calculate the hash value of the read first key data;

[0035] Read the second key data from the second NorFlash and calculate the hash value of the read second key data.

[0036] In some embodiments, the step of generating a metric to be verified based on the first hash value and the third hash value using a preset algorithm includes:

[0037] The first hash value is concatenated with the hash value of the read patch segment to obtain the first metric value to be verified;

[0038] The first metric to be verified and the hash value of the read secondary bootstrap segment are used to obtain the second metric to be verified.

[0039] The hash value of the two metrics to be verified and the first key data read are concatenated to obtain the third metric to be verified.

[0040] The third metric to be verified and the hash value of the read firmware segment are concatenated to obtain the fourth metric to be verified.

[0041] The hash value of the fourth metric to be verified and the second key data read are concatenated to obtain the fifth metric to be verified.

[0042] In some embodiments, the step of reading the measurement value from the second NorFlash outside the solid-state drive controller chip and comparing it with the measurement value to be verified includes:

[0043] The first metric value is compared with the first metric value to be verified to determine whether the two are the same;

[0044] The second metric is compared with the second metric to be verified to determine whether they are the same;

[0045] The third metric is compared with the third metric to be verified to determine whether they are the same;

[0046] The fourth metric is compared with the fourth metric to be verified to determine whether they are the same;

[0047] The fifth metric is compared with the fifth metric to be verified to determine whether they are the same.

[0048] In some embodiments, when the comparison is successful, the first metric value is the same as the first metric value to be verified, the second metric value is the same as the second metric value to be verified, the third metric value is the same as the third metric value to be verified, the fourth metric value is the same as the fourth metric value to be verified, and the fifth metric value is the same as the fifth metric value to be verified.

[0049] The aforementioned solid-state drive (SSD) boot program storage method stores the first hash value of the loaded boot program in the first NorFlash within the SSD controller chip. Based on the second hash value and the first hash value of the boot program and boot data, a measurement value is generated using a preset algorithm. This measurement value, along with the boot program and boot data, is simultaneously stored in the second NorFlash outside the SSD controller chip. A trust chain is established using the first hash value of the loaded boot program as the root of trust. The measurement value is used to proactively measure the software environment upon which the SSD boot depends, thus establishing and transmitting a trust chain for a trusted software system. This allows for verification using the stored data during program startup, thereby improving the security of SSD booting.

[0050] The aforementioned solid-state drive (SSD) boot method, through a special storage method for the boot program, adds a verification step to the loaded program or data during the boot process. The boot process can only continue when the calculated metric value passes the verification, and the boot process is actively blocked if the metric value fails the verification. This ensures that the SSD can only be booted using legitimate and secure programs, thereby improving the security of the SSD. Attached Figure Description

[0051] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other embodiments can be obtained based on these drawings without creative effort.

[0052] Figure 1 This is a flowchart illustrating a solid-state drive boot program storage method 100 according to an embodiment of the present invention.

[0053] Figure 2A A schematic diagram of the storage frame in the first NorFlash provided for another embodiment of the present invention;

[0054] Figure 2B A schematic diagram of the storage frame in a second NorFlash provided in another embodiment of the present invention;

[0055] Figure 3 This is a flowchart illustrating a solid-state drive boot method 200 provided in another embodiment of the present invention. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to specific examples and the accompanying drawings.

[0057] It should be noted that all uses of "first" and "second" in the embodiments of the present invention are for the purpose of distinguishing two entities or parameters with the same name but different names. It is clear that "first" and "second" are only for the convenience of expression and should not be construed as limiting the embodiments of the present invention. Subsequent embodiments will not explain this in detail.

[0058] In one embodiment, please refer to Figure 1 As shown, the present invention provides a method for storing boot programs on a solid-state drive, specifically, the method includes the following steps:

[0059] Step 101: Obtain the bootloader of the solid-state drive and calculate the first hash value of the bootloader;

[0060] In this embodiment, the bootloader is the first piece of code executed by the embedded system after power-on. After initializing the CPU and related hardware, it loads the operating system image or the embedded application into memory and then jumps to the space where the operating system resides to start the operating system. The first hash value of the bootloader is calculated by representing the bootloader as a binary number. The first hash value is the hash value obtained by performing a hash algorithm on the binary data.

[0061] Step 102: Store the bootloader and the first hash value in the first NorFlash within the solid-state drive controller chip;

[0062] In this embodiment, the first hash value can be appended to the end, the beginning, or a pre-defined position in the middle of the bootloader. This invention does not limit the specific location or method of storing the two.

[0063] Step 103: Obtain the startup program and startup data, and calculate the second hash value of the startup program and / or the startup data;

[0064] In this embodiment, the boot program refers to the program required for the solid-state drive (SSD) to boot, typically including firmware, secondary boot segments, and patches. Boot data refers to the data required for the SSD to boot, usually including critical and non-critical data. Critical data includes data that may be modified during boot and data that will not be modified. In practice, hash calculations can be performed only on a specific part of the boot program, such as the firmware segment, or only on a certain type of data or all of the boot data. Alternatively, a second hash value can be calculated for selected portions of both the boot program and the boot data. Furthermore, in practice, hash values ​​can be calculated for all three types of program segments in the boot program, or one or two segments can be selected for hash value calculation. The same applies to the selection of boot data.

[0065] Step 104: Generate a metric value based on the first hash value and the second hash value using a preset algorithm, and store the metric value, the startup program, and the startup data in the second NorFlash outside the solid-state drive controller chip.

[0066] In this embodiment, when the calculated second hash value includes multiple values, the metric value can be calculated step by step. For example, the metric value of each program segment depends on the metric value of the previous program segment for cumulative calculation. Alternatively, the hash value of each stage can be concatenated with the first hash value. In the specific implementation process, the settings can be flexibly configured according to the user's needs and the required security level.

[0067] The aforementioned solid-state drive (SSD) boot program storage method stores the first hash value of the loaded boot program in the first NorFlash within the SSD controller chip. Based on the second hash value and the first hash value of the boot program and boot data, a measurement value is generated using a preset algorithm. This measurement value, along with the boot program and boot data, is simultaneously stored in the second NorFlash outside the SSD controller chip. A trust chain is established using the first hash value of the loaded boot program as the root of trust. The measurement value is used to proactively measure the software environment upon which the SSD boot depends, thus establishing and transmitting a trust chain for a trusted software system. This allows for verification using the stored data during program startup, thereby improving the security of SSD booting.

[0068] In some embodiments, the boot program includes a patch segment, a secondary boot segment, and a firmware segment. The boot data includes first critical data, second critical data, and non-critical data. The first critical data represents data required before firmware boot, and the second critical data represents data required during firmware boot. Since non-critical data has little impact on the operation before or after boot, this embodiment does not measure non-critical data. That is, hash values ​​are calculated only for all types of boot programs and all types of boot data other than non-critical data. Specifically, the aforementioned step 103 includes the following sub-steps:

[0069] Step 1031: Obtain the patch segment and calculate the hash value of the patch segment;

[0070] Step 1032: Obtain the secondary bootstrap segment and calculate the hash value of the secondary bootstrap segment;

[0071] Step 1033: Obtain the firmware segment and calculate the hash value of the firmware segment;

[0072] Step 1034: Obtain the first key data and calculate the hash value of the first key data;

[0073] Step 1035: Obtain the second key data and calculate the hash value of the second key data.

[0074] In some embodiments, step 104 specifically includes the following sub-steps:

[0075] Step 1041: Concatenate the first hash value with the hash value of the patch segment to obtain the first metric value;

[0076] Step 1042: Concatenate the first metric value and the hash value of the secondary bootstrap segment to obtain the second metric value;

[0077] Step 1043: Concatenate the hash value of the second metric and the first key data to obtain the third metric;

[0078] Step 1044: Concatenate the third metric value and the hash value of the firmware segment to obtain the fourth metric value;

[0079] Step 1045: Concatenate the hash value of the fourth metric and the second key data to obtain the fifth metric;

[0080] Step 1046: Add the first metric value, the second metric value, the third metric value, the fourth metric value and the fifth metric value to the patch segment, the secondary boot segment, the firmware segment, the first key data and the second key data respectively according to preset rules and store them in the second NorFlash.

[0081] In yet another embodiment, please refer to Figure 2A and Figure 2B As shown, because a trust chain needs to be established, the metric value for each stage needs to be calculated based on the boot order of the SSD. Let's assume the loading order of the SSD program and data is as follows: BootLoader, patch segment, secondary boot segment, first critical data, firmware segment, and second critical data required for firmware startup. Then, the SSD boot program storage method includes:

[0082] (1) The manufacturer calculates the hash value BLHash based on the BootLoader code. Only the manufacturer knows the BootLoader code, and the calculated BLHash cannot be leaked to ensure its trustworthiness. Therefore, BLHash can be used as the root of trust to establish a chain of trust. The hash value hash1 is calculated based on the patch code compiled during firmware compilation. The measurement value measurement1 of the patch segment is calculated according to the agreed hash algorithm (such as SM3, SHA1-256, etc.) and the following formula, and added to the end of the patch segment. The BootLoader code and its corresponding hash value are burned into the first NorFlash in the solid-state drive controller chip. For details, please refer to [link to relevant documentation]. Figure 2A As shown.

[0083] The formula is: metric = Hash(metric from the previous stage || hash of the code in the current stage);

[0084] The symbol “||” indicates that two sets of data are connected together.

[0085] (2) Calculate the hash value hash2 based on the code of the secondary bootstrap section, and use the same algorithm Hash(measurement1||hash2) to calculate the measurement value measurement2 of the secondary bootstrap section, and add it to the end of the secondary bootstrap section.

[0086] (3) Based on the first key data, calculate its hash value hash3, and use the same algorithm Hash(measurement2||hash3) to calculate the measurement value measurement3 of the first key data, and add it to the end of the introductory section.

[0087] (4) Following this pattern, calculate the measurement values ​​for the firmware segment and the second key data in sequence. Burn the organized code and data into the external NorFlash of the solid-state drive (SSD) for loading during SSD boot. Finally, burn it into the second NorFlash outside the SSD controller chip, with the structure as follows: Figure 2B As shown.

[0088] It should be noted that in this embodiment, non-critical data is not stored using a measurement method. When the solid-state drive has a high boot security level, the non-critical data can also be stored in the same way after calculating the measurement value of the second critical data.

[0089] The aforementioned solid-state drive boot program storage method differs from traditional boot program storage methods. By adding a root of trust and verification data to the NorFlash storage of the program inside and outside the main controller chip, this storage method requires an additional verification step during program startup. Furthermore, the measurement values ​​corresponding to each program segment and data are established and passed step by step, which helps to improve the security of solid-state drive booting.

[0090] In some embodiments, please combine Figure 3 As shown, the present invention also provides a solid-state drive (SSD) boot method. The SSD has a boot program, which is stored using the aforementioned SSD boot program storage method. The SSD boot method specifically includes the following steps:

[0091] Step 201: Read the bootloader and the first hash value from the first NorFlash in the solid-state drive controller chip, and run the bootloader;

[0092] Step 202: Read the boot program and boot data from the second NorFlash outside the solid-state drive controller chip, and calculate the third hash value of the boot program and boot data;

[0093] Step 203: Generate a metric value to be verified based on the first hash value and the third hash value using a preset algorithm;

[0094] Step 204: Read the measurement value from the second NorFlash outside the solid-state drive controller chip and compare it with the measurement value to be verified;

[0095] Step 205: If the comparison is successful, the boot process is executed based on the boot program and boot data; otherwise, the solid-state drive is powered off to terminate the boot process.

[0096] The aforementioned solid-state drive (SSD) boot method, through a special storage method for the boot program, adds a verification step to the loaded program or data during the boot process. The boot process can only continue when the calculated metric value passes the verification, and the boot process is actively blocked if the metric value fails the verification. This ensures that the SSD can only be booted using legitimate and secure programs, thereby improving the security of the SSD.

[0097] In some embodiments, the boot program includes a patch segment, a secondary boot segment, and a firmware segment, and the boot data includes first key data and second key data, wherein the first key data represents the data required before firmware boot, and the second key data represents the data required during firmware boot.

[0098] In some embodiments, step 202 specifically includes the following sub-steps:

[0099] Step 2021: Read the patch segment from the second NorFlash and calculate the hash value of the read patch segment;

[0100] Step 2022: Read the secondary boot segment from the second NorFlash and calculate the hash value of the read secondary boot segment;

[0101] Step 2023: Read the firmware segment from the second NorFlash and calculate the hash value of the read firmware segment;

[0102] Step 2024: Read the first key data from the second NorFlash and calculate the hash value of the read first key data;

[0103] Step 2025: Read the second key data from the second NorFlash and calculate the hash value of the read second key data.

[0104] In some embodiments, step 203 specifically includes the following sub-steps:

[0105] Step 2031: Concatenate the first hash value with the hash value of the read patch segment to obtain the first metric value to be verified;

[0106] Step 2032: Combine the first metric to be verified with the hash value of the read secondary bootstrap segment to obtain the second metric to be verified;

[0107] Step 2033: Concatenate the second metric to be verified and the hash value of the first key data read to obtain the third metric to be verified;

[0108] Step 2034: Concatenate the third metric to be verified and the hash value of the read firmware segment to obtain the fourth metric to be verified.

[0109] Step 2035: Concatenate the fourth metric to be verified and the hash value of the second key data read to obtain the fifth metric to be verified.

[0110] In some embodiments, step 204 includes the following sub-steps:

[0111] Step 2041: Compare the first metric with the first metric to be verified to determine whether they are the same;

[0112] Step 2042: Compare the second metric with the second metric to be verified to determine whether they are the same;

[0113] Step 2043: Compare the third metric with the third metric to be verified to determine whether they are the same;

[0114] Step 2044: Compare the fourth metric with the fourth metric to be verified to determine whether they are the same;

[0115] Step 2045: Compare the fifth metric with the fifth metric to be verified to determine whether they are the same.

[0116] In some embodiments, when the comparison is successful, the first metric value is the same as the first metric value to be verified, the second metric value is the same as the second metric value to be verified, the third metric value is the same as the third metric value to be verified, the fourth metric value is the same as the fourth metric value to be verified, and the fifth metric value is the same as the fifth metric value to be verified.

[0117] In yet another embodiment, the startup procedure is used below. Figure 2A and Figure 2B Taking the storage architecture as an example, the solid-state drive (SSD) boot method is as follows:

[0118] (1) BootLoader starts and reads the hash value BLHash of Bootloader stored in non-volatile memory in the main controller.

[0119] (2) Load code and data from NorFlash into a specified area in DDR.

[0120] (3) Read the patch segment code from DDR, calculate the hash value hash1 (calculation is only performed on the code, excluding the measurement value measurement1 of the fixed bytes at the end of the patch segment code), calculate the measurement value MEASUREMENT1 of the patch segment based on Hash(BLHash||hash1), and compare it with the measurement value measurement1 at the end of the patch segment code when flashing the firmware. If they match, it means that the patch segment has not been tampered with. Continue the startup process; otherwise, terminate the startup process.

[0121] (4) Read the secondary boot segment code from DDR, calculate the hash value hash2, calculate the measurement value MEASUREMENT2 of the secondary boot segment based on Hash(MEASUREMENT1||hash2), and compare it with the measurement value measurement2 at the end of the secondary boot segment code when burning the firmware. If they match, it means that the secondary boot segment has not been tampered with. Continue the startup process; otherwise, terminate the startup process.

[0122] (5) Read the first key data from DDR, calculate its hash value hash3, calculate the measurement value MEASUREMENT3 of the first key data according to Hash(MEASUREMENT2||hash3), and compare it with the measurement3 provided when burning the firmware. If they match, it means that the first key data has not been tampered with. Continue the startup process; otherwise, terminate the startup process.

[0123] (6) By analogy, calculate the measurement value of the firmware segment and the second key data in turn and compare it with the measurement value at the end. If they are consistent, continue to the next step of the process; otherwise, power off and terminate the startup process.

[0124] In addition, it should be noted that some critical data may be modified according to the actual situation during the operation of the solid-state drive (such as the second critical data). If an update is made to the second NorFlash, the new metric value needs to be recalculated based on the metric value of the previous stage and the hash value of these critical data, and then saved together to the second NorFlash for verification during the next power-on.

[0125] The aforementioned solid-state drive (SSD) boot method possesses at least the following beneficial technical effects: It uses the hash value of the BootLoader, known only to the manufacturer, as the root of trust. The calculation of the metric value at each stage depends on the metric value of the previous trusted stage to determine the trustworthiness of the current stage, thus forming a trust chain. This trust chain can obtain various codes or data affecting platform trustworthiness through a trusted measurement mechanism, and determine the platform's trustworthiness by comparing this data with expected data; ensuring the security of the SSD boot process and preventing the boot process from being affected by altering NorFlash data.

[0126] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0127] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for storing a boot program on a solid-state drive, characterized in that, The solid-state drive boot program storage method includes: Obtain the bootloader of the solid-state drive and calculate the first hash value of the bootloader; The bootloader and the first hash value are stored in the first NorFlash within the solid-state drive controller chip; Obtain the boot program and boot data, wherein the boot program includes a patch segment, a secondary boot segment, and a firmware segment, and the boot data includes first key data and second key data, and calculate the hash values ​​of the patch segment, the secondary boot segment, the firmware segment, the first key data, and the second key data respectively; The first hash value and the hash value of the patch segment are concatenated to obtain the first metric value; The first metric value and the hash value of the secondary bootstrap segment are concatenated to obtain the second metric value; The hash value of the second metric and the hash value of the first key data are concatenated to obtain the third metric; The third metric value and the hash value of the firmware segment are concatenated to obtain the fourth metric value; The hash value of the fourth metric and the second key data are concatenated to obtain the fifth metric. The first metric value, the second metric value, the third metric value, the fourth metric value, and the fifth metric value are added to the patch segment, the secondary boot segment, the firmware segment, the first key data, and the second key data according to preset rules, and stored in the second NorFlash.

2. The solid-state drive boot program storage method according to claim 1, characterized in that, The first key data represents the data required before firmware startup, and the second key data represents the data required during firmware startup.

3. A method for booting a solid-state drive, characterized in that, The solid-state drive (SSD) has a boot program, which is stored using the SSD boot program storage method according to any one of claims 1-2, wherein the SSD boot method includes: Read the bootloader and the first hash value from the first NorFlash in the solid-state drive controller chip, and run the bootloader; The boot program and boot data are read from the second NorFlash outside the solid-state drive controller chip. The boot program includes a patch segment, a secondary boot segment, and a firmware segment. The boot data includes first key data and second key data. The hash values ​​of the read patch segment, secondary boot segment, firmware segment, first key data, and second key data are calculated respectively. The first hash value is concatenated with the hash value of the read patch segment to obtain a first metric to be verified; the first metric to be verified is concatenated with the hash value of the read secondary boot segment to obtain a second metric to be verified; the second metric to be verified is concatenated with the hash value of the read first key data to obtain a third metric to be verified; the third metric to be verified is concatenated with the hash value of the read firmware segment to obtain a fourth metric to be verified; the fourth metric to be verified is concatenated with the hash value of the read second key data to obtain a fifth metric to be verified. The first metric value, the second metric value, the third metric value, the fourth metric value, and the fifth metric value are read from the second NorFlash outside the solid-state drive controller chip and compared with the first metric value to be verified, the second metric value to be verified, the third metric value to be verified, the fourth metric value to be verified, and the fifth metric value to be verified, respectively. If the comparison is successful, the boot process is executed based on the boot program and boot data; otherwise, the solid-state drive is powered off to terminate the boot process.

4. The solid-state drive boot method according to claim 3, characterized in that, The first key data represents the data required before firmware startup, and the second key data represents the data required during firmware startup.

5. The solid-state drive boot method according to claim 3, characterized in that, The steps of reading the first metric value, the second metric value, the third metric value, the fourth metric value, and the fifth metric value from the second NorFlash outside the solid-state drive controller chip and comparing them with the first metric value to be verified, the second metric value to be verified, the third metric value to be verified, the fourth metric value to be verified, and the fifth metric value to be verified, respectively, include: The first metric value is compared with the first metric value to be verified to determine whether the two are the same; The second metric is compared with the second metric to be verified to determine whether they are the same; The third metric is compared with the third metric to be verified to determine whether they are the same; The fourth metric is compared with the fourth metric to be verified to determine whether they are the same; The fifth metric is compared with the fifth metric to be verified to determine whether they are the same.

6. The solid-state drive boot method according to claim 5, characterized in that, When the comparison is successful, the first metric value is the same as the first metric value to be verified, the second metric value is the same as the second metric value to be verified, the third metric value is the same as the third metric value to be verified, the fourth metric value is the same as the fourth metric value to be verified, and the fifth metric value is the same as the fifth metric value to be verified.

Images