KatCe
commented
3 days ago data_ack being constantly high is only valid in the Wishbone classic mode, and Kronos supports pipelined mode. However, a CPU should not rely on valid external inputs. Connecting a memory operating in classic mode or fault injections could trigger the vulnerability.
To exploit this vulnerability, the attacker consistently set the "data_ack_i" signal to 1. This behavior is permissible according to the Wishbone Interface Specification, which Kronos core is designed to follow.
If the "data_ack" signal is activated, the "lsu_rdy" signal inside the kronos_lsu.sv file will also be activated. However, because of the CPU bug, the activation of "lsu_rdy" signal without request for load or store will cause the CPU control signals to be in an erroneous state. Consequently, the "csr_wr_en" signal inside kronos_csr.sv will be wrongly activated when any arithmetic or logical instruction is executed, if there is a Zicsr instruction preceding it. This leads to the [31:20] field of this arithmetic or logical instruction being misinterpreted as the CSR write address, and the op1 field being misinterpreted as the CSR write data. As a result, a CSR is incorrectly written with the op1's data of this arithmetic or logical instruction. Subsequently, with another Zicsr instruction, the CSR value can be loaded into another GPR. This causes a functional error, as a GPR is unintentionally contaminated with the value of another GPR, leading to data leakage inside the CPU.