linux-kernel - Re: [External] Re: [PATCH 3/3] riscv: crash: use NMI to stop the CPU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <DDZ8G0K2921V.8B66OPQY2GXG@ventanamicro.com>
Date: Mon, 03 Nov 2025 18:23:52 +0100
From: Radim Krčmář <rkrcmar@...tanamicro.com>
To: "yunhui cui" <cuiyunhui@...edance.com>
Cc: "Conor Dooley" <conor@...nel.org>, <paul.walmsley@...ive.com>,
 <palmer@...belt.com>, <aou@...s.berkeley.edu>, <alex@...ti.fr>,
 <luxu.kernel@...edance.com>, <atishp@...osinc.com>, <cleger@...osinc.com>,
 <ajones@...tanamicro.com>, <apatel@...tanamicro.com>,
 <linux-kernel@...r.kernel.org>, <linux-riscv@...ts.infradead.org>,
 <songshuaishuai@...ylab.org>, <bjorn@...osinc.com>, <charlie@...osinc.com>,
 <masahiroy@...nel.org>, <valentina.fernandezalanis@...rochip.com>,
 <jassisinghbrar@...il.com>, <conor.dooley@...rochip.com>, "linux-riscv"
 <linux-riscv-bounces@...ts.infradead.org>
Subject: Re: [External] Re: [PATCH 3/3] riscv: crash: use NMI to stop the
 CPU

2025-11-03T22:10:25+08:00, yunhui cui <cuiyunhui@...edance.com>:
> Hi Radim,
>
> On Tue, Oct 28, 2025 at 8:36 PM Radim Krčmář <rkrcmar@...tanamicro.com> wrote:
>>
>> 2025-10-28T10:42:12+00:00, Conor Dooley <conor@...nel.org>:
>> > On Mon, Oct 27, 2025 at 09:34:31PM +0800, Yunhui Cui wrote:
>> >> NMI is more robust than IPI for stopping CPUs during crashes,
>> >> especially with interrupts disabled. Add SBI_SSE_EVENT_LOCAL_CRASH_NMI
>> >> eventid to implement NMI for stopping CPUs.
>> >>
>> >> Signed-off-by: Yunhui Cui <cuiyunhui@...edance.com>
>> >> ---
>> >> diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
>> >> @@ -487,6 +487,7 @@ enum sbi_sse_attr_id {
>> >>  #define SBI_SSE_EVENT_GLOBAL_LOW_PRIO_RAS   0x00108000
>> >>  #define SBI_SSE_EVENT_LOCAL_SOFTWARE_INJECTED       0xffff0000
>> >>  #define SBI_SSE_EVENT_LOCAL_UNKNOWN_NMI             0xffff0001
>> >> +#define SBI_SSE_EVENT_LOCAL_CRASH_NMI               0xffff0002
>>
>> This event isn't defined in the SBI pull request.
>>
>> I assume it's a pure software event that the platform shouldn't inject.
>> If we want to reserve more events for software use, why not make them
>> generic, like SBI_SSE_EVENT_LOCAL_SOFTWARE_INJECTED?
>
> In fact, it's not just crash NMI, but also stop NMI, kgdb NMI, etc. An
> event can only register one SSE handler. If all use
> SBI_SSE_EVENT_LOCAL_SOFTWARE_INJECTED, we'll have to execute each
> different NMI handler in sequence within the SSE handler, with each
> NMI handler checking for itself if there are NMIs of its type to
> process.
> Is that what you mean too?

My main point is that a platform doesn't seem to care what 0xffff0002 is
used for, so SBI could just assign a range of SSE event vectors for
software use, without trying to be overly specific about the purpose.
(I don't see a meaningful difference between 0xffff0000 and 0xffff0002.)

Demultiplexing a single SSE event vector is possible if event handlers
don't have to (or shouldn't) preempt each other.
I assume that we do need at least two software SSE event vectors, since
we should be able to interrupt other SSE handlers to execute the SSE
crash handler.
Do you think that two software SSE events are sufficient, or should we
aim to reserve more in SBI?

Thanks.