Linux 7.3 Kernel Enforces 120-Second Halt on Abnormal EFI Processing

AFFILIATE_PRODUCTS:

EFI Protection Mechanism in Linux 7.3

A new protection mechanism has been integrated into the development Linux 7.3 kernel to prevent system freezes caused by faulty EFI firmware. A 120-second timeout is set for the completion of EFI runtime service calls, after which the firmware is declared to be in a “wedged” state.

This change addresses the serious problem where EFI firmware bugs observed on certain platforms cause the entire user space to freeze. Traditionally, the Linux kernel waited indefinitely for the completion of EFI runtime service calls. If the buggy firmware failed to respond, the caller would block indefinitely while holding the efi_runtime_lock, subsequently blocking all future EFI runtime service calls. Processes like efivarfs, NVRAM writes, set_wakeup_time, and ACPI PRM handlers would all halt, requiring a reboot to recover.

Patch Developed by Meta Engineer

The patch was developed by Breno Leitao, a kernel engineer at Meta and a Debian developer. He encountered this issue firsthand on NVIDIA Grace servers operated by Meta and developed the patch series. As Leitao explained in the cover letter, when an EFI runtime service call hangs inside the firmware, the kworker for efi_rts_wq gets stuck within the firmware call and cannot be canceled. The only externally observable signs were a “workqueue lockup” message and user-space processes piling up on an uninterruptible semaphore.

In the NVIDIA Grace server case, the PC and LR were inside the firmware’s runtime memory. With the firmware unresponsive, the worker remained stuck, reporting “workqueue lockups” at 127, 157, and 188 seconds. The issue was ultimately resolved when an external monitoring system rebooted the host.

Rationale and Limitations of the

120-Second Timeout

The timeout threshold was set to 120 seconds. According to Leitao, this was determined to be a period longer than any “legitimate EFI runtime service call.” The premise is that calls exceeding 120 seconds are not justified.

This change does not fix the firmware bug itself. Firmware fixes are the vendor’s responsibility; this patch prevents a single stuck EFI call from triggering a cascade that freezes the entire user space. Leitao states that this change transforms the “generic mystery of a stuck task” into a clear “EFI firmware is at fault” signal in dmesg, which is particularly useful in large cluster environments. It eliminates the possibility of the same symptoms being attributed to dozens of unrelated crash causes.

Since the Linux 7.2 release, the kernel development community has continuously worked to improve hardware compatibility. As seen in the Linux 7.2-rc1 release, incorporating AMDGPU HDMI 2.1 FRL and Cache Aware Scheduling, scheduler and GPU driver refreshes have progressed, and Linux 7.3 marks the stable support for Intel Nova Lake S integrated GPUs, with new hardware support on the mainline. This EFI protection mechanism is also positioned as part of the trend to enhance hardware reliability.

Structural Issues in Firmware Quality

The EFI runtime services hang issue highlights the significant variation in firmware implementation quality across hardware vendors. Leitao explicitly stated, “This series doesn’t fix the firmware bug - that’s vendor territory,” pointing out that this issue is not something that can be resolved solely within the Linux kernel. The kernel-side timeout mechanism is merely a defensive line to limit the damage; resolving the root cause requires action from the firmware vendor.

The occurrence on NVIDIA Grace servers suggests that as ARM-based servers proliferate in cloud and large-scale data center environments, firmware robustness is a critical issue. Especially in large-scale operational environments like Meta’s, where a single server’s failure can impact the entire service, the importance of such defensive mechanisms is further amplified.

Editorial Opinion

In the short term, this change offers direct benefits to large cluster operators. It can transform obscure freezes caused by EFI firmware bugs into clear error signals in dmesg, drastically improving root cause analysis during incidents. However, whether the 120-second threshold maintains its validity will need to be verified with future operational data.

In the long term, by becoming standard in the kernel, this protection mechanism could exert pressure on firmware vendors. As an environment is established where EFI runtime service hangs are clearly detected and logged, firmware with poor quality will more easily surface as an unavoidable management issue. With the expansion of the ARM server market, harmonizing firmware quality is likely to become an industry-wide challenge.

An untested point of contention is whether the 120-second threshold will prove excessive or insufficient in the future. The possibility cannot be denied that new feature expansions related to GPU virtualization or Secure Boot could extend the processing time for legitimate EFI calls. A stage may arrive where dynamic threshold adjustment or platform-specific customization mechanisms are needed.

References

• “Linux 7.3 Better Protects Against Buggy EFI Firmware Taking Down The Rest Of User-Space”, by Michael Larabel — Phoronix, 2026-08-23T19:05:02.000Z (ARR)
• Source URL: https://www.phoronix.com/news/Linux-7.3-EFI