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: <FEE77392-D778-4412-B4B7-583EF58955EB@zytor.com>
Date: Wed, 04 Jun 2025 08:28:47 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Xin Li <xin@...or.com>, Sohil Mehta <sohil.mehta@...el.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 June 3, 2025 9:34:27 AM PDT, Xin Li <xin@...or.com> wrote:
>On 5/13/2025 1:37 PM, Sohil Mehta wrote:
>> Prior to NMI-source support, the vector information was ignored by the
>> hardware while delivering NMIs. With NMI-source, the architecture
>> currently supports a 16-bit source bitmap to identify the source of the
>> NMI. Upon receiving an NMI, this bitmap is delivered as part of the FRED
>> event delivery mechanism to the kernel.
>> 
>> Assign a vector space of 0-15 that is specific to NMI-source and
>> independent of the IDT vector space of 0-255. Being a bitmap, the
>> NMI-source vectors do not have any inherent priority associated with
>> them. The order of executing the NMI handlers is up to the kernel.
>
>I'm thinking should we mention that the bitmap could be extended more
>than 16 bits in future?  Or we just don't emphasize 16-bit or 0~15?
>
>
>> 
>> Existing NMI handling already has a priority mechanism for the NMI
>> handlers, with CPU-specific (NMI_LOCAL) handlers executed first,
>> followed by platform NMI handlers and unknown NMI (NMI_UNKNOWN) handlers
>> being last. Within each of these NMI types, the handlers registered with
>> NMI_FLAG_FIRST are given priority.
>> 
>> NMI-source follows the same priority scheme to avoid unnecessary
>> complexity. Therefore, the NMI-source vectors are assigned arbitrarily,
>> except for vectors 0 and 2.
>> 
>> Vector 0 is set by the hardware whenever a source vector was not used
>> while generating an NMI or the originator could not be reliably
>> identified. Do not assign it to any handler.
>> 
>> Vector 2 is reserved for external NMIs corresponding to Local APIC -
>> LINT1. Some third-party chipsets may send NMI messages with a hardcoded
>> vector of 2, which would result in vector 2 being set in the NMI-source
>> bitmap. To avoid confusion, do not assign vector 2 to any handler.
>> 
>> NMI-source vectors are only assigned for NMI_LOCAL type handlers.
>> Platform NMI handlers have a single handler registered per type. They
>> don't need additional source information to differentiate among them.
>> 
>> Use the assigned vectors to register the respective NMI handlers. Warn
>> if the vector values are unexpected.
>> 
>> A couple of NMI handlers, such as the microcode rendezvous and the crash
>> reboot, do not use the typical NMI registration interface. Leave them
>> as-is for now.
>> 
>> Originally-by: Jacob Pan <jacob.jun.pan@...ux.intel.com>
>> Signed-off-by: Sohil Mehta <sohil.mehta@...el.com>
>
>Reviewed-by: Xin Li (Intel) <xin@...or.com>

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. 

   -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.