LinuxカーネルEFIブートスタブまたは「独自のブートローダー」

はじめに

最近の記事「 ブートローダーを使用せずにLinux OSをダウンロードする」を読んだ後、2つのことに気付きました。多くは2011年に遡る「新しい」ことに興味があります。 著者は最も基本的なものを説明しませんでした。 別の記事もありましたが、すでに古くなっていたか、または多くの不必要で同時に言われていないものがありました。



具体的には、カーネルアセンブリオプションCONFIG_EFI_STUBの要点を見落としていました。 U（lu / ku / edu / * etc *）buntuの最近のバージョンでは、このオプションはデフォルトですでに有効になっているため、作成者には疑いはありませんでした。

私の知る限り、現在、指定されたバージョン以上のディストリビューションに含まれています：Arch Linux、Fedora 17、OpenSUSE 12.2、Ubuntu 12.10。 コメントでは、2.6カーネルを搭載したDebianでもできると述べましたが、これは最新バージョンからのバックポートに過ぎません。 これらのディストリビューションを再構築する必要はまったくありません！ しかし、他のCONFIG_EFI_STUBでは、ほとんどの場合、オプションはカーネルバージョン3.3.0以降でのみ使用可能であるか、デフォルトでオフになっているため、まったく存在しません。 したがって、CONFIG_EFI_STUBオプションを使用してコンパイルされたカーネルには、以下で説明するすべてのことが当てはまります。

それでは、Linux Kernel EFI Boot Stubとは正確には何ですか？

一般的な情報

そして... "exeファイル"以上のものはありません！ はい、 PE / COFFを 「ねじ止め」します。 まあ、というか、 UEFIブートローダーを喜ばせるために、わずかな変更を加えたその下のzakoだけです。 これを確認するには、カーネルの最初の2バイトを読み取ります。

$ od /boot/vmlinuz-linux --address-radix=x --read-bytes=2 -t x1c 0000000 4d 5a MZ 0000002
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おなじみですよね？ 少なくとも一度「楽しみのために」メモ帳、16進エディタ、またはクールなものでMS-DOSまたはWindows実行可能ファイルを開いた人のために。 これらは、実際にMS-DOSでこのファイル形式を開発したMark Zbikowskiの頭文字です。 このスタブの署名は、現代のWindows実行可能ファイルの名残のままであり、ファイルごとに最大64バイトのヘッダーを食い尽くしています！



DOSヘッダーは、カーネルがブートセクターとしてブートするときに実行され、PEファイルの実行時にMS-DOSのように誓うレガシーコードに該当します。「直接フロッピーブートはサポートされていません。 代わりにブートローダープログラムを使用してください。 ディスクを取り出し、任意のキーを押して再起動します... "。 したがって、ここのこのヘッダーからの情報は、実際には署名「MZ」と次のヘッダーのオフセットアドレスを除いてゴミです。



続けましょう。

PE / COFF仕様は、オフセット0x3cに、署名「PE \ 0 \ 0」を持つ2番目のヘッダーの32ビットオフセットがあることを示しています。

 $ od /boot/vmlinuz-linux --address-radix=x --read-bytes=4 --skip-bytes=0x3c -t x4 00003c 000000b8 000040
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのため、オフセットは0xb8です。これは、x86_64アーキテクチャの現在の安定したカーネルに当てはまります。x86では0xa8になります。 私たちは読みます：

 $ od /boot/vmlinuz-linux --address-radix=x --read-bytes=4 --skip-bytes=0xb8 -t x1c 0000b8 50 45 00 00 PE \0 \0 0000bc
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、2番目のヘッダーの署名を示します。 ご想像のとおり、これはPortable Executableというフレーズの略語で、実行可能ファイル内のペイロードが開始されます。



Windowsブートローダーでさえ、このヘッダーのフィールドの約半分を気にせず、UEFIでもそれらを必要としなかったため、それらの一部は静的に登録されましたが、重要なものはカーネルアセンブリ中に入力されます。 多くの「不要な」フィールド、すべての種類のタイムスタンプ、制御合計などは、単にゼロのままです。 基本的に、寸法、オフセット、エントリポイントなどが入力されます。したがって、このPEファイルの名前を完全に拡張できます。 ただし、従来のLordPEまたはPEToolsユーティリティは、署名に非常に満足しており、ファイルについて知っていることをすべて伝えます。











Windowsの「実際の」実行可能ファイルとの主な違いは、オプションのヘッダーのサブシステムフラグです。これは、IMAGE_SUBSYSTEM_EFI_APPLICATIONで設定され、グラフィカルのIMAGE_SUBSYSTEM_WINDOWS_GUIまたはシンボリック（コンソール）アプリケーションのIMAGE_SUBSYSTEM_WINDOWS_CUIではありません。

