| 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
| ||
|
Message-ID: <CAJZ5v0hWpp2M-uDGEpM-gzRSbtGGoBfJk6PVbT71iLsovTdxTg@mail.gmail.com>
Date: Tue, 27 Jan 2026 22:05:49 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Armin Wolf <W_Armin@....de>
Cc: linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] ACPI: OSL: Panic when encountering a fatal ACPI error
On Tue, Jan 27, 2026 at 7:32 AM Armin Wolf <W_Armin@....de> wrote:
>
> The ACPI spec states that the operating system should respond
> to a fatal ACPI error by "performing a controlled OS shutdown in
> a timely fashion". Windows complies with this requirement by entering
> a BSOD upon executing the "Fatal()" ASL opcode, a implementation
> detail that is used by some firmware implementations for signaling
> fatal hardware errors.
>
> Comply with the ACPI specification by triggering a kernel panic
> when ACPICA signals a fatal ACPI error.
I'm not sure if a kernel panic really counts as "a controlled OS shutdown".
Shouldn't this be treated in a similar way to crossing a critical
thermal trip point?
Also, is there a reason beyond "follow Windows" to do this?
> Users can still disable
> this behavior by using the acpi.panic_on_fatal kernel option to
> work around firmware bugs.
This is not enough. You are talking about throwing away user data if
the firmware asks the kernel to do so.
> Link: https://uefi.org/specs/ACPI/6.6/19_ASL_Reference.html#fatal-fatal-error-check
> Signed-off-by: Armin Wolf <W_Armin@....de>
> ---
> Changes since v1:
> - use IS_ENABLED() for checking the presence of CONFIG_ACPI_PANIC_ON_FATAL
> ---
> .../admin-guide/kernel-parameters.txt | 9 +++++++++
> drivers/acpi/Kconfig | 11 +++++++++++
> drivers/acpi/osl.c | 19 ++++++++++++++++++-
> 3 files changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 1058f2a6d6a8..140bb239857f 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -187,6 +187,15 @@ Kernel parameters
> unusable. The "log_buf_len" parameter may be useful
> if you need to capture more output.
>
> + acpi.panic_on_fatal= [ACPI]
> + {0 | 1}
> + Causes the kernel to panic when the ACPI bytecode signals
> + a fatal error. The default value of this setting can
> + be configured using CONFIG_ACPI_PANIC_ON_FATAL.
> + Overriding this value should only be done for diagnosing
> + ACPI firmware problems, as some firmware implementations
> + use this mechanism to signal fatal hardware errors.
> +
> acpi_enforce_resources= [ACPI]
> { strict | lax | no }
> Check for resource conflicts between native drivers
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index df0ff0764d0d..7139e7d8ac25 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -65,6 +65,17 @@ config ACPI_THERMAL_LIB
> depends on THERMAL
> bool
>
> +config ACPI_PANIC_ON_FATAL
> + bool "Panic on fatal ACPI error"
> + default y
> + help
> + The ACPI bytecode can signal that a fatal error has occurred using the Fatal()
> + ASL operator, normaly causing a kernel panic. Disabling this option causes such
> + a condition to be treated like a ordinary ACPI error.
> +
> + This setting can also be overridden during boot using the acpi.panic_on_fatal
> + kernel parameter.
> +
> config ACPI_DEBUGGER
> bool "AML debugger interface"
> select ACPI_DEBUG
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index 05393a7315fe..6375db6d22ea 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -11,7 +11,9 @@
>
> #define pr_fmt(fmt) "ACPI: OSL: " fmt
>
> +#include <linux/kconfig.h>
> #include <linux/module.h>
> +#include <linux/panic.h>
> #include <linux/kernel.h>
> #include <linux/slab.h>
> #include <linux/mm.h>
> @@ -70,6 +72,10 @@ static bool acpi_os_initialized;
> unsigned int acpi_sci_irq = INVALID_ACPI_IRQ;
> bool acpi_permanent_mmap = false;
>
> +static bool panic_on_fatal = IS_ENABLED(CONFIG_ACPI_PANIC_ON_FATAL);
> +module_param(panic_on_fatal, bool, 0);
> +MODULE_PARM_DESC(panic_on_fatal, "Trigger a kernel panic when encountering a fatal ACPI error");
> +
> /*
> * This list of permanent mappings is for memory that may be accessed from
> * interrupt context, where we can't do the ioremap().
> @@ -1381,9 +1387,20 @@ acpi_status acpi_os_notify_command_complete(void)
>
> acpi_status acpi_os_signal(u32 function, void *info)
> {
> + struct acpi_signal_fatal_info *fatal_info;
> +
> switch (function) {
> case ACPI_SIGNAL_FATAL:
> - pr_err("Fatal opcode executed\n");
> + fatal_info = info;
> + if (panic_on_fatal) {
> + panic("Fatal ACPI BIOS error (type 0x%X code 0x%X argument 0x%X)",
> + fatal_info->type, fatal_info->code, fatal_info->argument);
> + } else {
> + pr_emerg("Fatal ACPI BIOS error (type 0x%X code 0x%X argument 0x%X)\n",
> + fatal_info->type, fatal_info->code, fatal_info->argument);
> + add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
> + }
> +
> break;
> case ACPI_SIGNAL_BREAKPOINT:
> /*
> --
> 2.39.5
>
>
Powered by blists - more mailing lists