CN117033101A

CN117033101A - Processor fuzzy test method supporting run-time instruction variation

Info

Publication number: CN117033101A
Application number: CN202310991329.8A
Authority: CN
Inventors: 周亚金; 刘诣元; 徐金焱; 林浩然
Original assignee: Zhejiang University ZJU
Current assignee: Zhejiang University ZJU
Priority date: 2023-08-08
Filing date: 2023-08-08
Publication date: 2023-11-10

Abstract

The invention discloses a processor fuzzy test method supporting runtime instruction variation, which uses runtime information to generate an instruction stream with effective format and semantics. Compared with the existing processor fuzzy test method, the method can effectively and efficiently explore the state of the processor, and has higher test speed and better test effect.

Description

Processor fuzzy test method supporting run-time instruction variation

Technical Field

The invention relates to the field of processor verification, in particular to a processor ambiguity test method supporting instruction variation in operation.

Background

As performance increases and functionality expands, processor designs are becoming more and more complex. Modern processors are extremely bulky, often with billions of transistors and multiple cores. This makes the processor more and more prone to errors and even the latest commodity processors have hardware errors. For example, intel found 37 errors in their 13 th generation CPU. Errors in the processor can not only produce incorrect results, but can also result in catastrophic errors. Since hardware vulnerabilities are difficult to repair after chip fabrication is complete, it is critical to verify the processor before the wafer is manufactured.

In recent years, some hardware fuzzing techniques have achieved good results in verifying processor designs. However, due to the complexity of the processors, they are subject to complex input grammars, fraudulent variation guides, and model implementation differences. Thus, how to effectively and efficiently authenticate a processor remains an open problem.

Disclosure of Invention

Aiming at the defects of the prior art, the invention provides a processor ambiguity test method supporting the variation of instructions during operation, which comprises the following specific technical scheme:

a processor fuzzy test method supporting run-time instruction variation is provided, wherein a plurality of rounds of tests are continuously performed before the loopholes of a tested processor are found, and each round of test comprises the following steps:

step one: generating an excitation template containing a test instruction according to the seeds;

step two: submitting the excitation template to a collaborative simulation test platform to enable the tested processor and the instruction set architecture simulator to synchronously execute test instructions; in the test process, when each test instruction is taken out, the test instruction is deformed according to the runtime information; in the execution process, collecting the coverage rate of the tested processor and the execution result of the tested processor and the instruction set architecture simulator on each test instruction; when the execution results are different, judging whether the execution results of the tested processor are legal, and if so, synchronizing the execution results of the tested processor to the instruction set architecture simulator; if the test instruction is illegal, judging that the vulnerability is found, outputting the vulnerability, and terminating execution of the subsequent test instruction;

step three: after the execution of the test instruction sequence is completed, evaluating the coverage rate of the tested processor, and returning to the step two if the coverage rate meets the requirement; and if the coverage rate does not meet the requirement, adjusting the seeds, and returning to the step one.

Further, the first step is implemented by the following substeps:

(1.1) generating a test instruction according to the seeds to form a test instruction sequence;

(1.2) inserting in the test instruction sequence a memory access instruction to access a peripheral, the peripheral being operable to provide an operand;

(1.3) shuffling a test instruction sequence inserted with a memory access instruction according to seeds;

(1.4) configuring a fuzzy execution environment according to the seeds;

(1.5) combining the fuzzy execution environment with the shuffled test instruction sequence, and compiling to generate an executable file, namely an excitation template.

Further, the test instructions include a plurality of test blocks, the end of each test block placing a control transfer instruction to link them together; the test block is selected from an integer arithmetic test block, a floating point arithmetic test block, a status and control register test block, a memory operation test block, an atomic memory operation test block, a system operation test block, and a custom extension test block.

Further, in the second step, each test instruction in the excitation template is deformed by using a deformer, and the deformation process is as follows:

the deformer is embedded between the instruction fetching unit and the decoding unit of the tested processor in a software logic mode, monitors the internal state of the tested processor, hives the acquired instruction, performs field-aware mutation on the acquired instruction, and returns the deformed instruction; the morpher maintains a morph map such that the processor under test and the instruction set architecture simulator are able to execute the same morph instruction.

