Fuzzy test method and related device

Abstract

The embodiment of the invention provides a fuzzy test method based on coverage rate for trusted firmware, and the method comprises the steps: carrying out the variation of functions and parameters based on code coverage information during the variation of a seed, and guiding the generation of a test case through the coverage rate. The situation that the same function or the same segment of code of the BL31 firmware is repeatedly tested due to the fact that the generated test cases are the same is avoided, and on the basis that comprehensive testing of the BL31 firmware is guaranteed, the testing efficiency can be improved.

Description

Technical Field

[0001] The present specification relates to the field of computer application technology, specifically, to trusted firmware technology under the field of computer application technology, and more specifically, to a fuzzy testing method and related devices. Background Art

[0002] Fuzz Testing is a software testing technique used to discover vulnerabilities, errors, and security issues in software. Fuzz testing tests the robustness and security of software by inputting a large amount of randomly generated data or instruction sequences into the software. This method can effectively detect unforeseen defects and security vulnerabilities, especially in the boundary conditions and abnormal situations of the software.

[0003] Most existing fuzz testing tools run in an operating system environment and are used to perform fuzz testing on user applications in the operating system environment, but cannot perform fuzz testing on trusted firmware. Summary of the invention

[0004] The embodiments of this specification provide a fuzzy testing method and related devices to achieve the purpose of fuzzy testing on BL31 firmware.

[0005] To achieve the above technical objectives, the embodiments of this specification provide the following technical solutions:

[0006] In a first aspect, an embodiment of the present specification provides a fuzz testing method, which is applied to a system on chip, wherein the system on chip includes a rich execution environment subsystem REE and a trusted execution environment subsystem TEE, wherein the REE is used to run a test case application, a first application, and a REE operating system, wherein the REE operating system includes a proxy non-secure driver, and the TEE is used to run a second application, a BL32 firmware, and a BL31 firmware, wherein the BL32 firmware includes a proxy secure driver, and the BL31 firmware includes a coverage application; the fuzz testing method includes:

[0007] The first application, in response to a test request carrying a test case, transmits the test request to the BL31 firmware via a target path;

[0008] The target path includes: a first path, or a second path; the first path includes: the first application calls the proxy non-secure driver, and uses the proxy non-secure driver to call SMC through a secure monitoring mode to pass the test request to the BL31 firmware; the second path includes: the first application passes the test request to the second application, calls the proxy secure driver through the second application, and uses the proxy secure driver to pass the test request to the BL31 firmware through the SMC;

[0009] The test request is used to instruct the BL31 firmware to execute the test case for fuzz testing, and to instruct the coverage application to return the code coverage information of the test case to the test case application. The test case is generated by the test case application based on the code coverage information. The code coverage information includes code coverage, and the code coverage is used to characterize the proportion of the code called by the test case to the code of the BL31 firmware.

[0010] In a second aspect, an embodiment of the present specification provides a system on chip, including: a processor, the processor is used to build a rich execution environment subsystem REE and a trusted execution environment subsystem TEE, the REE is used to run a test case application, a first application and a REE operating system, the REE operating system includes a proxy non-secure driver, the TEE is used to run a second application, BL32 firmware and BL31 firmware, the BL32 firmware includes a proxy secure driver, and the BL31 firmware includes a coverage application; wherein,

[0011] The processor is configured to: respond to a test request carrying a test case through the first application, and pass the test request to the BL31 firmware through a target path;

[0012] The target path includes: a first path, or a second path; the first path includes: the first application calls the proxy non-secure driver, and uses the proxy non-secure driver to call SMC through a secure monitoring mode to pass the test request to the BL31 firmware; the second path includes: the first application passes the test request to the second application, calls the proxy secure driver through the second application, and uses the proxy secure driver to pass the test request to the BL31 firmware through the SMC;

[0013] The test request is used to instruct the BL31 firmware to execute the test case for fuzz testing, and to instruct the coverage application to return the code coverage information of the test case to the test case application. The test case is generated by the test case application based on the code coverage information. The code coverage information includes code coverage, and the code coverage is used to characterize the proportion of the code called by the test case to the code of the BL31 firmware.

[0014] In a third aspect, an embodiment of the present specification further provides a computing device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the fuzzy testing method as described above when executing the computer program.

[0015] In a fourth aspect, an embodiment of the present specification further provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the fuzzy testing method as described above is implemented.

[0016] In a fifth aspect, an embodiment of the present specification provides a computer program product or a computer program, wherein the computer program product includes a computer program, and the computer program is stored in a computer-readable storage medium; the processor of the computer device reads the computer program from the computer-readable storage medium, and the processor implements the steps of the above-mentioned fuzzy testing method when executing the computer program.

