linux-kernel - Re: [PATCH] ACPI: APEI: GHES: Improve ghes_notify

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: <aQvjenMVnpOgne1t@agluck-desk3>
Date: Wed, 5 Nov 2025 15:53:30 -0800
From: "Luck, Tony" <tony.luck@...el.com>
To: Yazen Ghannam <yazen.ghannam@....com>
CC: "Rafael J. Wysocki" <rafael@...nel.org>, Borislav Petkov <bp@...en8.de>,
	Hanjun Guo <guohanjun@...wei.com>, Mauro Carvalho Chehab
	<mchehab@...nel.org>, <linux-acpi@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <patches@...ts.linux.dev>, Andi Kleen
	<andi.kleen@...el.com>
Subject: Re: [PATCH] ACPI: APEI: GHES: Improve ghes_notify_nmi() status check

On Wed, Nov 05, 2025 at 04:19:24PM -0500, Yazen Ghannam wrote:
> On Mon, Nov 03, 2025 at 03:05:47PM -0800, Tony Luck wrote:
> > N.B. I only talked to an Intel BIOS expert about this. GHES code is shared by
> > other architectures, so it would be wise to get confirmation on whether this
> > assumption applies to all, or is Intel (or X86) specific.
> 
> I think that is how the ACPI spec describes it.
> https://uefi.org/specs/ACPI/6.5/18_Platform_Error_Interfaces.html?highlight=hest#error-source-discovery
> 
> The HEST and other tables are fixed at init time. There's an ACPI notify
> event for if/when a device method needs to be re-evaluted, but I don't
> think anything in APEI expects that.

Yazen,

Thanks for looking.

James Morse pointed me to the fact that HAVE_ACPI_APEI_NMI
is only selected by arch/x86/Kconfig. So scope is limited
to x86.

That "18.3 Error Source Discovery" section of the ACPI spec feels
pretty vague. The "During initialization, OSPM examines the tables"
bit is comforting, but I was worried that although the tables are
static (so the generic ACPI address from the NMI error source
shouldn't change) there is an extra level of indirection where
that points to a location that holds the address of the error
status block. Some might not consider that as part of the "tables".

Further pondering has me 99% convinced that there would be no
reason for firmware to update that pointer (though it has led
me to wonder why that indirection exists).

Rafael: I think this patch is good to go.

-Tony