UEFI Boot Option Architectureとは

UEFIのboot option構造を、Boot####、BootOrder、BootNext、BootCurrent、EFI_LOAD_OPTION、BDS flow、デバッグ観点から整理します。

更新 約 5 分
Đọc bằng 日本語 Tiếng Việt English
Boot / UEFI Boot Manager cover

UEFI Boot Option Architecture とは、firmware が boot target をどのように表現し、保存し、選択するかという仕組みです。中心になるのは Boot####BootOrderBootNextBootCurrent といった UEFI variables と、各 Boot#### の中に入る EFI_LOAD_OPTION です。

個別の variable だけを覚えると理解が分断されます。boot のデバッグでは、誰が boot option を作り、誰が順序を決め、誰が device path を parse し、誰が LoadImage() を呼び、失敗後にどの policy が順序を変えるのかをまとめて見る必要があります。

全体像

UEFI Boot Option Architecture

UEFI Variable Store
├─ BootOrder
│  └─ UINT16 list: 0001, 0003, 0007...
├─ BootNext
│  └─ One-time UINT16 option
├─ BootCurrent
│  └─ Current booted option
├─ Boot0001
│  └─ EFI_LOAD_OPTION
├─ Boot0003
│  └─ EFI_LOAD_OPTION
└─ Boot0007
   └─ EFI_LOAD_OPTION

BootOrder は参照リストにすぎません。description、attributes、device path、optional data は Boot#### に入ります。BootNext は一回限りの override で、BootCurrent は今回 firmware が実際に使った option を示します。

各要素の役割

主な構成要素
要素 役割 よくある問題
Boot#### 個別の boot option を表す device path が古い、inactive、重複 entry
BootOrder boot を試す順序を決める 存在しない entry を参照する、policy に書き換えられる
BootNext 一回限りの次回 boot option 消されない、意図せず BootOrder を override する
BootCurrent 今回使われた option を記録する 未設定や誤設定で debug が難しくなる
EFI_LOAD_OPTION Boot#### の data format parser offset や FilePathListLength が間違う
Device Path loader または device への経路 LoadImage が失敗する、別 disk から起動する

BDSでboot optionが使われる流れ

01 Policy

Platform policy

boot mode、hotkey、recovery、fast boot を決める。

02 Next

BootNextを確認

存在すれば一回限りの boot target として使う。

03 Order

BootOrderを読む

boot option numbers のリストを取得する。

04 Option

Boot####を読む

対応する EFI_LOAD_OPTION を parse する。

05 Path

Device Pathを解決

device、filesystem、EFI file を探す。

06 Run

LoadImage/StartImage

bootloader を load して実行する。

BDSでboot optionが消費される流れ。

OS loader の問題に見える boot failure でも、実際には firmware が device path 解決や LoadImage() の段階で止まっていることがあります。

Boot####は誰が作るのか

Boot option は複数の producer から作られます。

  • OS loader を検出した firmware
  • ユーザーが option を追加する BIOS Setup UI
  • OS installer
  • efibootmgr や Windows の boot 管理 tool
  • recovery flow や firmware update logic
  • fallback entry を作る platform policy

producer が多いため、boot option は重複したり、古くなったり、UI と variable store の見え方がずれたりします。

boot optionのlifecycle

boot option は概ね次の流れを取ります。

Create -> Add to BootOrder -> Try -> Success/Fail -> Keep/Reorder/Delete/Disable

実際には次のようなパターンがあります。

  • option は作られたが BootOrder に追加されていない。
  • option は BootOrder にあるが inactive。
  • 失敗を繰り返した option を firmware が後ろへ移動する。
  • clone や SSD 交換後も古い disk を指している。
  • OS update が新しい entry を作るが古い entry を消さない。
  • firmware update が NVRAM を preserve し、古い問題も残る。

実際のデバッグ例: boot option leak

boot option leak は、新しい boot option が作られ続ける一方で古い entry が整理されない状態です。時間がたつと variable store が圧迫され、boot menu に似た entry が大量に並ぶことがあります。

症状の例です。

  • Boot0001Boot0004Boot0008 が同じ description を持つ。
  • BootOrder が不自然に長い。
  • BIOS Setup に似た entry が大量に表示される。
  • SetVariable()EFI_OUT_OF_RESOURCES を返し始める。
  • 空き容量不足で dbx update や BIOS Setup save が失敗する。

確認の流れです。

  1. Boot#### を dump する。
  2. description と full device path を比較する。
  3. どの entry が BootOrder から参照されているか確認する。
  4. 新しい entry を作っている producer を探す。
  5. variable store reclaim を確認する。
  6. Secure Boot variables や Setup variables を不用意に削除しない。

sourceを読むときのチェックポイント

Boot option architecture source-reading checklist

BDS、Boot Manager、variable codeを読むときの確認点。

あると便利なログ

BootNext
BootOrder
BootCurrent
All Boot#### names
EFI_LOAD_OPTION attributes
Device Path text
OptionalData size
Producer path if a new option is created
LoadImage status
StartImage status
Variable store free space or quota

良い log があれば、boot option の構造が悪いのか、選択 policy が悪いのか、loader そのものが失敗しているのかを切り分けやすくなります。

関連ノート

この記事が役に立ったら

ファームウェア、BIOS/UEFI、組み込みシステムを学んでいる人に共有したり、作者を応援したりできます。

ご意見

Nội dung liên quan

Một số bài viết, ghi chú hoặc project có liên quan đến nội dung bạn vừa đọc.

Biến note thành bài viết hoàn chỉnh

Notes là nơi ghi nhanh khái niệm.