Re: [PATCH v4 2/3] riscv: vector: allow non-preemptible kernel-mode vector with IRQs off

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Removing the `!irqs_disabled()` check from `may_use_simd()` exposes KVM guest vector state to corruption and leakage by hardirqs.
--

--- Patch [2]: [PATCH v4 2/3] riscv: vector: allow non-preemptible kernel-mode vector with IRQs off ---
commit db1e5a6ad1a80d124f168f9dae7f399f6eec4f67
Author: Andy Chiu <tchiu@tenstorrent.com>

riscv: vector: allow non-preemptible kernel-mode vector with IRQs off

This commit upgrades get/put_cpu_vector_context to allow safe execution under
both IRQ off and regular process context, similar to arm64/fpsimd. It also
exports these symbols for the KVM module to call.

> diff --git a/arch/riscv/include/asm/simd.h b/arch/riscv/include/asm/simd.h
> index adb50f3ec2057..f176a8072c625 100644
> --- a/arch/riscv/include/asm/simd.h
> +++ b/arch/riscv/include/asm/simd.h
[ ... ]
> @@ -36,20 +36,10 @@ static __must_check inline bool may_use_simd(void)
>  	/*
>  	 * Nesting is achieved in preempt_v by spreading the control for
>  	 * preemptible and non-preemptible kernel-mode Vector into two fields.
> -	 * Always try to match with preempt_v if kernel V-context exists. Then,
> -	 * fallback to check non preempt_v if nesting happens, or if the config
> -	 * is not set.
> +	 * Only non-preempt_v can nest on top of preempt_v, if non-preempt_v is
> +	 * unavailable, then preempt_v is not allowed.
>  	 */
> -	if (IS_ENABLED(CONFIG_RISCV_ISA_V_PREEMPTIVE) && current->thread.kernel_vstate.datap) {
> -		if (!riscv_preempt_v_started(current))
> -			return true;
> -	}
> -	/*
> -	 * Non-preemptible kernel-mode Vector temporarily disables bh. So we
> -	 * must not return true on irq_disabled(). Otherwise we would fail the
> -	 * lockdep check calling local_bh_enable()
> -	 */
> -	return !irqs_disabled() && !(riscv_v_flags() & RISCV_KERNEL_MODE_V);
> +	return !(riscv_v_flags() & RISCV_KERNEL_MODE_V);

[Severity: High]
Does removing the !irqs_disabled() check here expose KVM guest vector state
to corruption and leakage by hardirqs?

If KVM loads guest vector state into CPU registers during kvm_arch_vcpu_load(),
and a hardirq using vector instructions fires while running KVM code,
may_use_simd() will now return true.

Would kernel_vector_begin() then save the CPU hardware registers (which contain
KVM guest data) into the host task's current->thread.vstate, followed by the
hardirq clobbering the CPU registers with its own vector operations?

If this happens, when the hardirq returns KVM would resume with corrupted
vector state, and the host task (e.g., QEMU) could receive the leaked guest
state.

While this series exports KVM symbols to potentially let KVM set
RISCV_KERNEL_MODE_V to protect the state, are the actual KVM patches to set
this flag missing from this series, leaving the tree vulnerable in the interim?

>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260725001749.2579274-1-tchiu@tenstorrent.com?part=2