You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: