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: <55527575-e3b8-4cf6-b09c-b81437e0c892@intel.com>
Date: Wed, 7 May 2025 14:48:34 -0700
From: Sohil Mehta <sohil.mehta@...el.com>
To: Peter Zijlstra <peterz@...radead.org>
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 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.

>>  	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;
}

>>  	/*
>>  	 * NMIs are edge-triggered, which means if you have enough
>>  	 * of them concurrently, you can lose some because only one
>>  	 * can be latched at any given time.  Walk the whole list
>>  	 * to handle those situations.
>> +	 *
>> +	 * However, NMI-source reporting does not have this limitation.
>> +	 * When NMI-source information is available, only run the
>> +	 * handlers that match the reported vectors.
>>  	 */
>>  	list_for_each_entry_rcu(a, &desc->head, list) {
>>  		int thishandled;
>>  		u64 delta;
>>  
>> +		if (source_bitmap && !match_nmi_source(source_bitmap, a))
>> +			continue;
> 
> 		if (!(souce & BIT(a->source_vector)))
> 			continue;
> 
>>  		delta = sched_clock();
>>  		thishandled = a->handler(type, regs);
>>  		handled += thishandled;