[0017] It can be seen from the above technical solution that the fuzzy testing method provided in the embodiment of this specification is implemented based on a system on a chip including REE and TEE, REE is used to run the test case application, the first application and the REE operating system, and the REE operating system includes a TEE driver, TEE is used to run the second application, BL32 firmware and BL31 firmware, the BL32 firmware includes a proxy security driver, and the BL31 firmware includes a coverage application. When the method is implemented, the first application responds to the test request carrying the test case, and the test request is passed to the BL31 firmware through the target path, wherein the target path includes a first path transmitted to the BL31 firmware through the REE side and a second firmware transmitted to the BL31 firmware through the TEE side, so as to meet different test requirements. The transmission requirements of the trial case ensure the comprehensive test of the BL31 firmware; in addition, the test request is used to instruct the BL31 firmware to execute the test case for fuzz testing, and instruct the coverage application to return the code coverage information of the test case to the test case application, the test case is generated by the test case application based on the code coverage information, the code coverage information includes code coverage, and the code coverage is used to characterize the proportion of the code called by the test case to the code of the BL31 firmware. In this way, the generation of test cases is guided by the coverage, avoiding the repeated testing of the same function or the same code of the BL31 firmware due to the same generated test cases, which is conducive to improving the test efficiency on the basis of ensuring the comprehensive testing of the BL31 firmware. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

[0019] Figure 1A schematic diagram of the relationship between a security architecture and trusted firmware provided for the implementation of this specification;

[0020] Figure 2 A flowchart of a fuzzy testing method provided for one embodiment of this specification;

[0021] Figure 3 A schematic diagram of a first path provided for one embodiment of this specification;

[0022] Figure 4 A schematic diagram of a second path provided for one embodiment of this specification;

[0023] Figure 5 A schematic diagram of the structure of a computing device provided for one embodiment of the present specification. DETAILED DESCRIPTION

[0024] Unless otherwise defined, the technical terms or scientific terms used in the embodiments of this specification shall have the common meanings understood by persons with ordinary skills in the field to which this specification belongs. The words "first", "second" and similar words used in the embodiments of this specification do not indicate any order, quantity or importance, but are only used to avoid confusion of constituent elements.

[0025] Unless the context requires otherwise, throughout the specification, "plurality" means "at least two", and "including" is interpreted as an open, inclusive meaning, that is, "including, but not limited to". In the description of the specification, the terms "one embodiment", "some embodiments", "exemplary embodiments", "examples", "specific examples" or "some examples" are intended to indicate that a particular feature, structure, material or characteristic associated with the embodiment or example is included in at least one embodiment or example of the specification. The schematic representation of the above terms does not necessarily refer to the same embodiment or example.

[0026] The following will be combined with the drawings in the embodiments of this specification to clearly and completely describe the technical solutions in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this specification.

[0027] Overview

[0028] As mentioned in the background technology, fuzz testing is of great significance to software development, as it can promptly detect anomalies in developed software and fix them in a timely manner. However, most existing fuzz testing tools run in an operating system environment. Although most of these fuzz testing tools are open source tools and are widely used, these tools run in an operating system environment and are only used to perform fuzz testing on user applications developed and run in the operating system environment. They are not suitable for fuzz testing of trusted firmware.

[0029] In order to solve this problem, a fuzz testing method suitable for trusted firmware is developed. The inventor proposes a fuzz testing method based on trusted firmware. Before explaining the concept of the fuzz testing method, a brief introduction to trusted firmware is first given:

[0030] Trusted firmware refers to the firmware component used to provide a secure boot and operating environment in a computer system. Trusted firmware unifies the underlying interface standards, such as the power state control interface, secure boot requirements, and the secure monitoring mode call operation for switching between the secure world state and the normal world state. Trusted firmware aims to unify the underlying operations so that the code can be reused and ported. At the same time, as an interface between the operating system and the underlying hardware, trusted firmware is a key component to ensure the security of sensitive data.

[0031] refer to Figure 1 , Figure 1 A secure hardware architecture is shown. The secure hardware architecture is a system architecture designed for computing devices, and its purpose is to build a security framework for computing devices to resist various possible attacks. The implementation of the secure hardware architecture can be to divide the hardware and software resources of the processor into a secure (Secure World) and a normal (NormalWorld) world. All operations that require confidentiality are performed in the secure world (such as fingerprint recognition, password processing, data encryption and decryption, and security authentication, etc.), and the remaining operations are performed in the normal world (such as user operating systems, various ordinary applications, etc.). The secure world and the normal world are converted through a mode called monitor mode (Monitor Mode). In the processor architecture, the physical processor core can be virtualized into two cores, a non-secure core (NS Core), which runs the code of the normal world, and another secure core (Secure Core), which runs the code of the secure world. The specific structural type of the secure hardware architecture can refer to the Trust Zone (TZ for short) and SGX (Software Guard Extensions) technology.

