BIOSセットアップおよびその他のUEFIアプリケーションからスクリーンショットを取得するためのDXEドライバーを作成しています

SecureBootに関する最後の記事では、BIOSセットアップを介してUEFIを構成する際にスクリーンショットを撮る機能が本当に不足していましたが、テキストコンソールをシリアルポートにリダイレクトしました。 これは素晴らしい解決策ですが、いくつかのサーバーマザーボードで使用できます。それを使用すると、擬似グラフィックのみを取得できますが、実際の擬似グラフィックを取得したいです。見栄えがよく、毎回ターミナルウィンドウから切り取る必要はありません。

これがまさにこの記事で行うことですが、同時にDXEドライバーとは何か、それを自分で作成、組み立て、テストする方法、UEFIでのキーボード入力と画面への出力の仕組み、接続されたストレージデバイス間でこれを見つける方法、ファイルを書き込むことができる場所、UEFIからファイルに何かを保存する方法、および外部Cコードをファームウェアの一部として機能するように適合させる方法。

あなたがまだ興味があるなら、私はあなたの下であなたを待っています。

免責事項

UEFIのドライバーの作成とデバッグについて話す前に、ファームウェアの実験は危険なビジネスであり、「レンガ」につながる可能性があり、最も不幸な場合にはハードウェア障害につながる可能性があるとすぐに言っておく価値があります。事前に警告します。あなたがここで読むすべては、あなた自身の危険とリスクで使用します、私はあなたのファームウェアまたはボードの機能性の損失に対して責任を負いません。 ファームウェアで実験を開始する前に、プログラマを使用してSPIフラッシュの内容全体の完全なコピーを作成する必要があります。 この方法でのみ、ソフトウェアの障害後のファームウェアの正常な回復を保証できます。

プログラマーはいないが、 DXEドライバーを作成してデバッグしたい場合は、 OVMF 、VmWare Workstation 12、またはUEFIがサポートされている他の仮想化システムを使用してください。

そこで必要なものとそれがDXEドライバーである理由

私たちのタスクは、特定のキーの組み合わせを押すことで、UEFIアプリケーションの操作中（たとえばBIOSセットアップ）に画面全体からスクリーンショットを取得し、書き込みアクセス権を持つファイルシステムを見つけて、結果のスクリーンショットを保存することです。 何らかのステータス表示を取得するのもいいでしょう。 なぜなら スクリーンショットを撮るには、UEFIアプリケーションの操作を中断する必要があります。UEFIにはプリエンプティブマルチタスクがまだないため、それらを削除するプログラム自体はアプリケーションにはなりません。したがって、DXEドライバーが必要です。

その作業のスキームは、およそ次のように計画されています。

0 。 テキスト入力（キーストロークを処理するため）とグラフィック出力（スクリーンショットを取得するものがあるように）の出現後にのみロードします。

1 LCtrl + LAlt + F12の組み合わせ（または好みに合わせて）を使用可能なすべての入力テキストコンソールに押すためのハンドラーを切断します。

2 。 ハンドラーでは、すべての出力グラフィックコンソールを見つけ、それらからスクリーンショットを取得し、 PNG形式にエンコードします （UEFIアプリケーションは通常数百万色を使用しないため、この形式のスクリーンショットはBMPで数メガバイトではなく数十キロバイトのサイズで取得されます）。

３ 。 同じハンドラーで、ルートに書き込むことができる最初のファイルシステムを見つけ、そこに受信したファイルを保存します。

最初に見つかったFSではなく、たとえばUSBデバイスのみまたはESPパーティションのみを選択することで機能を拡張することができます。これを読者に任せて、独立して動作させてください。

SDKを選択

UEFIで動作する新しいコードを作成するための2つの異なるSDKがあります。UEFIフォーラムの新しいEDK2と、古いIntelコードに基づいた独立した開発者のGNU-EFIです。 どちらのソリューションも、Cおよび/またはアセンブラーでコードを記述することを意味します。この場合、純粋なCとのやり取りを試みます。

どのSDKが優れているかを判断することは私にとってではありませんが、EDK2を使用することをお勧めします。 公式でクロスプラットフォームであり、変更のソースに近いため、新しい機能（古いバグの修正とともに）がはるかに速く表示されます。また、コードを作成するすべてのIBVで使用されます。

EDK2は絶え間ない開発の過程にあり、トランクに1日に2〜3コミットを一貫して追加していますが、ここでは最新のトレンドを追跡しないため（まだ動作しません）、このために後者を使用しますUDK2015と呼ばれる瞬間安定カットEDK2 。

さまざまなコンパイラーによってクロスプラットフォームおよびビルド機能を提供するために、EDK2はTXT（環境構成）、DEC、DSCおよびFDF（パッケージ構成）およびINF（コンポーネント構成）構成ファイルを使用して各プラットフォームのメイクファイルを生成します。物語、そして今すぐEDK2を入手してHelloWorldをアセンブルする必要があります 。今すぐ詳細を調べるのが待ちきれない場合は、ドキュメントに従ってください。

ビルド環境をカスタマイズする

Cおよびアセンブラーでコードをビルドするために必要なソフトウェアはすでにマシンにインストールされていることが理解されています。 そうでない場合、WindowsユーザーはWindowsデスクトップ用Visual Studio 2013 Expressをインストールすることをお勧めします; LinuxおよびOSXユーザーはGCC 4.4-4.9およびNASMが必要です。

これらすべてが既にインストールされている場合は、 UDK2015をダウンロードし、UDK2015.MyWorkSpace.zipのすべてのコンテンツをファイルを作成する権限がある場所（少なくともデスクトップまたはホームディレクトリに直接）に解凍し、 BaseTools（Windows）のコンテンツを解凍するだけです。 .zipまたはBaseTools（Unix.zip）を前の手順で取得したMyWorkSpaceディレクトリに追加し、 UDK2015などで適切な名前に変更します。

ターミナルを開き、新しく作成されたUDK2015ディレクトリに移動して、 edksetup.bat （または.sh ） スクリプトを実行します 。これにより、テキストファイルのセットがConfサブディレクトリにコピーされます。tools_def.txtおよびtarget.txtに注目します。

最初のファイルは十分に大きく、アセンブリー環境に必要なコンパイラーCおよびASL 、アセンブラー、リンカーなどへのパスを持つ環境変数の定義が含まれています。 必要に応じて、そこに示されているパスを修正するか、独自のユーティリティセット（いわゆるToolChain ）を追加できますが、私のアドバイスを聞いた場合は、VS2013（32ビットWindowsの場合）またはVS2013x86（で64ビットWindowsの場合）、またはGCC44 | ... | GCC49（GCCのバージョンに応じて、 gcc --versionに応じて親切に表示されます）。

2番目のファイルにはデフォルトのアセンブリ設定が含まれており、次の値を設定することをお勧めします。

ACTIVE_PLATFROM = MdeModulePkg/MdeModulePkg.dsc #      TARGET = RELEASE #   TARGET_ARCH = X64 # DXE     64-,       TOOL_CHAN_TAG = VS2013x86 # | VS2013 | GCC44 | ... | GCC49 | YOUR_FANCY_TOOLCHAIN,      
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

UDK2015で別のターミナルを開き、Linux / OSXで次のコマンドを実行します。

 . edksetup.sh BaseTools
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Windowsの場合、パラメーターのない通常のedksetup.batで十分です。

ここで、すべてが正しく実行された場合、 ビルドコマンドを使用してビルド環境をテストし、一定時間後に次のようなメッセージで終了します。

 - Done - Build end time: ... Build total time: ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

[ 完了]の代わりに[ 失敗]が表示される場合、設定に問題があります。 WindowsのVS2013x86およびXubuntu 14.04.3- OIAの GCC48で上記を確認しました。

プロジェクト構造

EDK2のアプリケーションとドライバーは個別にアセンブルされるのではなく、いわゆるパッケージの一部として、つまり パッケージ。 アプリケーション自体に加えて、パッケージには、ライブラリ、ヘッダーファイルのセット、およびパッケージの構成とその内容の説明が記述されたファイルも含まれます。 これは、さまざまなドライバーとアプリケーションがさまざまなライブラリー実装を使用して、さまざまなヘッダーファイルとGUIDにアクセスできるようにするために行われます。 MdeModulePkgを使用します。これは、アーキテクチャとハードウェアに依存しない非常に一般的なパッケージであり、ドライバーを組み込むことができれば、UEFI 2.1以降の実装で動作することがほぼ保証されます。 このアプローチの欠点は、その中のほとんどのライブラリ（たとえば、デバッグ出力を取得するために使用されるDebugLib）が単なるスタブであり、そのような必要が生じた場合は自分で作成する必要があることです。

ドライバーをビルドするには、ビルドする必要のあるライブラリ、プロトコル、ファイルに関する情報を含むINFファイルが必要です。また、このINFファイルへのパスをパッケージのDSCファイルに追加して、アセンブリシステムがそのINFを認識できるようにしますファイルは。

最後から始めましょう。ファイルUDK2015 / MdeModulePkg / MdeModulePkg.dscを開いて、[Components]セクションまでスクロールします（検索で見つけることができます-高速です）。 このセクションには、パッケージに属するすべてのファイルが順番にリストされます;セクションの先頭は次のようになります。

 [Components] MdeModulePkg/Application/HelloWorld/HelloWorld.inf MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.inf ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そこに将来のINFファイルを、 UDK2015に対する相対パスとともに追加します。 MScreenModuleDkgでCrScreenshotDxeフォルダーを直接作成し、INFファイルにCrScreenshotDxe.infという名前を付けることを提案します。 ご想像のとおり、CrはCodeRushの出身であり、この記事の著者は謙虚です。 結果は次のようになります。

 [Components] MdeModulePkg/CrScreenshotDxe/CrScreenshotDxe.inf MdeModulePkg/Application/HelloWorld/HelloWorld.inf MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.inf ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

変更を保存し、DSCファイルを閉じます。デバッグ出力を構成したくない場合は、それを変更しませんが、これはまったく別の話です。

次に、INFファイル自体を入力する必要があります。

上記のCrScreenshotDxe.sファイルを作成します。 今すぐbuildコマンドを繰り返した場合、成功する必要があります。そうでなければ、何か間違ったことをしました。

さて、最後に、ドライバー用の空白があり、コードの作成に直接進むことができます。 このようなアセンブリシステムは役に立たないことは明らかであり、テキストファイルを編集して作業することはあまり快適ではないため、各IBVにはEDK2アセンブリシステムを最新のIDEに統合する独自のソリューションがあります。たとえば、AMI Visual eBIOS環境はこれにはEclipseプラグインが含まれ、PhoenixとInsydeにはVisual Studioが含まれています。

有名なコンピューターセキュリティの専門家であるAlex Ionescuによって作成された素晴らしいVisualUefiプロジェクトがまだあります。VisualStudioが好きなら、ぜひ試してみることをお勧めしますが、今のところハードコアを使い続け、オールドスクールの精神を維持します。

キーストロークへの対応

ここではすべてが非常に簡単です：ドライバーを読み込むとき、 SimpleTextInputExプロトコルのすべてのインスタンスをソートします。これは、いくつかのキーボードがシステムに接続されている場合でも、キーボードドライバーによって公開されます。 それにもかかわらず、念のため、利用可能なすべてのインスタンスをソートし、応答するキーの組み合わせをパラメーターとして受け入れる各関数RegisterKeyNotifyと、押した後に呼び出されるコールバック関数へのポインターを呼び出し、組み合わせが必要です。すべての主要な作業はすでに完了しています。

コンパイルを成功させるには、 後述のTakeScreenshotおよびShowStatus関数ではまだ十分ではありません。

書き込みアクセス、ファイルへのデータ書き込みが可能なFSを探しています

利用可能なグラフィックコンソールを探して、そこからスクリーンショットを撮る前に、これらの同じスクリーンショットをどこかに保存できるかどうかを確認する必要があります。 これを行うには、 SimpleFileSystemプロトコルのすべてのインスタンスを検索します。SimpleFileSystemプロトコルは、FSがファームウェアに認識されている検出された各ボリュームのPartitionDxeドライバーによって公開されます。 ほとんどの場合、既知のFSはFAT12 / 16/32ファミリ（FAT32のみ）のみであり、UEFI規格に従ってESPに使用できます。 次に、見つかったFSに書き込むことができることを確認する必要があります。さまざまな方法でそれを行うことができます。最も簡単な方法は、その上にファイルを作成し、読み取りおよび書き込み用に開くことです。それが機能する場合、このFSに書き込むことができます もちろん、このソリューションは最適ではありませんが、機能するため、演習として読者に正しい実装が提供されます。

このコードは他に何も必要とせず、そのまま機能します。

グラフィカルコンソールを探しており、そのスクリーンショットを撮ります

スクリーンショットを保存するものがあることを確認したら、それらを削除しましょう。 これを行うには、各出力デバイスについて、GOPドライバーおよびVideoBIOSによって公開されたGOPプロトコルのすべてのインスタンス（より正確には、プロトコルについて何も知らないVBIOS自体ではなく、古いVBIOSとUEFIの間のレイヤーを実装するConSplitterドライバー）をソートする必要がありますグラフィックス付き。 このプロトコルには、 最初の画像のみが必要になるまでフレームバッファとの間で画像をコピーするためのBlt機能があります。 同じプロトコルのModeオブジェクトを使用すると、目的のサイズのバッファーを選択し、画面の一部からではなく画面全体からスクリーンショットを撮るのに必要な現在の画面解像度を取得できます。 スクリーンショットを受け取ったので、完全に黒ではないことを確認する価値があります。そのようなものを保存すると、FSで時間とスペースが無駄に消費されるためです。ペイントで必要なサイズの黒い長方形を描画できます。 次に、画像をBGR（Bltが提供する）からRGB（PNGエンコーダが必要とする）に変換する必要があります。そうしないと、スクリーンショットの色が間違ってしまいます。 変換後に取得した画像をエンコードし、前の手順で見つけたファイルシステム上のファイルに保存します。 現在の日時から8.3形式でファイル名を収集するため、あるスクリーンショットが別のスクリーンショットを上書きする可能性は低くなります。

Lodepng_encode32は作業とShowStatusに既に十分ではありませんが、継続します。

画像をPNG形式でエンコードします

コードを記述する最良の方法は、コードを記述しないことです。そのため、 lodepngと呼ばれるPNGのエンコードおよびデコード用の既製のライブラリを使用してみましょう。 ダウンロードし、Cファイルの横に置き、 lodepng.hとlodepng.cの行を[Sources.common] セクションのINFファイルに追加し、ヘッダーファイルを含めます。...何もコンパイルしません。標準のC言語ライブラリはこのようにして完全に削除できます。 初めて仕上げます。

lodepng.hの先頭に、次を追加します。

 #include <Uefi.h> //      UEFI #define LODEPNG_NO_COMPILE_DECODER //   PNG #define LODEPNG_NO_COMPILE_DISK //    , .. fopen/fwrite    #define LODEPNG_NO_COMPILE_ALLOCATORS //   malloc/realloc/free, ..     #define LODEPNG_NO_COMPILE_ERROR_TEXT //     #define LODEPNG_NO_COMPILE_ANCILLARY_CHUNKS //     PNG, ..   #if !defined(_MSC_VER) //   size_t  GCC,  MS        #define size_t UINTN #endif
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、行を#include <string.h>でコメントアウトしますが 、これもありません。 もちろん、そこにtype_t型を定義することで同じ名前のローカルファイルを作成できますが、変更し始めているので変更します。

Lodepng.cはもう少し複雑です size_tに加えて、標準ライブラリから、memset、memcpy、malloc、realloc、free、qsortも必要であり、浮動小数点計算も使用します。 Qsortの実装はAppleからドラッグでき、メモリ関数はgBS-> CopyMem 、 gBS-> SetMem 、 gBS-> AllocatePoolおよびgBS-> FreePoolのラッパーにすることができ、FPUでの作業について通知するにはCONST INT32定数を定義する必要があります_fltused = 0; そうでなければ、リンカーは彼女の不在を誓います。 標準の#includesを使用してファイルにコメントを付けることについてはもう話していません。すべてが明確です。

Qsort.cも同じ方法で通常の戦闘に還元されます。それを.infファイルに追加することを忘れないでください。

ステータスを表示する

ShowStatus関数を記述するのは残り、ドライバーの準備は完了です。 この同じステータスはさまざまな方法で取得できます。たとえば、POSTエンコーダーに接続されているCPU IOポート80hで0x00から0xFFまでの数字を出力しますが、誰もが持っているわけではありませんが、ラップトップではまったく発生しません。 スピーカーをきしむことはできますが、これはまずプラットフォームに依存しており、2番目にスクリーンショットを2枚撮った後、私を激怒させます。 キーボードのライトを点滅させることができます。これは読者にとって追加のタスクです。このグラフィックコンソールを介してグラフィックコンソールを直接操作する状態を表示します。画面の左上隅に目的の色の小さな四角形を表示します。 この場合、白い四角は「ドライバーが正常にロードされました」、黄色-「記録機能のないFS」、青-「現在のコンソールのスクリーンショットは完全に黒で、保存しても意味がありません」、赤-「エラーが発生しました」、最後に緑-を意味しますスクリーンショットを撮って保存しました。」 すべてのコンソールでこの四角形を表示し、しばらくしてから、上書きされたイメージの一部を復元する必要があります。

これですべてが準備が整い、正常に実行されますが、準備が整うまで見たり、GitHubから既製のドライバーをダウンロードして自分のドライバーと比較したり、いくつかの変更を説明するのを忘れていました。

UEFIシェルで結果をテストする

UDK2015 / Build / MdeModulePkg / RELEASE / X64 / MdeModulePkg / CrScreenshotDxe / CrScreenshotDxe / OUTPUTからアセンブルされたドライバーを取得します。そこから必要なファイルは2つだけです。CrScreenshotDxe.efiドライバー自体と、 CrScreenspexDeの依存関係セクションです。

最初に、UEFIシェルからドライバーの動作をテストします。 UEFIシェルを使用してファイルCrScreenshotDxe.efiをUSBスティックにコピーし、ブートして、 fs0：でフラッシュドライブのルートに移動します（システムに接続されているディスクの数に応じて数が変わる場合があります） 。load CrScreenshotDxe.efiコマンドを実行します 。 成功メッセージが表示され、画面の上部隅に白い四角が点滅している場合は、ドライバーが稼働中であることを意味します。 私にとってはこのように見えます：

次に、 LCtrl + LAlt + F12を大胆に押して、ステータスを確認します。 AMIシステムでは、グラフィックコンソールが1つしかないため、緑色の四角形が点滅し、1回の組み合わせで1つのスクリーンショットを取得します。 PhoenixとInsydeを使用しているシステムでは、2つのグラフィックコンソールがあり、そのうちの1つは空であるため、最初に青い正方形、次に緑の正方形が表示されますが、スクリーンショットも1つしかありません。 UEFIシェルからのテスト結果は同じように見えます。解像度は800x600ではなく、1366x768です。

さて、すべてがシェルから機能し、次のようにUEFIアプリケーションからスクリーンショットを取得できます。

変更されたファームウェアで結果をテストする

残念ながら、BIOSセットアップのスクリーンショットはこの方法では削除できません-ドライバーの読み込みが遅すぎます。 2つの解決策があります。1つ目は、 UEFIToolを使用してファームウェアのDXEボリュームの依存関係セクションと共にドライバーを追加することです。2つ目は、PCIeデバイスのOptionROMに追加することです。その後、ファームウェアの変更は不要です。後で必要な鉄片を入手したら、2番目の方法を実装しようとしますが、最初の方法には問題はありません。USBフラッシュドライブを挿入、縫製、開始、スティックし、BIOSセットアップに移動し、LCtrl + LAlt + F12を押します- 出来上がり、青と緑の正方形が表示され、すべてが機能します。結果は次のようになります。

これは成功です、紳士。

おわりに

ドライバーが作成され、コードがGitHubに投稿され、OptionROMでアイデアを確認するために残り、トピックは閉じられていると言えます。

ここで何が起こっているのかまだ理解できない場合は、コードにバグを見つけましたか、または記事、著者、UEFIの極悪さ、またはレガシーBIOSでどれだけ良かったのかを議論したいだけです。コメントを歓迎します。

読者の皆さんの注意、良いDXEドライバーに感謝します。