オンサイトセミナー
豊田孝の「IT談話館」 Windowsメモリダンプ解析を依頼する WinDbgとシステム分析




 本「IT談話館」一般公開記事は、書籍 「インサイド Microsoft Windows」 程度の基礎知識をお持ちの方を想定しています。



WinDbg、CPU、Windowsビルド番号


 SaaS時代におけるWindows 10の頻繁なる内部更新は、性能向上と互換性維持などに加え、ML/DL/AI時代への対応と位置付けられています。簡単に表現すれば、Windows 10はCloudサービスと連携しながらBig Dataを収集・蓄積する「ソフトウェアセンサー」、という役割を担っています。本「IT談話館」は、そのソフトウェアセンサーのユーザー空間とカーネル空間を独自の解析コードで詳しく解析する技術を保有し、「Windowsメモリダンプ解析サービス」を提供しています。「本館サービス」をご利用の際には、所属チーム内でご協議の上、「ご連絡」頂けると幸いです。

 「メモリダンプ」を解析すると、採取時点におけるシステム内部の「異様な動き」を検出・解析することができます。「異様な動き」の中には、システムパフォーマンスの低下、既存アプリの動作異常、システムクラッシュ原因、あるいは、セキュリティー脅威なども含まれます。

 本「IT談話館」の「一般公開記事」は、「Active Memory Dump とカーネルメモリダンプ」の解析結果を基に起草され、0dayをはじめとする脆弱性研究者、組み込みシステム開発者、デジタルフォレンジック技術者、および、EDR製品のビジネス関係者に広く読まれています。公開はあくまでもビジネスに支障の出ない範囲に限定されていますが、それでも、インターネット空間上で容易に入手できるレベルの記事ではありません。

 現在、セキュリティー問題を無視することはできません。Microsoft社の技術者側の作業負担だけではなく、同社製品の利用者側の作業負担も増しています。困ったことではありますが、当面避けられません。セキュリティーの視点からWindows10ソフトウェアセンサーを見た場合、本「IT談話館」の確認範囲では、「カーネル層保護ロジック」に加え、次のような保護メカニズム階層が考案・実装されています。下記リンクはすべて本館記事を指しています。
  1. Silo/Server Silo
  2. Job
  3. Session
  4. Protected Process
  5. Mandatory Integrity Control(MIC)
  6. Windows API(+CPU)
  7. CPU
 本稿は本館のこの「WinDbgとCPU」記事の続編になります。CPU問題と各種対策に関しては「Meltdown and Spectre」を参照するとよいでしょう。各ベンダーや研究者の作業視点の変遷と対策が整理されています。本稿では、CPU問題とWindowsビルド番号の関係を検討します。結論を先取りすると、ビルド番号が同一であっても同一のWindowsカーネルとは限りません。

 次の情報は2018年5月11日に採取された「Activeメモリダンプ」から取り出されています。
1: kd> vertarget
Windows 10 Kernel Version 17134 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 17134.1.amd64fre.rs4_release.180410-1804
Machine Name:
Kernel base = 0xfffff801`63699000 PsLoadedModuleList = 0xfffff801`63a561d0
Debug session time: Fri May 11 07:58:31.309 2018 (UTC + 9:00)
System Uptime: 0 days 0:32:48.173

1: kd> dt nt!_kprcb bp*
   +0x0f8 BpbState : Uint2B
   +0x0f8 BpbIbrsPresent : Pos 0, 1 Bit
   +0x0f8 BpbStibpPresent : Pos 1, 1 Bit
   +0x0f8 BpbSmepPresent : Pos 2, 1 Bit
   +0x0f8 BpbSimulateSpecCtrl : Pos 3, 1 Bit
   +0x0f8 BpbSimulateIbpb : Pos 4, 1 Bit
   +0x0f8 BpbIbpbPresent : Pos 5, 1 Bit
   +0x0f8 BpbCpuIdle : Pos 6, 1 Bit
   +0x0f8 BpbClearSpecCtrlOnIdle : Pos 7, 1 Bit
   +0x0f8 BpbHTDisabled : Pos 8, 1 Bit
   +0x0f8 BpbUserToUserOnly : Pos 9, 1 Bit
   +0x0f8 BpbReserved : Pos 10, 6 Bits
   +0x0fa BpbSpecCtrlValue : UChar
   +0x0fb BpbCtxSwapSetValue : UChar
   +0x0fc BpbPad : [4] UChar
 CPUに関する情報はインターネット上にあふれていることもあり、本稿ではこの情報内の個々のビットの機能説明は割愛します(「参考」)。この情報を素直に解釈すると、米Microsoft社の対策チームは当時の「分岐予測」の状態把握「BpbState」にまず努め、必要最小の対策を取ろうとしている印象を受けます。同対策チームはCPU問題に関する情報収集と分析を開始したばかりの段階といったところでしょう。情報が整理されていません。

 次に紹介する内部情報は2019年3月10日に採取された「Activeメモリダンプ」から取り出しています。ビルド番号は「17134.1」であり、上の情報と同じです。
1: kd> vertarget
Windows 10 Kernel Version 17134 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 17134.1.amd64fre.rs4_release.180410-1804
Machine Name:
Kernel base = 0xfffff802`9ea1b000 PsLoadedModuleList = 0xfffff802`9edc9150
Debug session time: Sun Mar 10 06:57:53.854 2019 (UTC + 9:00)
System Uptime: 2 days 22:17:18.721