[0032] Trusted Firmware (TF) is a security solution that divides the privilege levels during the startup and operation of computing devices. These privilege levels are combined with the secure hardware architecture to jointly ensure the security of the startup process of computing devices. Specifically, trusted firmware technology divides four privilege levels from EL0 (Exception Level 0) to EL3. From EL0 to EL3, the privilege levels increase in sequence. From high LE to low EL through the ERET (Exit from Exception Return) instruction, from low EL to high EL through exception, so that different privilege levels can be strictly distinguished. Among them, EL0, EL1 and EL2 can be divided into NS-ELx (None Secure ELx, x = 0, 1, 2, i.e. normal world ELx) and S-ELx (Secure ELx, x = 0, 1, 2, i.e. secure world ELx), while EL3 only has secure world EL3. In some cases, the firmware required to run during the startup process of the computing device may include BL1 firmware, BL2 firmware, BL31 firmware, BL32 firmware and BL33 firmware.

[0033] Among them, BL1 firmware can be called Trusted Boot ROM (Trusted Boot ROM), which is the earliest firmware running in the boot process and is also the firmware stored in the processor ROM (Read-Only Memory). BL1 firmware is not together with the BIOS of the computing device. In some types of trusted firmware technology, BL1 firmware is the root of trust for everything. BL1 firmware can be used to initialize the core hardware of the computing device (such as Trusted SRAM (Trusted Static Random Access Memory), serial port, etc.) and find BL2 firmware. In some cases, BL1 firmware will verify the signature of BL2 firmware. BL1 firmware runs at the EL3 privilege level.

[0034] BL2 firmware can be called Trusted Boot Firmware. BL2 firmware also runs at the EL3 privilege level. The significant difference between BL2 firmware and BL1 firmware is that BL2 firmware can be stored on an external trusted storage device, and its trustworthiness can be based on the verification of BL1 firmware. BL2 firmware will initialize some key security hardware and software frameworks. After the initialization is completed, BL2 firmware will find BL31.

[0035] BL31 firmware can be called EL3 Runtime Firmware. BL31 firmware also runs at the EL3 privilege level and is the last security bastion of the EL3 privilege level. Unlike BL1 firmware and BL2 firmware, BL31 firmware is not a one-time run. It continuously provides security-related services to the normal world (Non-Secure) through SMC (Secure Monitor Call).

[0036] BL32 firmware can include OP-TEE OS (Open Portable Tee Operate System) and trusted applications. OP-TEE OS can refer to the operating system of the trusted execution environment TEE. BL32 firmware runs on S-EL1, and the trusted application on BL32 firmware runs on S-EL0. In some cases, after OP-TEE OS runs, it returns to EL3's BL31 firmware, BL31 firmware finds BL33 firmware, and BL31 firmware can also verify the signature of BL33 firmware.

[0037] BL33 firmware may include firmware (Non-Trusted Firmware) running in the normal world. BL33 firmware may include UEFI (Unified Extensible Firmware Interface) firmware or U-boot (boot loader for embedded fields) for desktops, servers and other fields. It may also include Linux Kernel (Linux kernel) and basic input output system (BIOS) firmware. In the normal world, the execution permissions of EL0, EL1, EL2, and EL3 increase in sequence. Among them, UEFI firmware is configured to run at the EL2 level of the normal world, and OP-TEE OS is configured to run at the EL1 level of the secure world. When entering the UEFI (BL33) startup, OP-TEE OS has completed the startup, and UEFI and OP-TEE OS can communicate through the secure monitor call (SMC) interface. Therefore, when performing UEFI booting, when verifying the integrity and security of the image file, the normal world can trigger the SMC method to call the corresponding interface of the OP-TEE OS in the secure world to implement certain functions. In this way, the verification process involving the image file can be passed to the secure world for verification, and the verification result can be returned to the normal world.

[0038] Understandably, Figure 1For the purpose of illustrative purposes only, the trusted firmware and related concepts are introduced. In some embodiments, the trusted firmware includes Figure 1 More or less firmware, for example, in some implementations, the trusted firmware may also include firmware such as STMM (Standalone MM, independent management module), or the boot order of the trusted firmware may also vary, which is not exhaustive in this specification.

[0039] Rich Execution Environment (REE, also known as normal execution environment) subsystem, which can be used to run objects such as the operating system (OS) and normal applications (also known as client applications (CA)) of computing devices. REE can run in the normal world.

[0040] Trusted Execution Environment (TEE) subsystem, which can be used to run trusted applications (TA) to meet the application requirements of digital rights management (DRM), mobile payment and sensitive data protection. TEE can run in the secure world.

