From: "Ard Biesheuvel" <ardb@kernel.org>
To: "Hamza Mahfooz" <hamzamahfooz@linux.microsoft.com>,
linux-efi@vger.kernel.org
Cc: "Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"Kees Cook" <kees@kernel.org>, "Arnd Bergmann" <arnd@arndb.de>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64/efi: only disable the EFI runtime service that faulted
Date: Thu, 22 Oct 2026 08:05:17 +0200 [thread overview]
Message-ID: <13d53e6d-9fc0-4926-b8e6-3ee75ea82660@app.fastmail.com> (raw)
In-Reply-To: <20261021230503.2075618-1-hamzamahfooz@linux.microsoft.com>
Hello Hamza,
On Thu, 22 Oct 2026, at 01:05, Hamza Mahfooz wrote:
> When the firmware faults while executing an EFI runtime service, arm64
> recovers from the exception, returns EFI_ABORTED to the caller and
> disables all EFI runtime services for the remainder of the boot.
>
> That is a rather big hammer.
It does not just return EFI_ABORTED to the caller. It basically does a
longjmp() out of the faulting context straight back to the caller in
the kernel, skipping all execution that would have occurred on the
way back out if the fault had not occurred.
Assuming that the runtime services are still in a sane state after this
is not justified, so I don't think making this change is a good idea.
Do the systems in question expose the RTC via the standardized ACPI
methods as well? I'd be fine with some logic that avoids rtc-efi
entirely if the RTC can be driven by a native ACPI driver: that
seems a worthwhile improvement in its own right, given that EFI
runtime services are evil and should be avoided where possible.
next prev parent reply other threads:[~2026-10-22 6:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 23:05 [PATCH] arm64/efi: only disable the EFI runtime service that faulted Hamza Mahfooz
2026-10-22 6:05 ` Ard Biesheuvel [this message]
2026-10-22 20:30 ` Hamza Mahfooz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=13d53e6d-9fc0-4926-b8e6-3ee75ea82660@app.fastmail.com \
--to=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=hamzamahfooz@linux.microsoft.com \
--cc=ilias.apalodimas@linaro.org \
--cc=kees@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox