mirror of
https://gitlab.com/qemu-project/qemu
synced 2024-09-06 18:05:37 +00:00
2e98339918
For a TOR entry to match, the stard address must be lower than the end address. Normally this is always the case, but correct code might still run into the following scenario: Initial state: pmpaddr3 = 0x2000 pmp3cfg = OFF pmpaddr4 = 0x3000 pmp4cfg = TOR Execution: 1. write 0x40ff to pmpaddr3 2. write 0x32ff to pmpaddr4 3. set pmp3cfg to NAPOT with a read-modify-write on pmpcfg0 4. set pmp4cfg to NAPOT with a read-modify-write on pmpcfg1 When (2) is emulated, a call to pmp_update_rule() creates a negative range for pmp4 as pmp4cfg is still set to TOR. And when (3) is emulated, a call to tlb_flush() is performed, causing pmp_get_tlb_size() to return a very creatively large TLB size for pmp4. This, in turn, may result in accesses to non-existent/unitialized memory regions and a fault, so that (4) ends up never being executed. This is in m-mode with MPRV unset, meaning that unlocked PMP entries should have no effect. Therefore such a behavior based on PMP content is very unexpected. Make sure no negative PMP range can be created, whether explicitly by the emulated code or implicitly like the above. Signed-off-by: Nicolas Pitre <nico@fluxnic.net> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <3oq0sqs1-67o0-145-5n1s-453o118804q@syhkavp.arg> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> |
||
|---|---|---|
| .. | ||
| alpha | ||
| arm | ||
| avr | ||
| cris | ||
| hexagon | ||
| hppa | ||
| i386 | ||
| loongarch | ||
| m68k | ||
| microblaze | ||
| mips | ||
| nios2 | ||
| openrisc | ||
| ppc | ||
| riscv | ||
| rx | ||
| s390x | ||
| sh4 | ||
| sparc | ||
| tricore | ||
| xtensa | ||
| Kconfig | ||
| meson.build | ||