[0041] In order to implement fuzz testing based on trusted firmware, the inventors set up a test case application for generating test cases, a first application for responding to and delivering test requests, and an agent non-secure driver for calling SMC to communicate with BL31 firmware in REE based on a system on a chip including a security architecture REE and TEE, and set up a second application for receiving test requests in TEE, a second application for calling SMC to communicate with BL31 firmware to pass the test request to OP-TEE. The invention relates to an agent security driver of an OS and a coverage application for obtaining code coverage information of a test case and returning it to a test case application. When the method is implemented, a first application responds to a test request carrying a test case, and transmits the test request to a BL31 firmware through a target path, wherein the target path includes a first path transmitted to the BL31 firmware through the REE side and a second firmware transmitted to the BL31 firmware through the TEE side, so as to meet the transmission requirements of different test cases and ensure a comprehensive test of the BL31 firmware. In addition, the test request is used to instruct the BL31 firmware to execute the test case for fuzz testing, and to instruct the coverage application to return the code coverage information of the test case to the test case application. The test case is generated by the test case application based on the code coverage information. The code coverage information includes code coverage, and the code coverage is used to characterize the proportion of the code called by the test case to the code of the BL31 firmware. In this way, the generation of test cases is guided by the coverage, so as to avoid repeated testing of the same function or the same code of the BL31 firmware due to the same generated test cases, which is conducive to improving the test efficiency on the basis of ensuring a comprehensive test of the BL31 firmware.

[0042] Based on the above concept, an embodiment of the present specification provides a fuzzy testing method. The fuzzy testing method provided in the embodiment of the present specification will be exemplarily described below in conjunction with the accompanying drawings.

[0043] Exemplary Methods

[0044] To be applied to Figure 2 Taking the system on chip in as an example, some embodiments of this specification exemplarily illustrate the fuzz testing method, the system on chip includes a rich execution environment subsystem REE and a trusted execution environment subsystem TEE, the REE is used to run the test case application, the first application and the REE operating system, the REE operating system includes a proxy non-secure driver, the TEE is used to run the second application, BL32 firmware and BL31 firmware, the BL32 firmware includes a proxy secure driver, and the BL31 firmware includes a coverage application; the fuzz testing method includes:

[0045] S201: The first application responds to a test request carrying a test case by transmitting the test request to the BL31 firmware through a target path;

[0046] The target path includes: a first path, or a second path; the first path includes: the first application calls the proxy non-secure driver, and uses the proxy non-secure driver to call SMC through a secure monitoring mode to pass the test request to the BL31 firmware; the second path includes: the first application passes the test request to the second application, calls the proxy secure driver through the second application, and uses the proxy secure driver to pass the test request to the BL31 firmware through the SMC;

[0047] S202: The test request is used to instruct the BL31 firmware to execute the test case for fuzz testing, and to instruct the coverage application to return the code coverage information of the test case to the test case application. The test case is generated by the test case application based on the code coverage information. The code coverage information includes code coverage, and the code coverage is used to characterize the proportion of the code called by the test case to the code of the BL31 firmware.

[0048] In this embodiment, the test case application and the first application can be a user application (ClientApplication, CA), running in REE, the test case application can be used to generate test cases and test requests carrying test cases, and the first application can be used to receive test requests, and the purpose of sending the test request to the proxy non-safe driver in the kernel state in the user state is achieved by calling the proxy non-safe driver included in the REE operating system (REE OS). The proxy non-safe driver sends the test request to the BL31 firmware through the SMC to request the BL31 firmware to execute the test case and perform fuzz testing.

[0049] The second application and the proxy security driver can be a trusted application (TA) in the TEE. Unlike the second application, the proxy security driver can be integrated into the OP-TEE OS and has relatively higher security.

[0050] refer to Figure 3 , Figure 3A path diagram for transmitting a test request through a first path is shown. After the first application receives a test request carrying a test case generated by a test case application, the test request is sent to the BL31 firmware by calling the SMC through a proxy non-secure driver, so that the BL31 firmware executes the test case to implement fuzz testing. The coverage application in the BL31 firmware obtains the code coverage information of the test case and returns it to the first application, which is then returned to the test case application through the first application to guide the test case application to generate a new test case.

[0051] refer to Figure 4 , Figure 4 A schematic diagram of a path for transmitting a test request through a second path is shown, wherein the first application transmits the test request to the second application, and the second application calls a proxy security driver, and uses the proxy security driver to call the SMC to transmit the test request to the BL31 firmware. The communication between the first application and the second application can be implemented based on a specific API interface (Application Programming Interface) or the like, and the first application reconstructs the test request according to the API interface specification and transmits the reconstructed test request to the second application.