構造

一般に、すべては通常のPEファイルの場合と同じです。 現在、Arch Linuxカーネルの安定バージョン3.11.4はリポジトリからのもので、「。setup」、「。reloc」、「。text」の3つのセクションが含まれています。

• .setupセクションには、互換モードでロードする場合の初期化のための主にレガシーコードが含まれています。 プロセッサのすべてのスイッチングモードであるUEFIモードにロードする場合、初期初期化はファームウェアによって行われます。
• ローダーには.relocセクションが必ず必要であるため、カーネルを構築するときに空の「つまり」スタブが作成されます。
• 実際、最も興味深い.codeセクションには、EntryPointと残りのカーネルのメインコードが含まれています。 EFIアプリケーションが見つかった後、ローダーはLoadImageブートサービスを実行し、それによりイメージ全体をメモリにロードします。 常駐のタイプは、サブシステムフィールドによって異なります。EFI_APPLICATIONは、機能するときにアンロードされます。 EFI_DRIVERはアンロード可能であり、重大なエラーが発生した場合にのみアンロードされます。 次に、制御はエントリポイントに転送されます。通常は、efi_main（）関数です。Cのmain（）に類似しています。

実際、最初はカーネルをexeファイルと呼んでいました。 実際、これはPE32 +形式を使用する単純なEFIアプリケーションです。

基本的な要件

まず、EFIモードブートモードをアクティブにする必要があります。 アイテムはベンダーが考えるように呼び出すことができ、通常は[ブートオプション]タブにあります。 レガシーモードやCSM（互換性サポートモード）、または単にBOISモードのようなものがある場合は、同様の（U）EFIモード、拡張モード、または詳細モードに変更します。



マザーボードに「Windows 8 Ready！」というロゴがある場合、ほとんどの場合、EFIブートモードはデフォルトですでにアクティブになっています。



ほとんどの場合、LinuxカーネルをEFIモードで起動するには、セキュアブートオプションを無効にする必要があります。

ディスクレイアウト

多くのソースは、 MBRではなくGPTパーティションが必要であることを示していますが、そうではありません。 UEFIはMBRに対応しています。 別のこと、たとえば、Windowsは強制的にディスクを強制的にEFIモードで起動する新しい方法でブレークし、マスターブートレコードの古さを誓います。 そして当然！ ディスクに最新のマークを付けておくと、何も失うことはなく、勝つだけです。

第一に、すべての種類のプライマリ/論理パーティション、「そこに行くな-ここに行く」などの基本的な問題はありません。

第二に、SolidStateディスクは大量に進んでいますが、そのボリュームはさほど驚くことではありませんが、数テラバイトの通常の「ターンテーブル」のサイズは誰も驚かないでしょう。 ただし、MBRでは、最大約2TBのパーティションをマークアップできます。 一方、GPT は多くのことを見ています。数を指定することさえできません。そのようなサイズのディスクは比較的すぐには表示されません。

さらに、ディスクの最初と最後でGPTレコードを複製する、整合性チェックサムなど、あらゆる種類のボーナスを追加することで、GPT用のディスクを指定することをためらうことなく望みを加えることができます。



GNU / Linuxのさまざまなユーティリティを使用してディスクをパーティション分割する方法に関する記事はたくさんあります。

別のセクション

セクションタイプ

nn-tat年にわたる標準の開発の後、エンジニアはハードコードは良くないと判断しました。 ブートパーティションがどこにあるかは問題ではありません。UEFIブートローダーはそれを非常に簡単に実行します。すべてのパーティションとディスクを順番に調べ、1つの特別なパーティションを探します。 その特異性は、MBRマークアップの場合、コードが0xEF（EFIから推測されるように）の型を持っているという事実にあります。 GPTマークアップの場合、 GUIDがC12A7328-F81F-11D2-BA4B-00A0C93EC93Bに等しいセクション 。



ここにはいくつかの暗黙があります。 たとえば、partedなどのすべてのマークアップユーティリティには、パーティションに適用される「ブート」フラグを設定および表示する機能があります。 したがって、MBRの場合、そのような可能性は実際に存在します。つまり、パーティションが「ブート可能」であることをBIOSに示す実際のバイトがあります。 このフラグは、MBRをダウンロードするBIOSにフィードするパーティションに配置できます。 しかし、GPTを扱っているときには、本当にフラグはありません！ このフラグにより​​、partedは上記と等しいGUIDのみを意味します。 つまり、実際にはGPTブートフラグ= GPT EFIパーティションです！ gdiskはこれに悩まされません：



