Linux 7.3 カーネル、異常なEFI処理を120秒で強制停止

AFFILIATE_PRODUCTS:

Linux 7.3のEFI保護機構

開発中のLinux 7.3カーネルに、不具合のあるEFIファームウェアによるシステム停止を防ぐ新たな保護機構が統合された。EFIランタイムサービスの完了処理に120秒のタイムアウトが設定され、超過時にはファームウェアが「wedged」状態であると宣言される仕組みだ。

本次の変更は、一部のプラットフォームで確認されているEFIファームウェアの不具合が、ユーザースペース全体を巻き込んで停止するという深刻な問題に対応するものである。Linuxカーネルは従来、EFIランタイムサービス呼び出しの完了を無期限に待機していた。不具合のあるファームウェアが応答を返さない場合、呼び出し元はefi_runtime_lockを保持したまま永久にブロックされ、以降のすべてのEFIランタイムサービス呼び出しがブロックされる。efivarfs、NVRAM書き込み、set_wakeup_time、ACPI PRMハンドラなど、一連の処理がすべて停止し、リブートまで復帰しない事態が発生する。

Metaエンジニアによるパッチ開発

パッチの開発を手がけたのは、MetaのカーネルエンジニアでありDebian開発者のBreno Leitao氏だ。Metaが運用するNVIDIA Graceサーバーで実際にこの問題に遭遇し、パッチシリーズを開発した。Leitao氏がパッチシリーズのカバーレットで説明した状況によると、EFIランタイムサービス呼び出しがファームウェア内でハングした場合、efi_rts_wqのkworkerはファームウェア呼び出し内部でスタックし、キャンセルできない。外部から確認できる唯一の兆候は「workqueue lockup」メッセージと、割り込み不可のセマフォ上で積み上がるユーザースペースプロセスのみであった。

NVIDIA Graceサーバーでの事例では、PCとLRがEFIランタイムサービスのファームワークメモリ内にあり、ファームウェアが応答を返すことなく、ワーカーが127秒、157秒、188秒の「workqueue lockup」レポート間ずっとスタックし続けた。外部のモニタリングシステムが最終的にホストをリブートすることで解決したという。

120秒の根拠と限界

タイムアウトの閾値は120秒に設定された。Leitao氏によれば、これは「任意の妥当な正当な EFIランタイムサービス呼び出し」よりも長い期間と判断された値である。120秒を超える呼び出しは、妥当な理由によるものではないという前提に基づいている。

今回の変更はファームウェアのバグそのものを修正するものではない。ファームウェア修正はベンダーの責務であり、今回のパッチが解決するのは、1つのスタックしたEFI呼び出しがユーザースペース全体を巻き込む連鎖を防ぐことである。Leitao氏は、この変更が「ジェネリックなスタックタスクのミステリー」を、dmesgに明確に「EFI firmware is at fault」というシグナルに変換し、特に大規模クラスタ環境で有用であると述べている。同一の症状が無関係な数十の停止原因に帰属される可能性を排除できるためだ。

Linux 7.2のリリース以降、カーネル開発コミュニティはハードウェアとの親和性改善を継続的に推進してきた。Linux 7.2-rc1リリース、AMDGPU HDMI 2.1 FRLやCache Aware Schedulingを統合 ではSchedulerやGPUドライバーの刷新が進み、Linux 7.3、Intel Nova Lake S統合GPUを安定対応へ では新ハードウェアへの対応が本線にある。今回のEFI保護機構も、こうしたハードウェア信頼性向上の流れに位置づけられる変更である。

ファームウェア品質の構造的問題

EFIランタイムサービスのハング問題は、ファームウェア実装の品質管理が、ハードウェアベンダー間で大きくばらついていることを示している。Leitao氏は、「This series doesn’t fix the firmware bug - that’s vendor territory」と明言しており、この問題がLinuxカーネル側で完結する性質のものではないことを指摘している。カーネル側のタイムアウト機構はあくまで被害拡大を食い止める防御線であり、根本原因の解決にはファームウェアベンダーの対応が不可欠である。

NVIDIA Graceサーバーでの発生事実は、クラウドや大規模データセンター環境でARMベースサーバーが普及する中で、ファームウェアの堅牢性が重要な課題であることを示唆している。特にMetaのような大規模運用環境では、1台のサーバーの停止がサービス全体に波及しうるため、このような防御的機構の重要性はさらに増す。

編集部の見解

短期的に見れば、今回の変更は大規模クラスタ運用者に直接的な恩恵をもたらす。EFIファームウェアの不具合による不明な停止を、dmesg上の明確なエラーシグナルに変換できるため、障害時の原因切り分けが劇的に改善されそうだ。120秒という閾値設定が妥当性を維持できるかは、今後の運用データで検証される必要がある。

長期的には、この保護機構がカーネル標準装備となったことで、ファームウェアベンダーに対する圧力にもなりうる。EFIランタイムサービスのハングが明確に検出・記録される環境が整うため、品質の低いファームウェアは管理画面で回避不能な問題として浮上しやすくなる。ARMサーバー市場の拡大に伴い、ファームウェア品質の均質化が業界全体の課題になりそうだ。

未検証の論点として、120秒という閾値が将来的に過剰か不足かの判断が問われる場面がありうる。GPUバーチャライゼーションやSecure Boot関連の新機能拡張により、正当なEFI呼び出しの処理時間が延長される可能性も否定できない。閾値の動的調整や、プラットフォームごとのカスタマイズ機構が必要になる局面が訪れるだろうか。

参考

• 「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)
• 元記事URL: https://www.phoronix.com/news/Linux-7.3-EFI