linux-kernel - Re: [PATCH v5 5/9] x86/nmi: Add support to handle NMIs with source information

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250508121544.GH4439@noisy.programming.kicks-ass.net>
Date: Thu, 8 May 2025 14:15:44 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Sohil Mehta <sohil.mehta@...el.com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, Xin Li <xin@...or.com>,
	"H . Peter Anvin" <hpa@...or.com>,
	Andy Lutomirski <luto@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Sean Christopherson <seanjc@...gle.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Namhyung Kim <namhyung@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	Jiri Olsa <jolsa@...nel.org>, Ian Rogers <irogers@...gle.com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Kan Liang <kan.liang@...ux.intel.com>,
	Tony Luck <tony.luck@...el.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Vitaly Kuznetsov <vkuznets@...hat.com>,
	"Rafael J . Wysocki" <rafael@...nel.org>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Zhang Rui <rui.zhang@...el.com>, Lukasz Luba <lukasz.luba@....com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Brian Gerst <brgerst@...il.com>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
	Jacob Pan <jacob.pan@...ux.microsoft.com>,
	Andi Kleen <ak@...ux.intel.com>, Kai Huang <kai.huang@...el.com>,
	Nikolay Borisov <nik.borisov@...e.com>,
	linux-perf-users@...r.kernel.org, linux-edac@...r.kernel.org,
	kvm@...r.kernel.org, linux-pm@...r.kernel.org,
	linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH v5 5/9] x86/nmi: Add support to handle NMIs with source
 information

On Wed, May 07, 2025 at 02:48:34PM -0700, Sohil Mehta wrote:
> On 5/7/2025 2:14 AM, Peter Zijlstra wrote:
> > On Tue, May 06, 2025 at 06:21:41PM -0700, Sohil Mehta wrote:
> >>
> >> diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
> >> index a1d672dcb6f0..183e3e717326 100644
> >> --- a/arch/x86/kernel/nmi.c
> >> +++ b/arch/x86/kernel/nmi.c
> > 
> >>  static int nmi_handle(unsigned int type, struct pt_regs *regs)
> >>  {
> >>  	struct nmi_desc *desc = nmi_to_desc(type);
> >> +	unsigned long source_bitmap = 0;
> > 
> > 	unsigned long source = ~0UL;
> > 
> 
> Thanks! This makes the logic even simpler by getting rid of
> match_nmi_source(). A minor change described further down.
> 
> Also, do you prefer "source" over "source_bitmap"? I had it as such to
> avoid confusion between source_vector and source_bitmap.

Yeah, I was lazy typing. Perhaps just call it bitmap then?

> >>  	nmi_handler_t ehandler;
> >>  	struct nmiaction *a;
> >>  	int handled=0;
> >> @@ -148,16 +164,40 @@ static int nmi_handle(unsigned int type, struct pt_regs *regs)
> >>  
> >>  	rcu_read_lock();
> >>  
> >> +	/*
> >> +	 * Activate NMI source-based filtering only for Local NMIs.
> >> +	 *
> >> +	 * Platform NMI types (such as SERR and IOCHK) have only one
> >> +	 * handler registered per type, so there is no need to
> >> +	 * disambiguate between multiple handlers.
> >> +	 *
> >> +	 * Also, if a platform source ends up setting bit 2 in the
> >> +	 * source bitmap, the local NMI handlers would be skipped since
> >> +	 * none of them use this reserved vector.
> >> +	 *
> >> +	 * For Unknown NMIs, avoid using the source bitmap to ensure all
> >> +	 * potential handlers have a chance to claim responsibility.
> >> +	 */
> >> +	if (cpu_feature_enabled(X86_FEATURE_NMI_SOURCE) && type == NMI_LOCAL)
> >> +		source_bitmap = fred_event_data(regs);
> > 
> > 	if (cpu_feature_enabled(X86_FEATURE_NMI_SOURCE) && type == NMI_LOCAL) {
> > 		source = fred_event_data(regs);
> > 		if (source & BIT(0))
> > 			source = ~0UL;
> > 	}
> > 
> 
> Looks good, except when fred_event_data() returns 0. I don't expect it
> to happen in practice. But, maybe with new hardware and eventually
> different hypervisors being involved, it is a possibility.
> 
> We can either call it a bug that an NMI happened without source
> information. Or be extra nice and do this:
> 
> if (cpu_feature_enabled(X86_FEATURE_NMI_SOURCE) && type == NMI_LOCAL) {
> 	source = fred_event_data(regs);
> 	if (!source || (source & BIT(0)))
> 		source = ~0UL;
> }

Perhaps also WARN about the !source case?