ネットワークケーブルを用いたカーネルデバッグ接続の設定手順

こんにちは、K里です。   今回はネットワークケーブルを用いたカーネルデバッグ接続の設定手順についてお話したいと思います。   これまでのカーネルデバッグ接続におけるインターフェースは RS-232C、IEEE1394、USB が使用されてきましたが、Windows 8 から新たにネットワークケーブルを使用したカーネルデバッグ接続が可能となりました。他のインターフェースを使用した接続状態と比較すると、ネットワークケーブルを使用した場合、ホストPC とターゲットPC がローカルネットワーク上に存在すればよいため、設置場所が制限されない(ホスト PC とターゲット PC を隣同士で並べる必要がなくなる) ことや、ホスト PC のデバッグポート数に依存することなく多くのターゲット PC を接続状態にできることが主なメリットになると思われます。   ネットワークデバッグ接続を行うための要件として、Windbg 等のデバッガを起動しデバッグを行うホスト PC は、Windows XP 以降の OS が対象となり、デバッグポートとするネットワークアダプターについては特に制限はありません。対してデバッグ対象となるターゲットPC は、Windows 8 と Windows Server 2012 のみが対象となり、また以下のネットワークアダプターについてデバッグ接続をサポートしています。   Title: Supported Ethernet NICs for Network Kernel Debugging in Windows 8 URL: http://msdn.microsoft.com/ja-JP/library/windows/hardware/hh830880   上記要件を満たすホスト PC とターゲット PC…


フィルターマネージャー

皆さん、こんにちは。A寿です。   突然ですが、皆さんは、カクテルコンペティションに行ったことはありますか?・・・このお話にご興味のある方は本文の最後の【閑話休題】までどうぞ。   さて、今回は、ファイルシステムのフィルターマネージャーの概念や基本的な用語をご紹介したいと思います。フィルターマネージャーのお話が出てくる経緯としてレガシーフィルターやミニフィルター等の用語については、以前の cleng さんの記事をご参照いただければと思います。   まず、もっとも単純な概念図として、以下の図をご覧ください。     この図を使って、I/Oの流れを説明します。ユーザーモードからのI/O要求が、I/Oマネージャーによってファイルシステムに送られます。I/O はファイルシステムドライバースタックの上位ドライバーから順に処理されていきます。この時、フィルターマネージャーは、ファイルシステムドライバーの上方に位置しており、ここでファイルシステムドライバーへのI/O要求を横取りします。フィルターマネージャーは、登録されたミニフィルターに対し、「高度 (Altitude) 」が高いミニフィルターから順に、I/O要求を渡していきます。渡されたI/O要求に対応するコールバックをミニフィルターが持っていれば、それが呼び出されます。そして、I/Oはファイルシステムドライバーや、その下のボリュームのストレージドライバーのスタックへと送られていきます。   ちなみに、ここで、デバイススタックの話をしておきますと、フィルターマネージャーは、レガシーフィルターであるため、そのデバイスオブジェクトに対して !devstack を実行すれば、ファイルシステムドライバーのデバイスオブジェクトの上に fltmgr として表示されます。これは、通常のデバイススタックにアタッチするデバイスオブジェクトと同様に、デバイススタック全体が削除・追加されないと、レガシーフィルターは取り外したり挿入したりできないことを意味します。それに対して、ミニフィルターの場合は、予めデバイススタックとして積まれたフィルターマネージャーに対して登録したり解除したりできるので、動的に挿入したり取り外したり(ロードしたりアンロードしたり)できます。   さて、ここで、「高度 (階層、Altitude) 」について補足します。高度は、全てのミニフィルターが一意の値を持つ、浮動小数です。この値が高いと、よりデバイススタックとして上位であることを表します。そして、浮動小数であることにより、弊社やサードパーティ様が新しいミニフィルターを開発しても、任意の高度を与えることができます。また、ミニフィルターの種類によって高度の範囲が決まっています。例えば、上図の通り、アンチウィルスフィルター (FSFilter Anti-Virus) は、レプリケーションフィルター (FSFilter Replication) よりも高い高度を持っています。これは、別のサーバーにI/Oをレプリケート(複製)されるよりも前に、アンチウィルスフィルターでスキャンする必要があるためです。   なお、高度は、弊社が発行・管理しております。下記ドキュメントの「ファイルシステム ミニフィルターの高度割り当て」や「ミニフィルターの高度割り当ての要求 (英語) 」のリンクを見ていただければ、どこの会社がどの種類のどの高度を使っているかですとか、弊社への申請方法がわかります。     ファイル システム フィルター ドライバー   http://msdn.microsoft.com/ja-jp/library/windows/hardware/gg462968.aspx   ミニフィルターを開発されるお客様で、もし弊社のサンプルの高度をそのまま使っているお客様がいらっしゃいましたら、他社様のミニフィルターや、自社でのテスト用サンプルミニフィルターなどとの衝突を起こさないように、変更していただくことをおすすめいたします。   続いて、フィルターマネージャーにおいて基本的な 3 つの用語、フレーム、ボリューム、インスタンス、について、以下の図を用いて説明します。図のデバイススタックについて簡単に説明しますと、ボリューム \Device\HarddiskVolume2 の上に、ミニフィルターCとミニフィルターBが登録されたフィルターマネージャー (fltmgr.sys) 、(fltmgr.sys 以外の何らかの)レガシーフィルター、ミニフィルターAが登録されたフィルターマネージャー、というスタックになっています。(便宜上、ボリュームとフィルターマネージャーの間の、ファイルシステムやストレージドライバーのスタックは省略しています。)ボリューム…


WDK 8 のドライバー開発の新機能

ひさかたぶりです。まさかたです。   先日、ついに Windows 8 が発売されました。巷では、各メーカー様から発売された様々な Windows 8 対応のデバイスが並んでおり、どれを購入しようか目移りしてしまいますね。 そして、Windows Driver Kit 8 については、先日のなおきお~さんの記事でも書かれていましたように、既にリリースされておりますが、皆様、使いこなしていらっしゃいますでしょうか? ご存知の通り、WDK 8 は Visual Studio 2012 に統合され、Intellisense などの従来の Visual Studio の便利な機能が使えるようになった他に、WDK 8 のドライバー開発に特化した便利な機能がいくつか追加されております。 WDK 8 で何が新しくなったのかをお知りになりたい場合は、まずは以下のリンクから見ていただくのがよろしいかと思います。   Windows 8 の新機能 http://msdn.microsoft.com/ja-jp/library/windows/hardware/hh451220(v=vs.85).aspx   そんな中で、今回は、私が使う中でこれは便利だなと思ったものとして、ビルドしたドライバーの動作確認をする際に役立つ機能を、簡単にご紹介させていただきたいと思います。 それは、Visual Studio が自動的に、① ビルドしたドライバーパッケージの INF からカタログ ファイルを生成し、② カタログ ファイルにテスト署名をした上で、③ テスト用の PC にインストールしてくれるという機能です。今までこれらの手順は、ドライバーをビルドし直す度に、手動で行う必要があったかと思いますが、WDK 8 では、これらの作業は全て自動的に行うことができるようになりました。これなら、ドライバーを手元で動作確認する場合にもとても便利です。   というわけで、さっそく具体的なやり方を順に追って見てみましょう。今回も、例によって Toaster サンプルを例に取って見てみたいと思います。サンプルコードの取得方法が分からないという方は、先日のなおきお~さんの記事をご参照ください。…


PCI デバイスコンフィグレーション空間へのアクセス方法

皆さん、こんにちは。A寿です。   突然ですが、皆さんは、イルカに触ったことはありますか?・・・このお話にご興味のある方は本文の最後の【閑話休題】までどうぞ。   さて、今回は、 PCI デバイスコンフィグレーション空間へのアクセス方法についてご紹介したいと思います。   PCI デバイスコンフィグレーション空間への Read/Write を行うには、以下の2種類の方法のいずれかを利用します。     (1) BUS_INTERFACE_STANDARD バス インターフェースの GetBusData メソッド(読み取り)/ SetBusData メソッド(書き込み)   (2) IRP_MJ_PNP の IRP_MN_READ_CONFIG(読み取り)/ IRP_MN_WRITE_CONFIG(書き込み)   このどちらの方法も下記の公開情報にサンプルも含めて方法が載っておりますので、ご参照いただければ幸いです。     PCI デバイスの構成情報と場所情報の取得方法   http://support.microsoft.com/kb/253232/ja   上記ドキュメントにも記載がありますが、 HalGetBusData などの HAL API は、廃止されておりますので、ご利用されないことを推奨いたします。 このことは、以下のドキュメントにも記載があります。     HalGetBusData   http://msdn.microsoft.com/en-us/library/ff546599(VS.85).aspx       The HalGetBusData routine is…


Windows Driver Kit (WDK) 8.0 がリリースされました

