A firmware security mechanism verification method and device, electronic equipment and medium

By randomly generating multiple execution sequences of enable protection and LOCK mechanisms, global and partial LOCK mechanism verification is performed, solving the problem of insufficient verification coverage of firmware security mechanisms in existing technologies and realizing the reliability and robustness of chip security mechanisms.

CN120217382BActive Publication Date: 2025-11-25ZHONGKE HAOXIN (ZHUHAI) TECHNOLOGY CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202510295420.5
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2025-03-13
Publication Date
2025-11-25
Estimated Expiration
2045-03-13

Smart Images

  • Figure CN120217382B_ABST
    Figure CN120217382B_ABST
Patent Text Reader

Abstract

The application provides a firmware security mechanism verification method and device, electronic equipment and medium. The verification method is for a target chip designed with a firmware security mechanism. The firmware security mechanism includes different levels of enabling protection mechanisms and LOCK mechanisms. The LOCK mechanisms include global LOCK mechanisms and partial LOCK mechanisms. The method includes: randomly generating multiple enabling execution sequences of the different levels of enabling protection mechanisms to verify enabling protection verification results; performing global LOCK mechanism and partial LOCK mechanism verification to determine LOCK verification results of the target chip; the partial LOCK mechanisms are verified based on the state of randomly setting LOCK control bits; and target verification results of the firmware security mechanism are determined based on the enabling protection verification results and the LOCK verification results, so as to comprehensively simulate complex operation scenarios in actual use and ensure the reliability and robustness of the firmware security mechanism of the chip.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of chip security technology, and more specifically, to a firmware security mechanism verification method, apparatus, electronic device, and medium. Background Technology

[0002] Currently, non-volatile memory within chips is almost entirely implemented through direct programming (write) and erasing operations. In practical use, due to misoperation or system malfunctions, stored information may be accidentally overwritten or erased, leading to data loss or system failure. Existing technologies provide certain security mechanisms for firmware security protection through enable and lock mechanisms, but the following problems still exist: insufficient verification coverage for security mechanisms, limited scenarios, and fixed test cases. Therefore, existing verification methods cannot guarantee the reliability of chip security mechanisms. Summary of the Invention

[0003] In view of this, the purpose of this application is to provide a firmware security mechanism verification method, apparatus, electronic device and medium that can comprehensively verify the reliability and robustness of chip protection mechanisms, and improve verification efficiency and coverage.

[0004] This application provides a firmware security mechanism verification method. The verification method targets a target chip with a pre-designed firmware security mechanism. The firmware security mechanism includes different levels of enable protection mechanisms and a lock mechanism. The lock mechanism includes a global lock mechanism and a partial lock mechanism. The partial lock mechanism includes multiple lock control bits, each corresponding to a memory unit partition. The verification method includes the following steps:

[0005] Multiple enable execution sequences for different levels of enable protection are randomly generated, and the enable protection verification result of the target chip is determined based on the multiple enable execution sequences.

[0006] The global LOCK mechanism and partial LOCK mechanism are verified to determine the LOCK verification result of the target chip; the partial LOCK mechanism is verified based on the state of the randomly set LOCK control bits.

[0007] The target verification result of the firmware security mechanism is determined based on the enable protection verification result and the LOCK verification result.

[0008] In some embodiments, the firmware security mechanism verification method, wherein randomly generating multiple enable execution orders for different levels of enable protection, and determining the enable protection verification result of the target chip based on the multiple enable execution orders, includes:

[0009] Randomly generate multiple enable execution sequences for the different levels of enable protection;

[0010] Configure the enable for each enable execution order corresponding to the target chip, and determine the enable configuration result corresponding to each enable execution order;

[0011] Based on the enable configuration results corresponding to each enable execution order, the enable protection verification result of the target chip is determined.

[0012] In some embodiments, the firmware security mechanism verification method, wherein determining the enable configuration result corresponding to each enable execution order includes:

[0013] Determine whether the enable corresponding to this enable execution order has been configured successfully;

[0014] If so, determine that the enabling configuration result corresponding to this enabling execution order is a successful enabling configuration;

[0015] If not, the enable configuration result corresponding to this enable execution order is determined to be enable configuration failure.

[0016] In some embodiments, the firmware security mechanism verification method, wherein determining the enable protection verification result of the target chip based on the enable configuration result corresponding to each enable execution order, includes:

[0017] Determine whether only the enable configuration result corresponding to the specified enable execution order is a successful enable configuration;

[0018] If so, the enable protection verification result of the target chip is determined to be effective.

[0019] In some embodiments, the firmware security mechanism verification method, wherein randomly generating multiple enable execution sequences for different levels of enable protection includes:

[0020] Set the corresponding number for different levels of enabled protection;

[0021] The numbers corresponding to different levels of enabled protection are randomly assigned without replacement to determine the execution order of the various enabled protections.

[0022] In some embodiments, the firmware security mechanism verification method, wherein performing global LOCK mechanism and partial LOCK mechanism verification to determine the LOCK verification result of the target chip includes:

[0023] The target chip is set to a global LOCK state, and the global LOCK verification result of the target chip is determined based on the first operation verification result of the memory cell of the target chip.

[0024] Randomly set the LOCK control bit of at least one target memory cell partition to a locked or unlocked state, and determine the partial LOCK verification result of the target chip based on the second operation verification result of the target memory cell partition;

[0025] Based on the global LOCK verification results and partial LOCK verification results of the target chip, the LOCK verification result of the target chip is determined.

[0026] In some embodiments, the firmware security mechanism verification method, determining the global LOCK verification result of the target chip based on the operation verification result of the memory cell of the target chip, includes:

[0027] Set the target chip to a global LOCK state and verify whether the memory unit of the target chip is unable to perform operations;

[0028] If so, confirm that the global lock verification result is normal.

[0029] In some embodiments, the firmware security mechanism verification method, determining the partial LOCK verification result of the target chip based on the second operation verification result of the target storage unit partition, includes:

[0030] Verify whether the target storage unit partition can be operated on, and determine the execution result of the second operation corresponding to the target storage unit partition;

[0031] If the execution result of the second operation corresponding to the target storage unit partition matches the LOCK control bit status, the partial LOCK verification result is determined to be normal.

[0032] In some embodiments, the firmware security mechanism verification method, based on the global LOCK verification result and partial LOCK verification result of the target chip, determines the LOCK verification result of the target chip, including:

[0033] If both the global LOCK verification result and the partial LOCK verification result of the target chip are normal, then the LOCK verification result of the target chip is determined to be normal.

[0034] In some embodiments, in the firmware security mechanism verification method, determining the target verification result of the firmware security mechanism based on the enable protection verification result and the LOCK lock verification result includes:

[0035] If both the enable protection verification result and the LOCK verification result are normal, then the target verification result of the firmware security mechanism is determined to be normal.

[0036] In some embodiments, a firmware security mechanism verification device is also provided. The verification device is designed for a target chip with a firmware security mechanism, the firmware security mechanism including different levels of enable protection mechanisms and LOCK mechanisms; the LOCK mechanism includes a global LOCK mechanism and a partial LOCK mechanism; the partial LOCK mechanism includes multiple LOCK control bits, each LOCK control bit corresponding to a memory unit partition; the verification device includes:

[0037] The first determining module is used to randomly generate multiple enabling execution sequences for the different levels of enabling protection, and determine the enabling protection verification result of the target chip based on the multiple enabling execution sequences;

[0038] The second step determines the module, which is used to verify the global LOCK mechanism and the partial LOCK mechanism, and to determine the LOCK verification result of the target chip; the partial LOCK mechanism is verified based on the state of the randomly set LOCK control bits.

[0039] The third determining module is used to determine the target verification result of the firmware security mechanism based on the enable protection verification result and the LOCK verification result.

[0040] In some embodiments, an electronic device is also provided, the electronic device including: a processor, a memory and a bus, the memory storing machine-readable instructions executable by the processor, the processor communicating with the memory via the bus when the electronic device is running, and the steps of the firmware security mechanism verification method being executed by the processor when the machine-readable instructions are executed.

[0041] In some embodiments, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, performs the steps of the firmware security mechanism verification method.

[0042] This application provides a firmware security mechanism verification method, apparatus, electronic device, and medium. The verification method targets a target chip with a pre-designed firmware security mechanism. The firmware security mechanism includes different levels of enable protection mechanisms and lock mechanisms. The lock mechanism includes a global lock mechanism and a partial lock mechanism. The partial lock mechanism includes multiple lock control bits, each corresponding to a memory unit partition. The verification method includes the following steps: randomly generating multiple enable execution orders for the different levels of enable protection; determining the enable protection verification result of the target chip based on the multiple enable execution orders; and performing verification of the global lock mechanism and the partial lock mechanism. The target chip's LOCK verification result is determined; the partial LOCK mechanism is verified based on the state of randomly set LOCK control bits; the target verification result of the firmware security mechanism is determined based on the enable protection verification result and the LOCK verification result; thus, for chips with different levels of enable protection mechanisms, global LOCK mechanisms, and partial LOCK mechanisms, various possible enable sequences and abnormal situations are tested through random test cases, and a large number of possible lock state combinations are comprehensively tested, thereby simulating complex operating scenarios in actual use (such as random misoperation, system abnormalities, etc.), ensuring that the firmware security mechanism can work normally under various conditions, thereby ensuring the reliability and robustness of the chip's firmware security mechanism. Attached Figure Description

[0043] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0044] Figure 1 A flowchart of the firmware security mechanism verification method according to an embodiment of this application is shown;

[0045] Figure 2 Another flowchart of the verification method for the firmware security mechanism described in the embodiments of this application is shown;

[0046] Figure 3 A flowchart illustrating the method for determining the enable protection verification result of the target chip based on the multiple enable execution sequences according to an embodiment of this application is shown.

[0047] Figure 4 A flowchart of the method for determining the LOCK verification result of the target chip according to an embodiment of this application is shown;

[0048] Figure 5A schematic diagram showing the correspondence between the LOCK control bit and the Flash space according to an embodiment of this application is provided.

[0049] Figure 6 A schematic diagram of the firmware security mechanism verification device according to an embodiment of this application is shown;

[0050] Figure 7 A schematic diagram of the structure of the electronic device described in an embodiment of this application is shown. Detailed Implementation

[0051] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0052] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0053] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0054] Currently, non-volatile memory within chips is almost entirely implemented through direct programming (write) and erasing operations. In practical use, due to misoperation or system malfunctions, stored information may be accidentally overwritten or erased, leading to data loss or system failure. Existing technologies provide certain security mechanisms for firmware security protection through enable and lock mechanisms, but the following problems still exist: insufficient verification coverage for security mechanisms, limited scenarios, and fixed test cases. Therefore, existing verification methods cannot guarantee the reliability of chip security mechanisms.

[0055] Existing firmware security protection mechanisms typically employ the following two mechanisms: Enable mechanism: This controls memory access permissions via an enable signal. Programming or erasing operations can only be performed on the memory when the enable signal is valid; otherwise, the operation will be rejected. LOCK mechanism: This restricts memory access permissions via a lock signal.

[0056] Based on this, this application provides a firmware security mechanism verification method, apparatus, electronic device, and medium. The verification method targets a target chip with a pre-designed firmware security mechanism. The firmware security mechanism includes different levels of enable protection mechanisms and lock mechanisms. The lock mechanism includes a global lock mechanism and a partial lock mechanism. The partial lock mechanism includes multiple lock control bits, each corresponding to a memory unit partition. The verification method includes the following steps: randomly generating multiple enable execution sequences for the different levels of enable protection; determining the enable protection verification result of the target chip based on the multiple enable execution sequences; and performing verification of the global lock mechanism and the partial lock mechanism. The method involves determining the LOCK verification result of the target chip; the partial LOCK mechanism is verified based on the state of the randomly set LOCK control bit; the target verification result of the firmware security mechanism is determined based on the enable protection verification result and the LOCK verification result; thus, for chips with different levels of enable protection mechanisms, global LOCK mechanisms and partial LOCK mechanisms, various possible enable sequences and abnormal situations are tested through random test cases, and a large number of possible lock state combinations are comprehensively tested, thereby simulating complex operation scenarios in actual use (such as random misoperation, system abnormality, etc.), ensuring that the firmware security mechanism can work normally under various conditions, thereby ensuring the reliability and robustness of the chip's firmware security mechanism.

[0057] Please refer to Figure 1 , Figure 1 A flowchart of the firmware security mechanism verification method according to an embodiment of this application is shown. The firmware security mechanism verification method is for a target chip with a well-designed firmware security mechanism. The firmware security mechanism includes different levels of enable protection mechanisms and LOCK mechanisms. The LOCK mechanism includes a global LOCK mechanism and a partial LOCK mechanism. The partial LOCK mechanism includes multiple LOCK control bits, and each LOCK control bit corresponds to a memory unit partition.

[0058] like Figure 1 As shown, the verification method includes the following steps S101-S103:

[0059] S101. Randomly generate multiple enable execution sequences for the different levels of enable protection, and determine the enable protection verification result of the target chip based on the multiple enable execution sequences;

[0060] S102. Perform global LOCK mechanism and partial LOCK mechanism verification to determine the LOCK verification result of the target chip; the partial LOCK mechanism is verified based on the state of randomly set LOCK control bits.