[0052] After the test request is passed to the BL31 firmware, the BL31 firmware can execute the test case according to the instruction of the test request to perform fuzz testing. In addition, the coverage application in the BL31 firmware can calculate the code coverage information based on the received test case, and the code coverage information can be returned to the test case application by writing to the shared memory, etc. The shared memory serves as the communication medium between REE and TEE. Figure 3 and Figure 4 In the embodiment, the coverage application writes the code coverage information into the shared memory, and the code coverage information written into the shared memory notifies the first application to read the code coverage information from the shared memory and returns it to the test case application. The code coverage information can be used to guide the test case application to generate new test cases, and avoid generating test cases with a high degree of duplication with historical test cases. In some embodiments, the code coverage information written into the shared memory can directly notify the test case application to read the code coverage information from the shared memory, that is, the coverage application returns the code coverage information of the test case to the test case application, including: the coverage application writes the code coverage information of the test case into the shared memory, and the code coverage information written into the shared memory is used to instruct the test case application to read the code coverage information. This specification does not limit the specific return method of the code coverage information, which depends on the actual situation.

[0053] The code coverage rate included in the code coverage information includes but is not limited to at least one of function coverage rate, statement coverage rate, branch coverage rate, condition coverage rate and line coverage rate, wherein the function coverage rate indicates the proportion of functions called by the test case to the defined functions in the BL31 firmware; the statement coverage rate indicates the proportion of statements required to be executed by the test case to the statements in the BL31 firmware; the branch coverage rate indicates the proportion of branches (such as if statements) required to be executed by the test case to the branches in the BL31 firmware; the condition coverage rate indicates the proportion of the true value and false value of the Boolean expression required to be tested by the test case to the true value and false value of the Boolean expression in the BL31 firmware; the line coverage rate indicates the proportion of the line source code required to be tested by the test case to the total line source code in the BL31 firmware. In addition to the code coverage rate, the code coverage information may also include the function coverage rate that characterizes the proportion of functions required to be tested by the test case to the total functions in the BL31 firmware, etc. This specification does not limit this, and it depends on the actual situation.

[0054] In this embodiment, the fuzz testing method is implemented based on a system on a chip including REE and TEE, REE is used to run a test case application, a first application and a REE operating system, and the REE operating system includes a TEE driver, TEE is used to run a second application, BL32 firmware and BL31 firmware, the BL32 firmware includes a proxy security driver, and the BL31 firmware includes a coverage application. When the method is implemented, the first application responds to a test request carrying a test case, and the test request is passed to the BL31 firmware through a target path, wherein the target path includes a first path transmitted to the BL31 firmware through the REE side and a second firmware transmitted to the BL31 firmware through the TEE side, so as to meet the transmission requirements of different test cases. The test request is used to instruct the BL31 firmware to execute the test case for fuzz testing, and to instruct the coverage application to return the code coverage information of the test case to the test case application. The test case is generated by the test case application based on the code coverage information. The code coverage information includes code coverage, and the code coverage is used to characterize the proportion of the code called by the test case to the code of the BL31 firmware. In this way, the generation of test cases is guided by the coverage, so as to avoid repeated testing of the same function or the same code of the BL31 firmware due to the same generated test cases. On the basis of ensuring the comprehensive testing of the BL31 firmware, it is beneficial to improve the testing efficiency.

[0055] In one embodiment of the present specification, a feasible generation process of a test case is provided. Specifically, the process of generating the test case based on the code coverage information by applying the test case includes:

[0056] The test case application generates a seed, and the seed is mutated based on the code coverage information to obtain the test case, wherein the seed includes function information of the BL31 firmware and parameter information corresponding to the function information.

[0057] In the present embodiment, the test case application may include a seed generation module, a mutation module and a fuzzy test module, wherein the seed generation module is used to generate the seeds that the fuzzy test depends on, as the initial seed input, to form a corpus, the seeds in the corpus may refer to the basic input data for generating test cases, which include files, network data packets, memory blocks, command line parameters, etc., for calling the partial code of the BL31 firmware. The larger the coverage of the seeds in the corpus, the deeper the vulnerability of the BL31 firmware that can be found. The mutation module modifies the seeds according to the seed and the security monitoring mode call specification, and generates a large number of unexpected new test cases. The fuzzy test module sends the test request carrying the generated test case to the first application, so as to realize the purpose of providing unexpected input to the system. In some embodiments, the test case application is also used to monitor the abnormal results (such as program crash, assertion failure, etc.) of the BL31 firmware running the test case to find the vulnerability of the BL31 firmware.

[0058] In one implementation of this specification, mutating the seed based on the code coverage information includes:

