nmbl(No More Boot Loader): ブートローダーの代わりにカーネルを使う

• Red Hatのブートローダーエンジニアリングチームは、GRUBブートローダーを置き換える新しい方法を開発中
• nmbl (no more boot loader) という高速で安全なLinuxベースのユーザー空間ソリューションを提案
• GRUBブートローダーの問題点
  • GRUBは強力で柔軟なブートローダーで、複数のアーキテクチャで使われている（x86_64、aarch64、ppc64le OpenFirmware）
  • しかし機能が複雑なため保守が難しく、Linuxカーネルと重複したり後れを取ったりすることが多い
  • また、多くのセキュリティ脆弱性を引き起こす
• Linuxカーネルの利点
  • Linuxカーネルは大規模な開発者基盤を持ち、機能開発や脆弱性対応を迅速に進められる
  • 全体的なレビューもより徹底して行われる
• 新しいソリューション: カーネルをブートローダーとして使う
  • EFIスタブによってUEFI上でロードされ、Unified Kernel Image (UKI) としてパッケージ化される
  • カーネル、initramfs、カーネルコマンドラインが、最終的なブートターゲットに到達するために必要なすべてを含む
  • 必要なドライバー、ファイルシステム対応、ネットワーキングがすでに組み込まれており、コードの重複を防げる

[xguru]

Hacker Newsの意見

• 10年前からUEFIを使ってきた。起動時間は少し短縮されるが、ブートローダーにはさまざまな利点がある

  • Windowsとのデュアルブートが簡単にできる
  • カーネルのcmdlineを編集して起動問題を解決できる
  • 複数のカーネルとinitrdイメージを簡単に選択できる
  • UEFI設定メニューに簡単にアクセスできる
  • 他のEFIアプリケーションを起動できる

• FreeBSDのブートローダーはinitramfsなしで起動できる。より賢いブートローダーが必要だ

  • ZFSを理解し、必要なモジュールを事前にロードできる
  • モジュール依存関係を理解し、必要なすべてのモジュールを事前にロードできる

• UEFI環境の機能と制約について誤解が多い。プロジェクトの実際の目標が誤って理解されている

  • Lennartの批判記事のほうが、より興味深い懸念を提起している

• 90年代のDEC AlphaシステムでLinuxを起動していたMILOを思い出す

  • 中間ブートローダーが必要で、安定性を重視したリリースサイクルが必要だ
  • データ駆動のメニュー／設定レイヤーが必要だ

• 以前ChromebookでLinux+Corebootを使っていた。Tianocore UEFI BIOSのドライバーバグのため、Linuxを直接使っていた

  • Rust TUIを書いて、すべてのパーティションをマウントし、カーネルイメージをkexecした
  • すべてのドライバーを重複して持つ必要はないと思う

• UEFIとLinuxの機能をもっと活用したほうがよい。ZFSBootMenuは4年間EFIアプリケーションを提供してきた

  • 第1段階のカーネル起動には1.5〜2秒ほどかかる

• kexecとの互換性問題を懸念している

  • 例えば、NVidiaモジュールはkexecの前にアンロードしなければならない
  • ACPIの問題や互換性の問題もある
  • kexecの仕組みは多様なカーネルバージョンをサポートするよう設計されているのではないかと推測する

• EFIスタブがマルチブート、カーネル、initrdを設定してからジャンプするだけならシンプルだ

  • 中間ローダーが大きく複雑になりすぎる必要はない
  • UEFI APIや別のプログラミング環境を避けるためにLinux全体を含めるのは不要だ

• 提案されている解決策がマルチOSブートを扱えるのか気になる

  • grubはLinuxとWindows、さらに3つ目のOSまで起動できる
  • Red Hatのソリューションが商用利用に限定されるのではないかと懸念される
  • 年に1〜2回しか再起動しないシステムで、どんな問題を解決するのか理解しにくい

• plain EFISTUBよりこのソリューションを使う理由がわからない

  • ArchでEFISTUBを使っており、Windowsを起動するときはBIOSメニューを使っている
  • Linuxベースのブートローダーの利点が理解できない