Further, the comparison process of the execution result of the test instruction is abstracted into two phases, namely a submitting phase and a judging phase; in the commit phase, the processor under test first commits its program counter and the executed instructions; once the instruction set architecture simulator receives the commit request, it executes the next instruction and then checks whether the executed instruction is consistent with the commit of the processor under test; if the check passes, the instruction set architecture simulator records its reference write-back data to the scoreboard; the judging stage starts after the write-back data of the test instruction is ready; the write back value is compared with a reference value in the scoreboard to determine whether the execution result of the instruction is consistent.

Further, when the execution results of the tested processor and the instruction set architecture simulator on the test instruction are different, the following four conditions are required to be satisfied when the execution result of the tested processor is judged to be legal:

(1) The test instruction is a state and control instruction, or a memory operation instruction;

(2) The processor under test grants the test instruction access to the privileged register or the reserved address space without error;

(3) If the instruction is a state and control instruction, then only the WARL field defined in the specification in the destination register may not be equal;

(4) If the instruction is a memory operation instruction and data is read from a peripheral address outside the specification, the data can be unequal, otherwise the data should be equal;

further, the seed configures test attributes including privilege state of test, instruction set of test, switch and configuration of virtual memory, weight of test object, intensity of instruction shuffling.

Further, the deformer deforms each test instruction in the excitation template, including field-level deformation and semantic-level deformation;

the field level distortion specifically includes:

when a new test instruction arrives, the morpher first decodes the instruction, determines which fields are morphable, and then randomly selects the valid opcode defined in the specification to replace the opcode-related field in the morphable field;

the semantic level of distortion includes distortion of instruction immediate, operands:

the modification to the instruction immediate is specifically: the deformer generates effective address offset according to the current program counter and the address space;

there are two different variants to operands:

mode one: the morpher maintains a pool of general purpose registers to provide the required type of operands;

mode two: the morpher uses a sliding window to record the destination register fields of instructions that are still executing in the pipeline to provide operands that form a pipeline race.

Further, the operands provided by the peripheral include a 32-bit or 64-bit integer, a 32-bit or 64-bit floating point number, a memory address, and a page table entry.

The beneficial effects of the invention are as follows:

the invention discloses a processor fuzzy test method supporting instruction variation in operation, which designs a new input structure, provides multi-stage operation variation primitives, provides an instruction deformation technology capable of dynamically varying instructions, and uses a state synchronization technology to eliminate the implementation difference of microarchitecture. Compared with the existing processor fuzzy test method, the method has more excellent test effect and faster test speed.

Drawings

FIG. 1 is a flow chart of a processor fuzziness test method supporting run-time instruction mutation.

FIG. 2 is a graph of processor coverage versus test results.

Detailed Description

The objects and effects of the present invention will become more apparent from the following detailed description of the preferred embodiments and the accompanying drawings, it being understood that the specific embodiments described herein are merely illustrative of the invention and not limiting thereof.

The invention will be described in detail with reference to the accompanying drawings, taking as an example the application of the invention to RISC-V instruction set processor validation. As shown in fig. 1, in the processor ambiguity test method supporting run-time instruction variation according to the embodiment of the present invention, a plurality of rounds of tests are continuously performed before discovering a bug of a tested processor, and each round of tests includes the following steps:

step one: an excitation template containing test instructions is generated from the seed.

The test properties of the stimulus templates are configured by the seeds. The seed decides the following test attributes: the privilege state of the test, the instruction set of the test, the switching and configuration of virtual memory, the weight of the test object (in this example, the test block), the strength of instruction shuffling.

(1.1) generating test instructions according to the seeds to form a test instruction sequence.

To generate the test instruction sequences in the excitation templates, the present embodiment designs a variety of test blocks and encodes their weights in the seeds. The higher the test block weight in the seed, the greater the likelihood of generation. Seven types of test blocks cover various hardware functional blocks of the processor, including integer arithmetic test blocks, floating point arithmetic test blocks, status and control register test blocks, memory operation test blocks, atomic memory operation test blocks, system operation test blocks, and custom extension test blocks.

(1.2) inserting in the test instruction sequence a memory access instruction to access a peripheral, the peripheral being operable to provide an operand.

The peripheral is implemented in software and interacts with the processor under test using a Verilog DPI interface for providing operands, including integers (32 bits or 64 bits), floating point numbers (32 bits or 64 bits), memory addresses, page table entries, and the like. The end of each test block will also place control transfer instructions to link them together.

