blob: 779ede768abff79f4e47bdd3516315dc9fb649d2 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
graphic: 0.888
performance: 0.825
risc-v: 0.821
semantic: 0.794
device: 0.759
architecture: 0.728
files: 0.716
permissions: 0.698
peripherals: 0.615
ppc: 0.595
PID: 0.570
socket: 0.556
network: 0.547
vnc: 0.528
kernel: 0.528
i386: 0.516
mistranslation: 0.483
x86: 0.477
arm: 0.402
debug: 0.394
hypervisor: 0.379
register: 0.371
boot: 0.357
assembly: 0.348
VMM: 0.341
user-level: 0.336
TCG: 0.316
virtual: 0.244
KVM: 0.207
Invalid memory access allowed (possibly due to TLB bypassing PMP after mret)
Description of problem:
A load instruction that should be blocked by PMP due to MPRV changing the effective privilege mode to U is allowed. The sequence that I observed was:
1. Be in machine mode.
2. Set MPP to U (0).
3. Set MPRV to 1.
4. Enter an ISR, setting MPP to M (3).
5. Load from address xxxx (populating the QEMU TLB).
6. Execute mret, setting MPP back to U (0).
7. Load from address xxxx, which should fail but succeeds without any TLB fill.
Steps to reproduce:
```
git clone https://github.com/dreiss/qemu_pmp_repro
cd qemu_pmp_repro
./build_and_run.sh
```
The `build_and_run.sh` script expects `riscv-none-elf-gcc` and `qemu-system-riscv64` on PATH. It will also attempt to run the reproducer with `spike`, the reference RISC-V emulator, which succeeds.
Additional information:
Adding a call to `tlb_flush` to `helper_mret` causes this test to pass in QEMU, but I don't know if that's a valid fix.
Output from `build_and_run.sh`:
[output.txt](/uploads/108547bcb160a8f0bfffe72ea77b215f/output.txt)
|
