linux-kernel - Re: [patch 37/53] x86/cpu: Detect real BSP on crash kernels

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: <871qarlvub.ffs@tglx>
Date: Mon, 08 Jan 2024 15:54:04 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: "Zhang, Rui" <rui.zhang@...el.com>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>
Cc: "jgross@...e.com" <jgross@...e.com>, "mikelley@...rosoft.com"
 <mikelley@...rosoft.com>, "arjan@...ux.intel.com" <arjan@...ux.intel.com>,
 "kprateek.nayak@....com" <kprateek.nayak@....com>, "x86@...nel.org"
 <x86@...nel.org>, "kan.liang@...ux.intel.com" <kan.liang@...ux.intel.com>,
 "thomas.lendacky@....com" <thomas.lendacky@....com>, "ray.huang@....com"
 <ray.huang@....com>, "andrew.cooper3@...rix.com"
 <andrew.cooper3@...rix.com>, "Sivanich, Dimitri"
 <dimitri.sivanich@....com>, "paulmck@...nel.org" <paulmck@...nel.org>,
 "Mehta, Sohil" <sohil.mehta@...el.com>, "andy@...radead.org"
 <andy@...radead.org>, "Tang, Feng" <feng.tang@...el.com>
Subject: Re: [patch 37/53] x86/cpu: Detect real BSP on crash kernels

On Mon, Jan 08 2024 at 14:11, Zhang, Rui wrote:
>> +static __init void check_for_kdump_kernel(void)
>> +{
>> +       u32 bsp_apicid;
>> +
>> +       /*
>> +        * There is no real good way to detect whether this a kdump()
>> +        * kernel, but except on the Voyager SMP monstrosity which is
>> not
>> +        * longer supported, the real BSP has always the lowest
>> numbered
>> +        * APIC ID. If a crash happened on an AP, which then ends up
>> as
>> +        * boot CPU in the kdump() kernel, then sending INIT to the
>> real
>> +        * BSP would reset the whole system.
>> +        */
>
>
> Hi, Thomas,
>
> Unfortunately this causes a regression on Intel Meteorlake platform,
> where the BSP APIC ID is NOT the lowest numbered APIC ID (instead,
> CPU12, the first Ecore CPU, has APIC ID 0).

Bah. Let me think about that.