[0059] The target data is mutated based on the code coverage information to obtain function information corresponding to the code not called by the historical test case and parameter information corresponding to the function information; the target data includes at least one of the function information of the BL31 firmware and the parameter information corresponding to the function information.

[0060] The function information of the BL31 firmware is used to characterize the functions that the BL31 firmware can execute, including but not limited to secure boot verification and secure monitoring mode call. The parameter information corresponding to the function information may include parameters for configuring and calling the corresponding functions. In this embodiment, not only the fuzzy test of the function variation is implemented, but also the fuzzy test of the parameter information variation is implemented, which is conducive to the comprehensive testing of the BL31 firmware.

[0061] In order to avoid obtaining illegal test cases and causing unexpected test results in the process of generating test cases, in one embodiment of the present specification, after mutating the seed based on the code coverage information to obtain the test case, the method further includes:

[0062] The test cases are subjected to a validity check, and the test cases that fail the check are discarded.

[0063] In this embodiment, in order to avoid obtaining parameter information and / or functional information outside the specification during the mutation process, after the seed is mutated to obtain the test case, the test case is checked for legality, and only the test cases that pass the check will be added to the queue to be executed, while the test cases that fail the check will be discarded to avoid illegal test cases from causing unexpected test results. For example, assuming that the value range of the ID corresponding to the functional information of the BL31 firmware is 1 to 10, if the value of the ID corresponding to the functional information in the mutated test case is 15, then the value exceeds the normal value range, and it can be determined that the functional information in the test case is illegal.

[0064] In one implementation of the present specification, a feasible mutation method is proposed. Specifically, the mutating the seed based on the code coverage information includes:

[0065] Based on the code coverage information, mutating the seed using a target mutation method;

[0066] The target variation method includes at least one of: bit flipping, integer addition / subtraction arithmetic operation, content replacement, and code unit insertion.

[0067] Among them, bit flipping may refer to changing the value of data from 1 to 0, or from 0 to 1, to achieve bit flipping mutation; integer addition / subtraction arithmetic operations may refer to performing certified addition and subtraction arithmetic operations on data, to achieve integer addition / subtraction arithmetic operations mutation; content replacement may refer to replacing specific content with the original content in the seed, to achieve content replacement mutation; code unit insertion may refer to replacing or inserting an automatically generated or user-provided code unit (such as a token) into the seed, to achieve code unit insertion mutation.

[0068] According to the selection and combination of the target mutation mode, a large number of different test case generation requirements can be met, and the purpose of comprehensive testing of the BL31 firmware can be achieved. In addition to the mutation modes mentioned above, articulated mutation modes can also be included. This specification does not limit the target mutation mode, which depends on the actual situation.

[0069] In one embodiment of the present specification, a feasible method for selecting a test request delivery path is provided. Specifically, the first application responds to the test request carrying the test case, and delivers the test request to the BL31 firmware through the target path, including:

[0070] The first application responds to the test request carrying the test case, determines the target path according to the function ID in the test case, and passes the test request to the BL31 firmware through the target path; the function ID is used to characterize the function information of the BL31 firmware.

[0071] The BL31 firmware can provide rich functions for REE and TEE, but some functions can only be triggered from the REE side (i.e., triggered by the program on the REE side), while some functions can only be triggered from the TEE side (i.e., triggered by the program on the TEE side). Therefore, in the fuzz testing method, the first path and the second path are distinguished to meet the transmission and triggering requirements of different test cases to the BL31 firmware.

[0072] In order to quickly determine the transmission path of the test request, in this implementation, the function ID is used to characterize the function information of the BL31 firmware called in the test case. According to the function ID, it can be determined whether the function information called by the test case is triggered from the REE side or the TEE side. According to different function IDs, the function to be tested by the test case can be quickly determined, and then the corresponding target path can be selected according to whether the function needs to be triggered from the REE side or the TEE side. The entire process does not require parsing all the data of the test case, which is conducive to quickly determining the transmission path of the test request.

[0073] A specific implementation of this specification provides a specific feasible execution process of a fuzzy testing method, and the specific process includes:

[0074] S1. The test case module generates a seed, mutates the seed based on the code coverage information to obtain a test case, and sends a test request carrying the test case to the first application;

[0075] S2. The first application determines whether to trigger from the secure world or the non-secure world according to the function ID of the test case. If the test case needs to be triggered from the secure world, the test case is passed to the BL31 firmware through the second path; if the test case needs to be triggered from the non-secure world, the test case is passed to the BL31 firmware through the first path;

[0076] The S3 and BL31 firmware executes SMC, and the coverage application feedbacks code coverage information.

[0077] Exemplary Devices

