Verification method and device for TrustZone function of chip and electronic equipment
The UVM program and C program interaction within an electronic device simplifies and enhances the verification of TrustZone functions in IC chips by automating file construction and separate secure/non-secure world verification, addressing inefficiencies and inaccuracies in existing methods.
Patent Information
- Application Number
- CN202411270437.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-11
- Publication Date
- 2024-12-13
AI Technical Summary
The verification of the TrustZone function in IC chips is inefficient and prone to inaccuracies due to its tight coupling with software, leading to confusion and omissions in permission control logic, which complicates the verification process.
A method and device utilizing a UVM program and C program interaction within an electronic device to simulate and verify the TrustZone function, enabling separate configuration and data transmission for secure and non-secure worlds, with automated construction of verification files and standardized UVM program interactions.
Improves the efficiency and accuracy of TrustZone function verification by simplifying file construction and reducing confusion between secure and non-secure world permissions, ensuring thorough verification of chip functions.
Smart Images
Figure CN119129496A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of IC chip verification technology, for example, to a verification method and device, and electronic equipment for the TrustZone function of a chip. Background Art
[0002] At present, in order to cope with the increasingly frequent chip attacks, the TrustZone function has been introduced into the chip. The TrustZone function divides the chip's central processor into two independently running environments: the secure world and the non-secure world, achieving comprehensive hardware isolation from the kernel to the chip level. This design allows sensitive data and critical operations to be protected in the secure world, while ordinary applications run in the non-secure world, effectively preventing unauthorized access and malicious tampering.
[0003] Since the TrustZone function is part of the chip's security solution, it is necessary to verify the TrustZone function in the chip design before producing the chip.
[0004] However, due to the tight coupling between the TrustZone function and the software level, its verification work usually needs to be carried out after the chip's software function design is completed, which results in a tight time for verifying the chip's TrustZone function. In addition, the TrustZone function involves complex permission control logic. If the TrustZone function is verified in a collaborative way to improve verification efficiency, it is very easy to cause confusion between the permissions of the secure world and the non-secure world and omissions in verification, resulting in low accuracy of the verification results of the TrustZone function. Therefore, there is an urgent need for a technical solution that can efficiently and accurately verify the TrustZone function of the chip.
[0005] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of the present application, and therefore may include information that does not constitute the prior art known to ordinary technicians in the field. Summary of the invention
[0006] In order to provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. The summary is not an extensive review, nor is it intended to identify key / critical elements or delineate the scope of protection of these embodiments, but rather serves as a prelude to the detailed description that follows.
[0007] The embodiments of the present disclosure provide a method and device for verifying the TrustZone function of a chip, and an electronic device, which can improve the efficiency and accuracy of verifying the TrustZone function of the chip.
[0008] In some embodiments, a verification method for the TrustZone function of a chip is applied to an electronic device. The verification method is implemented by running a chip verification environment in the electronic device. The chip verification environment is deployed with a UVM program and a chip to be tested. The chip to be tested is a code file simulated based on a chip design scheme. The verification method includes: receiving first configuration information and constructing a verification file; after the chip to be tested is powered on, loading the verification file into a C program of the chip to be tested; receiving second configuration information, and according to the second configuration information, enabling the UVM program to perform data transmission interaction with the C program for multiple verification items, and obtaining verification response information fed back by the C program; and confirming the verification result of the TrustZone function of the chip to be tested according to the verification response information.
[0009] Optionally, the second configuration information includes secure world configuration information and non-secure world configuration information, and the verification response information includes first response information and second response information; according to the second configuration information, the UVM program and the C program are enabled to perform data transmission interaction for multiple verification projects, and verification response information fed back by the C program is obtained, including: when the C program runs in a secure world environment, the UVM program is enabled to perform data transmission interaction for multiple verification projects with the C program according to the secure world configuration information, and first response information for each verification project is obtained; when the C program runs in a non-secure world environment, the UVM program is enabled to perform data transmission interaction for multiple verification projects with the C program according to the non-secure world configuration information, and second response information for each verification project is obtained.
[0010] Optionally, the secure world configuration information includes the first loop number of each verification project; enabling the UVM program to perform data transmission interaction for multiple verification projects with the C program according to the secure world configuration information to obtain the first response information of each verification project, including: enabling the UVM program to send security verification data corresponding to the current verification project to the C program multiple times according to the first loop number of the current verification project, so that the C program executes the security verification data multiple times and feeds back the response information each time to obtain the first response information of the current verification project; after obtaining the first response information of all verification projects, ending the data transmission interaction between the UVM program and the C program in the secure world environment.
[0011] Optionally, after the data transmission interaction between the UVM program and the C program in the secure world environment is completed, the verification method further includes: sending a switching instruction to the C program so that the C program switches to the non-secure world environment for execution.
[0012] Optionally, the non-secure world configuration information includes the second loop number of each verification project; the UVM program is enabled to perform data transmission interaction for multiple verification projects with the C program according to the non-secure world configuration information to obtain second response information for each verification project, including: enabling the UVM program to send non-secure verification data corresponding to the current verification project to the C program multiple times according to the second loop number of the current verification project, so that the C program executes the non-secure verification data multiple times and feeds back the response information each time to obtain the second response information of the current verification project; after obtaining the second response information of all verification projects, the data transmission interaction between the UVM program and the C program in the non-secure world environment is terminated.
[0013] Optionally, the secure world configuration information further includes a first exception expected value, and the non-secure world configuration information further includes a second exception expected value; when the C program runs the Secure Fault handling function, the first exception expected value and the second exception expected value are both 1.
[0014] Optionally, the verification result of the TrustZone function of the chip under test is confirmed according to the verification response information, including: when the first response information of each verification item meets the requirements of the corresponding verification item, confirming that the secure world of the TrustZone function of the chip under test has passed the verification; when the second response information of each verification item meets the requirements of the corresponding verification item, confirming that the non-secure world of the TrustZone function of the chip under test has passed the verification.
[0015] Optionally, the first configuration information includes the interrupt vector table address of the secure world code and the non-secure world code, the first requirement information of the secure world code and the second requirement information of the non-secure world code; the first configuration information is received, and a verification file is constructed, including: generating the secure world code according to the first requirement information to obtain a first ROM file; generating the non-secure world code according to the second requirement information, and moving the NSC lib library in the first ROM file to the non-secure world code to obtain a second ROM file; and integrating the first ROM file and the second ROM file into a verification file according to the interrupt vector table address.
[0016] In some embodiments, a verification device for the TrustZone function of a chip includes a processor and a memory storing program instructions, and the processor is configured to execute the verification method for the TrustZone function of the chip as described above when running the program instructions.
[0017] In some embodiments, an electronic device includes: a device body; and a verification device for the TrustZone function of a chip as described above, installed in the device body.
[0018] The TrustZone verification method, device, and electronic device provided in the embodiments of the present disclosure can achieve the following technical effects: In the disclosed embodiment, the electronic device can automatically construct a verification file for loading the C program of the chip to be tested, only the verification personnel need to input the first configuration information, which simplifies the work of the verification personnel in writing the verification file. In this way, the efficiency of verifying the TrustZone function of the chip is improved. In the disclosed embodiment, the TrustZone function verification is performed by using the UVM program in the chip verification environment of the electronic device to interact with the C program of the chip to be tested for data transmission. The standardization advantages of the UVM program and the underlying implementation advantages of the C program can be fully utilized, and the behaviors of the secure world and the non-secure world of the TrustZone function can be accurately simulated. Compared with the method of multi-person collaboration, this method can avoid the problems of confusion of permissions and omissions in verification of the secure world and non-secure world of the TrustZone function during verification. In this way, the accuracy of verifying the TrustZone function of the chip is improved.
[0019] The above general description and the following description are exemplary and explanatory only and are not intended to limit the present application. BRIEF DESCRIPTION OF THE DRAWINGS
[0020] One or more embodiments are exemplarily described by corresponding drawings, which do not limit the embodiments. Elements with the same reference numerals in the drawings are shown as similar elements, and the drawings do not constitute a scale limitation, and wherein: Figure 1 is a schematic diagram of an electronic device provided by an embodiment of the present disclosure; Figure 2 is a schematic diagram of a verification method for a TrustZone function of a chip provided by an embodiment of the present disclosure; Figure 3 is a schematic diagram of another verification method for the TrustZone function of a chip provided by an embodiment of the present disclosure; Figure 4 It is a schematic diagram of data transmission interaction between a UVM program and a C program provided by an embodiment of the present disclosure; Figure 5 is a schematic diagram of a verification device for a TrustZone function of a chip provided by an embodiment of the present disclosure; Figure 6 It is a schematic diagram of another verification device for the TrustZone function of a chip provided by an embodiment of the present disclosure. DETAILED DESCRIPTION
[0021] In order to be able to understand the features and technical contents of the embodiments of the present disclosure in more detail, the implementation of the embodiments of the present disclosure is described in detail below in conjunction with the accompanying drawings. The attached drawings are for reference only and are not used to limit the embodiments of the present disclosure. In the following technical description, for the convenience of explanation, a full understanding of the disclosed embodiments is provided through multiple details. However, one or more embodiments can still be implemented without these details. In other cases, to simplify the drawings, well-known structures and devices can be simplified for display.
[0022] The terms "first", "second", etc. in the specification and claims of the embodiments of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the terms used in this way can be interchanged where appropriate, so that the embodiments of the embodiments of the present disclosure described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions.
[0023] Unless otherwise stated, the term "plurality" of a feature means two or more.
[0024] In the embodiment of the present disclosure, the character " / " feature indicates that the preceding and following objects are in an "or" relationship. For example, the A / B feature indicates: A or B.
[0025] The term "and / or" is a description of the association relationship between objects, and the characteristic indicates that there can be three relationships. For example, A and / or B, the characteristic indicates: A or B, or, A and B.
[0026] The term "correspondence" may refer to an association relationship or a binding relationship. The correspondence between A and B means that there is an association relationship or a binding relationship between A and B.
[0027] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present disclosure may be combined with each other.
[0028] In the embodiment of the present disclosure, the verification method for the TrustZone function of the chip is applied to Figure 1 The electronic device 100 with UVM program deployed therein is shown. Figure 1 As shown, the electronic device 100 includes a device body 110 and a verification device 500 (600) for the TrustZone function of a chip.
[0029] Specifically, a chip verification environment is provided in the electronic device 100 , and a UVM program and a chip to be tested are deployed in the chip verification environment. The UVM program and the C program of the chip to be tested can perform data transmission interaction.
[0030] Specifically, the UVM program is a System Verilog (SV) program deployed based on UVM (Universal Verification Methodology). The chip to be tested is a code file simulated based on the chip design scheme, and an executable C program is deployed in the code file, which is used to simulate various functions of the chip.
[0031] Specifically, the verification device 500 ( 600 ) for the TrustZone function of the chip is installed in the device body 110 .
[0032] Optionally, the verification device 600 for the TrustZone function of the chip includes a processor, and the processor can automatically construct a verification file according to the received first configuration information. After the chip to be tested is powered on, the constructed verification file can be loaded into the C program of the chip to be tested. The processor can make the UVM program and the C program perform data transmission interaction for multiple verification items according to the received second configuration information, and obtain the verification response information fed back by the C program. The verification response information that the processor can obtain confirms the result of the verification of the TrustZone function of the chip to be tested.
[0033] In combination with the above electronic device, the embodiment of the present disclosure provides a verification method for the TrustZone function of a chip, such as Figure 2 As shown, the verification method includes: S201: The processor receives first configuration information and constructs a verification file.
[0034] Specifically, the verification file is a ROM (Read-Only Memory) file used to build the TrustZone function in the C program of the chip under test.
[0035] Specifically, the ROM file of the TrustZone function includes two sets of codes, the secure world and the non-secure world, and the first configuration information refers to the configuration information that specifies the interrupt vector table addresses of the two sets of codes, the functions required for the secure world and the functions required for the non-secure world. Therefore, before building the verification file, it is necessary to receive the first configuration information.
[0036] Specifically, the electronic device is provided with a GCC (GNU Compiler Collection) compiler, and the GCC compiler is preset with a TCL standard script that can compile two sets of codes, the secure world and the non-secure world, according to the first configuration information. Therefore, after receiving the first configuration information, the processor can build a verification file by calling the GCC compiler.
[0037] S202 , after the chip under test is powered on, the processor loads the verification file into the C program of the chip under test.
[0038] Specifically, it is understandable that the download detection program for identifying files in the chip under test allows the chip under test to identify whether there are new files to be downloaded or updated only after power-on is completed. And if the verification file is loaded when the chip under test is not fully powered on or is in an unstable state, the verification file received by the chip under test may be damaged, which will affect the subsequent verification of the TrustZone function of the chip. Therefore, it is necessary to load the verification file into the C program of the chip under test after confirming that the chip under test has been powered on.
[0039] S203, the processor receives the second configuration information, and enables the UVM program to perform data transmission interaction of multiple verification items with the C program according to the second configuration information, and obtains verification response information fed back by the C program.
[0040] Specifically, the UVM (Universal Verification Methodology) program is a tool deployed inside an electronic device to build a verification environment and verification data, and can perform data transmission interaction for multiple verification projects with the C program of the chip under test based on the verification data it generates.
[0041] Specifically, in the disclosed embodiment, a set of verification sequences are predefined in the UVM program, which includes a series of verification steps or operations, which are designed to verify the TrustZone function of the chip by interacting with the C program. Specifically, the verification sequence can provide a reusable and inheritable verification framework, and the verification personnel can complete the TrustZone function by changing the corresponding parameters according to the verification requirements without having an in-depth and comprehensive understanding of the entire verification process. In this way, even less experienced verification personnel can quickly carry out the verification of the TrustZone function, which can save a lot of verification time.
[0042] Specifically, the second configuration information is information for guiding the UVM program to adjust the verification steps or operations in the verification sequence. Therefore, the UVM program and the C program can perform data transmission interaction for multiple verification items according to the second configuration information.
[0043] Optionally, the second configuration information may include but is not limited to: Verification project parameters: specific indicators of the verification project, the scope of verification data, verification duration, etc. Data transmission protocol: the format, rate, verification method, etc. of data transmission between the UVM program and the C program. Error handling and exception management: the processing strategy when encountering errors or abnormal situations during the verification process, such as retry mechanism, fault report generation, etc.
[0044] Specifically, verification items refer to the content that needs to be verified for the secure world and non-secure world in the TrustZone function. For example, secure storage verification, secure encryption verification, and secure isolation verification for the secure world. Another example is stability verification and compatibility verification for the non-secure world.
[0045] S204: The processor confirms the verification result of the TrustZone function of the chip under test according to the verification response information.
[0046] Specifically, the verification response information fed back by the C program is feedback data generated after the C program executes the verification data sent by the UVM program according to the second configuration information. According to these feedback data, the performance of the C program in each verification project can be clearly understood, and the various functions of the secure world and the non-secure world of the TrustZone function can be judged whether they can be normally executed according to the performance. Therefore, the processor can confirm the verification result of the TrustZone function of the chip to be tested according to the verification response information.
[0047] In the disclosed embodiment, the electronic device can automatically construct a verification file for loading the C program of the chip to be tested, only the verification personnel need to input the first configuration information, which simplifies the work of the verification personnel in writing the verification file. In this way, the efficiency of verifying the TrustZone function of the chip is improved. In the disclosed embodiment, the TrustZone function verification is performed by using the UVM program in the chip verification environment of the electronic device to interact with the C program of the chip to be tested for data transmission. The standardization advantages of the UVM program and the underlying implementation advantages of the C program can be fully utilized, and the behaviors of the secure world and the non-secure world of the TrustZone function can be accurately simulated. Compared with the method of multi-person collaboration, this method can avoid the problems of confusion of permissions and omissions in verification of the secure world and non-secure world of the TrustZone function during verification. In this way, the accuracy of verifying the TrustZone function of the chip is improved.
[0048] In the embodiment of the present disclosure, the second configuration information includes the secure world configuration information and the non-secure world configuration information, and the verification response information includes the first response information and the second response information. The embodiment of the present disclosure provides another verification method for the TrustZone function of a chip, such as Figure 3 As shown, the verification method includes: S301: The processor receives first configuration information and constructs a verification file.
[0049] S302 , after the chip under test is powered on, the processor loads the verification file into the C program of the chip under test.
[0050] S303: The processor receives second configuration information, where the second configuration information includes secure world configuration information and non-secure world configuration information, and the verification response information includes first response information and second response information.
[0051] Specifically, the secure world configuration information is information that needs to be configured when verifying various functions of the secure world of the TrustZone function, for example, the number of verifications for each verification item of the secure world.
[0052] Specifically, the non-secure world configuration information is information that needs to be configured when verifying various functions of the non-secure world of the TrustZone function, for example, the number of times each verification item of the non-secure world is verified.
[0053] S304, when the C program runs in the secure world environment, the UVM program is enabled to perform data transmission interaction of multiple verification items with the C program according to the secure world configuration information to obtain the first response information of each verification item.
[0054] Specifically, when the C program runs in the secure world environment, it indicates that the permissions of the TrustZone function are divided in the secure world. In this case, the C program runs the secure world code in the verification file. Therefore, in this case, it is necessary to make the UVM program perform data transmission interaction with the C program for multiple verification items according to the secure world configuration information to verify the various functions of the secure world of the TrustZone function.
[0055] Optionally, the secure world configuration information includes the first loop number of each verification project; enabling the UVM program to perform data transmission interaction for multiple verification projects with the C program according to the secure world configuration information to obtain the first response information of each verification project, including: enabling the UVM program to send security verification data corresponding to the current verification project to the C program multiple times according to the first loop number of the current verification project, so that the C program executes the security verification data multiple times and feeds back the response information each time to obtain the first response information of the current verification project; after obtaining the first response information of all verification projects, ending the data transmission interaction between the UVM program and the C program in the secure world environment.
[0056] Specifically, in order to ensure the accuracy of the verification results of each function of the secure world, the embodiment of the present disclosure sets the number of verifications required (ie, the first cycle number) for each verification item of the secure world.
[0057] Specifically, each time the UVM program sends the security verification data corresponding to the current verification project to the C program, the security verification data is written to the first storage address bit in the memory RAM of the chip to be tested. After the security verification data is written to the first storage address bit, a first start flag (such as 0x7777) is sent to the first flag address bit. After the C program recognizes that there is a first start flag in the flag address bit, it reads the security verification data from the first storage address bit.
[0058] Specifically, each time the C program finishes reading the security verification data, it will generate the response data for the current verification item, and write the response data to the second storage address bit in the memory RAM of the chip under test. After writing the response data to the second storage address bit, a first end flag (such as 0x8888) will be sent to the first flag address bit. After the C program recognizes that there is a first end flag in the first flag address bit, it will read the response data for each verification of the current verification item from the second storage address bit.
[0059] Optionally, the first flag address bit should be a relatively stable and easily identifiable address bit in the storage area corresponding to the secure world in the memory RAM, for example, the address bit 0x0000-0x0001.
[0060] For example, Figure 4 In the data transmission interaction process between the UVM program and the C program shown, the first storage address bit is 0x0012-0x0112, and the second storage address bit is 0x0002-0x0003.
[0061] Optionally, after the data transmission interaction between the UVM program and the C program in the secure world environment is completed, the verification method further includes: sending a switching instruction to the C program so that the C program switches to the non-secure world environment for execution.
[0062] Specifically, after the data transmission interaction between the UVM program and the C program in the secure world environment is completed, that is, after the UVM program and the C program complete the verification of various functions of the secure world through data transmission interaction, the processor will send a switching instruction to the C program through the UVM program to switch the C program to run in the non-secure world environment, so as to facilitate subsequent verification of various functions of the non-secure world.
[0063] Specifically, the UVM program may send a switching instruction to the C program by sending a switching flag (such as 0x1111) to the first flag address bit.
[0064] S305, when the C program runs in the non-secure world environment, the processor enables the UVM program to perform data transmission interaction for multiple verification items with the C program according to the non-secure world configuration information, and obtain second response information for each verification item.
[0065] Specifically, when the C program runs in the non-secure world environment, it indicates that the permissions of the TrustZone function are divided in the non-secure world. In this case, the C program runs the non-secure world code in the verification file. Therefore, in this case, it is necessary to make the UVM program perform data transmission interaction of multiple verification items with the C program according to the non-secure world configuration information to verify the various functions of the non-secure world of the TrustZone function.
[0066] Optionally, the non-secure world configuration information includes the second loop number of each verification project; the UVM program is enabled to perform data transmission interaction for multiple verification projects with the C program according to the non-secure world configuration information to obtain second response information for each verification project, including: enabling the UVM program to send non-secure verification data corresponding to the current verification project to the C program multiple times according to the second loop number of the current verification project, so that the C program executes the non-secure verification data multiple times and feeds back the response information each time to obtain the second response information of the current verification project; after obtaining the second response information of all verification projects, the data transmission interaction between the UVM program and the C program in the non-secure world environment is terminated.
[0067] Specifically, in order to ensure the accuracy of the verification results of each function of the non-secure world, the embodiment of the present disclosure sets the number of verifications required (ie, the second cycle number) for each verification item of the non-secure world.
[0068] Specifically, each time the UVM program sends the non-safety verification data corresponding to the current verification project to the C program, the non-safety verification data is written to the third storage address bit in the memory RAM of the chip to be tested. After the safety verification data is written to the third storage address bit, a second start flag (such as 0xaaaa) is sent to the second flag address bit. After the C program recognizes that there is a second start flag in the second flag address bit, it reads the non-safety verification data from the third storage address bit.
[0069] Specifically, each time the C program finishes reading the non-security verification data, it will generate the response data for the current verification item, and write the response data to the fourth storage address bit in the memory RAM of the chip under test. After writing the response data to the fourth storage address bit, a second end flag (such as 0x5555) will be sent to the second flag address bit. After the C program recognizes that there is a second end flag in the first flag address bit, it will read the response data for each verification of the current verification item from the fourth storage address bit.
[0070] Optionally, the second flag address bit should be a relatively stable and easily identifiable address bit in the storage area corresponding to the non-secure world in the memory RAM, for example, the address bit 0x1000-0x1001.
[0071] For example, Figure 4 In the data transmission interaction process between the UVM program and the C program shown, the third storage address bit is 0x1012-0x1112, and the fourth storage address bit is 0x1002-0x1003.
[0072] S306: The processor confirms the verification result of the TrustZone function of the chip under test according to the first response information and the second response information.
[0073] Specifically, the performance of the C program in each verification item when running in the secure world can be clarified according to the first response information, and whether the various functions of the secure world of the TrustZone function can be executed normally can be judged according to the performance. The performance of the C program in each verification item when running in the non-secure world can be clarified according to the second response information, and whether the various functions of the non-secure world of the TrustZone function can be executed normally can be judged according to the performance. Therefore, the processor can confirm the verification result of the TrustZone function of the chip under test according to the first response information and the second response information.
[0074] Optionally, when the first response information of each verification item meets the requirements of the corresponding verification item, it is confirmed that the security world of the TrustZone function of the chip under test has passed the verification.
[0075] Specifically, if the first response information of each verification item meets the requirements of the corresponding verification item, it indicates that each function of the secure world of the TrustZone function can be executed normally. Therefore, in this case, it can be confirmed that the secure world of the TrustZone function of the chip under test has passed the verification.
[0076] Optionally, when the second response information of each verification item meets the requirements of the corresponding verification item, it is confirmed that the non-secure world of the TrustZone function of the chip under test has passed the verification.
[0077] Specifically, if the second response information of each verification item meets the requirements of the corresponding verification item, it indicates that each function of the non-secure world of the TrustZone function can be executed normally. Therefore, in this case, it can be confirmed that the non-secure world of the TrustZone function of the chip under test has passed the verification.
[0078] In the disclosed embodiment, targeted verification is performed on the secure world and non-secure world of the TrustZone function respectively, reducing the risk of confusion between the secure world and non-secure world permissions of the TrustZone function during verification and improving the accuracy of verification of the TrustZone function of the chip.
[0079] In some embodiments, the secure world configuration information further includes a first exception expected value, and the non-secure world configuration information further includes a second exception expected value; when the C program runs the Secure Fault handling function, the first exception expected value and the second exception expected value are both 1.
[0080] Specifically, the Secure Fault processing function is a processing function for processing specific faults or exceptions in the secure world and the non-secure world of the TrustZone function.
[0081] Specifically, in the secure world, the chip is expected to be able to resist various security threats and attacks, and in the non-secure world, the chip expects the system to be able to run stably. When the C program runs the Secure Fault handler, the Secure Fault handler is being verified, but in this case, the chip may mistakenly determine that there is an exception in the Secure Fault handler of the TrustZone function, preventing the C program from continuing to run, resulting in the inability to perform subsequent verification. Therefore, in the embodiment of the present disclosure, a first exception expected value and a second exception expected value are set, and when the C program runs the Secure Fault handler, the first exception expected value and the second exception expected value are set to 1, so that the chip will not judge the verification of running the Secure Fault handler as an exception.
[0082] In some embodiments, the first configuration information includes the interrupt vector table address of the secure world code and the non-secure world code, the first requirement information of the secure world code and the second requirement information of the non-secure world code; the first configuration information is received and a verification file is constructed, including: generating the secure world code according to the first requirement information to obtain a first ROM file; generating the non-secure world code according to the second requirement information, and moving the NSC lib library in the first ROM file to the non-secure world code to obtain a second ROM file; integrating the first ROM file and the second ROM file into a verification file according to the interrupt vector table address.
[0083] Specifically, the first requirement information specifies the functions that the secure world code should have, and the GCC compiler has preset standard codes with different functions. Therefore, the secure world code can be generated by integrating the standard codes with the specified functions according to the first requirement information, thereby obtaining the first ROM file.
[0084] Specifically, the generated secure world code is a hex file, which the GCC compiler automatically converts into a ROM file.
[0085] Specifically, the second requirement information specifies the functions that the code of the non-secure world should have, and the GCC compiler has preset standard codes with different functions. Therefore, the non-secure world code can be generated by integrating the standard codes of the specified functions according to the second requirement information, thereby obtaining the second ROM file.
[0086] Specifically, the generated non-secure world code is a hex file, which the GCC compiler automatically converts into a ROM file.
[0087] Specifically, the TrustZone function provides the non-secure callable permission (NSC) for the non-secure world. The NSC permission is the only springboard for the non-secure world to access the secure world. When a secure function needs to be executed in the non-secure world, the non-secure world code can only jump to the NSC permission area first, and then jump to the corresponding secure function in the corresponding secure world through a jump instruction for execution. The NSC lib library is a library that specifies the secure functions that can be jumped. Therefore, when building the non-secure world code, the NSC lib library needs to be moved to the non-secure world code.
[0088] Specifically, the interrupt vector table addresses of the secure world code and the non-secure world code refer to the interrupt processing paths that isolate the secure world code and the non-secure world code. Therefore, the first ROM file and the second ROM file can be integrated into a verification file based on the interrupt vector table address.
[0089] In the disclosed embodiment, the electronic device can automatically construct a verification file for loading the C program of the chip to be tested, as long as the verification personnel inputs the first configuration information, thereby simplifying the verification personnel's work of writing the verification file. In this way, the efficiency of verifying the TrustZone function of the chip can be improved.
[0090] Combination Figure 5As shown, the embodiment of the present disclosure provides a verification device 500 for the TrustZone function of a chip, which is applied to an electronic device, in which a chip verification environment is deployed, and the chip verification environment is deployed with a UVM program and a chip to be tested, and the chip to be tested is a code file simulated based on a chip design scheme, including: a construction module 501, a loading module 502, an interaction module 503 and a confirmation module 504. The construction module 501 is configured to receive first configuration information and build a verification file. The loading module 502 is configured to load the verification file into the C program of the chip to be tested after the chip to be tested is powered on. The interaction module 503 is configured to receive second configuration information, and according to the second configuration information, the UVM program and the C program perform data transmission interaction of multiple verification items, and obtain verification response information fed back by the C program. The confirmation module 504 is configured to confirm the verification result of the TrustZone function of the chip to be tested according to the verification response information.
[0091] Combination Figure 6 As shown, an embodiment of the present disclosure provides a verification device 600 for the TrustZone function of a chip, including: a processor (processor) 601 and a memory (memory) 602. Optionally, the device may also include a communication interface (Communication Interface) 603 and a bus 604. Among them, the processor 601, the communication interface 603, and the memory 602 can communicate with each other through the bus 604. The communication interface 603 can be used for information transmission. The processor 601 can call the logic instructions in the memory 602 to execute the verification method for the TrustZone function of the chip of the above embodiment.
[0092] In addition, the logic instructions in the memory 602 described above may be implemented in the form of software functional units and when sold or used as independent products, may be stored in a computer-readable storage medium.
[0093] The memory 602 is a computer-readable storage medium that can be used to store software programs and computer executable programs, such as program instructions / modules corresponding to the method in the embodiment of the present disclosure. The processor 601 executes the functional application and data processing by running the program instructions / modules stored in the memory 602, that is, the verification method for the TrustZone function of the chip in the above embodiment is implemented.
[0094] The memory 602 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and an application required for at least one function; the data storage area may store data created according to the use of the terminal device, etc. In addition, the memory 602 may include a high-speed random access memory and may also include a non-volatile memory.
[0095] An embodiment of the present disclosure provides a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured to execute the above-mentioned verification method for the TrustZone function of a chip.
[0096] The technical solution of the embodiment of the present disclosure can be embodied in the form of a software product, which is stored in a storage medium and includes one or more instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in the embodiment of the present disclosure. The aforementioned storage medium may be a non-transient storage medium, such as: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, and other media that can store program codes.
[0097] The above description and the accompanying drawings fully illustrate the embodiments of the present disclosure so that those skilled in the art can practice them. Other embodiments may include structural, logical, electrical, process and other changes. The embodiments represent only possible changes. Unless explicitly required, separate components and functions are optional, and the order of operations may vary. Parts and features of some embodiments may be included in or replace parts and features of other embodiments. Moreover, the words used in this application are only used to describe the embodiments and are not used to limit the claims. As used in the description of the embodiments and the claims, unless the context clearly indicates, the singular forms of "a", "an" and "the" are intended to include plural forms as well. Similarly, the term "and / or" as used in this application refers to any and all possible combinations of one or more associated listings. In addition, when used in this application, the term "comprise" and its variants "comprises" and / or comprising refer to the presence of stated features, wholes, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or groups thereof. In the absence of further restrictions, the elements defined by the sentence "including one..." do not exclude the presence of other identical elements in the process, method or device including the elements. In this article, each embodiment may focus on the differences from other embodiments, and the same and similar parts between the embodiments may refer to each other. For the methods, products, etc. disclosed in the embodiments, if they correspond to the method part disclosed in the embodiments, then the relevant parts can refer to the description of the method part.
[0098] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software may depend on the specific application and design constraints of the technical solution. The technicians may use different methods for each specific application to implement the described functions, but such implementations should not be considered to exceed the scope of the embodiments of the present disclosure. The technicians may clearly understand that, for the convenience and simplicity of description, the specific working processes of the systems, devices and units described above may refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here.
[0099] In the embodiments disclosed herein, the disclosed methods and products (including but not limited to devices, equipment, etc.) can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units can be only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between each other shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms. The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to implement this embodiment. In addition, each functional unit in the embodiment of the present disclosure may be integrated in a processing unit, or each unit may exist physically alone, or two or more units may be integrated in one unit.
[0100] The flowchart and block diagram in the accompanying drawings show the possible architecture, function and operation of the system, method and computer program product according to the embodiment of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of the code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. In some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, which can depend on the functions involved. In the description corresponding to the flowchart and the block diagram in the accompanying drawings, the operations or steps corresponding to different boxes can also occur in a different order from the order disclosed in the description, and sometimes there is no specific order between different operations or steps. For example, two consecutive operations or steps can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, which can depend on the functions involved. Each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified functions or actions, or may be implemented by a combination of dedicated hardware and computer instructions.
Claims
1. A verification method for the TrustZone function of a chip, applied to electronic equipment, characterized in that: The verification method is implemented by running a chip verification environment in an electronic device. The chip verification environment is deployed with a UVM program and a chip to be tested. The chip to be tested is a code file simulated based on a chip design scheme. The verification method includes: Receiving first configuration information and constructing a verification file; After the chip under test is powered on, the verification file is loaded into the C program of the chip under test; Receive the second configuration information, and according to the second configuration information, enable the UVM program to perform data transmission interaction of multiple verification items with the C program, and obtain verification response information fed back by the C program; Confirm the verification result of the TrustZone function of the chip under test based on the verification response information.
2. The verification method according to claim 1, characterized in that: The second configuration information includes the secure world configuration information and the non-secure world configuration information, and the verification response information includes the first response information and the second response information; according to the second configuration information, the UVM program and the C program perform data transmission interaction for multiple verification items, and obtain the verification response information fed back by the C program, including: When the C program runs in the secure world environment, the UVM program performs data transmission interaction of multiple verification items with the C program according to the secure world configuration information to obtain the first response information of each verification item; When the C program runs in the non-secure world environment, the UVM program is enabled to perform data transmission interaction of multiple verification items with the C program according to the non-secure world configuration information to obtain second response information of each verification item.
3. The verification method according to claim 2, characterized in that: The secure world configuration information includes the first cycle number of each verification item; The UVM program performs data transmission interaction of multiple verification items with the C program according to the security world configuration information, and obtains the first response information of each verification item, including: Make the UVM program send the security verification data corresponding to the current verification project to the C program multiple times according to the first cycle number of the current verification project, so that the C program executes the security verification data multiple times, and feeds back the response information each time, and obtains the first response information of the current verification project; After obtaining the first response information of all verification items, the data transmission interaction between the UVM program and the C program in the secure world environment is terminated.
4. The verification method according to claim 3, characterized in that: After completing the data transmission interaction between the UVM program and the C program in the secure world environment, the verification method further includes: Send a switch instruction to the C program so that the C program switches to the non-secure world environment for execution.
5. The verification method according to claim 2, characterized in that: The non-secure world configuration information includes the second cycle number of each verification item; The UVM program is enabled to perform data transmission interaction of multiple verification items with the C program according to the non-safe world configuration information, and the second response information of each verification item is obtained, including: Make the UVM program send the non-safety verification data corresponding to the current verification project to the C program multiple times according to the second cycle number of the current verification project, so that the C program executes the non-safety verification data multiple times, and feeds back the response information each time, and obtains the second response information of the current verification project; After obtaining the second response information of all verification items, the data transmission interaction between the UVM program and the C program in the non-safe world environment is terminated.
6. The verification method according to any one of claims 2 to 5, characterized in that: The secure world configuration information further includes a first abnormal expected value, and the non-secure world configuration information further includes a second abnormal expected value; When the C program runs the Secure Fault processing function, the first exception expected value and the second exception expected value are both 1.
7. The verification method according to any one of claims 2 to 5, characterized in that: Confirm the verification result of the TrustZone function of the chip under test based on the verification response information, including: When the first response information of each verification item meets the requirements of the corresponding verification item, confirm that the security world of the TrustZone function of the chip under test has passed the verification; When the second response information of each verification item meets the requirements of the corresponding verification item, it is confirmed that the non-secure world of the TrustZone function of the chip under test passes the verification.
8. The verification method according to any one of claims 1 to 5, characterized in that: The first configuration information includes the interrupt vector table addresses of the secure world code and the non-secure world code, the first requirement information of the secure world code and the second requirement information of the non-secure world code; Receive the first configuration information and construct a verification file, including: Generate a secure world code according to the first requirement information and obtain a first ROM file; Generate a non-secure world code according to the second requirement information, and move the NSC lib library in the first ROM file to the non-secure world code to obtain a second ROM file; According to the interrupt vector table address, the first ROM file and the second ROM file are integrated into a verification file.
9. A verification device for the TrustZone function of a chip, comprising a processor and a memory storing program instructions, characterized in that: The processor is configured to execute the verification method for the TrustZone function of a chip according to any one of claims 1 to 8 when running the program instructions.
10. An electronic device, characterized in that: include: Equipment body; The verification device for the TrustZone function of a chip as described in claim 9 is installed in the device body.