(1.3) shuffling the test instruction sequence after the memory access instruction is inserted according to the seeds.

(1.4) configuring the fuzzy execution environment according to the seeds.

The fuzzy execution environment in the stimulus template may be implemented by extending the test environment provided by the official RISC-V test library. The fuzzy execution environment initializes the processor under test and configures the environment according to test attributes, such as available instruction extensions, address translation modes and page tables, and runtime privilege levels. During the simulation, the fuzzy execution environment is placed in an immutable physical region and is responsible for handling exceptions and interrupts at the highest privilege level. In addition to managing the execution environment, the fuzzy execution environment also provides an interface to obscure the system environment.

Step two: submitting the excitation template to a collaborative simulation test platform to enable the tested processor and the instruction set architecture simulator to synchronously execute test instructions; in the test process, when each test instruction is taken out, the test instruction is deformed according to the runtime information; in the execution process, collecting the coverage rate of the tested processor and the execution result of the tested processor and the instruction set architecture simulator on each test instruction; when the execution results are different, judging whether the execution results of the tested processor are legal, and if so, synchronizing the execution results of the tested processor to the instruction set architecture simulator; if the test instruction is illegal, the loophole is found, the loophole is output, and the execution of the subsequent test instruction is terminated.

In this step, the runtime command is deformed by the deformer. The deformer is embedded between the finger taking unit and the decoding unit of the tested processor in the form of software logic. The Verilog DPI interface is used for interacting with a tested processor, namely, the internal state of the processor is monitored, the acquired instruction is hijacked, field-aware mutation is carried out on the acquired instruction, and the deformed instruction is returned. In addition, to ensure that the instruction set architecture simulator can perform the same morph as the processor under test, the morpher maintains a morph map, ensuring that the processor under test and the instruction set architecture simulator can always perform the same morph instruction.

The deformer deforms each test instruction in the excitation template, including field-level deformation and semantic-level deformation;

the field level distortion specifically includes:

when a new test instruction arrives, the morpher first decodes the instruction, determines which fields are morphable, and then randomly selects the valid opcode defined in the specification to replace the opcode-related field in the morphable field.

there are two different variants to operands:

The comparison process of the execution results of the deformed test instruction is abstracted into two stages, namely a submitting stage and a judging stage. During the commit phase, the processor under test first commits its program counter and the executed instructions. Once the instruction set architecture simulator receives the commit request, it executes the next instruction and then checks whether the executed instruction is consistent with the commit of the processor under test. If the check passes, the instruction set architecture simulator records its reference write-back data to the scoreboard. The judgment stage starts after the write-back data of the test instruction is ready. The write back value is compared with a reference value in the scoreboard to determine whether the execution result of the instruction is consistent.

During execution, the method also performs state synchronization on the synthetic difference. The rules of state synchronization are strict. One difference must meet the following four preconditions to be considered a legitimate difference. First, legal differences are limited to state and control instructions and memory operation instructions, as these instructions may involve operations that are out of verification range. Second, the control flow information of the processor under test must pass the check of the instruction commit phase. If the processor erroneously grants access to the privileged register or the reserved address space, the emulator will throw the exception due to the lack of authority, resulting in an unsynchronized control flow. Synchronization will be prevented after an instruction address violation is observed during the instruction commit phase. Third, if the destination register of the instruction is a status and control register, i.e., if the instruction is a status and control instruction, then only the WARL fields defined in the specification in the destination register may not be equal. Fourth, if the instruction reads data from a peripheral address outside the specification, i.e., the instruction reads data from a peripheral address outside the specification. If the instruction is a memory operation instruction and data is read from a peripheral address outside of the specification, the data may not be equal. By further fine-grained checking it can be ensured that all synchronous differences are outside the verification range.

And after the execution of the test instruction sequence is completed, evaluating the coverage rate of the tested processor, and if the coverage rate meets the requirement, re-executing the test instruction sequence. Because of the presence of the morpher, a different but similar test instruction than the preceding sequence will be executed. And if the coverage rate does not meet the requirement, adjusting the seeds, and executing the regenerated excitation template.

