ファームウェアの秘密を探る旅: BIOS/UEFI から OS まで

コンピュータの電源ボタンを押した瞬間に何が起こるのか疑問に思ったことはありませんか? 画面が点灯する前のその短い休止の背後で、一連の複雑なプロセスが進行しています。この記事では に飛び込み、 かを探ります。 、ファームウェアの魅力的な世界 ブート プロセス中にさまざまなコンポーネントがどのように相互作用する これらのつながりを理解することで、システムを動かす基礎要素をより明確に把握できるようになります。ここでは主に に焦点を当てますが、多くの原則は他のアーキテクチャにも当てはまります。 Intel x86 アーキテクチャ このシリーズの第 1 部を見逃した方は、 ご覧ください。 こちらをクリックして それでは、ファームウェアの背後にある謎を解き明かしましょう。 目次： 定義 全体的なファームウェアアーキテクチャ 第一段階ブートローダー (FSBL) BIOS (POST フェーズ) UEFI プラットフォーム初期化 (PI) コアブート その他の解決策 第 2 ステージ ブート ローダー (SSBL) BIOS UEFI OS ブートローダー 定義 : ハードウェアに組み込まれた特殊なタイプのソフトウェアで、低レベルの制御を提供し、ハードウェアが正しく機能し、他のシステム コンポーネントと対話できるようにします。 ファームウェア : プラットフォームの電源投入後にハードウェアの初期化を行うレガシー ファームウェア (元々は 用に作成されたもの)。今日では、漠然とファームウェアの完全なセットと呼ばれることがよくあります。 基本入出力システム (BIOS) IBM PC : コンピュータの起動を担当するファームウェアの一般的な名称。 に代わる最新の概念として使用され、プロセッサとチップセットを初期化するためのブートストラップ コードを含む や、サードパーティ (マザーボード開発者など) がプラットフォーム固有の初期化を実行するためのインターフェイスを提供することがよくあります。 ブートローダ BIOS フレームワーク : ブートローダの終了時に実行されるソフトウェア。第 2 段階のブートローダ、オペレーティング システム、BIOS/UEFI アプリケーションなどです。通常は、ファームウェアの設計に従ってブートストラップ フローを処理します。 ペイロード と という用語の使い方は、その意味が文脈によって異なるため、混乱を招く可能性があります。ただし、 、 、または について言及する場合、通常は を指します。 BIOS ブートローダ ファームウェア BIOS ブートローダ オペレーティング システムとハードウェアの間で実行されるファームウェアの完全なセット と : Intel によって開発されたオリジナルの仕様です。Unified 、オリジナルの仕様を標準化および拡張するために によって作成された、 の後継です。ほとんどの場合、 と 同じ意味で使用されます。 EFI UEFI Extensible Firmware Interface (EFI) は、 Extensible Firmware Interface (UEFI) は UEFI フォーラム EFI EFI UEFI は 全体的なファームウェアアーキテクチャ ファームウェア コンポーネントがどのように相互作用するかを理解するために、接続されているすべての部分を含むアーキテクチャ全体を調べます。下の図に示す実行フローは、 の一部である から始まります。そこから、さまざまなファームウェア ステージを経て進行します。 第 1 ステージ ブートローダ リセット ベクター ファームウェアまたは BIOS は、通常、2 つの主要な部分に分けられ、その間のインターフェースは通常最小限です。 : システムのハードウェア コンポーネントの初期化を担当します。 ハードウェア初期化 : オペレーティング システムおよびユーザーへの必要なインターフェースを提供します。 OS およびユーザーへのインターフェース プラットフォーム ファームウェアの設計は、ハードウェアの初期化とブート機能を組み合わせた にすることも、 の に従うこともできます。設計の選択はシステム要件によって異なり、特定のデバイスに適している場合があります。 モノリシック モジュール式 段階的なブート フロー 次の図は、さまざまなファームウェア コンポーネントがどのように相互作用し、ブート プロセスをサポートするために一緒に使用されるかを示しています (矢印は実行の順序を示します)。 これらの図が今は複雑に思えても心配しないでください。この記事を読んだ後にもう一度見直すと、より明確になります。 第一段階ブートローダー (FSBL) このファームウェアは てコンピューターと組み込みシステムを初期化するように設計されています。つまり、絶対に必要なことだけを実行し、制御を に渡してオペレーティング システムを起動します。FSBL 以外のストレージ メディアからオペレーティング システムをロードしません。基礎となるハードウェアを初期化するだけで、ハード ドライブ、SSD、USB フラッシュ ドライブなどのブート メディアは処理しないため、実際に 起動するには別のソフトウェアが必要です。 、最小限のハードウェア初期化に重点を置い 第 2 ステージ ブートローダー は、 フラッシュ チップ オペレーティング システムを : FSBLの主な責任 : 16 ビット から 32 ビット に切り替えます ( : BIOS の場合は )。 CPU リアル モード 保護モード 注 仮想 8086 モード : を呼び出して、 の を構成します。 キャッシュ使用率 FSP-T C 環境 Cache-As-RAM : ボード固有の初期化メソッドを呼び出して、構成されたデバッグ ポートを初期化します。 デバッグ ポート : を呼び出してシステムのメインメモリを初期化し、重要なシステムメモリ情報を保存します。 メモリの初期化 FSP-M : 外部デバイスとのインターフェース用に汎用入出力 (GPIO) ピンを構成します。 GPIO : 早期プラットフォーム初期化を実行し、 を使用してチップセット、CPU、および IO コントローラーの初期化を完了します。 シリコン FSP-S : PCI デバイスを列挙し、メモリ アドレスや IRQ などのリソースを割り当てます。 PCI 列挙 : ペイロードに渡す必要がある準備情報 (コアブート テーブル、HOB) を含む および テーブルを設定します。 ペイロードの準備 SMBIOS ACPI : ペイロードへの制御のロードと転送。 ロードとハンドオフ BIOS (POST フェーズ) コンピューティングの初期の頃は、オープンソース ソフトウェアは広く普及しておらず、ほとんどの BIOS 実装は独自のものでした。Super や など、BIOS POST ソース コードを提供するオープン ソリューションはわずかしかありません。これらのプロジェクトは、IBM 5150/5155/5160 システムとほとんどの XT クローンで動作するように設計されました。 PC/Turbo XT BIOS GLaBIOS ただし、 や などのよく知られているオープンソースの BIOS 実装は、ベアハードウェア上で実行することを目的としていないため、ハードウェアの初期化を実行しません。ただし、これらは として広く使用されており、QEMU や Bochs などの仮想環境でネイティブに実行されます。 OpenBIOS SeaBIOS 第 2 ステージ ブートローダ いずれにせよ、これらの初期の BIOS を直接操作したり、その詳細を深く調べる必要はほとんどありません。ただし、探索することに興味がある場合は、前述のリポジトリが適切な出発点になります。 現在の開発動向から判断すると、独自の BIOS ソリューションの開発は進行中ではないようで、このようなプロジェクトは最新の代替手段の登場により時代遅れになっています。 UEFI プラットフォーム初期化 (PI) ブート プロセスは、次の図に示すように、左から始まり右に進む段階的なフローに従います。プラットフォーム ブート プロセスのタイムラインは、黄色のボックスで示されるように、次のフレーズに分割されます。 : 後の最初のフェーズで、主な機能は一時 RAM (CPU または SRAM) をセットアップすることです。 セキュリティ (SEC) リセット ベクター Cache-As-RAM : このフェーズでは と呼ばれる特殊なドライバーがディスパッチされます。これらのモジュールは、CPU とチップセットの構成や のセットアップなど、重要なハードウェア初期化を処理します。 Pre-EFI 初期化 (PEI) 、Pre-EFI 初期化モジュール (PEIM) メイン メモリ (DRAM) : このフェーズでは、システムの残りの初期化が実行されます。DXE フェーズは、 を提供して、システムの動作に必要なさまざまなプロトコルとドライバーをサポートします。 ドライバー実行環境 (DXE) UEFI サービス : このフェーズでは、プラットフォーム ブート ポリシーを実装し、ブート シーケンスを決定して、適切なブート デバイス/ローダーを選択します。 ブート デバイス選択 (BDS) : このフェーズでは、システムは UEFI サービスを使用してアプリケーションを実行し、OS を準備します。これには、UEFI 環境からオペレーティング システムへの移行が含まれ、 呼び出しで終了します。 一時システム ロード (TSL) ExitBootServices() : このフェーズでは、オペレーティング システムは完全に動作し、その制御下でシステムを管理します。 実行時 (RT) : このフェーズでは、ハードウェアまたは OS がクラッシュ/シャットダウン/再起動するシナリオに対処します。ファームウェアは回復アクションを試行する場合がありますが、UEFI PI 仕様では、このフェーズの特定の要件や動作は定義されていません。 After Life (AL) このプロセスとその実行フェーズは でカバーされています。ただし、 (図の太い青い線で示されています) もあります。これは前のドキュメントの一部ではなく、 で説明されています。UEFI 名前と頻繁な使用は混乱を招く可能性がありますが、これら 2 つのドキュメントの焦点は異なります。 、UEFI プラットフォーム初期化 (PI) 仕様 UEFI インターフェイス UEFI 仕様 の : 低レベルのファームウェア コンポーネント間のインターフェイスに焦点を当て、これらのモジュールがプラットフォームを初期化するためにどのように相互作用するかを詳細に説明します。 UEFI PI 仕様 : オペレーティング システム (OS) とファームウェア間のやり取りのためのインターフェイスを定義します。これについては のコンテキストでさらに詳しく説明します。UEFI 仕様は PI 仕様に依存していることに注意してください。 UEFI 仕様 、第 2 ステージ ブートローダ 基本的に、どちらの仕様もインターフェースに関するものですが、レベルが異なります。詳細については、 で両方の仕様にアクセスできます。 UEFI フォーラムの Web サイト 当初、第 1 ステージ ブートローダと第 2 ステージ ブートローダの区別を考慮せずに、統合ファームウェア ソリューションとして設計されました。ただし、 を と呼ぶ場合、 、 、および フェーズが含まれます。DXE を と 段階に分ける理由は、初期化プロセスにおける役割が異なるためです。 UEFI PI は UEFI 第 1 ステージ ブートローダ SEC PEI 初期の DXE 初期段階 後期 フェーズでは、ドライバーは通常、重要な CPU/PCH/ボードの初期化を実行し、DXE フェーズをプラットフォーム固有のハードウェアから分離するのに役立つ も生成します。AP プラットフォーム固有の詳細をカプセル化し、 フェーズがハードウェアの詳細とは独立して動作できるようにします。 初期の DXE DXE アーキテクチャ プロトコル (AP) は 後期の DXE コアブート Coreboot の仕組みに関する詳細な記事が近日公開されます。私のソーシャル メディアをフォローしてください。近日中に公開されます。 その他の解決策 : コアハードウェアコンポーネントの初期化のみを提供し、その後ペイロードをロードする純粋な第 1 段階のブートローダ。ただし、 、AMD x86 やその他のアーキテクチャはサポートされていません。 Intel Slim Bootloader (SBL) Intel x86 プラットフォームでのみ動作し : 第一段階と第二段階の両方のブートローダーです。ただし、プラットフォームの x86 から直接ブートする (ベア モードと呼ばれる) ためのサポートは、他のファームウェアに比べて制限されています。組み込みシステムや ARM ベースのデバイスでより人気があります。第二段階のブートローダーとして、U-Boot は を実装しますが、組み込みシステムに重点を置いています。 U-Boot リセット ベクター UEFI のサブセット 第 2 ステージ ブート ローダー (SSBL) 初期のハードウェア セットアップが完了すると、 が始まります。その主な役割は を設定し、OS がシステム リソースを管理し、ハードウェア コンポーネントと対話できるようにすることです。 第 2 段階 、オペレーティング システムとプラットフォーム ファームウェアの間にソフトウェア インターフェイス 、ハードウェア レベルのインターフェイスのほとんどを処理することで OS とアプリケーションの開発を簡素化することを目的としています。この抽象化により、開発者は基盤となるハードウェアの違いを気にすることなく、より高レベルの機能に集中できます。 SSBL は、 ハードウェアのバリエーションを可能な限り隠し : SSBLの主な責任 : メモリ マッピング、SMBIOS、ACPI テーブル、SPI フラッシュなど、プラットフォーム固有の情報を から取得します。 プラットフォーム情報の取得 第 1 段階ブートローダ : SMM、SPI、PCI、SCSI/ATA/IDE/DISK、USB、ACPI、ネットワーク インターフェイスなどのドライバーが含まれます。 プラットフォームに依存しないドライバーを実行します : オペレーティング システムとハードウェア コンポーネント間の通信を容易にする一連のサービスを提供します。 サービス実装 (別名インターフェイス) : システム構成のセットアップ メニューを提供し、ユーザーは起動順序、ハードウェア設定、その他のシステム パラメータに関連する設定を調整できます。 セットアップ メニュー : 利用可能なブート メディアからペイロード (おそらくオペレーティング システム) を見つけてロードするメカニズム。 ブート ロジック BIOS BIOS のインターフェースは と呼ばれます。これらの関数は、ハードウェア アクセス用の一連のルーチンを提供しますが、システムの特定のハードウェア上でどのように実行されるかという具体的な詳細は、ユーザーには表示されません。 、BIOS サービス/関数/割り込み呼び出し 16 ビット では、 x86 アセンブリ言語命令を介してソフトウェア割り込みを呼び出すことで簡単にアクセスできます。32 ビット では、 値の処理方法が異なるため、ほぼすべての BIOS サービスが利用できません。 リアル モード INT プロテクト モード セグメント このインターフェイスの使用方法の例として アドレス指定を使用してセクター ベースのハード ディスクとフロッピー ディスクの読み取りおよび書き込みサービスを提供する ( ) を取り上げます。2 つのセクター (1024 バイト) を読み取り、メモリ アドレス にロードするとすると、次のコードを実行できます。 、シリンダ ヘッド セクター (CHS) ディスク サービス INT 13h 0x9020 mov $0x02, %ah # Set BIOS read sector routine mov $0x00, %ch # Select cylinder 0 mov $0x00, %dh # Select head 0 [has a base of 0] mov $0x02, %cl # Select sector 2 (next after the # boot sector) [has a base of 1] mov $0x02, %al # Read 2 sectors mov $0x00, %bx # Set BX general register to 0 mov %bx, %es # Set ES segment register to 0 mov $0x9020, %bx # Load sectors to ES:BX (0:0x9020) int $0x13 # Start reading from drive jmp $0x9020 # Jump to loaded code このサービスが SeaBios でどのように記述されているかに興味がある場合は、 を参照してください。 src/disk.c BOOTフェーズ デバイスから (セクター 0) を読み取ることによって、 (ハード ドライブ、CD-ROM、フロッピー ディスクなど) の検索を開始します。 最初の 512 バイトのセクター 起動可能なデバイス BIOS のブートストラップ シーケンスは、見つかった最初の有効な を、コンピューターの物理メモリの アドレス にロードします (ヒント: と 同じ物理アドレスを参照します)。 マスター ブート レコード (MBR) 物理 0x7C00 0x0000:0x7c00 0x7c0:0x0000 は BIOS はペイロードの に制御を移します。この ペイロード コード全体を格納するには小さすぎますが、 からペイロードの残りをロードする目的で使用されます。この時点で、ペイロードは BIOS によって公開されたインターフェイスを使用できます。 最初の 512 バイト ロードされたセクターは ブート可能なデバイス 初期の頃には ことは注目に値します。BIOS は であり、1980 年代の実際の IBM PC で動作していたのと同じように動作します。他のメーカーは、IBM 互換の BIOS を して作成しただけです。その結果、BIOS メーカーが新しい BIOS 機能を発明したり、重複する機能を持たせたりすることを防ぐ規制はありませんでした。 BIOS 仕様が存在しなかった 事実上の標準 リバース エンジニアリング 統合拡張ファームウェア インターフェース (UEFI) 前述のように、UEFI 自体は単なる仕様であり、多くの実装があります。最も広く使用されているのは、UEFI および PI 仕様のオープンソース ある です。EDKII だけでは完全に機能するブート ファームウェアを作成するには不十分ですが、ほとんどの商用ソリューションの強固な基盤を提供します。 リファレンス実装で TianoCore EDK II さまざまな をサポートし、UEFI インターフェイスを提供するために、 プロジェクトが使用されます。これは、実行された初期セットアップとブート ファームウェアによって提供されるプラットフォーム情報に依存して、システムを UEFI 環境用に準備します。 ファーストステージ ブートローダ UEFI ペイロード UEFI ペイロードは、プラットフォームに依存しない フェーズと フェーズを使用します。さまざまなプラットフォームに適応できる汎用ペイロードを提供します。ほとんどの場合、カスタマイズやプラットフォーム固有の調整は必要なく、 からプラットフォーム情報を取得してそのまま使用できます。 DXE BDS ファーストステージ ブートローダー : UEFI ペイロードのバリアント : 必要な実装固有のプラットフォーム情報を抽出するための解析ライブラリが必要です。ブートローダが API を更新する場合は、ペイロードも更新する必要があります。 レガシー UEFI ペイロード : に準拠し、共通イメージ形式として または を使用します。ペイロード自体を解析するのではなく、ペイロード エントリで を受信することを想定しています。 ユニバーサル UEFI ペイロード ユニバーサル スケーラブル ファームウェア (USF) 仕様 実行可能およびリンク可能形式 (ELF) フラット イメージ ツリー (FIT) ハンドオフ ブロック (HOB) 問題なく動作しますが、EDK2 コミュニティは業界を へと移行させようとしています。ペイロードの選択は、ファームウェア コンポーネントによって異なります。たとえば、 なしでは、 を実行することはできません。一方、コアブートでユニバーサル 使用するには、 に変換するためのシム レイヤーが必要です。これは、 でのみ利用可能な機能です。 レガシー UEFI ペイロードは ユニバーサル UEFI ペイロード 私のパッチ Slim Bootloader で SMM サポート付きのレガシー ペイロード ペイロードを コアブート テーブルを HOB StarLabs EDK2 フォーク インタフェース すべての UEFI 準拠システムは、UEFI 環境で実行されるすべてのコード (ドライバー、アプリケーション、OS ローダー) に渡される を提供します。このデータ構造により、UEFI 実行可能ファイルは、 、 のコレクションなどの にアクセスできます。 システム テーブル ACPI SMBIOS、 UEFI サービス システム構成テーブル テーブル構造は に記述されています。 MdePkg/Include/Uefi/UefiSpec.h typedef struct { EFI_TABLE_HEADER Hdr; CHAR16 *FirmwareVendor; UINT32 FirmwareRevision; EFI_HANDLE ConsoleInHandle; EFI_SIMPLE_TEXT_INPUT_PROTOCOL *ConIn; EFI_HANDLE ConsoleOutHandle; EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *ConOut; EFI_HANDLE StandardErrorHandle; EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *StdErr; // // A pointer to the EFI Runtime Services Table. // EFI_RUNTIME_SERVICES *RuntimeServices; // // A pointer to the EFI Boot Services Table. // EFI_BOOT_SERVICES *BootServices; UINTN NumberOfTableEntries; EFI_CONFIGURATION_TABLE *ConfigurationTable; } EFI_SYSTEM_TABLE; サービスには、 、 、 などのタイプが含まれます。 ブート サービス ランタイム サービス プロトコルによって提供されるサービス UEFI は を設定することでデバイスへのアクセスを抽象化します。これらの 、他のモジュールがそれらを見つけて使用できるようにする によって識別されます。これらはブート サービスを通じて検出できます。 、UEFI プロトコル プロトコルは関数ポインターを含むデータ構造であり グローバル一意識別子 (GUID) これらのプロトコルを生成し、実際の関数 (ポインターではありません!) はドライバー自体に含まれています。このメカニズムにより、UEFI 環境内のさまざまなコンポーネントが相互に通信できるようになり、OS が独自のドライバーをロードする前にデバイスと対話できるようになります。 UEFI ドライバーは 一部のプロトコルは UEFI 仕様で事前定義および説明されていますが、ファームウェア ベンダーは てプラットフォームの機能を拡張することもできます。 独自のカスタム プロトコルを作成し ブートサービス 起動時に 使用できる関数を提供します。これらのサービスは 関数が呼び出されるまで利用可能です ( )。 のみ EFI_BOOT_SERVICES.ExitBootServices() MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c すべてのブート サービスへのポインターは、 ( ) に格納されます。 ブート サービス テーブル MdePkg/Include/Uefi/UefiSpec.h typedef struct { EFI_TABLE_HEADER Hdr; ... EFI_GET_MEMORY_MAP GetMemoryMap; EFI_ALLOCATE_POOL AllocatePool; EFI_FREE_POOL FreePool; ... EFI_HANDLE_PROTOCOL HandleProtocol; ... EFI_EXIT_BOOT_SERVICES ExitBootServices; ... } EFI_BOOT_SERVICES; ランタイムサービス オペレーティング システムの実行中も、最小限のサービス セットにアクセスできます。ブート サービスとは異なり、これらのサービスは、任意のペイロード (OS ブートローダーなど) が の呼び出しによってプラットフォームを制御した後も有効です。 EFI_BOOT_SERVICES.ExitBootServices() すべてのランタイム サービスへのポインターは、 ( ) に格納されます。 ランタイム サービス テーブル MdePkg/Include/Uefi/UefiSpec.h typedef struct { EFI_TABLE_HEADER Hdr; ... EFI_GET_TIME GetTime; EFI_SET_TIME SetTime; ... EFI_GET_VARIABLE GetVariable; EFI_GET_NEXT_VARIABLE_NAME GetNextVariableName; EFI_SET_VARIABLE SetVariable; ... EFI_GET_NEXT_HIGH_MONO_COUNT GetNextHighMonotonicCount; EFI_RESET_SYSTEM ResetSystem; ... } EFI_RUNTIME_SERVICES; 下の図は、ブート サービスとランタイム サービスのタイムラインを示しており、各サービスがいつアクティブになるかを正確に確認できます。 ブートデバイス選択 (BDS) フェーズ UEFI 仕様では と呼ばれるブート ポリシー エンジンが定義されています。これは、特定の順序で をロードしようとします。この順序とその他の設定は、グローバル を変更することで構成できます。最も重要な変数について説明します。 、UEFI ブート マネージャー UEFI アプリケーション NVRAM (不揮発性ランダム アクセス メモリ) 変数 ( は一意の 16 進数値に置き換えられます) — ブート/ロード オプション。 Boot#### #### — 現在実行中のシステムを起動するために使用されるブート オプション。 BootCurrent — 次回の起動のみの起動オプション。これは、1 回の起動のみ を置き換え、最初の使用後にブート マネージャーによって削除されます。これにより、 を変更せずに、次回の起動の動作を変更できます。 BootNext BootOrder BootOrder — 順序付けられたブート オプション ロード リスト。ブート マネージャーは、このリストの最初のアクティブ オプションのブートを試行します。失敗した場合は、次のオプションを試行します。 BootOrder — ブート マネージャーによってサポートされるブート オプションの種類。 BootOptionSupport - または から起動値を自動的に選択するまでの、ファームウェアのブート マネージャーのタイムアウト (秒単位)。 Timeout BootNext BootOrder これらの変数は を使用してLinuxから簡単に取得できます。 、efibootmgr(8) [root@localhost ~]# efibootmgr BootCurrent: 0000 Timeout: 5 seconds BootOrder: 0000,0001,2001,2002,2003 Boot0000* ARCHLINUX HD(5,GPT,d03ca3cf-1511-d94e-8400-c7a125866442,0x40164000,0x100000)/File(\EFI\ARCHLINUX\grubx64.efi) Boot0001* Windows Boot Manager HD(1,GPT,6f185443-09fc-4f15-afdf-01c523565e52,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)57a94e544f5753000100000088900100780000004200430044039f0a42004a004500430054003d007b00390064006500610038003600320063002d1139006300640064002d0034006500370030102d0061006300630031002d006600330032006200330034003400640034003700390035007d00000033000300000710000000040000007fff0400 Boot0002* ARCHLINUX HD(5,GPT,d03ca3cf-1511-d94e-8400-c7a125866442,0x40164000,0x100000) Boot2001* EFI USB Device RC Boot2002* EFI DVD/CDROM RC Boot2003* EFI Network RC 上記のコード スニペットを参考にして、ブートを見てみましょう。UEFI は リストの反復処理を開始します。リスト内の各エントリについて、対応する 変数を検索します (0000 の場合は の場合は など)。変数が存在しない場合は、次のエントリに進みます。変数が存在する場合は、変数の内容を読み取ります。各ブート オプション変数には、可変長フィールドのバイト パック バッファーである 記述子が含まれています (これは単なるデータ構造です)。 BootOrder Boot#### Boot0000 Boot2003 EFI_LOAD_OPTION データ構造は[MdePkg/Include/Uefi/UefiSpec.h][ )に記載されています。 https://github.com/tianocore/edk2/blob/edk2-stable202405/MdePkg/Include/Uefi/UefiSpec.h#L2122 typedef struct _EFI_LOAD_OPTION { /// The attributes for this load option entry. UINT32 Attributes; /// Length in bytes of the FilePathList. UINT16 FilePathListLength; /// The user readable description for the load option. /// Example: 'ARCHLINUX' / 'Windows Boot Manager' / `EFI USB Device` // CHAR16 Description[]; /// A packed array of UEFI device paths. /// Example: 'HD(5,GPT,d03ca3cf-1511-d94e-8400-c7a125866442,0x40164000,0x100000)/File(\EFI\ARCHLINUX\grubx64.efi)' // EFI_DEVICE_PATH_PROTOCOL FilePathList[]; /// The remaining bytes in the load option descriptor are a binary data buffer that is passed to the loaded image. /// Example: '57a9...0400' in Boot0001 variable // UINT8 OptionalData[]; } EFI_LOAD_OPTION; この時点で、ファームウェアは ( ) を調べます。ほとんどの場合、コンピューターはストレージ デバイス (ハード ドライブ/SSD/NVMe など) から起動されます。そのため、 ノードが含まれます。 デバイス パス EFI_DEVICE_PATH_PROTOCOL デバイス パスには HD(Partition Number, Type, Signature, Start sector, Size in sectors) - パーティション スキームに使用される形式をキーワード (1) または (2) で示します。 タイプ MBR GPT - タイプが の場合は 4 バイトの MBR 署名、タイプが の場合は 16 バイトの 。 署名 MBR GPT UUID : 他のパスを変換する方法に興味がある場合は、 参照してください。 注 UEFI 仕様 v2.10、10.6.1.6 テキスト デバイス ノード リファレンスを UEFI はディスクを調べて、ノードに一致するパーティションがあるかどうかを確認します。存在する場合は、 としてマークする特定 でラベル付けされている必要があります。これは、 の特定のバージョンに基づいて仕様が決められ、 と呼ばれるファイル システムでフォーマットされています。実際は、通常の です。 EFI システム パーティション (ESP) のグローバル一意識別子 (GUID) FAT ファイル システム EFI ファイル システム FAT12/16/32 : にファイルへの明示的なパス File が含まれている場合、UEFI はその特定のファイルを検索します。たとえば、 オプションには が含まれています。 ネイティブ ブート デバイス パス File(\Path\To\The\File.efi) Boot0000 File(\EFI\ARCHLINUX\grubx64.efi) : 単にディスクを指している場合、ファームウェアはアーキテクチャに基づいた ( ( の場合は 、 / の場合は )) を使用します。このメカニズムにより (USB ドライブなど) を UEFI で動作させることができます。 のみが使用されます。たとえば、 オプションはこのメカニズムを使用します。 フォールバック ブート デバイス パスが フォールバック ブート パス \EFI\BOOT\BOOT{arch}.EFI amd64 BOOTx64.EFI i386 IA32 BOOTia32.EFI 、ブート可能なリムーバブル メディア フォールバック ブート パス Boot0002 上記のすべての オプションは、 の出力例に表示されるブート オプションを指します。 注: Boot#### efibootmgr どちらの場合も、 ( 、UEFI シェル、ユーティリティ ソフトウェア、システム セットアップなど) をメモリにロードします。この時点で、制御は のエントリ ポイントに転送されます。BIOS とは 、 ファームウェアに制御を返すことができます (アプリケーションがシステムの制御を引き継ぐ場合を除く)。このような状況が発生した場合、または何か問題が発生した場合、 次の エントリに移動し、まったく同じプロセスに従います。 UEFI ブート マネージャーは UEFI アプリケーション OS ブートローダー UEFI アプリケーション 異なり UEFI アプリケーションは ブート マネージャーは Boot#### 仕様では、 データベース変数を自動的に維持できることが述べられています。これには、参照されていない、または解析できないロード オプション変数の削除が含まれます。さらに、順序付きリストを書き換えて、対応するロード オプション変数のないロード オプションを削除することもできます。 ブート マネージャーが 上記のテキストは について説明しています。また、UEFI ファームウェアは、BIOS をエミュレートする モードで実行できます。 UEFI ブート 互換性サポート モジュール (CSM) OS ブートローダー ファームウェア (通常は ) によって起動され、そのインターフェイスを使用して ソフトウェア。OS と同じくらい複雑で、次のような機能を提供します。 第 2 ステージ ブートローダ OS カーネルをロードする さまざまなファイルシステム（HFS+、ext4、XFSなど）からの読み取り ネットワーク経由のやり取り（例：TFTP、HTTP） 対応カーネルの起動 マルチブート チェーンローディング 初期 RAM ディスクのロード ( ) initrd さらにもっと！ これらのプログラムの一般的な設計については、この記事の範囲外です。一般的な OS ブートローダーの詳細な比較については、 と を参照してください。 ArchLinux wiki Wikipedia の記事 Windows システムは と呼ばれる独自の OS ブートローダーを使用します。 、Windows ブート マネージャー (BOOTMGR) ファームウェアはもはや コードではありません。 になり、現在のトレンドはこれに拍車をかけています。ファームウェア上で や など、多くの興味深いアプリケーションを実行できます。 小さくて複雑な 膨大な量の複雑なコード Doom Twitter 全体的なアーキテクチャを理解することで、これらのコンポーネントを頭の中で整理しやすくなります。既存のファームウェアの設計を調べることで、コンピューターの電源を入れるたびに展開される魅力的なプロセスについて理解を深めることができます。このトップダウンの視点は、各部分の役割を明確にするだけでなく、最新のファームウェア システムの高度で進化する性質も強調します。 リソース UEFI 仕様バージョン 2.10 UEFI プラットフォーム初期化仕様バージョン 1.8 (Errata A) EDK II ドキュメント Slim ブートローダ プロジェクト ドキュメント UEFI ブート: では、これは実際にどのように機能するのでしょうか? 最新のUEFIベースのプラットフォームブートを理解する Intel Galileo の UEFI ブート シーケンスの解析 いくつかの一般的なアーキテクチャにおけるディスク デバイスの「パス」に関する非常に簡単なメモ。 コンピュータの起動方法