Information Leakage Vuneratbility - via Memory

[Mengyuan410]

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. If the "lsu_rdy" signal is always activated despite there being no load/store request, the CPU control signals will be in an erroneous state. This condition causes a register data to be wrongly read as the op1 data from the register file, even when the instruction is invalid. The address of the register that is wrongly read as op1 corresponds to the invalid instruction's [19:15] bits.

Additionally, due to the CPU's erroneous state, the instruction cannot be decoded correctly. This might cause the CPU to wrongly recognize this invalid instruction as a load, resulting in an unexpected load. The wrongly read op1 data is treated as the load address. This unexpected load causes a value from memory to be inadvertently loaded into the GPR with an address equal to the invalid instruction's [11:7] bits.

This situation can be viewed in two ways:

1. Data leakage from memory to GPRs due to the unexpected load.
2. Data leakage between GPRs. Data from different memory locations will be loaded into the GPR with an address corresponding to the invalid instruction's [11:7] bits, based on the data of the GPR with an address corresponding to the invalid instruction's [19:15] bits.

[KatCe]

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.