Re: [PATCH v10 3/9] riscv: sse: mask events during shutdown and kexec

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Normal kexec fails to mask SSE events on both the boot and secondary CPUs, risking arbitrary code execution or memory corruption in the new kernel context.
- [High] The patch fails to mask SSE during normal panics on uniprocessor (UP) kernels, leaving the kernel vulnerable to firmware events while in a panicked state.
- [High] The hibernation resume path does not mask SSE events before restoring the image, leading to a window where firmware may use an invalidated handler context.
--

commit cf02237f794742a346c6ebd5d4d2368943f1d5da
Author: Zhanpeng Zhang <zhangzhanpeng.jasper@bytedance.com>

riscv: sse: mask events during shutdown and kexec

This commit introduces SSE masking during various shutdown paths,
including panic, CPU stop, restart, poweroff, and crash shutdown. It
ensures that a hart stops accepting SSE events before Linux stops
servicing the registered handlers.

> diff --git a/arch/riscv/kernel/machine_kexec.c b/arch/riscv/kernel/machine_kexec.c
> index 738df176ff6f1..24e7affae70bf 100644
> --- a/arch/riscv/kernel/machine_kexec.c
> +++ b/arch/riscv/kernel/machine_kexec.c
[ ... ]
> @@ -127,6 +137,7 @@ void
>  machine_crash_shutdown(struct pt_regs *regs)
>  {
>  	local_irq_disable();
> +	riscv_sse_mask_current_hart();
>  
>  	/* shutdown non-crashing cpus */

[Severity: High]
This covers the crash shutdown path, but does the normal kexec path also
need to mask SSE events?

It looks like machine_shutdown() in arch/riscv/kernel/machine_kexec.c
misses an explicit call to riscv_sse_mask_current_hart() for the boot CPU
before jumping to the new image:

arch/riscv/kernel/machine_kexec.c:machine_shutdown() {
    local_irq_disable();
    ...
    smp_shutdown_nonboot_cpus(smp_processor_id());
}

Additionally, for secondary CPUs, smp_shutdown_nonboot_cpus() routes
through CPU hotplug and eventually calls sbi_cpu_stop() in
arch/riscv/kernel/cpu_ops_sbi.c:

arch/riscv/kernel/cpu_ops_sbi.c:sbi_cpu_stop() {
    ...
    ret = sbi_hsm_hart_stop();
}

This path also appears to miss masking the SSE state, which would leave it
unmasked when the new kernel brings them back up.

Could firmware deliver SSE events to stale handler addresses after a normal
kexec under these conditions?

> diff --git a/arch/riscv/kernel/reset.c b/arch/riscv/kernel/reset.c
> index 14eb08a6db855..fdab37e7ae52d 100644
> --- a/arch/riscv/kernel/reset.c
> +++ b/arch/riscv/kernel/reset.c
> @@ -6,6 +6,20 @@
>  #include <linux/efi.h>
>  #include <linux/reboot.h>
>  #include <linux/pm.h>
> +#include <linux/smp.h>
> +
> +#include <asm/sse.h>
> +
> +#ifndef CONFIG_SMP
> +void __noreturn panic_smp_self_stop(void)
> +{
> +	riscv_sse_mask_current_hart();
> +	local_irq_disable();
> +
> +	for (;;)
> +		cpu_relax();
> +}
> +#endif

[Severity: High]
Will this function actually be called for the primary panicking CPU on
uniprocessor builds?

Looking at kernel/panic.c, the primary panicking CPU enters this branch:

kernel/panic.c:vpanic() {
    if (panic_try_start()) {
        /* go ahead */
    } else if (panic_on_other_cpu())
        panic_smp_self_stop();
    ...
}

Since panic_try_start() returns true for the panicking CPU, it bypasses
panic_smp_self_stop() and instead relies on smp_send_stop(). However,
smp_send_stop() is an empty macro on UP builds.

Does this leave the kernel vulnerable to firmware events while in a panicked
state on UP kernels, since the CPU enters the final infinite loop without
masking SSE?

[ ... ]
> @@ -30,12 +46,14 @@ void machine_restart(char *cmd)
>  
>  void machine_halt(void)
>  {
> +	riscv_sse_mask_current_hart();
>  	do_kernel_power_off();
>  	default_power_off();
>  }
>  
>  void machine_power_off(void)
>  {
> +	riscv_sse_mask_current_hart();
>  	do_kernel_power_off();
>  	default_power_off();
>  }

[Severity: High]
Since we are masking SSE events for power off and restart, do we also need
to mask them during hibernation resume?

When the temporary restore kernel jumps to overwrite its own memory with the
hibernated kernel's image in swsusp_arch_resume(), it doesn't seem to
explicitly mask SSE events:

arch/riscv/kernel/hibernate.c:swsusp_arch_resume() {
    ...
    hibernate_restore_image(resume_hdr.saved_satp, ...);
    return 0;
}

If an SSE event triggers immediately after the overwrite, could firmware jump
into corrupted memory because it still retains the temporary kernel's SSE
handler registrations?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260911121456.33223-1-zhangzhanpeng.jasper@bytedance.com?part=3