結論： EFIパーティションがMBR上にある場合、パーティションタイプをEFIパーティションとブートフラグに設定します。 GPTがEFIパーティションタイプまたはブートフラグの場合、それらは同じものです。



保護的なMBRにインストールされるGPTレガシーブートフラグなど、あらゆる種類のものがありますが、これらはすべて互換モードでのみ使用される松葉杖です。 GPTモードでは、UEFIブートは無視する必要があります。

ファイルシステム

ソースが異なると、書き込みも異なります。 誰かがFAT16を使用できると言い、誰かがFAT12でも推奨しています。 しかし、公式仕様のアドバイスに従うほうがよいのではないでしょうか？ そして、システムパーティションはFAT32にある必要があると彼女は言います。 リムーバブルメディア（USB HDD、USBフラッシュ）の場合-FAT32に加えてFAT12 / FAT16も

パーティションのサイズについては何も言われていません。 ただし、ブートローダーとファームウェアの初期の松葉杖とバグの実装により、さまざまな「驚き」を回避するために、少なくとも520MiB（546MB）のサイズが推奨されることが実験的に判明しました。 ここでは、運が良ければ、32 MBのパーティションに問題はないかもしれません。

ディレクトリ構造

ローダーは「ラベル付き」パーティションを見つけてファイルシステムをサポートしていることを確認した後、パーティションのルートを基準にしたパスですべてのアクションを実行し始めます。 さらに、このセクションのすべてのファイルは\ EFI \ディレクトリにある必要があります。このディレクトリは、セクションのルートにある唯一のファイルです。 慣例により、各ベンダーは一意の名前のフォルダーを選択し、\ EFI \に配置することをお勧めします。例： \ EFI \ redhat \ 、 \ EFI \ microsoft \ 、 \ EFI \ archlinux \ 。 ベンダーのディレクトリには、直接実行可能なefiアプリケーションが含まれています。 アーキテクチャごとに1つのファイルをお勧めします。 ファイルには拡張子.efiが必要です。



リムーバブルデバイスの場合、 \ EFI \ BOOT \ディレクトリが対象です。 また、アーキテクチャごとに1つのファイルのみを推奨します。 これに加えて、ファイルはboot {arch} .efiと呼ばれるべきです。 たとえば、 \ EFI \ BOOT \ bootx64.efiです。 利用可能なアーキテクチャ： ia32、x64、ia64、arm、aa64 。

NVRAMアクセス

デフォルトでは、不揮発性UEFIメモリに何も書き込まれない場合、 \ EFI \ BOOT \ bootx64.efiがロードされます。 NVRAMに必要なアプリケーションへのパスを書き込むには、efibootmgrユーティリティを使用できます。 現在のエントリを表示してみましょう。

 # efibootmgr -v
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一部のディストリビューションでは、このユーティリティが機能するために含まれるカーネルオプションCONFIG_EFI_VARSが必要です。

降りる

そのため、 550 MiB FAT32 EFIシステムパーティション（ESP）をマークしました。 または、2番目のシステムを備えたWindowsがあり、すでに自分で作成しています。 確かに、彼女は通常、約100MBのサイズで作成しますが、個人的には、問題は一度もありません。

EFIブートSTUBをサポートするカーネルが/ bootに既にあります。



次に、いくつかのシナリオがあります。

• 最初に内容をコピーすることにより、 mount --bindを介してESP \ {vendor} \ on / bootをマウントでき ます 。
  例外

  このアイテムは、 / bootディレクトリにシンボリックリンクを含まないディストリビューションにのみ適しています 。 たとえば、カーネル自体を含むいくつかのリンクが含まれているため、openSUSEにマウントすることはできません。
• または、カーネルを更新するときに、毎回、カーネルとRAMディスクをESP \ {vendor} \にコピーします
• EFIドライバーを使用して/ブートファイルシステムを読み取って直接ブートし、カーネルに拡張子「.efi」を追加するだけで済みます（ハードリンクの改善）。

ここで、ブートポイントを何らかの方法でNVRAM UEFIに追加する必要があります。 ここでも、多くのオプションがあります。



ブートローダーGRUB2、rEFIndなどを使用して既にEFIモードでロードされている場合（efibootmgr -vは誓いません）、すべて正常です：