[0061] S103. Determine the target verification result of the firmware security mechanism based on the enable protection verification result and the LOCK verification result.

[0062] Please refer to Figure 2 , Figure 2 Another flowchart of the verification method for the firmware security mechanism described in an embodiment of this application is shown. Figure 2 As shown, for multi-level enabled protection, the enabled protection is executed randomly, then the LOCK protection is performed, and finally the operation is executed.

[0063] The firmware security mechanism includes different levels of enable protection mechanisms. These different levels of enable protection mechanisms must be enabled in a specified execution order. If the order is incorrect, even if all of them are enabled, the operation cannot be performed, thus achieving enable protection.

[0064] The global LOCK mechanism is used to set the global LOCK state (locked or unlocked). When locked, all global storage units cannot be operated.

[0065] Partial locking mechanisms divide storage units into logical regions (such as Block 0, Block 1, Block 2, etc.), each of which can be independently programmed, erased, or locked. Each region corresponds to a locking control bit, which sets the state of each locking control bit (locked or unlocked). When the locking control bit is locked, the corresponding storage unit partition cannot be operated on.

[0066] For example, the LOCK control bit of Block 0 is LOCK0, and the LOCK control bit of Block 1 is LOCK1. When performing an operation, it is necessary to check the LOCK control bit of the partition corresponding to the target address. If the LOCK control bit is locked, the operation is rejected.

[0067] The storage unit is a non-volatile memory inside the chip, such as Flash or EEPROM.

[0068] In step S101, multiple enable execution sequences for different levels of enable protection are randomly generated, and the enable protection verification result of the target chip is determined based on the multiple enable execution sequences.

[0069] The enable protection verification results include normal and abnormal. A normal enable protection verification result is that only a specific execution sequence can successfully enable protection; other execution sequences will fail to enable protection.

[0070] The random generation of multiple enable execution sequences for different levels of enable protection can be achieved automatically by a program. These multiple enable execution sequences can be all possible sequences or only some of the possible sequences.

[0071] Since there are generally not many levels of enable protection, it is usually to cover all possible enable execution sequences. This allows for random sequence testing to cover multiple or even all possible execution sequences, verifying the robustness of the enable protection mechanism. It ensures that enable protection can only be activated when executed strictly in sequence, avoiding misoperation, ensuring the legality and security of operations, and effectively protecting chip security.

[0072] Please refer to Figure 3 The random generation of multiple enable execution sequences for different levels of enable protection, and the determination of the enable protection verification result of the target chip based on the multiple enable execution sequences, includes the following steps S301-S303:

[0073] S301. Randomly generate multiple enable execution sequences for the different levels of enable protection;

[0074] S302. Configure the enable corresponding to each enable execution order for the target chip, and determine the enable configuration result corresponding to each enable execution order;

[0075] S303. Based on the enable configuration results corresponding to each enable execution order, determine the enable protection verification result of the target chip.

[0076] The determination of the enable configuration result corresponding to each enable execution order includes:

[0077] Determine whether the enable corresponding to this enable execution order has been configured successfully;

[0078] If so, determine that the enabling configuration result corresponding to this enabling execution order is a successful enabling configuration;

[0079] If not, the enable configuration result corresponding to this enable execution order is determined to be enable configuration failure.

[0080] In this context, successful configuration enables protection to be enabled, while failure to configure enables protection to be enabled results in failure to enable protection.

[0081] The determination of the enable protection verification result of the target chip based on the enable configuration result corresponding to each enable execution order includes:

[0082] Determine whether only the enable configuration result corresponding to the specified enable execution order is a successful enable configuration;

[0083] If so, the enable protection verification result of the target chip is determined to be effective.

[0084] It determines whether only the enable configuration result corresponding to the specified enable execution order is a successful enable configuration, that is, whether only a specific execution order can successfully enable protection.

[0085] Thus, the verification method described in this application not only verifies whether the specified enable execution order (that is, the specific enable execution order, or the preset enable execution order) can be successfully enabled, but also verifies whether other possible enable execution orders can be successfully enabled, thereby ensuring the comprehensiveness of the verification.

[0086] The random generation of multiple enable execution sequences for the different levels of enable protection includes:

[0087] Set the corresponding number for different levels of enabled protection;

[0088] The numbers corresponding to different levels of enabled protection are randomly assigned without replacement to determine the execution order of the various enabled protections.

[0089] For example, the execution order of ending the enable includes: level 1, level 2, and level 3; the specified execution order is: if written according to level 1, level 2, and level 3, then enable protection is turned on, otherwise it is turned off.

[0090] Assign a number to each of the Level 1, Level 2, and Level 3 enable protections. Then, perform a non-replacement randomization on these numbers (discard the numbers after randomization). Configure the corresponding enable protections after randomization and record the order. After all the numbers have been executed, check the execution order. If it meets the requirements, the enable configuration is successful; otherwise, the enable configuration fails.

[0091] The numbers corresponding to the different levels of enabled protection are unique identifiers used to identify each level of protection.

[0092] For example: Level 1 protection is numbered 1, Level 2 protection is numbered 2, and Level 3 protection is numbered 3.

[0093] These numbers are randomly selected without replacement to generate an execution order; for example, a random order [2,1,3] indicates that level 2 protection is executed first, then level 1 protection is executed, and finally level 3 protection is executed.

[0094] Configure and enable protection in a randomly generated order, and record the order; after all numbers have been executed, check whether the order meets the requirements of Level 1, Level 2, and Level 3; if the order is correct, the protection is enabled successfully; otherwise, the protection is enabled but fails.

[0095] For example, if the generation order is [1,2,3], the protection is enabled successfully; if the protection is enabled for other execution orders, it means that the protection mechanism is verified successfully.

[0096] In step S102, global LOCK mechanism and partial LOCK mechanism verification are performed to determine the LOCK verification result of the target chip; the partial LOCK mechanism is verified based on the state of randomly set LOCK control bits.

[0097] The effectiveness of the LOCK mechanism is fully verified by randomly setting the LOCK state and checking the corresponding LOCK control bit when performing operations.

[0098] Please refer to Figure 4 The verification of the global LOCK mechanism and the partial LOCK mechanism to determine the LOCK verification result of the target chip includes the following steps S401-S403:

[0099] S401. Set the target chip to a global LOCK state, and determine the global LOCK verification result of the target chip based on the first operation verification result of the memory unit of the target chip;

[0100] S402. Randomly set the LOCK control bit of at least one target memory cell partition to a locked state or an unlocked state, and determine the partial LOCK verification result of the target chip based on the second operation verification result of the target memory cell partition.

[0101] S403. Based on the global LOCK verification result and partial LOCK verification result of the target chip, determine the LOCK verification result of the target chip.

[0102] For a global lock mechanism, no operation can be performed if the lock is active. For a partial lock mechanism, verification is performed by checking whether the position of the operation to be performed corresponds to the lock bit. Specifically, for example... Figure 5 As shown, the LOCK control bit 501 corresponds to the Flash space 502. Therefore, by randomly selecting the LOCK control bit, and then checking the corresponding LOCK control bit during Flash operation, it can be determined whether to perform the operation.

[0103] The operation can be an erase or write operation.

[0104] Optionally, in some embodiments, the global lock verification result of the target chip is determined based on the operation verification result of the memory cells of the target chip, including:

[0105] Set the target chip to a global LOCK state and verify whether the memory unit of the target chip is unable to perform operations;

[0106] If so, confirm that the global lock verification result is normal.

[0107] Specifically, set a global lock state, attempt to perform programming or erasure operations, and verify whether the operation is rejected under the global lock state. If rejected, the global lock verification result is confirmed to be normal.

[0108] The partial lock verification results of the target chip are determined based on the second operation verification results of the target memory cell partition, including:

[0109] Verify whether the target storage unit partition can be operated on, and determine the execution result of the second operation corresponding to the target storage unit partition;

[0110] If the execution result of the second operation corresponding to the target storage unit partition matches the LOCK control bit status, the partial LOCK verification result is determined to be normal.

[0111] Here, verifying whether the target storage unit partition can perform an operation can also be referred to as verifying whether the target storage unit partition is allowed to perform an operation.

[0112] Specifically, the state (locked or unlocked) of each LOCK control bit is randomly set. When performing an operation, the state of the LOCK control bit corresponding to the operation address is checked. If the LOCK control bit is locked, the operation is rejected; otherwise, the operation is allowed. The execution result of the second operation corresponding to the target storage unit partition is determined to match the state of the LOCK control bit. If both match, the partial LOCK verification result is determined to be normal.

[0113] The verification method described in this application embodiment can cover a variety of possible LOCK configurations by randomly setting the LOCK state, verifying the comprehensiveness of the LOCK mechanism and ensuring that the memory can effectively reject illegal operations in the LOCK state.

[0114] Based on the global lock verification results and partial lock verification results of the target chip, the lock verification results of the target chip are determined, including:

[0115] If both the global LOCK verification result and the partial LOCK verification result of the target chip are normal, then the LOCK verification result of the target chip is determined to be normal.

