UEFI BIOSファイルデバイス、パート2：UEFIファームウェアボリュームとその内容

すでにこの記事の1部（ 1部 、 1部2部）の部分の後ろで、ついにUEFIファームウェアボリュームの構造とUEFIファイルシステムフォーマットについて説明します。

はじめに

記事のこの部分では、バージョン2のファイル形式について説明します。 既存のすべてのBIOSで使用されます。 PI規格の最新バージョンでは、バージョン3の形式の説明が追加されましたが、16 MBを超えるファイルにはまだ必要です。GigabyteはZ87ボードですでにこの点に近づいていますが、まだボードにはありません。 最新のすべてのIntelマザーボードの記述子領域は、16 MB以下の容量で2チップ以下をサポートしているため、バージョン3フォーマットの使用は、少なくともIntelチップセットの次世代の変更まで延期されます。



例として、Zotac Z77-ITX WiFiのファイルバージョン229からBIOS領域を取得します。

次のプログラムが必要になります。

• あなたの好みに合わせて16進エディタ、私はHxDを使用します
• ユーティリティPhoenixToolv2.xx。MDL フォーラムのトピックからダウンロードできます。

ファームウェア音量

ファームウェアボリュームの構造とPI FFS形式については、UEFIプラットフォーム初期化ドキュメントのボリューム3で説明されています。

ファームウェアボリュームは、次の属性を持つフラッシュコンテンツの論理表現です。

1. 名前：FVとそのすべての部分の名前はGUIDです
2. サイズ：すべてのデータ、ヘッダー、および空き領域が含まれます
3. 形式：FV内のファイルシステムタイプ、異なるタイプには異なるGUIDがあります
4. Allignment：FVの最初のバイトは、指定された境界（次数2の倍数）に位置合わせされる必要がありますEFI_FVB_WEAK_ALIGNMENT
   
   
   
   の位置合わせは、ヘッダーにEFI_FVB_WEAK_ALIGNMENT
   
   
   
   フラグが設定されていない限り、その中のすべてのファイルの位置合わせよりも弱くはなりません。 この場合、2の累乗でアライメントを実行できますが、このFVは移動できなくなります
5. 読み取り、書き込み保護、自己無効化読み取りまたは書き込み保護の属性
6. OEMの裁量オプション

FV内で使用されるファイルシステムに関係なく、FVヘッダーは標準化され、次のようになります。

 typedef struct { UINT8 ZeroVector[16]; UINT8 FileSystemGuid[16]; UINT64 FvLength; UINT32 Signature; UINT32 Attributes; UINT16 HeaderLength; UINT16 Checksum; UINT16 ExtHeaderOffset; UINT8 Reserved[1]; UINT8 Revision; EFI_FV_BLOCK_MAP BlockMap[]; } EFI_FIRMWARE_VOLUME_HEADER; typedef struct { UINT32 NumBlocks; UINT32 Length; } EFI_FV_BLOCK_MAP
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ZeroVector ：FVの先頭では、リセットベクトルがゼロアドレスにあるプロセッサとの互換性のために16バイトが予約されています。 このブロックにゼロ以外の何かが存在することで、ブートファームウェアボリュームを他のボリュームと間違いなく区別できます。

FileSystemGuid ：このFV内で使用されるファイルシステムを定義します。

FvLength ：すべてのヘッダーのFVサイズ。

署名 ：FVの検索に使用され、標準では常に0x4856465Fです。 {'_','F','V','H'}



。

属性 ：上記で説明したのと同じ属性。 そこにはたくさんありますが、私たちにとって最も重要なのは前述のEFI_FVB_WEAK_ALIGNMENT



。これは、FVがインストールされている場合、 EFI_FVB_ALIGNMENT



からEFI_FVB_ALIGNMENT_1



からEFI_FVB_ALIGNMENT_2G



およびEFI_FVB_ERASE_POLARITY



のセットの1つです。 残りは、メモリ領域としてFVで動作するコードに必要であり、私たちにとっては役に立たないので、それらをリストしません。

HeaderLength ：拡張ヘッダーを除くヘッダーのサイズ。約以下。

チェックサム ：16ビットヘッダーチェックサム。 正しいヘッダーの合計は0x0000になります。

ExtHeaderOffset ：拡張ヘッダーの先頭のオフセット。 記述されたFVのGUID、GUIDとともにOEMファイルタイプのリスト、および電子署名を含めることができます。 現時点では、拡張ヘッダーが埋め込まれた単一のFVは見たことがありません。そのため、考慮しません。 FVに追加のヘッダーがない場合、このフィールドには0x0000があります。

予約済み：予約済みフィールド、常に0x00。

リビジョン ：PI標準では、1つのリビジョン（2番目のリビジョン）の構造のみが記述されているため、このフィールドは常に0x02です。

BlockMap ：両方のフィールドにゼロがある同じ構造で終わるEFI_FV_BLOCK_MAP



構造のリストとして保存されるブロックマップ。 なぜなら 最新のフラッシュマイクロサーキットはすべて同種である（つまり、同じサイズのブロックを持っている）ため、リスト全体は通常2つのエントリのみで構成されています。



上記のコンプライアンスの例を確認しましょう。

16進エディタでBIOSファイルを開き、BIOS領域の先頭までのオフセット0x500000に移動します。



先頭に16個のゼロがあり、ファイルシステムGUIDがあり、このFVのサイズが0x020000であり、署名が配置され、属性が設定され、ヘッダーのサイズが0x48バイトであり、チェックサムが計算され、拡張ヘッダーがなく、予約フィールドが配置され、この中にあることがわかりますFVにはそれぞれ0x1000のブロックが20個あり、合計でFvLengthフィールドに示されたサイズを正確に与えます。

ほとんどの場合、BIOSにはさまざまな目的のために設計されたいくつかの異なるFVがありますが、これは必須ではなく、すべてを1つにまとめることができます。 UEFI BIOSのすべてのメーカー間でのFVとファイルのネストの度合いのチャンピオンはIntelで、最大12レベルのネストがあります。

理論的には異なるファイルシステムをFVに使用できますが、実際には1つだけが使用されます。PIFFSについては、これから説明します。

ファームウェアファイルシステム

これは、ディレクトリと階層のないフラットファイルシステムであり、そのファイルはすべてhorseディレクトリにあります。 ファイルのリストを取得するには、FSを最初から最後まで実行する必要があります。 すべてのファイルには、標準で定義されたヘッダーが必要です。 ファイルは、ファイルシステムの先頭から8バイトの境界線上に配置する必要があります。大きな境界線上に配置するには、特別なファイルプレースホルダーが提供されます。

この規格では、各FVの最後に存在する必要がある特別なVTFファイルについても説明していますが、実際には、BIOSイメージの最後のFVの最後にのみ存在し、その最後のバイトがチップ全体の最後になるように配置されています。 SECフェーズに必要なブートストラップコードが含まれています。

ファイルヘッダー

FFSファイルヘッダーは次のように構成されています。

 typedef struct { UINT8 Name[16]; UINT8 HeaderChecksum; UINT8 DataChecksum; UINT8 Type; UINT8 Attributes; UINT8 Size[3]; UINT8 State; } EFI_FFS_FILE_HEADER;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

名前 ： 名前として機能するファイルのGUID。 1つのFVに、以下で説明するPADファイルでない場合、同じGUIDを持つ2つのファイルは存在できません。

HeaderChecksum ：DataChecksumフィールドを除く8ビットのヘッダーチェックサム。 正しいヘッダーは、合計で0x00になります。

DataChecksum ：ヘッダーを除く、ファイルの内容の8ビットチェックサム。 常に計算する必要はありませんが、 FFS_ATTRIB_CHECKSUM



属性がFFS_ATTRIB_CHECKSUM



場合のみです。それ以外の場合、このフィールドはFFS_ATTRIB_CHECKSUM



設定されます。

タイプ ：ファイルタイプ。 標準では、13の標準ファイルタイプ（0x01-0x0D）、OEMファイル用の32ユーザータイプ（0xC0-0xDF）、デバッグ用の16ユーザータイプ（0xE0-0xEF）、および現在のバージョンのFFSに固有の16タイプ（0xF0-0xFF）を定義しています現在0xF0のみが使用されています-プレースホルダーファイルにはEFI_FV_FILETYPE_FFS_PAD



。

この特殊ファイルには、null GUID、null属性、標準状態、および任意のサイズなど、任意のものを含めることができます。 標準によると、ファイルは空でなければなりません。 ヘッダービットを除くすべてのビットをEFI_FVB_ERASE_POLARITY



に設定する必要があります。 これは、標準の8バイトより大きい境界に沿って、それに続くファイルを位置合わせするために使用されます。 PADファイルの最小サイズは、ヘッダーのサイズ-24バイトです。

標準のファイルタイプに戻ります。

属性 ：私たちにとって重要な属性はFFS_ATTRIB_FIXED



。これは、ファイルがFV内にFFS_ATTRIB_FIXED



できないことを示し、FFS_ATTRIB_DATA_ALIGNMENTのセットは、ファイルのデータ（ヘッダーではなく）が境界に整列していることを示します。

サイズ ：24ビットUINTとして保存されたヘッダーと共にファイルサイズ。

状態 ：ファイルの状態。 このフィールドは、FVをメモリにロードした後、およびFV内のファイルの操作中に使用されます。 BIOSイメージ内のすべての有効なファイルのステータスは0xF8です。



ファイルの種類に戻ります。 この記事の1.5部をまだ読んでいない人は、を読んで読むことをお勧めします。そうしないと 、何も理解できない危険があります。

既に知っているように、13の標準ファイルタイプが定義されています。

役職	種類	説明
RAW	0x01	このようなファイルの構造は、ユーザーによって完全に決定され、事前に何も知られていない
フリーフォーム	0x02	このようなファイルにはセクション構造がありますが、セクションの内容については事前に何もわかりません。
SECURITY_CORE	0x03	SECフェーズでコードを実行するセキュリティカーネル
PEI_CORE	0x04	PEIコア、別名PEI Foundation
DXE_CORE	0x05	DXEのコア、別名DXE Foundation
ペイム	0x06	PEIモジュール
ドライバー	0x07	DXEドライバー
COMBINED_PEIM_DRIVER	0x08	ハイブリッドPEI / DXEモジュール
申込み	0x09	アプリケーション。 起動するのはDXEマネージャーではなく、ユーザーであるという点でDXEドライバーとは異なります。 アプリケーションは、UEFIセットアップ、UEFIシェル、BIOSアップデートなどです。
SMM	0x0A	SMMモジュール
FIRMWARE_VOLUME_IMAGE	0x0B	画像FV。 これは、あるFVを別のFVに埋め込むことができる特別なファイルです
COMBINED_SMM_DXE	0x0C	SMM / DXEハイブリッドモジュール
SMM_CORE	0x0D	カーネルSMM、別名SMM Init

ファイルで上記を確認してください。



FVヘッダーの最初の0x48バイトはもう興味がありませんが、すぐ後に続くものが興味を持ちます。 GUID CEF5B9A3-476D-497F-9FDC-E98143E0422C、ヘッダーチェックサム0x36、削除された属性FFS_ATTRIB_CHECKSUM



を示すデータチェックサム0xAA、属性なし、サイズ0x1FFB8標準のファイルがあることがわかります。 。 真実のように聞こえます。



次にセクションについて。 RAWを除くすべてのFFSファイルは、ファイルデータ領域の先頭から4バイトの境界で整列したセクションに分割する必要があります。 各タイプのファイルには、セクションの数とタイプに関する独自の要件がありますが、この記事には要件のリストはありません。長すぎて退屈すぎます。 しかし、セクションの見出し、それらの目的と種類については、現在検討しています。

セクションヘッダー

最小セクションヘッダーは次のようになります。

 typedef struct { UINT8 Size[3]; UINT8 Type; } EFI_COMMON_SECTION_HEADER;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サイズ ：ファイルヘッダーと同じ形式のセクションサイズ。

タイプ ：セクションのタイプ。

セクションは、カプセル化とリーフの2つのサブクラスに分けられます。 前者には他のタイプのセクションが含まれ、後者には直接データが含まれます。 一部のタイプのセクションには拡張ヘッダーがありますが、先頭は常に一般的なヘッダーと一致します。

カプセル化セクションには、次の3種類のコンテンツが定義されています。

0x01- EFI_SECTION_COMPRESSION



は、セクションが何らかのアルゴリズムに従って圧縮されていることを示します。

EFI_COMPRESSION_SECTIONの完全な見出し（タイトルの単語が混同されていない、それだけです）は次のようになります。

 typedef struct { UINT8 Size[3]; UINT8 Type; UINT32 UncompressedSize; UINT8 CompressionType; } EFI_COMPRESSION_SECTION;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

UncompressedSize ：解凍されたデータのサイズ。

CompressionType ：適用された圧縮アルゴリズム。

現時点では、Tiano（0x01）とLZMA（0x02）の2つの圧縮アルゴリズムがあります。 構造を変更せずにセクションがアンパックされた場合、圧縮タイプとして0x00が設定され、セクションサイズはパックされたデータのサイズと一致します。 TianoアルゴリズムはLZ77とIntelのハフマンコードの組み合わせであり、圧縮および解凍コードはBSDLの下のTianoCoreプロジェクトファイルから取得できます。 LZMAアルゴリズムはあまりにもよく知られているので、再度説明することはできません。圧縮および圧縮解除コードはLZMA SDKにあります。



カプセル化セクションのタイプについて続けましょう。

0x02- EFI_SECTION_GUID_DEFINED



は、セクションに記録されたGUIDに従って、ファイルのユーザーがセクションの内容を表示する必要があることを示します。 このようなセクションでは、さまざまなOEMデータ、およびセクションまたはファイル全体の電子署名を保存できます。

0x03- EFI_SECTION_DISPOSABLE



は、データがファイルの操作にとって重要ではなく、スペースを節約するために再アセンブリ中に削除できるセクションを示します。 実際のファイルでは、BIOSは見つかりません。

リーフセクションには、12のコンテンツタイプが定義されています。

役職	種類	説明
PE32	0x10	すべてのヘッダーを含むPE32 +形式の64ビット実行可能コード。 UEFIの実行可能コードのメイン形式。
写真	0x11	64ビットの位置に依存しない実行可能コード。 一部のPEIモジュールでのみ使用され、形式はPE32 +と同じです。再配置情報のみが切り捨てられます。
TE	0x12	モジュールおよびPEIコアで使用される64ビットの実行可能コード。 PE32 +とは、プロセッサキャッシュのスペースを節約するために削減されたヘッダーが異なります。 この記事の1.5部の説明を読んでください。
DXE_DEPEX	0x13	配置されているDXEドライバーの依存関係を説明するセクション。 このセクションの形式については、第2巻で説明しています
バージョン	0x14	ファイルのバージョンと、オプションでフルバージョンのUnicode文字列が含まれます。 非常にまれです。
USER_INTERFACE	0x15	ファイル名を持つunicode-termが含まれます。 このセクションの内容でファイルを検索すると非常に便利です。 これは頻繁に使用されますが、そのようなセクションを含む単一のファイルがないBIOSも見つかります。
互換性16	0x16	古いシステムとの互換性のための16ビット実行可能コード。
FIRMWARE_VOLUME_IMAGE	0x17	FV画像を含むセクション。 このFV内には、マイクロサーキット内の場所がなくなるまで、そのようなセクションを含むファイルがある場合もあります。
FREEFORM_SUBTYPE_GUID	0x18	セクションにはデータが含まれ、その解釈は記録されたGUIDの先頭に依存します。 めったに使用されません。
RAW	0x19	生データを含むセクション。 それらをどうするかは、このファイルを開いた人によって決定されます。
PEI_DEPEX	0x1B	常駐するPEIモジュールの依存関係を説明するセクション。 このセクションの形式は、ボリューム1で説明されています。
SMM_DEPEX	0x1C	配置されているSMMドライバーの依存関係を説明するセクション。形式はDXE_DEPEXと同じです。

上記の例で確認してください。 前回検討したRAWファイルにはセクションが含まれていないため、別のファイル、つまりオフセット0x7AD210にあるPchUsbという名前のPEIモジュールを取り上げます。



これは実際にはPEIM（ファイルタイプは0x06）であり、2つのセクションが含まれていることがわかります。 サイズ0x3AおよびタイプPEI_DEPEX（0x1B）の最初のセクションには、その依存関係に関する情報が含まれています。 2番目のセクション（4バイトの境界で整列）のサイズは0x31Aで、COMPRESSED_SECTION（0x01）型であり、その中のデータはLZMAアルゴリズム（0x02）でパックされ、アンパック後のサイズは0x558です。 LZMAを解凍する方法を心得ている場合は、このセクションの内容をすでに推測しているはずです。そうでない場合は、お知らせします。 さらに2つのセクションがあります。モジュールの実行可能コードを含むPE32と、ファイル名を含むUSER_INTERFACEです。 あなたは、LZMAを私の心の中に解凍できないかどうか、どうやって知るのですか？ そのためのアプリがあります！

PhoenixToolと結論

このアプリケーションはPhoenixToolと呼ばれ、その主なタスクはSLICをUEFI BIOSファイルに追加することですが、私たちは法を順守しており、BIOSにSLICを追加しません。 プログラムのすべての機能の中で、使用するBIOSを指定した後に使用できる[構造]ボタンに注目します。 構造が別のウィンドウで開き、UEFI BIOSイメージがツリーとして表示されます。 各コンポーネントについて、その情報と使用可能なアクションが右側に表示されます。 このウィンドウの上記の例で検討したファイルは次のようになります。



このプログラムでは、ファイル構造の編集を制限できますが、回避するためにファイル構造を変更しないことをお勧めします。



UEFI実行可能ファイルをより適切に編集する方法とこれができることについては、次の記事を参照してください。

ご清聴ありがとうございました。

文学

UEFIプラットフォーム初期化仕様1.2.1エラッタA、UEFIフォーラムによるドキュメント