1: kd> dt nt!_kprcb bp*
   +0x0f8 BpbState : UChar
   +0x0f8 BpbCpuIdle : Pos 0, 1 Bit
   +0x0f8 BpbFlushRsbOnTrap : Pos 1, 1 Bit
   +0x0f8 BpbIbpbOnReturn : Pos 2, 1 Bit
   +0x0f8 BpbIbpbOnTrap : Pos 3, 1 Bit
   +0x0f8 BpbStateReserved : Pos 4, 4 Bits
   +0x0f9 BpbFeatures : UChar
   +0x0f9 BpbClearOnIdle : Pos 0, 1 Bit
   +0x0f9 BpbEnabled : Pos 1, 1 Bit
   +0x0f9 BpbSmep : Pos 2, 1 Bit
   +0x0f9 BpbFeaturesReserved : Pos 3, 5 Bits
   +0x0fa BpbCurrentSpecCtrl : UChar
   +0x0fb BpbKernelSpecCtrl : UChar
   +0x0fc BpbNmiSpecCtrl : UChar
   +0x0fd BpbUserSpecCtrl : UChar
   +0x0fe BpbPad : [2] UChar
 前の情報と比較すると、CPU問題に関する情報収集と分析がかなり進み、状態把握(BpbState)と対策(BpbFeatures)に分離・整理されています。米Microsoft社の対策チームは、状態把握に加え、問題解決に向けた視点をいくつか確保しつつある様子が垣間見えます。たとえば、「BpbClearOnIdle」は制御がIdleプロセスに移った際には分岐予測を禁止する対策が取られたことを明確に打ち出されています。本館の経験では、この状態把握と対策が分離されたことにより、解析コードの開発がより容易になります。Idleプロセスに関しては本館の「Idleプロセスと名無しのプロセス」記事が参考になるかもしれません。

 これまでの情報からは、ビルド番号が同じWindowsであっても、カーネル内部は劇的に異なっていることがはっきり分かります。最後に、比較的新しいビルド番号「18362.1」を持つWindowsのカーネル内部を確認しておきます。
0: kd> vertarget
Windows 10 Kernel Version 18362 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 18362.1.amd64fre.19h1_release.190318-1202
Machine Name:
Kernel base = 0xfffff802`6e400000 PsLoadedModuleList = 0xfffff802`6e848130
Debug session time: Thu Dec 26 15:26:37.338 2019 (UTC + 9:00)
System Uptime: 3 days 5:48:09.082

0: kd> dt nt!_kprcb bp*
nt!_KPRCB
   +0x0f8 BpbState : UChar
   +0x0f8 BpbCpuIdle : Pos 0, 1 Bit
   +0x0f8 BpbFlushRsbOnTrap : Pos 1, 1 Bit
   +0x0f8 BpbIbpbOnReturn : Pos 2, 1 Bit
   +0x0f8 BpbIbpbOnTrap : Pos 3, 1 Bit
   +0x0f8 BpbIbpbOnRetpolineExit : Pos 4, 1 Bit
   +0x0f8 BpbStateReserved : Pos 5, 3 Bits
   +0x0f9 BpbFeatures : UChar
   +0x0f9 BpbClearOnIdle : Pos 0, 1 Bit
   +0x0f9 BpbEnabled : Pos 1, 1 Bit
   +0x0f9 BpbSmep : Pos 2, 1 Bit
   +0x0f9 BpbFeaturesReserved : Pos 3, 5 Bits
   +0x0fa BpbCurrentSpecCtrl : UChar
   +0x0fb BpbKernelSpecCtrl : UChar
   +0x0fc BpbNmiSpecCtrl : UChar
   +0x0fd BpbUserSpecCtrl : UChar
   +0x6d0 BpbRetpolineExitSpecCtrl : UChar
   +0x6d1 BpbTrappedRetpolineExitSpecCtrl : UChar
   +0x6d2 BpbTrappedBpbState : UChar
   +0x6d2 BpbTrappedCpuIdle : Pos 0, 1 Bit
   +0x6d2 BpbTrappedFlushRsbOnTrap : Pos 1, 1 Bit
   +0x6d2 BpbTrappedIbpbOnReturn : Pos 2, 1 Bit
   +0x6d2 BpbTrappedIbpbOnTrap : Pos 3, 1 Bit
   +0x6d2 BpbTrappedIbpbOnRetpolineExit : Pos 4, 1 Bit
   +0x6d2 BpbtrappedBpbStateReserved : Pos 5, 3 Bits
   +0x6d3 BpbRetpolineState : UChar
   +0x6d3 BpbRunningNonRetpolineCode : Pos 0, 1 Bit
   +0x6d3 BpbIndirectCallsSafe : Pos 1, 1 Bit
   +0x6d3 BpbRetpolineEnabled : Pos 2, 1 Bit
   +0x6d3 BpbRetpolineStateReserved : Pos 3, 5 Bits
 ご覧のように、把握対象となる状態の中に「BpbRetpolineState」が追加されているのが印象的です。また、「BpbTrappedBpbState」が追加され、システム状態を確認できるようになっており、より高精度な解析コードの開発を可能としています。解析コードの開発知識の習得には、「時間と予算の投資」が必要です。


 本「IT談話館」一般公開記事は、書籍 「インサイド Microsoft Windows」 程度の基礎知識をお持ちの方々を想定しています。
Windowsメモリダンプ解析技術開発室 ビジネスメニュー

Copyright©豊田孝 2004- 2020
本日は2020-09-28です。