PMP address range bug in QEMU

[dayeol]

SM region is accessible even there is the first PMP entry holding a right NAPOT-decoded address range covering the entire SM.
I suspect QEMU because this didn't happen before bumping QEMU to the latest version.
But the security monitor could be wrong, so we need more inspection.

[dayeol]

Tested in older version of QEMU and SiFive Unleashed.
Results when I try to access 0x80000000:
(1) Older QEMU - hangs

root@ucbva:~# busybox devmem 0x80000000
[hangs]

(2) SiFive Unleashed - kernel fault (works good)

# devmem 0x801ffff0
[   26.586560] devmem[147]: unhandled signal 11 code 0x2 at 0x000000000001be9c in busybox[10000+94000]
[   26.594843] CPU: 1 PID: 147 Comm: devmem Tainted: G        W        4.15.0-00082-g49ec1028b07c #31
[   26.603782] sepc: 000000000001be9c ra : 000000000001bdde sp : 0000003fffb8bb40
[   26.610984]  gp : 00000000000a64b0 tp : 0000002000157710 t0 : 000000000000013a
[   26.618192]  t1 : 00000020000d68fe t2 : ffffffffffffffff s0 : 0000000000000020
[   26.625391]  s1 : 0000000000000ff0 a0 : 0000002000159000 a1 : 0000000000002000
[   26.632603]  a2 : 0000000000000001 a3 : 0000000000000001 a4 : 0000000000000020
[   26.639808]  a5 : 0000002000159ff0 a6 : 0000000000000000 a7 : 00000000000000de
[   26.647009]  s2 : 0000000000000002 s3 : 0000003fffb8bd90 s4 : 0000000000000003
[   26.654222]  s5 : 0000000000002000 s6 : 0000002000159000 s7 : 0000000000000014
[   26.661426]  s8 : 0000002000157720 s9 : 00000000000a8000 s10: 0000000000000000
[   26.668634]  s11: 00000000000ac6d5 t3 : 000000000009e8fe t4 : 0000000000000002
[   26.675833]  t5 : 0000002000039eec t6 : 0000000000000000
[   26.681138] sstatus: 8000000200006020 sbadaddr: 0000002000159ff0 scause: 0000000000000005
Segmentation fault

[dayeol]

Obviously QEMU

[dayeol]

Related Issues:
riscvarchive/riscv-qemu#184
riscvarchive/riscv-qemu#185

[dayeol]

So far, those issues are not being handled by QEMU folks.
We might need to fix them ourselves

[silviuk]

Has this qemu bug been fixed in upstream so that can keystone be tested correctly in qemu now?
The riscv-qemu fork page linked in the documentation says "The RISC-V QEMU Port is Upstream".

[dayeol]

This has been fixed in upstream QEMU, and also an additional bug fix around PMP will be landing soon (v4.2)

Our latest dev branch bumped upstream QEMU v4.1 (#132) and has a local patch for the issue.
Thus, this issue was completely resolved.

@silviuk Since our QEMU requires an additional patch for emulating secure boot (with bootrom),
the upstream QEMU binary will not produce a valid attestation results.

If you don't need to test the attestation, you can use the v4.2 binary when it comes out.
Just remove the bootrom from QEMU parameters.