[0116] The number of random tests performed on a subset of locks and the number of lock control bits in each test can be determined based on the storage size, the number of lock control bits, and the required test coverage.

[0117] In some embodiments, a reasonable number of tests can be determined based on statistical principles. For example, assuming the Flash space has N partitions, and each partition has two states (LOCK or not), then the total number of possible state combinations is 2^N. N Since it may be impractical to completely cover all combinations, a certain percentage of combinations (such as 90% or 95%) can be covered through random testing.

[0118] In some embodiments, a number of tests can typically be determined empirically; for example, for a medium-sized flash space (such as 16 partitions), 1,000 or more random tests can be performed.

[0119] In some embodiments, the number of random tests performed on a portion of the lock can be dynamically adjusted based on the verification results of the portion of the lock. Specifically, if a problem is found during the testing process and the verification result of the portion of the lock is abnormal, the verification is stopped, the abnormal situation is analyzed, and after code iteration, the simulation verification is repeated until there are no abnormalities.

[0120] In step S103, the target verification result of the firmware security mechanism is determined based on the enable protection verification result and the LOCK verification result.

[0121] The determination of the target verification result of the firmware security mechanism based on the enable protection verification result and the LOCK verification result includes:

[0122] If both the enable protection verification result and the LOCK verification result are normal, then the target verification result of the firmware security mechanism is determined to be normal.

[0123] Based on this, the firmware security mechanism verification method described in this application requires that the verification of the enabled protection be executed strictly in a specific order to ensure the correctness of the execution order, rather than simply verifying whether the enabled protection is turned on or off; the LOCK mechanism is divided into global LOCK and partial LOCK, and the protection mechanism of each area is verified by randomly setting the LOCK state, so as to perform detailed and comprehensive verification of the partition LOCK; in summary, based on randomly generated test cases (such as the execution order of enabled protection and random setting of LOCK state), more possibilities are covered, while traditional verification methods use fixed test cases to cover known boundary conditions and typical scenarios, which may not be able to cover all random cases, especially since they usually only cover known abnormal cases, which may not be able to cover all random abnormalities.

[0124] Based on the same inventive concept, this application also provides a firmware security mechanism verification device corresponding to the firmware security mechanism verification method. Since the principle of the device in this application is similar to the firmware security mechanism verification method described above in this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0125] Please refer to Figure 6 , Figure 6 This illustration shows a schematic diagram of the firmware security mechanism verification device according to an embodiment of this application. The device is designed for a target chip with a firmware security mechanism, which includes different levels of enable protection mechanisms and lock mechanisms. The lock mechanism includes a global lock mechanism and a partial lock mechanism. The partial lock mechanism includes multiple lock control bits, each corresponding to a memory unit partition. Figure 6 As shown, the verification device includes:

[0126] The first determining module 601 is used to randomly generate multiple enabling execution sequences for the different levels of enabling protection, and determine the enabling protection verification result of the target chip based on the multiple enabling execution sequences;

[0127] The second step involves determining module 602, which is used to perform global LOCK mechanism and partial LOCK mechanism verification to determine the LOCK verification result of the target chip; the partial LOCK mechanism is verified based on the state of randomly set LOCK control bits.

[0128] The third determining module 603 is used to determine the target verification result of the firmware security mechanism based on the enable protection verification result and the LOCK lock verification result.

[0129] In some embodiments, in the firmware security mechanism verification device, the first determining module, when randomly generating multiple enabling execution sequences of different levels of enabling protection and determining the enabling protection verification result of the target chip based on the multiple enabling execution sequences, is specifically used for:

[0130] Randomly generate multiple enable execution sequences for the different levels of enable protection;

[0131] Configure the enable for each enable execution order corresponding to the target chip, and determine the enable configuration result corresponding to each enable execution order;

[0132] Based on the enable configuration results corresponding to each enable execution order, the enable protection verification result of the target chip is determined.

[0133] In some embodiments, in the firmware security mechanism verification device, the first determining module, when determining the enabling configuration result corresponding to each enabling execution order, is specifically used for:

[0134] Determine whether the enable corresponding to this enable execution order has been configured successfully;

[0135] If so, determine that the enabling configuration result corresponding to this enabling execution order is a successful enabling configuration;

[0136] If not, the enable configuration result corresponding to this enable execution order is determined to be enable configuration failure.

[0137] In some embodiments, in the firmware security mechanism verification device, when the first determining module determines the enable protection verification result of the target chip based on the enable configuration result corresponding to each enable execution order, it is specifically used for:

