Carding 4 Carders
Professional
Researchers from the Swiss Higher Technical School Zurich have developed a Cascade fuzzing testing system aimed at detecting errors and vulnerabilities in processors based on the RISC-V architecture. The toolkit has already identified 37 errors in processors, of which 29 were classified as previously unknown vulnerabilities.
Cascade developers tried to take into account the shortcomings of previously existing processor fuzzing testing systems, which were limited to executing only short pieces of code covering a small part of the instruction set and a limited number of instruction execution combinations. Cascade is aimed at generating large and complex programs that cover non-trivial instruction execution flows and lead to atypical CPU states. In Cascade, using the existing reference model of the RISC-V instruction set (RISC-V ISA), initially correct large randomized and interconnected execution flows (control flow) and data flow (data flow) are formed.
The execution and data flows in the generated program are closely intertwined, so if an error occurs in the data flow during execution, it will cascade into the subsequent execution process and most likely change the execution flow, which will lead to program incompletion. To identify problematic instructions in incomplete programs, Cascade gradually automatically reduces the running program until the minimum set of instructions that causes an error is found. This approach is much easier to implement and faster than classical error detection methods based on checking the state of actual execution with the state of the reference model c after each executed instruction.
Cascade tested five processors based on the RISC architecture-Kronos, PicoRV32, VexRiscv, CVA6, and BOOM - with a total of 37 errors detected. Most of the errors could lead to security issues, for example, some problems caused denial of service or information leaks during speculative execution of instructions by an unprivileged user.
• 12 errors led to a violation of the integrity of the data stream, which can be used to change the result of performing certain calculations in the code of another user when an attacker forms a certain state of microarchitectural structures. For example, a dynamic rounding error in CPU BOOM allows an attacker to use a different floating-point rounding mode in the victim's process.
* 18 errors led to information leaks, which, for example, allows an attacker to gain access to the state of FPU flags and registers through data analysis via third-party channels.
* 9 errors made it possible to intercept the execution flow, which allows an attacker to influence the execution of another program. For example, an error in the CVA6 processor resulted in setting incorrect flags that affect the result of calculations or overflow detection, and errors in VexRiscv processors led to incorrect execution of register comparison operations under certain conditions.
• 9 errors are related to false exception generation, which could be used by attackers to bypass isolation modes used, for example, in TEE environments (Trusted Execution Environment). For example, the exception was caused by reading some CSR registers (Control and Status Register), which allowed an attacker to simulate interaction with the system.
• 4 errors are caused by a lack of proper checks and allow an attacker to bypass security-related checks (for example, checks on the use of the FPU by other cores), substitute false information about the available CPU capabilities, or deceive analyzer programs.
* Three errors caused the processor to freeze when performing certain manipulations at any privilege level.
• One error was classified as a possibility of embedding hidden logic at the chip design stage (a malicious participant could make an error in the project by transmitting an apparently harmless description of the register transfer level (RTL)). Cascade discovered 3 inaccurate performance counter bugs (Perfcnts) in Kronos, VexRiscv and BOOM (K4, V13, B2). They incur an offset in the retired instruction counters when written by software.
Cascade developers tried to take into account the shortcomings of previously existing processor fuzzing testing systems, which were limited to executing only short pieces of code covering a small part of the instruction set and a limited number of instruction execution combinations. Cascade is aimed at generating large and complex programs that cover non-trivial instruction execution flows and lead to atypical CPU states. In Cascade, using the existing reference model of the RISC-V instruction set (RISC-V ISA), initially correct large randomized and interconnected execution flows (control flow) and data flow (data flow) are formed.
The execution and data flows in the generated program are closely intertwined, so if an error occurs in the data flow during execution, it will cascade into the subsequent execution process and most likely change the execution flow, which will lead to program incompletion. To identify problematic instructions in incomplete programs, Cascade gradually automatically reduces the running program until the minimum set of instructions that causes an error is found. This approach is much easier to implement and faster than classical error detection methods based on checking the state of actual execution with the state of the reference model c after each executed instruction.
Cascade tested five processors based on the RISC architecture-Kronos, PicoRV32, VexRiscv, CVA6, and BOOM - with a total of 37 errors detected. Most of the errors could lead to security issues, for example, some problems caused denial of service or information leaks during speculative execution of instructions by an unprivileged user.
• 12 errors led to a violation of the integrity of the data stream, which can be used to change the result of performing certain calculations in the code of another user when an attacker forms a certain state of microarchitectural structures. For example, a dynamic rounding error in CPU BOOM allows an attacker to use a different floating-point rounding mode in the victim's process.
* 18 errors led to information leaks, which, for example, allows an attacker to gain access to the state of FPU flags and registers through data analysis via third-party channels.
* 9 errors made it possible to intercept the execution flow, which allows an attacker to influence the execution of another program. For example, an error in the CVA6 processor resulted in setting incorrect flags that affect the result of calculations or overflow detection, and errors in VexRiscv processors led to incorrect execution of register comparison operations under certain conditions.
• 9 errors are related to false exception generation, which could be used by attackers to bypass isolation modes used, for example, in TEE environments (Trusted Execution Environment). For example, the exception was caused by reading some CSR registers (Control and Status Register), which allowed an attacker to simulate interaction with the system.
• 4 errors are caused by a lack of proper checks and allow an attacker to bypass security-related checks (for example, checks on the use of the FPU by other cores), substitute false information about the available CPU capabilities, or deceive analyzer programs.
* Three errors caused the processor to freeze when performing certain manipulations at any privilege level.
• One error was classified as a possibility of embedding hidden logic at the chip design stage (a malicious participant could make an error in the project by transmitting an apparently harmless description of the register transfer level (RTL)). Cascade discovered 3 inaccurate performance counter bugs (Perfcnts) in Kronos, VexRiscv and BOOM (K4, V13, B2). They incur an offset in the retired instruction counters when written by software.
