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



　本「IT談話館」一般公開記事は、10年以上の実務経験を持つ上級Windowsエンジニアを想定しています。
　本館は、Windowsカーネル深層を解析し、クラッシュ原因をはじめとするシステム内の「異様な動き」を検出・分析する
超高度な技術と実績を保有しています。


WinDbg、CPU、Windowsビルド番号


　本「IT談話館」の「一般公開記事」は、「Active Memory Dump とカーネルメモリダンプ」の解析結果を基に起草されています。「本館」主筆の「豊田孝」はDKOM(Direct Kernel Object Manipulation)ベースの解析手法の第一人者であり、Windowsカーネル空間の解析分野では世界の先頭を走っています。

　現在、セキュリティー問題を無視することはできません。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」が追加され、システム状態を確認できるようになっており、より高精度な解析コードの開発を可能としています。解析コードの開発知識の習得には、「時間と予算の投資」が必要です。


「Windowsメモリダンプ解析サービス」のご案内
Windowsメモリダンプ解析技術

Copyright©豊田孝 2004- 2024
本日は2024-12-31です。