[0078] In an exemplary embodiment of the present specification, a system on chip is further provided, including: a processor, the processor is used to build a rich execution environment subsystem REE and a trusted execution environment subsystem TEE, the REE is used to run a test case application, a first application and a REE operating system, the REE operating system includes a proxy non-secure driver, the TEE is used to run a second application, BL32 firmware and BL31 firmware, the BL32 firmware includes a proxy secure driver, and the BL31 firmware includes a coverage application; wherein,

[0079] The processor is configured to: respond to a test request carrying a test case through the first application, and pass the test request to the BL31 firmware through a target path;

[0080] The target path includes: a first path, or a second path; the first path includes: the first application calls the proxy non-secure driver, and uses the proxy non-secure driver to call SMC through a secure monitoring mode to pass the test request to the BL31 firmware; the second path includes: the first application passes the test request to the second application, calls the proxy secure driver through the second application, and uses the proxy secure driver to pass the test request to the BL31 firmware through the SMC;

[0081] The test request is used to instruct the BL31 firmware to execute the test case for fuzz testing, and to instruct the coverage application to return the code coverage information of the test case to the test case application. The test case is generated by the test case application based on the code coverage information. The code coverage information includes code coverage, and the code coverage is used to characterize the proportion of the code called by the test case to the code of the BL31 firmware.

[0082] For the specific limitations on the processor executing the fuzz testing method, please refer to the relevant limitations on the "fuzz testing method" in the previous article, and this specification will not go into details here.

[0083] Exemplary Computing Devices

[0084] Another embodiment of the present application further provides a computing device, see Figure 5 As shown, an exemplary embodiment of the present specification also provides a computing device, including: a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, it executes the steps of the fuzzy testing method according to various embodiments of the present specification described in the above embodiments of the present specification.

[0085] The internal structure of the computing device can be as follows Figure 5As shown, the computing device includes a processor, a memory, a network interface and an input device connected via a system bus. The processor of the computing device is used to provide computing and control capabilities. The memory of the computing device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computing device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, the steps of the fuzzy testing method according to various embodiments of the present specification are described in the above embodiments of the present specification.

[0086] The processor may include a main processor and may also include a baseband chip, a modem, etc.

[0087] The memory stores a program for executing the technical solution of the present invention, and may also store an operating system and other key services. Specifically, the program may include a program code, and the program code includes computer operation instructions. More specifically, the memory may include a read-only memory (ROM), other types of static storage devices that can store static information and instructions, a random access memory (RAM), other types of dynamic storage devices that can store information and instructions, a disk storage, a flash, and the like.

[0088] The processor may be a general-purpose processor, such as a general-purpose central processing unit (CPU), a microprocessor, etc., or an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the program of the scheme of the present invention. It may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0089] The input device may include a device for receiving data and information input by a user, such as a keyboard, a mouse, a camera, a scanner, a light pen, a voice input device, a touch screen, a pedometer, or a gravity sensor.

[0090] Output devices may include means that allow information to be output to a user, such as display screens, printers, speakers, etc.

[0091] The communication interface may include using any transceiver or the like to communicate with other devices or communication networks, such as Ethernet, Radio Access Network (RAN), Wireless Local Area Network (WLAN), etc.

[0092] The processor executes the program stored in the memory and calls other devices, which can be used to implement the various steps of any fuzzy testing method provided in the above embodiments of the present application.

[0093] The computing device may also include a display component and a voice component. The display component may be a liquid crystal display or an electronic ink display. The input device of the computing device may be a touch layer covered on the display component, or a button, trackball or touchpad provided on the housing of the computing device, or an external keyboard, touchpad or mouse.

[0094] Those skilled in the art will understand that Figure 5 The structure shown in the figure is only a block diagram of a part of the structure related to the scheme of this specification, and does not constitute a limitation on the computing device to which the scheme of this specification is applied. The specific computing device may include more or fewer components than shown in the figure, or combine certain components, or have a different arrangement of components.

[0095] Exemplary computer program products and storage media

[0096] In addition to the above-mentioned methods and devices, the fuzzy testing method provided in the embodiments of the present specification may also be a computer program product, which includes computer program instructions, which, when executed by a processor, enable the processor to execute the steps of the fuzzy testing method according to various embodiments of the present specification described in the above "Exemplary Method" section of the present specification.

[0097] The computer program product may be written in any combination of one or more programming languages ​​to write program code for performing the operations of the embodiments of the present specification, including object-oriented programming languages ​​such as Java, C++, etc., and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as a separate software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0098] In addition, an embodiment of the present specification also provides a computer-readable storage medium on which a computer program is stored, and the computer program is executed by a processor to execute the steps of the fuzzy testing method according to various embodiments of the present specification described in the above "Exemplary Method" section of the present specification.

