linux-kernel - Re: [PATCH v6 4/9] x86/nmi: Assign and register NMI-source vectors

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: <707b643e-a740-49a4-a549-7d63c5f4da76@intel.com>
Date: Wed, 11 Jun 2025 14:34:51 -0700
From: Sohil Mehta <sohil.mehta@...el.com>
To: "H. Peter Anvin" <hpa@...or.com>, Xin Li <xin@...or.com>,
	<x86@...nel.org>, <linux-kernel@...r.kernel.org>
CC: 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>, Peter Zijlstra <peterz@...radead.org>, "Sean
 Christopherson" <seanjc@...gle.com>, Adrian Hunter <adrian.hunter@...el.com>,
	Kan Liang <kan.liang@...ux.intel.com>, Tony Luck <tony.luck@...el.com>,
	"Zhang Rui" <rui.zhang@...el.com>, Steven Rostedt <rostedt@...dmis.org>,
	"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>, "Sandipan
 Das" <sandipan.das@....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 v6 4/9] x86/nmi: Assign and register NMI-source vectors

On 6/4/2025 8:28 AM, H. Peter Anvin wrote:
> 
> The architectural maximum* is 63 sources (plus the error bit), 
> although the current version only supports 1-15. If extended to be 
> wider, we would presumably add a new cpuid bit.
> 
> However, we should make sure there is nothing in the implementation 
> that limits us to 16 or 32 bits; when manipulating the bitmask we 
> should use a 64 bit type.
> 

There isn't anything in the implementation that would limit it to less
than 64 bits. However, (as suggested by Dave), I am planning to include:

	BUILD_BUG_ON(NMIS_VECTORS_MAX > 16);

If someone hits this compile issue while adding new vectors, it would
help them realize the limitations of the existing hardware.

We can recommend vector aliasing at that point or if there is hardware
in the pipeline that extends this beyond 16, we can simply get rid of
the BUILD_BUG_ON() along with the patches that add the new vectors.

> -hpa
> 
> * If we were to use the additional error reporting fields in the 
> FRED frame at some future point it could be extended as far as 207, 
> but since we at this point don't have anyone clamouring for more 
> than 15 this seems like a very remote possibility.