The method is compatible with the coverage rate index of the processor proposed by the existing design. For comparison with the advanced processor fuzzy test tool DifuzzRTL, the same control register coverage as DifuzzRTL is selected in this embodiment. The control register is a register whose value is used for any multiplexer select signal. In order to achieve control register coverage, all control registers are marked, the states of the marked registers are counted, and the sum of the counts is taken as the final coverage. The control register coverage is clock sensitive and reflects hardware status better than other coverage indicators. Note that coverage is only used to evaluate the effect of inputs and deformations, while implementing high coverage in a processor does not mean that the design is bug-free.

The method of the invention is compared with DifuzzRTL, and the well-known open source instruction generator riscv-dv and riscv-tture are compared on the verification effect of the rock-core processor. The coverage rate of the processor is selected for testing to measure the verification effect. The test results of fig. 2 show that the method of the present invention achieves higher coverage and better efficiency than other methods. The final coverage of the method is 4.4 times that of DifuzzRTL, 3.1 times that of riscv-torwire, and 1.6 times that of riscv-dv. DifuzzRTL takes 24 hours to achieve 480K coverage, while the present method only takes about 30 minutes to achieve the same coverage. Also, the method takes about 2.4 hours to reach coverage for riscv-dv to be completed in 24 hours. This remarkable result shows that the method can effectively and efficiently explore the processor state.

It will be appreciated by persons skilled in the art that the foregoing description is a preferred embodiment of the invention, and is not intended to limit the invention, but rather to limit the invention to the specific embodiments described, and that modifications may be made to the technical solutions described in the foregoing embodiments, or equivalents may be substituted for elements thereof, for the purposes of those skilled in the art. Modifications, equivalents, and alternatives falling within the spirit and principles of the invention are intended to be included within the scope of the invention.

Claims

1. A processor ambiguity test method supporting run-time instruction variation is characterized in that a plurality of rounds of tests are continuously performed before the loopholes of a tested processor are found, and each round of test comprises the following steps:

2. The processor ambiguity test method of claim 1 wherein step one is implemented by the sub-steps of:

(1.4) configuring a fuzzy execution environment according to the seeds;

3. The processor ambiguity test method for supporting a run-time instruction variation of claim 2, wherein,

the test instructions include a plurality of test blocks, the end of each test block placing a control transfer instruction to link them together; the test block is selected from an integer arithmetic test block, a floating point arithmetic test block, a status and control register test block, a memory operation test block, an atomic memory operation test block, a system operation test block, and a custom extension test block.

4. The processor ambiguity test method for supporting run-time command variation according to claim 1, wherein in the second step, each test command in the excitation template is deformed by using a deformer, and the deformation process is as follows:

5. The processor fuzzy test method of claim 1, wherein the comparison of the execution results of the test instruction is abstracted into two phases, namely a commit phase and a predicate phase; in the commit phase, the processor under test first commits its program counter and the executed instructions; once the instruction set architecture simulator receives the commit request, it executes the next instruction and then checks whether the executed instruction is consistent with the commit of the processor under test; if the check passes, the instruction set architecture simulator records its reference write-back data to the scoreboard; the judging stage starts after the write-back data of the test instruction is ready; the write back value is compared with a reference value in the scoreboard to determine whether the execution result of the instruction is consistent.

6. The processor ambiguity test method for supporting run-time instruction variation according to claim 1, wherein when the execution results of the test instruction by the tested processor and the instruction set architecture simulator are different, the following four conditions are satisfied when the execution result of the tested processor is judged to be legal:

(4) If the instruction is a memory operation instruction and data is read from a peripheral address outside of the specification, the data may not be equal, otherwise it should be equal.

7. The processor fuzzing method supporting run-time instruction mutation according to claim 1, wherein the seed configures test attributes including privilege state of test, instruction set of test, switch and configuration of virtual memory, weight of test object, intensity of instruction shuffling.

8. The processor fuzziness testing method supporting run-time instruction mutation of claim 1, wherein the morpher morphs each test instruction in the stimulus template comprising a field level morph and a semantic level morph;

the field level distortion specifically includes:

there are two different variants to operands:

9. The processor fuzziness testing method of claim 2, wherein the peripheral provided operands comprise 32-bit or 64-bit integers, 32-bit or 64-bit floating point numbers, memory addresses, page table entries.