<!--This is the upstream QEMU issue tracker. If you are able to, it will greatly facilitate bug triage if you attempt to reproduce the problem with the latest qemu.git master built from source. See https://www.qemu.org/download/#source for instructions on how to do this. QEMU generally supports the last two releases advertised on https://www.qemu.org/. Problems with distro-packaged versions of QEMU older than this should be reported to the distribution instead. See https://www.qemu.org/contribute/report-a-bug/ for additional guidance. If this is a security issue, please consult https://www.qemu.org/contribute/security-process/--> ## Host environment - Operating system: Ubuntu 24.04.4 LTS - OS/kernel version: Linux aster-MS-7D31 6.17.0-35-generic #35\~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue May 26 19:30:42 UTC 2 x86_64 x86_64 x86_64 GNU/Linux - Architecture: x86_64 - QEMU flavor: qemu-system-riscv64 - QEMU version: QEMU emulator version 11.0.50 (v11.0.0-2337-g60533c6193) Copyright (c) 2003-2026 Fabrice Bellard and the QEMU Project developers - QEMU command line: <!--Give the smallest, complete command line that exhibits the problem. If you are using libvirt, virsh, or vmm, you can likely find the QEMU command line arguments in /var/log/libvirt/qemu/$GUEST.log.--> ``` ./qemu-system-x86_64 -M q35 -m 4096 -enable-kvm -hda fedora32.qcow2 ``` ## Emulated/Virtualized environment - Operating system: <!--Windows 10 21H1, Fedora 37, etc.--> - OS/kernel version: <!--For POSIX guests, use `uname -a`.--> - Architecture: <!--x86, ARM, s390x, etc.--> ## Description of problem Executing `SRET` in Virtual User mode should raise a virtual-instruction exception, but QEMU raises an illegal-instruction exception instead. The RISC-V privileged specification lists the following as a virtual-instruction exception case: ```text in VU-mode, attempts to execute WFI when mstatus.TW=0, or to execute a supervisor instruction (SRET or SFENCE) ``` With the test case below, the hart is switched from Machine mode into Virtual User mode, then `sret` is executed. Expected behavior: ```text mcause = 0x16 ``` Observed behavior in QEMU: ```text mcause = 0x2 ``` This means QEMU treats VU-mode `SRET` as an ordinary insufficient-privilege illegal instruction instead of the architecturally required virtual-instruction exception. ## Steps to reproduce 1. Build this bare-metal test case: ```asm call machine_to_virtual_user sret # expected mcause = 0x16 ``` 2. Build command used: ```bash riscv64-unknown-elf-gcc \ -march=rv64imafdcvh_zicsr \ -mabi=lp64 \ -mcmodel=medany \ -nostdlib \ -nostartfiles \ -T linker.ld \ code.S machine_to_virtual.S machine_to_virtual_user.S \ -o code.elf ``` The actual local test harness used a longer `-march` string with additional extensions enabled, but the relevant requirement for this test is the Hypervisor extension. 3. Run QEMU with: ```bash qemu-system-riscv64 \ -machine virt \ -m 256M \ -bios none \ -kernel code.elf \ -serial null \ -display none \ -S -s \ -accel tcg \ -cpu rv64,h=on ``` 4. Connect with GDB: ```bash riscv64-unknown-elf-gdb code.elf set pagination off target remote :1234 c Ctrl-C info registers ``` 5. Observed result: ```text call machine_to_virtual_user sret priv = 0x4 mcause = 0x2 ``` Expected result: ```text mcause = 0x16 ``` In this GDB/QEMU output, `priv = 0x4` corresponds to Virtual User mode. ## Additional information The bare-metal test starts in Machine mode. The helper `machine_to_virtual_user` is part of the test harness. It first switches from M-mode to HS-mode, then uses `hstatus.SPV = 1` and `sret` to enter VU-mode. I verified the helper independently using a VU-mode probe: ```asm call machine_to_virtual_user csrr a0, sstatus ``` This correctly raises a virtual-instruction exception: ```text priv = 0x4 mcause = 0x16 ``` So the tested `SRET` instruction is executed in VU-mode as intended. <details> <summary>Virtual User mode helper code</summary> ```asm .globl machine_to_virtual_user machine_to_virtual_user: /* Disable guest-stage and VS-stage translation */ csrw hgatp, zero csrw vsatp, zero /* Make sure MRET goes to HS-mode first, not virtual mode */ li t6, 1 << 39 /* mstatus.MPV */ csrrc x0, mstatus, t6 /* Clear MPP */ li t6, 3 << 11 csrrc x0, mstatus, t6 /* Set MPP = S */ li t6, 1 << 11 csrrs x0, mstatus, t6 /* Clear TSR, so SRET is allowed in HS */ li t6, 1 << 22 csrrc x0, mstatus, t6 la t6, hs_to_vu csrw mepc, t6 li t6, 0 mret hs_to_vu: /* Now we are in HS-mode, V=0 */ /* hstatus.SPV = 1, so SRET returns to virtual mode */ li t6, 1 << 7 csrrs x0, hstatus, t6 /* sstatus.SPP = 0, so target nominal mode is U -> VU-mode */ li t6, 1 << 8 csrrc x0, sstatus, t6 la t6, branch_virtual_user csrw sepc, t6 li t6, 0 sret branch_virtual_user: ret ``` </details> The suspected source location is: ```text target/riscv/op_helper.c ``` The current `helper_sret()` checks whether the current privilege is at least Supervisor before checking the VU-mode virtual-instruction case: ```c target_ulong helper_sret(CPURISCVState *env) { uint64_t mstatus; privilege_mode_t prev_priv; bool prev_virt = env->virt_enabled; const privilege_mode_t src_priv = env->priv; const bool src_virt = env->virt_enabled; if (!(env->priv >= PRV_S)) { riscv_raise_exception(env, RISCV_EXCP_ILLEGAL_INST, GETPC()); } target_ulong retpc = env->sepc & get_xepc_mask(env); ... if (env->virt_enabled && get_field(env->hstatus, HSTATUS_VTSR)) { riscv_raise_exception(env, RISCV_EXCP_VIRT_INSTRUCTION_FAULT, GETPC()); } ... } ``` In VU-mode, `env->virt_enabled` is true, but `env->priv` is `PRV_U`. Therefore the first check raises `RISCV_EXCP_ILLEGAL_INST` immediately. That ordering appears to miss the architectural rule that executing a supervisor instruction such as `SRET` in VU-mode should raise a virtual-instruction exception. A possible fix direction is to handle the VU-mode case before the generic insufficient-privilege check: ```c target_ulong helper_sret(CPURISCVState *env) { uint64_t mstatus; privilege_mode_t prev_priv; bool prev_virt = env->virt_enabled; const privilege_mode_t src_priv = env->priv; const bool src_virt = env->virt_enabled; if (env->virt_enabled && env->priv < PRV_S) { riscv_raise_exception(env, RISCV_EXCP_VIRT_INSTRUCTION_FAULT, GETPC()); } if (!(env->priv >= PRV_S)) { riscv_raise_exception(env, RISCV_EXCP_ILLEGAL_INST, GETPC()); } target_ulong retpc = env->sepc & get_xepc_mask(env); ... if (env->virt_enabled && get_field(env->hstatus, HSTATUS_VTSR)) { riscv_raise_exception(env, RISCV_EXCP_VIRT_INSTRUCTION_FAULT, GETPC()); } ... } ``` Real impact: * This is not a direct host-security vulnerability. * However, it is an architectural correctness issue in the RISC-V virtualization behavior. * Conformance tests expecting `mcause = 0x16` for VU-mode `SRET` fail under QEMU. * Hypervisors or guest test harnesses may observe an illegal-instruction exception where real hardware should report a virtual-instruction exception. * This can cause guest exception handling, hypervisor trap dispatch, and emulator-vs-hardware comparison results to diverge from the RISC-V privileged specification. * The problem is visible in any test that checks the exact architectural trap cause for VU-mode supervisor-instruction execution. <!--The line below ensures that proper tags are added to the issue. Please do not remove it.-->