ご無沙汰しております。なおきお~です。 皆様、暑い日が続いいるので熱中症などにお気を付けください。 さて、8月は、ドライバ開発者の方々が熱くなるニュースとして新しい WDK 8.0 (Windows Driver Kit) がリリースされました。 そして今回のリリースでは、Visual Studio 2012 に統合されるという大幅な変更が行われています。 Windows XP の WDK 以降は、単体で開発可能なイメージであったため、少々 戸惑う方がいるかもしれませんのでサンプル コードを確認するまでの手順を紹介したいと思います。   まず、以下のサイトから WDK 8.0 をダウンロードするのですが、このURL のシステム要件に記載されている通り、予め Visual Studio Professional 2012 を入手いただきインストールをしておく必要があります。   Windows Driver Kit (WDK) 8 http://msdn.microsoft.com/ja-jp/library/windows/hardware/hh852362.aspx   要件を満たして、セットアップすると WDK 8.0 は、Program File (既定では、C:\Program Files\Windows Kits\8.0\) にインストールします。 しかし、既定では、サンプル コードはインストールしないため、以下の手順でテンプレートを使用して、ひな形を作成する必要があります。   ①     [ファイル] から[新規作成] の[プロジェクト]…


ACPI ドライバーインターフェース

こんにちは、K里です。 今回は ACPI ドライバーインターフェースについてお話したいと思います。ACPI (Advanced Configuration and Power Interface) は、OS 主導の電源管理制御を実現するために既定された OS – BIOS 間のインターフェース仕様になります。ACPI の電源制御は、OS がいつ何をやるかを決めるのに対し、ACPI BIOS は各種 ACPI テーブル (RSDP に始まり FACP、DSDT など)、AML などをサポートし、具体的な制御方法を提供します。 カーネルドライバーから ACPI BIOS に関する情報の取得あるいは制御を行う手法として、ACPI Control Method を定義しており、AML (ACPI Machine Language) で記述されます。カーネルドライバーは、ACPI Control Method が読み込まれるデバイスオブジェクト (PDO) の名前空間内で以下の IOCTL を使用してこれらの Method を実行することが可能です。これには、Child Object で定義される Control Method も含まれます。 l  IOCTL_ACPI_EVAL_METHOD l  IOCTL_ACPI_ASYNC_EVAL_METHOD…


Printing – NT EMF データの留意点

ご無沙汰しております。なおきお~です。梅雨時期は、湿気が多く過ごしづらい日も多いかと思いますが、皆さん、如何お過ごしでしょうか? さて、今回は、A尾さんの記事のプリンティングについて、ちょっと補足をしたいと思います。   A尾さんの「印刷時のスプーリングについて」では、NT EMF データや RAW データといったスプール データについて、解説があったかと思います。 この記事にあるとおり、データの種別に関わらず、プリント プロセッサのみとなります。   RAW データは、プリンタ デバイスに依存したデータ種別であるため、プリンタ ドライバ開発される方々が熟知されていると思いますし、ReadPrinter() でスプール データを読み込み、WritePrinter() で、プリント モニタ(ランゲージ モニタやポート モニタ) に通知するので、比較的 シンプルな構造になると思います。 Windows OS 標準のプリント プロセッサでも、RAW で始まるスプール データは、同じ概念で実装されています。     対して、NT EMF データは、バージョンがたくさんありますが、全て GdiStartDocEMF() といった GDI Functions for Print Processors にある API を使用してハンドリングします。 この API のリストを見ていただくと気づかれる方もいらっしゃると思いますが、ページ単位でしか NT EMF データをハンドリングすることができません。 つまり、ページの中に新たにレンダリング データを追加することはできませんし、削除することもできません。 また、NT EMF…


デバイス オブジェクトのセキュリティ その2

  久方ぶりです。まさかたです。 前回の記事で、デバイス オブジェクトのセキュリティという観点から、Security Descriptorの記述についてお話ししました。その時に、これ以外にも、デバイスオブジェクトをセキュリティで保護するためにドライバー側でできることとして、デバイスの名前空間の保護や、デバイスオープンの排他制御といったものがあることに触れましたが、今回はその名前空間の保護と排他制御の 2 点について簡単にお話ししたいと思います。 1. デバイスの名前空間の保護 デバイスの名前空間とは、例えば DeviceName という名前のデバイス オブジェクトがあった場合、CreateFile() で指定できるファイル パスの先頭に、”\Device\DeviceName” を持つパス全体を指します。 CreateFile() で名前付きのデバイス オブジェクトをオープンする場合、単純な “\Device\DeviceName” の他に、実は名前空間上にあるディレクトリやファイルを指すパスも指定することができ、この場合も、デバイスオブジェクトをオープンすることができてしまいます。 表 ファイルパスによるオブジェクトとセキュリティチェックの主体の違い ファイルパス (例) オブジェクト 既定のセキュリティチェックの主体 (1) \Device\DeviceName DeviceName のデバイス オブジェクト I/O マネージャー (2) \Device\DeviceName\ DeviceName の最上位 ディレクトリ オブジェクト ドライバー (3) \Device\DeviceName\File DeviceName 名前空間上の ファイル オブジェクト ドライバー デバイスの名前空間をサポートするドライバーでは、(2) や (3) のようなディレクトリやファイルのオープンにも対応していて、個々のオブジェクトに応じた何らかの処理をすることになります。ただ、多くドライバーではそのような処理は行わず、名前空間をサポートしない側に入るかと思います。そのため、ほとんどのドライバーで関心があるのは、デバイス オブジェクトそのものを指す “\Device\DeviceName” だけだと思います。…