[0138] Determine whether only the enable configuration result corresponding to the specified enable execution order is a successful enable configuration;

[0139] If so, the enable protection verification result of the target chip is determined to be effective.

[0140] In some embodiments, in the firmware security mechanism verification device, the first determining module, when randomly generating multiple enable execution sequences for different levels of enable protection, is specifically used for:

[0141] Set the corresponding number for different levels of enabled protection;

[0142] The numbers corresponding to different levels of enabled protection are randomly assigned without replacement to determine the execution order of the various enabled protections.

[0143] In some embodiments, in the firmware security mechanism verification device, the second determining module, when performing global LOCK mechanism and partial LOCK mechanism verification to determine the LOCK lock verification result of the target chip, is specifically used for:

[0144] The target chip is set to a global LOCK state, and the global LOCK verification result of the target chip is determined based on the first operation verification result of the memory cell of the target chip.

[0145] Randomly set the LOCK control bit of at least one target memory cell partition to a locked or unlocked state, and determine the partial LOCK verification result of the target chip based on the second operation verification result of the target memory cell partition;

[0146] Based on the global LOCK verification results and partial LOCK verification results of the target chip, the LOCK verification result of the target chip is determined.

[0147] In some embodiments, in the firmware security mechanism verification device, the second determining module, when determining the global LOCK verification result of the target chip based on the operation verification result of the target chip's memory unit, is specifically used for:

[0148] Set the target chip to a global LOCK state and verify whether the memory unit of the target chip is unable to perform operations;

[0149] If so, confirm that the global lock verification result is normal.

[0150] In some embodiments, in the firmware security mechanism verification device, the second determining module, when determining the partial LOCK verification result of the target chip based on the second operation verification result of the target storage unit partition, is specifically used for:

[0151] Verify whether the target storage unit partition can be operated on, and determine the execution result of the second operation corresponding to the target storage unit partition;

[0152] If the execution result of the second operation corresponding to the target storage unit partition matches the LOCK control bit status, the partial LOCK verification result is determined to be normal.

[0153] In some embodiments, the firmware security mechanism verification device, when determining the lock verification result of the target chip based on the global lock verification result and the partial lock verification result of the target chip, is specifically used for:

[0154] If both the global LOCK verification result and the partial LOCK verification result of the target chip are normal, then the LOCK verification result of the target chip is determined to be normal.

[0155] In some embodiments, in the firmware security mechanism verification device, the third determining module, when determining the target verification result of the firmware security mechanism based on the enable protection verification result and the LOCK lock verification result, is specifically used for:

[0156] If both the enable protection verification result and the LOCK verification result are normal, then the target verification result of the firmware security mechanism is determined to be normal.

[0157] Based on the same inventive concept, this application also provides an electronic device corresponding to the firmware security mechanism verification method. Since the principle of solving the problem by the electronic device in this application is similar to the firmware security mechanism verification method described above in this application, the implementation of the electronic device can refer to the implementation of the method, and the repeated parts will not be described again.

[0158] Please refer to Figure 7 , Figure 7 A schematic diagram of the structure of an electronic device according to an embodiment of this application is shown. The electronic device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of the firmware security mechanism verification method are performed.

[0159] Based on the same inventive concept, this application also provides an electronic device corresponding to a computer-readable storage medium. Since the principle of the computer-readable storage medium in this application is similar to the firmware security mechanism verification method described above in this application, the implementation of the computer-readable storage medium can refer to the implementation of the method, and the repeated parts will not be described again.

[0160] A computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the firmware security mechanism verification method.

[0161] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be through some communication interfaces; the indirect coupling or communication connection of devices or modules can be electrical, mechanical, or other forms.

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

[0163] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

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

[0165] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A firmware security mechanism verification method, characterized in that, The verification method targets a target chip with a well-designed firmware security mechanism, which includes different levels of enable protection mechanisms and a lock mechanism. The lock mechanism includes a global lock mechanism and a partial lock mechanism. The partial lock mechanism includes multiple lock control bits, each corresponding to a memory unit partition. The verification method includes the following steps: Multiple enable execution sequences for different levels of enable protection are randomly generated, and the enable protection verification result of the target chip is determined based on the multiple enable execution sequences. The global LOCK mechanism and partial LOCK mechanism are verified to determine the LOCK verification result of the target chip; the partial LOCK mechanism is verified based on the state of the randomly set LOCK control bits. The target verification result of the firmware security mechanism is determined based on the enable protection verification result and the LOCK verification result.

