ブートチェーンの内部（UEFI・ブートローダ・initramfs）

ブートは「信頼の連鎖」を伴う多段リレー

電源投入直後のマシンには、まだ OS どころかメモリの初期化すらありません。そこから少しずつ大きなプログラムを読み込んでいく過程がブートですが、上級的に重要なのは 各段が「次の段」をロードし、制御を明け渡す という構造です。前段は次段にとって唯一の信頼の起点であり、Secure Boot 環境ではこの連鎖が暗号的に保証されます。

全体像をまず1本のタイムラインで押さえます。

電源 ON / リセット
  → CPU がリセットベクタから実行（ファームウェア本体）
  → UEFI: SEC → PEI → DXE → BDS の各フェーズ
      (Secure Boot 有効時は各 EFI 実行体の署名を検証)
  → BDS が BootOrder/BootXXXX 変数を見て起動エントリを選択
  → ESP 上の \EFI\... のブートローダ (例 shimx64.efi → grubx64.efi)
  → GRUB が vmlinuz と initramfs を RAM へロード、boot params 構築
  → カーネル本体: 自己展開 → ページング有効化 → サブシステム初期化
  → initramfs を tmpfs に展開、/init を PID 1 として起動
  → 本物の root を見つけてマウント → switch_root で pivot
  → 本来の init (systemd 等) が PID 1 を引き継ぐ → サービス起動

基礎的な4段モデルは 起動（ブート）プロセス で扱いました。本稿はその各段の内部に踏み込みます。

UEFI の内部フェーズと変数ストア

レガシ BIOS が MBR 先頭512バイトを実行するのに対し、UEFI は ファイルシステムを理解する小さな OS に近い実装で、明確なフェーズ列を持ちます。

ブート対象は NVRAM 上の UEFI 変数 で管理されます。BootOrder が試行順を、Boot0001 などの BootXXXX 変数が各エントリ（どの ESP のどのパスの .efi を起動するか）を保持します。Linux では efibootmgr でこれらを読み書きできます。ブートローダが置かれる ESP（EFI System Partition） は FAT32 でフォーマットされた専用パーティションで、ファームウェアが読めるよう GPT 上に特定の種別 GUID で確保されます。

Secure Boot：鍵階層による署名検証

Secure Boot は、UEFI が 次に実行する EFI 実行体の署名を検証 し、許可された鍵で署名されたものだけを起動する仕組みです。鍵は階層構造になっています。

Linux 環境では多くの場合、Microsoft の鍵で署名された小さな第1段ローダ shim を db に通し、shim が独自の MOK（Machine Owner Key） を使って GRUB やカーネルを検証します。これにより、ディストリビュータは Microsoft の鍵階層を直接持たずに署名チェーンを延長できます。検証は段ごとに行われ、shim → grub → vmlinuz のいずれかが改ざんされると、その段で起動が拒否されます。

ブートローダ（GRUB）の役割

GRUB の本質的な仕事は、カーネル本体（vmlinuz）と initramfs を RAM に読み込み、ブートパラメータを整えてカーネルに制御を渡す ことです。UEFI 環境の GRUB は、ファームウェアの提供するブートサービス経由でファイルを読みます。実行イメージはおおむね次の流れです。

grub_main():
  load grub.cfg                  # メニュー定義を読む
  show menu / pick entry         # エントリ選択（タイムアウトあり）
  linux  /vmlinuz  root=UUID=... ro quiet  # カーネルと cmdline 指定
  initrd /initramfs.img          # initramfs を RAM へ
  boot                           # EFI ハンドオフでカーネルへジャンプ

ここで渡される root=、ro、init=、rd.* などのカーネルパラメータが、後段の動作を決定づけます。root=UUID=... はファイルシステムの UUID で本物の root を指定する方式で、デバイス名（/dev/sda1 等）が起動ごとに変わる問題を避けます。

カーネル展開とサブシステム初期化

GRUB から制御を受けたカーネルイメージ vmlinuz は、先頭に小さな セットアップ/展開コード を含む圧縮イメージです。順序は次のとおりです。

1. 自己展開: 圧縮された本体を所定アドレスへ伸長
2. アーキ依存の初期化: ページング有効化、CPU モード確定
3. start_kernel(): スケジューラ・メモリ管理・割り込みを初期化
4. ドライバ初期化、initramfs を tmpfs として展開
5. PID 1 として initramfs 内の /init を実行

この段で 仮想記憶が立ち上がる ため、以降のコードは物理アドレスではなく仮想アドレスで動きます。仮想記憶の原理は 仮想メモリ を参照してください。start_kernel() 完了後、カーネルは最初のユーザー空間プロセスとして PID 1 を起動しますが、通常それは本物の init ではなく initramfs の中の /init です。

initramfs：本物の root に到達するための一時 root

ここが上級者が混同しやすい要点です。なぜカーネルは直接本物の root をマウントしないのか。理由は 鶏と卵 にあります。本物の root が LVM・暗号化（LUKS）・RAID・NVMe・ネットワークストレージ上にある場合、それをマウントするには対応するドライバとユーザー空間ツールが必要です。しかしそれらは（多くの場合）まさにマウントしたい root の中にあります。

そこで、起動に必要な最小限のドライバとツールだけを詰めた initramfs（initial RAM filesystem） を GRUB が RAM に積み、カーネルがそれを tmpfs に展開して一時 root とします。/init の仕事はおおむね次のとおりです。

/init (initramfs 内, PID 1):
  必要なカーネルモジュールを insmod
  udev でデバイスを認識（/dev を populate）
  LUKS なら cryptsetup で復号、LVM なら vgchange で活性化
  root= が指す本物の FS をマウント → /sysroot
  switch_root /sysroot /sbin/init   # 一時 root を捨て pivot

switch_root は、新しい root へ移った上で initramfs の tmpfs を解放し、本物の root 上の init（systemd など）を新たな PID 1 として exec します。PID 1 が入れ替わる点が独特で、これによりメモリ上の使い捨て root から恒久的な root へ橋渡しされます。PID と最初のプロセスの位置づけは プロセスとスレッド も参考になります。

init システム：PID 1 がサービスを起動

本物の root 上の init（多くの環境で systemd）が PID 1 を引き継ぐと、ここからは依存関係に基づくサービス起動の世界です。systemd は unit（service・mount・target など）の依存グラフを解決し、独立なものは並列に起動します。古典的な SysVinit がランレベルごとにスクリプトを直列実行したのに対し、systemd は target（到達したい状態） と socket/path などの起動トリガ を使って並列化と遅延起動を行います。

ここまでのリレーを誰が誰に制御を渡すかで整理します。

まとめ

• ブートは リセットベクタ → UEFI（SEC/PEI/DXE/BDS）→ ローダ → カーネル → initramfs → init と制御を順送りする多段リレー。
• Secure Boot は PK/KEK/db/dbx の鍵階層で各段の署名を検証し、改ざんされた次段の実行を拒否する。
• initramfs は 本物の root をマウントするための使い捨て一時 root で、必要なドライバを積んでから switch_root で pivot し、PID 1 を本来の init に明け渡す。

カーネルとユーザー空間の境界は カーネルモードとユーザーモード、本物の root に到達したあとの隔離技術は 名前空間と cgroups（コンテナの基盤） も合わせてどうぞ。