linux-kernel - Re: Early boot regression from f0551af0213 ("x86/topology: Ignore non-present APIC IDs in a present package")

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: <87le59vw1y.ffs@tglx>
Date: Sat, 20 Apr 2024 00:15:21 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Lyude Paul <lyude@...hat.com>, Borislav Petkov <bp@...en8.de>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: Early boot regression from f0551af0213 ("x86/topology: Ignore
 non-present APIC IDs in a present package")

Paul!

On Fri, Apr 19 2024 at 13:38, Lyude Paul wrote:
> Awesome - can confirm the patch does indeed make the machine boot. Full
> dmesg from boot attached.

Thanks for providing the data.

[    0.089286] CPU topo: APIC ID 0 present 1
[    0.089294] CPU topo: APIC ID 0 present 0
[    0.089296] CPU topo: Hot-pluggable APIC ID 0 in present package.

ACPI is really a wonderland.

Can you please test the patch below?

Thanks,

        tglx
---
Subject: x86/topology: Deal with more broken ACPI tables
From: Thomas Gleixner <tglx@...utronix.de>
Date: Thu, 18 Apr 2024 21:02:39 +0200

Paul reported a regression which waas caused by the handling of non-present
CPUs in a present package. It's caused by the ACPI table on the system
which advertises APICs twice, present and non-present:

  CPU topo: APIC ID 0 present 1
  CPU topo: APIC ID 0 present 0
  CPU topo: Hot-pluggable APIC ID 0 in present package.                                                                                                                                                                         
Which causes the topology to get confused to the point that it fails to
bring the system up because the target APIC for the IOAPIC is not
available.

Prevent this by checking whether a non-present CPU has been already
registered as present before. If so emit a firmware warning and ignore the
registration request.

Fixes: f0551af0213 ("x86/topology: Ignore non-present APIC IDs in a present package")
Reported-by: Lyude Paul <lyude@...hat.com>
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
---
 arch/x86/kernel/cpu/topology.c |    6 ++++++
 1 file changed, 6 insertions(+)

--- a/arch/x86/kernel/cpu/topology.c
+++ b/arch/x86/kernel/cpu/topology.c
@@ -195,6 +195,12 @@ static __init void topo_register_apic(u3
 	} else {
 		u32 pkgid = topo_apicid(apic_id, TOPO_PKG_DOMAIN);

+		if (test_bit(apic_id, phys_cpu_present_map)) {
+			pr_warn_once(FW_BUG "Already present APIC ID %x registered again as non-present\n",
+				     apic_id);
+			return;
+		}
+
 		/*
 		 * Check for present APICs in the same package when running
 		 * on bare metal. Allow the bogosity in a guest.