results/classifier/zero-shot/118/device/1542


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

device: 0.810
performance: 0.795
graphic: 0.737
network: 0.702
VMM: 0.672
kernel: 0.670
architecture: 0.646
socket: 0.633
mistranslation: 0.620
ppc: 0.613
semantic: 0.594
permissions: 0.587
peripherals: 0.580
PID: 0.539
register: 0.522
vnc: 0.513
arm: 0.500
risc-v: 0.494
hypervisor: 0.453
i386: 0.449
files: 0.432
x86: 0.421
debug: 0.409
TCG: 0.353
assembly: 0.342
virtual: 0.333
KVM: 0.330
boot: 0.301
user-level: 0.290

Non-Executable PMP regions of size less than 4K trigger instruction access faults non-deterministically
Description of problem:
When a non-executable PMP region of size less than 4K (page size) with a start address that is not 4K-aligned is created, QEMU will non-deterministically dispatch instruction access faults when instructions are executed from the PMP-covered region (will in some cases, won't in others, based on the current TLB state)
Steps to reproduce:
1. Create a PMP region of size less than 4K, that is not aligned to the start of the page, make it non-executable
2. Flush TLB with `sfence.vma x0, x0`
3. Jump to the start of the pmp-protected page and start executing instructions
4. Notice that no instruction access fault is reported once we reach the protected region inside the page
Additional information:
@rth7680 I believe this is at least partially an unintentional result of this commit that you authored: 7e0d9973ea665bf459b2dbd173d0e51bc6ca5216, which modified the behavior of `get_page_addr_code_hostp` probes to probe a single byte, instead of a full page size (signaled by passing 0).
This means that we initially probe the first byte of the page, see that no PMP faults are raised, and then assume that no other bytes in the page can cause a PMP fault.

Note that I believe that simply changing this back to 0 from 1 is not enough, as this will likely simply reintroduce the issue I originally reported in #1053.