• カーネルパラメーターを送信できるefibootmgrを使用します。
• efibootmgrが起動したら、 UEFI Shellを使用できます。これは、コアと同様にEFIアプリケーションです。 彼のbcfgコマンドを使用して、ブートポイントを編集できます。
• そのようなオプションがあるかもしれません：efibootmgrはパラメーターを追加することを誓います。これは、ファームウェアがそれらの書き込みをサポートしていないことを意味します（または単に曲線である可能性が高い）。 前回の記事で、コメントはefi_no_storage_paranoiaカーネルパラメーターに言及していました 。 ただし、ファームウェアが仕様に従って完全に実装されていることが確実な場合にのみ使用できます。 開発者は、ベンダーが実装中に松葉杖と隙間を追加した場合、マザーボードの代わりにレンガを実現する可能性は低いと警告しています。
• UEFIシェルから起動することもできます。 目的のコマンドラインでカーネルブートコマンドを示すstartup.nsh スクリプトが作成されます。 そして、シェルがダウンロードポイントとして追加されます。
• 別の問題があります。1つのカーネルパスに対してのみアイテムを追加できますが、RAMディスクは表示されません。 ほとんどの記事では、組み込みのinitrdを使用してカーネルを再構築することを推奨しています。 これがカーネルの問題なのか、ブートローダーなのかはわかりません。 しかし、現時点では、90％のケースですべてがサポートされており、カーネルを再構築する必要はありません。
  
  
  エラーの考えられる原因

  カーネルにRAMディスクを埋め込むための推奨事項は、大抵、それへのパスを誤って指定するために行われました。 EFI Boot Stubの初期の実装では、カーネルはRAMディスクへの間違ったパスに関するエラーを吐き出しませんでしたが、静かにブートを拒否しました。 したがって、どうやら、誰もがカーネルに大量に導入し始め、サポートされていないと判断しました。 カーネルにブートスタブ機能が登場して以来、initrdパラメーターのサポートは存在していました。
  
  
  重要：RAMディスクへのパスは、 バックスラッシュ「\」を介して絶対に転送されますが、直接ではありません！ たとえば、 initrd = \ EFI \ archlinux \ initramfs-linux.img。
  
  
  アナキストの例外

  実際、3.8.0-rc5よりも高いバージョンのカーネルでは、フォワードスラッシュとバックスラッシュの違いは見られません。いずれも機能します。 しかし、バージョン3.2.0-rc5のブートスタブ機能の登場以来、カーネルは単にスラッシュで記録されたパスを認識せず、エラーなしでブートすることを静かに拒否しました。 これに関するエラーを宣誓し、バージョン3.4.0で学習しました。
  
  
  

EFIブートモードについて知り、ブートポイントを追加するために切り替えたい場合は、 既にこのモードである必要があります。それから、互換モードのままです。主な解決策は2つあります。

• EFIブートをサポートする最初のライブCDをダウンロードします。 そして、そこからすでにefibootmgrコマンドを使用します。
• UEFIシェルをダウンロードします。 それから、カーネルとRAMディスクを指定するだけでEFIモードで起動し、起動ポイントを編集できます。

ブートローダーなしのデュアルブート

2つのシステムが同時にインストールされていて、サードパーティのブートローダーをインストールしたくない場合は、両方をUEFIブートポイントに追加して、希望するブート順序を調整できます。 Windowsブートローダーは通常、 \ EFI \ Microsoft \ BOOT \ bootmgfw.efiにあります 。

合計

すべてが正常に完了したら、再起動し、ブートメニューを呼び出し、追加した項目を選択して、ほぼ瞬時のブートを確認します。 SSD、FastBoot、Readahead、およびArch Linuxの場合-約3〜4秒。 EFI Boot STUBを使用するサードパーティのブートローダーなしで、1年前からホームサーバーが読み込まれています。

もちろん、ここでの速度の向上はわずかですが、 Roderick Smithのような知識のある人が書いているように、EFIブートモードでは互換モードよりも「より適切な」機器の初期化が行われることがあります。

おわりに

UEFIファームウェアの相対的な湿気と完全に異なる実装のために、コード例を示しませんでした。 いずれの場合も、問題がある可能性があります。 私が説明したことが、一般原則を理解し、私の事例に当てはまることを願っています。

また、マザーボード製造元のWebサイトからUEFIの最新バージョンをフラッシュすることをお勧めします。

文学

UEFI公式仕様

Roderick W. SmithのWebページは、EFI、ブートローダー、およびディスクパーティションに関連する多くのユーティリティの著者の作品です。

ArchWiki：UEFIブートローダー -変更されておらず、ディストリビューションの1つで最も完全で最も完全なGNU / Linux wikiの1つ。

公式PE / COFF仕様