Re: [PATCH v6 6/8] RISC-V: KVM: Delegate SPELP bit to VS/VU mode if landing pad is enabled.

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The guest's Expected Landing Pad (ELP) state is not exposed to the KVM userspace API, causing silent loss of Forward-Edge CFI protection across live migrations.
- [High] KVM fails to initialize ENVCFG_LPE and ENVCFG_SSE in vcpu->arch.cfg.henvcfg when the Zicfilp/Zicfiss extensions are enabled, rendering the SPELP trap redirection dead code and silently disabling guest CFI protections.
--

--- Patch [6]: [PATCH v6 6/8] RISC-V: KVM: Delegate SPELP bit to VS/VU mode if landing pad is enabled. ---
commit bd73a6254729060ad92677fe490d23fc4aea31a6
Author: Inochi Amaoto <inochiama@gmail.com>

RISC-V: KVM: Delegate SPELP bit to VS/VU mode if landing pad is enabled.

This commit delegates the SPELP bit from the Zicfilp extension to VS/VU
mode when landing pad support is enabled. It clears and updates the guest
SSTATUS.SPELP bit during trap redirection based on the guest context.

> diff --git a/arch/riscv/kvm/vcpu_exit.c b/arch/riscv/kvm/vcpu_exit.c
> --- a/arch/riscv/kvm/vcpu_exit.c
> +++ b/arch/riscv/kvm/vcpu_exit.c

[ ... ]

> @@ -154,6 +154,13 @@ void kvm_riscv_vcpu_trap_redirect(struct kvm_vcpu *vcpu,
>  	/* Clear Guest SSTATUS.SIE bit */
>  	vsstatus &= ~SR_SIE;
>  
> +	/* Change Guest SSTATUS.SPELP bit */
> +	if (vcpu->arch.cfg.henvcfg & ENVCFG_LPE) {

[Severity: High]
Will this condition ever be true? Looking at the vCPU initialization
code in kvm_riscv_vcpu_config_ran_once(), it appears KVM does not currently
set ENVCFG_LPE or ENVCFG_SSE in henvcfg when the Zicfilp or Zicfiss
extensions are available.

If ENVCFG_LPE is never initialized, this block becomes dead code, and writes
to the guest's SENVCFG CSR for landing pads would be silently ignored by the
hardware. Should the HENVCFG setup be added to
kvm_riscv_vcpu_config_ran_once() so the guest can successfully enable
CFI protections?

> +		vsstatus &= ~SR_SPELP;
> +		vsstatus |= vcpu->arch.guest_context.sstatus & SR_SPELP;
> +		vcpu->arch.guest_context.sstatus &= ~SR_SPELP;

[Severity: High]
Does this new SPELP state need to be exposed to userspace to prevent
losing the landing pad state across live migrations?

When a guest traps to the hypervisor, the hardware saves the active ELP
state, which KVM now stores in vcpu->arch.guest_context.sstatus. However,
when userspace reads the core registers during migration:

arch/riscv/kvm/vcpu_onereg.c:kvm_riscv_vcpu_get_reg_core() {
        ...
        else if (reg_num == KVM_REG_RISCV_CORE_REG(mode))
                reg_val = (cntx->sstatus & SR_SPP) ?
                                KVM_RISCV_MODE_S : KVM_RISCV_MODE_U;
        ...
}

The SPELP bit is not extracted, meaning the VMM cannot save or restore
the guest's ELP state. If a migration occurs immediately after an indirect
branch in the guest, would resuming on the destination node with ELP=0
silently bypass the Zicfilp CFI hardware check?

> +	}
> +
>  	/* Update Guest SSTATUS */
>  	ncsr_write(CSR_VSSTATUS, vsstatus);
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260713010302.303278-1-inochiama@gmail.com?part=6