Headline

CVE-2022-34640: [Bug Report] Incorrect *tval for ecall/ebreak · Issue #898 · openhwgroup/cva6

The *tval of ecall/ebreak in CVA6 commit d315ddd0f1be27c1b3f27eb0b8daf471a952299a was discovered to be incorrect.

2 years ago

Our co-simulation framework found that the *tval of ecall/ebreak is incorrect.
In cva6, after ecall/ebreak, *tval will set to the machine code of the ecall/ebreak instruction.

In the following test case, after calling ebreak in s-mode, the value of mtval register is written to 0x100073, which is the machine code of ebreak instruction.

[spike] core   0: 0x0000000080000174 (0x00100193) li      gp, 1
[cva6]       664ns      649 S 0000000080000174 0 00100193 li             gp, 1
[cva6]  Exception @     66500, PC: 0000000080000178, Cause: Breakpoint, tval: 0000000000100073
[spike] core   0: 0x0000000080000178 (0x00100073) ebreak
[spike] core   0: exception trap_breakpoint, epc 0x0000000080000178
[spike] core   0:           tval 0x0000000080000178
... /* in handler */
[spike] core   0: 0x0000000080000190 (0x343022f3) csrr    t0, mtval
[error] WDATA SIM 0000000080000178, DUT 0000000000100073
[error] check board clear 5 error
[CJ]  integer register Judge Failed

riscv-priviledged P41 ：If mtval is written with a nonzero value when a breakpoint, address-misaligned, access-fault, or page-fault exception occurs on an instruction fetch, load, or store, then mtval will contain the faulting virtual address.
According to specifications, mtval should be the faulting address (or zero).

Issue 448 tests the value in stval of ecall from user mode, our verification framework further discovered that ebreak also has the same bug, and both of them could be triggered under any privilege modes.

ebreak testcase: cva6-1.zip
ecall testcase: cva6-2.zip