デバイス オブジェクトのセキュリティ

久方ぶりです。まさかたです。 今回は、デバイスにアクセスする際のセキュリティに深く関係のある、デバイスオブジェクトのセキュリティについてお話ししたいと思います。 まず、アプリケーションが、デバイスに対して I/O のリクエストをする場合、入り口として CreateFile() でデバイスハンドルを取得し、このハンドルを通して ReadFile() や WriteFile(), DeviceIoControl() などでリクエストを行います。このようなデバイスハンドルの取得や、I/O のリクエストの実行は、セキュリティの観点から、どんなユーザーからでも実行できては困りますので、一定の制限を設ける必要があります。 以前、A 寿さんの記事の中で、I/O コントロールの発行に必要なデバイス ハンドルのアクセス権限についてのお話がありましたが、それもこのようなセキュリティを保つための仕組みの一つだと思います。 通常は、デバイスへのアクセスは管理者権限を必要とする場合が多いのですが、お客様によっては、管理者権限以外でもアクセスできるようにしたいなど、このセキュリティをコントロールする方法についてお問い合わせいただくことがあります。 そこで、これに関連するお話として、ユーザーによって、CreateFile() の実行可否や、設定可能なアクセス権限などをコントロールすることができる、デバイスオブジェクトのセキュリティについてお話をしたいと思います。 セキュリティのチェックを行うためには、どのユーザーが、どのデバイスオブジェクトに対して、どんなアクセス権限を持っているのかといったことを識別し、判断する必要がありますが、そのための情報として、アクセストークン、や Security Descriptorと呼ばれるものがあります。それぞれの詳細は、こちらのページを見ていただければと思いますが、大まかには以下のようになると思います。 Access Token – アクセスする側 (アプリケーション等) が持つ情報 プロセスが持つ Security Context を表すオブジェクト。Security Context は、プロセスを実行しているユーザー アカウントと、それに付与される権限 (Read/Write/Execute など) の組み合わせで、Access Token には、ユーザーアカウントを識別する SID と、システムから許可された権限のリストが記述されている。SID は、ユーザー、グループ、ログオンセッションを識別するためのセキュリティ上の ID。 Security Descriptor – アクセスされる側 (デバイス オブジェクト等) が持つ情報 オブジェクトが持つセキュリティに関する記述子。Security Descriptorは、オブジェクトの所有者・グループの SID、ACL…


WOW64 デバッギング

ご無沙汰しております。なおきお~です。 少しずつ暖かくなり、過ごしやすい日が増えてきました。皆さん、如何お過ごしでしょうか? 暖かくなってきたとはいえ、季節の変わり目は、体調を崩しやすいので、お気を付けください。   春は、入学、入社など、新たな一歩を踏み出す季節でもあると思います。 新たな一歩というほど大げさなもの、新しいものではありませんが、今回は、WOW64 のデバッグの Tips を紹介したいと思います。   Windows 7 や Windows Server 2008 R2 のリリース以降、64 ビット Windows OS も浸透してきているように感じます。 ただ、32 ビットのアプリケーションは、まだまだ 多くあり、ユーザ モードのプロセスも含めて、完全に 64 ビットに移行できるのは、まだまだ 先のことになってしまうように思えます。 特に Windows OS に実装されている WOW64 は、完ぺきではないまでも、高い互換性を保持しているように思えます。 ただ、いざデバックをするとなると少々面倒になります。例えば、32 ビット プロセスに対して、64 ビットのメモリ ダンプを取得して、スタックが見られなかったり、カーネル モードのデバッギングの際で、32 ビット プロセスのコンテキストに合わせても、32 ビットのスタックが見られなかったりするなどです。   そんな時に、ちょっと便利な方法をユーザ モード デバッギングとカーネル モード デバッギングで、紹介します。 まず、ユーザ モード デバッギングでは、wow64exts.dll というデバッグ エクステンションを使用します。…