We recently became aware of “Cascade: CPU Fuzzing via Intricate Program Generation”, by Flavien Solt, Katharina Ceesay-Seitz, and Kaveh Razavi, all affiliated with ETH Zurich. This paper delves into the growing field of pre-silicon security analysis, particularly in CPU fuzzing, a technique used to uncover vulnerabilities in CPU designs before they are physically manufactured. The focus is on Cascade, a new tool that excels in creating efficient, error-free programs for CPU fuzzing. Cascade stands out for its effectiveness, having identified 37 new bugs in RISC-V CPU designs and a bug in the Yosys synthesizer. It addresses three main challenges: creating long random programs that don’t crash, efficient bug detection, and minimizing the size of programs that cause crashes.
How not to crash a random long program
In CPU fuzzing, a major issue is that randomly generated programs often crash because they try to access non-existent memory addresses. This problem worsens with longer programs, leading to less effective fuzzing since most instructions end up being non-random setup routines. Cascade solves this by pre-defining the control flow of programs, making them more likely to run to completion without crashing. It also focuses on increasing the proportion of actual fuzzing instructions in these longer programs, some of which contain up to 100,000 instructions.
How to detect bugs efficiently
Detecting bugs efficiently is another challenge addressed by the paper. The authors use a technique they call ‘asymmetric ISA pre-simulation’ to create programs with predictable control flows. This method simplifies bug detection, as it only requires checking if a program completes to identify a bug, rather than verifying the CPU’s behavior after every instruction.
Finding small problems in large programs
However, while long programs are great for fuzzing, they make it hard to pinpoint specific bugs. The paper describes a method to find the start and end of the buggy part of the program. The end is found through binary search, identifying the last block of instructions whose removal stops the bug. Finding the start is trickier, involving maintaining the program’s architectural state to pinpoint the initial buggy instruction. The resulting smaller program still triggers the bug, though the paper doesn’t specify how much smaller it is.
Conclusion
In conclusion, the paper is highly commendable for its innovative approach to CPU fuzzing. It not only explores the complex process of creating entangled data and control flow programs but also demonstrates the effectiveness of these methods with real-world examples. Significantly, it highlights the vast potential of pre-silicon analysis in finding and fixing CPU bugs before they become a part of the final product.