[0099] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this specification can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0100] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0101] The above-mentioned embodiments only express several implementation methods of this specification, and the descriptions are relatively specific and detailed, but they cannot be understood as limiting the scope of the solutions provided by the embodiments of this specification. It should be pointed out that for ordinary technicians in this field, several modifications and improvements can be made without departing from the concept of this specification, which all belong to the protection scope of this specification. Therefore, the protection scope of the patent of this specification shall be based on the attached claims.

Claims

1. A fuzzy testing method, characterized in that: Applied to a system on chip, the system on chip includes a rich execution environment subsystem REE and a trusted execution environment subsystem TEE, the REE is used to run a test case application, a first application and a REE operating system, the REE operating system includes a proxy non-secure driver, the TEE is used to run a second application, BL32 firmware and BL31 firmware, the BL32 firmware includes a proxy secure driver, and the BL31 firmware includes a coverage application; The fuzz testing method comprises: The first application, in response to a test request carrying a test case, transmits the test request to the BL31 firmware via a target path; The target path includes: a first path, or a second path; the first path includes: the first application calls the proxy non-secure driver, and uses the proxy non-secure driver to call SMC through a secure monitoring mode to pass the test request to the BL31 firmware; the second path includes: the first application passes the test request to the second application, calls the proxy secure driver through the second application, and uses the proxy secure driver to pass the test request to the BL31 firmware through the SMC; The test request is used to instruct the BL31 firmware to execute the test case for fuzz testing, and to instruct the coverage application to return the code coverage information of the test case to the test case application. The test case is generated by the test case application based on the code coverage information. The code coverage information includes code coverage, and the code coverage is used to characterize the proportion of the code called by the test case to the code of the BL31 firmware.

2. The method according to claim 1, characterized in that The process of applying the test case to generate the test case based on the code coverage information includes: The test case application generates a seed, and the seed is mutated based on the code coverage information to obtain the test case, wherein the seed includes function information of the BL31 firmware and parameter information corresponding to the function information.

3. The method according to claim 2, characterized in that The mutating the seed based on the code coverage information comprises: The target data is mutated based on the code coverage information to obtain function information corresponding to the code not called by the historical test case and parameter information corresponding to the function information; the target data includes at least one of the function information of the BL31 firmware and the parameter information corresponding to the function information.

4. The method according to claim 2, characterized in that: After mutating the seed based on the code coverage information to obtain the test case, the method further includes: The test cases are subjected to a validity check, and the test cases that fail the check are discarded.

5. The method according to claim 2, characterized in that: The mutating the seed based on the code coverage information comprises: Based on the code coverage information, mutating the seed using a target mutation method; The target variation method includes at least one of: bit flipping, integer addition / subtraction arithmetic operation, content replacement, and code unit insertion.

6. The method according to any one of claims 1 to 5, characterized in that: The first application responds to the test request carrying the test case, and transmits the test request to the BL31 firmware through the target path, including: The first application responds to the test request carrying the test case, determines the target path according to the function ID in the test case, and passes the test request to the BL31 firmware through the target path; the function ID is used to characterize the function information of the BL31 firmware.

7. The method according to any one of claims 1 to 5, characterized in that: The system on chip further includes: a shared memory, the shared memory being used as a communication medium between the REE and the TEE, and the coverage application returning the code coverage information of the test case to the test case application including: The coverage application writes the code coverage information of the test case into the shared memory, and the code coverage information written into the shared memory is used to instruct the test case application to read the code coverage information.

8. A system on chip, characterized in that: include: A processor, the processor is used to build a rich execution environment subsystem REE and a trusted execution environment subsystem TEE, the REE is used to run a test case application, a first application and a REE operating system, the REE operating system includes a proxy non-secure driver, the TEE is used to run a second application, BL32 firmware and BL31 firmware, the BL32 firmware includes a proxy secure driver, and the BL31 firmware includes a coverage application; wherein, The processor is configured to: respond to a test request carrying a test case through the first application, and pass the test request to the BL31 firmware through a target path; The target path includes: a first path, or a second path; the first path includes: the first application calls the proxy non-secure driver, and uses the proxy non-secure driver to call SMC through a secure monitoring mode to pass the test request to the BL31 firmware; the second path includes: the first application passes the test request to the second application, calls the proxy secure driver through the second application, and uses the proxy secure driver to pass the test request to the BL31 firmware through the SMC; The test request is used to instruct the BL31 firmware to execute the test case for fuzz testing, and to instruct the coverage application to return the code coverage information of the test case to the test case application. The test case is generated by the test case application based on the code coverage information. The code coverage information includes code coverage, and the code coverage is used to characterize the proportion of the code called by the test case to the code of the BL31 firmware.

9. A computing device, characterized in that The invention comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the fuzzy testing method according to any one of claims 1 to 7 when executing the computer program.

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

Images