All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 0/2] target/riscv: report the no-PMP-rule fault on the S/U fetch rather than on mret
@ 2026-10-28 20:01 tewaro
  2026-10-28 20:01 ` [PATCH v2 1/2] target/riscv: do not raise the no-PMP-rule access fault from mret tewaro
  2026-10-28 20:01 ` [PATCH v2 2/2] tests/tcg/riscv64: add test for mret to S-mode with no PMP entry tewaro
  0 siblings, 2 replies; 3+ messages in thread
From: tewaro @ 2026-10-28 20:01 UTC (permalink / raw)
  To: qemu-devel
  Cc: qemu-riscv, palmer, alistair.francis, liwei1518, daniel.barboza,
	zhiwei_liu, chao.liu, disclosures, tewaro, tewaro

Hi,

When PMP is implemented but no PMP entry has been configured, QEMU
raises the resulting access fault on the mret itself rather than on the
first S/U-mode fetch after it. The access is correctly denied either
way, but because the trap is taken before the privilege switch, S-mode
can never be entered on such a configuration. Patch 1 has the details
and the history; patch 2 adds a tests/tcg/riscv64 system test that
fails before and passes after it.

This is not reachable from S/U-mode or from a guest, since mret and
mnret are M-mode-only and PMP is configured from M-mode. The affected
software is firmware that executes mret with PMP present and no entry
configured, so I do not consider this a security issue. The same
symptom was reported in GitLab issue #2074; the earlier discussions in
Launchpad #1923197 and GitLab #585 were about whether the access should
fail, which is not in question here.

Tested with make check-tcg for riscv64-softmmu, and by rebuilding
v6.0.0 and v7.2.0 with only the mret check removed to confirm that the
normal PMP path has always handled this case on its own.

Provenance: the bug was found, and the analysis above was debugged, with
the help of Claude (Anthropic), used as a research and debugging aid as
permitted by docs/devel/code-provenance.rst. The code and the text of
the patches were written by me.

Changes in v2:
- Rebased onto current master (73294d096c). The new meson.build entry
  now sits among the tests added since v1; no other change.
- Resent over SMTP. v1 went out through the Gmail API, which rewrapped
  long lines, stripped trailing whitespace and replaced the Message-IDs,
  so it did not apply and the patches were not threaded under the cover
  letter. Thanks to Daniel for catching it.

v1: https://lore.kernel.org/qemu-devel/CAEq2Q90UbCK2=7SFGQErviup1=u0AYVf=n90NaJvo1M9N=_BUA@mail.gmail.com/


tewaro (2):
  target/riscv: do not raise the no-PMP-rule access fault from mret
  tests/tcg/riscv64: add test for mret to S-mode with no PMP entry

 target/riscv/tcg/op_helper.c         |  10 +--
 tests/tcg/riscv64/system/meson.build |   1 +
 tests/tcg/riscv64/test-mret-nopmp.S  | 100 +++++++++++++++++++++++++++
 3 files changed, 103 insertions(+), 8 deletions(-)
 create mode 100644 tests/tcg/riscv64/test-mret-nopmp.S

-- 
2.54.0 (Apple Git-157)



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-10-28 20:02 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-28 20:01 [PATCH v2 0/2] target/riscv: report the no-PMP-rule fault on the S/U fetch rather than on mret tewaro
2026-10-28 20:01 ` [PATCH v2 1/2] target/riscv: do not raise the no-PMP-rule access fault from mret tewaro
2026-10-28 20:01 ` [PATCH v2 2/2] tests/tcg/riscv64: add test for mret to S-mode with no PMP entry tewaro

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.