2. The firmware security mechanism verification method according to claim 1, characterized in that, The random generation of multiple enable execution sequences for different levels of enable protection, and the determination of the enable protection verification result of the target chip based on these multiple enable execution sequences, includes: Randomly generate multiple enable execution sequences for the different levels of enable protection; Configure the enable for each enable execution order corresponding to the target chip, and determine the enable configuration result corresponding to each enable execution order; Based on the enable configuration results corresponding to each enable execution order, the enable protection verification result of the target chip is determined.

3. The firmware security mechanism verification method according to claim 2, characterized in that, The determination of the enable configuration result corresponding to each enable execution order includes: Determine whether the enable corresponding to this enable execution order has been configured successfully; If so, determine that the enabling configuration result corresponding to this enabling execution order is a successful enabling configuration; If not, the enable configuration result corresponding to this enable execution order is determined to be enable configuration failure.

4. The firmware security mechanism verification method according to claim 2 or 3, characterized in that, The determination of the enable protection verification result of the target chip based on the enable configuration result corresponding to each enable execution order includes: Determine whether only the enable configuration result corresponding to the specified enable execution order is a successful enable configuration; If so, the enable protection verification result of the target chip is determined to be effective.

5. The firmware security mechanism verification method according to claim 1, characterized in that, The random generation of multiple enable execution sequences for the different levels of enable protection includes: Set the corresponding number for different levels of enabled protection; The numbers corresponding to different levels of enabled protection are randomly assigned without replacement to determine the execution order of the various enabled protections.

6. The firmware security mechanism verification method according to claim 1, characterized in that, The verification of the global and partial lock mechanisms to determine the lock verification result of the target chip includes: The target chip is set to a global LOCK state, and the global LOCK verification result of the target chip is determined based on the first operation verification result of the memory cell of the target chip. Randomly set the LOCK control bit of at least one target memory cell partition to a locked or unlocked state, and determine the partial LOCK verification result of the target chip based on the second operation verification result of the target memory cell partition; Based on the global LOCK verification results and partial LOCK verification results of the target chip, the LOCK verification result of the target chip is determined.

7. The firmware security mechanism verification method according to claim 6, characterized in that, The global lock verification result of the target chip is determined based on the operational verification results of the memory cells of the target chip, including: Set the target chip to a global LOCK state and verify whether the memory unit of the target chip is unable to perform operations; If so, confirm that the global lock verification result is normal.

8. The firmware security mechanism verification method according to claim 6 or 7, characterized in that, The partial lock verification results of the target chip are determined based on the second operation verification results of the target memory cell partition, including: Verify whether the target storage unit partition can be operated on, and determine the execution result of the second operation corresponding to the target storage unit partition; If the execution result of the second operation corresponding to the target storage unit partition matches the LOCK control bit status, the partial LOCK verification result is determined to be normal.

9. The firmware security mechanism verification method according to claim 6, characterized in that, Based on the global lock verification results and partial lock verification results of the target chip, the lock verification results of the target chip are determined, including: If both the global LOCK verification result and the partial LOCK verification result of the target chip are normal, then the LOCK verification result of the target chip is determined to be normal.

10. The firmware security mechanism verification method according to claim 1, characterized in that, The determination of the target verification result of the firmware security mechanism based on the enable protection verification result and the LOCK verification result includes: If both the enable protection verification result and the LOCK verification result are normal, then the target verification result of the firmware security mechanism is determined to be normal.

11. A firmware security mechanism verification device, characterized in that, The verification device is designed for a target chip with a firmware security mechanism, which includes different levels of enable protection mechanisms and a lock mechanism; the lock mechanism includes a global lock mechanism and a partial lock mechanism; the partial lock mechanism includes multiple lock control bits, each lock control bit corresponding to a memory unit partition; the verification device includes: The first determining module is used to randomly generate multiple enabling execution sequences for the different levels of enabling protection, and determine the enabling protection verification result of the target chip based on the multiple enabling execution sequences; The second step determines the module, which is used to verify the global LOCK mechanism and the partial LOCK mechanism, and to determine the LOCK verification result of the target chip; the partial LOCK mechanism is verified based on the state of the randomly set LOCK control bits. The third determining module is used to determine the target verification result of the firmware security mechanism based on the enable protection verification result and the LOCK verification result.

12. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of the firmware security mechanism verification method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the firmware security mechanism verification method as described in any one of claims 1 to 10.

Citation Information

Patent Citations

  • Verification method for shared storage multicore multithreading processor hardware lock

    CN102708090A

  • Method and device for function security verification, and computer readable storage medium

    CN117709249A