Windows 8/10のJobオブジェクト

**Windows内部解析サービス**
豊田孝の「IT談話館」	Windowsメモリダンプ解析を依頼する	WinDbgとシステム分析	Tweet

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

Windows 8/10のJobオブジェクト

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

　現在、セキュリティー問題を無視することはできません。Microsoft社側の負担だけではなく、同社製品の利用者側の負担も増しています。困ったことではありますが、当面避けられません。セキュリティーの視点から「Windows10ソフトウェアセンサー」を見た場合、本「IT談話館」の確認範囲では、「カーネル層保護ロジック」に加え、次のような保護メカニズム階層が考案・実装されています。下記リンクはすべて本館記事を指しています。

Silo/Server Silo
Job
Session
Protected Process
Mandatory Integrity Control(MIC)
Windows API(+CPU)
CPU
　本稿では、「Windows 8/10とJobオブジェクト(基礎)」前編に続き、Windows 8出荷タイミングで設計変更されたJobオブジェクトを取り上げます。前編ではJobオブジェクトを次のように整理しました。

Jobオブジェクトは、複数のプロセスを収容し、その動作を制御するWindowsメカニズムである。
Jobオブジェクトは、Windows 8にて再設計された主要なカーネルオブジェクトである。
　本稿では、Windows 10環境で採取された新旧2種類の「Active Memory Dump」を本館の独自解析コードで解析し、Google社のChromeにおけるJobオブジェクトの実装過程を考察します。なお、独自解析コードの開発知識の習得には、「時間と予算」の投資が必要です。

　まずは、次のメモリダンプを解析してみます。
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
　このメモリダンプは、2018年5月11日に採取されています。このダンプを解析してみます。
0xffffd30645650080	chrome.exe
0xffffd306474da580	chrome.exe
0xffffd306475e0080	chrome.exe
0xffffd306475f3080	eJob->0xffffd306478a3060	ProcLimit->1	TotalProcs->0001	ActiveProcs->1	InactiveProcs->0	chrome.exe
	+01: 0xffffd306475f3080	eJob->0xffffd306478a3060	ActiveThread->012	chrome.exe
0xffffd30647005080	eJob->0xffffd306474d3060	ProcLimit->1	TotalProcs->0001	ActiveProcs->1	InactiveProcs->0	chrome.exe
	+01: 0xffffd30647005080	eJob->0xffffd306474d3060	ActiveThread->016	chrome.exe
　この結果を見ると、Rendererと呼ばれる2つのプロセス「0xffffd306475f3080」と「0xffffd30647005080」がJobオブジェクトの制御下で動作していることが分かります。これらのプロセスは、次のようにControllerと呼ばれるプロセス「0xffffd30645650080」によって生成され、Sandbox化されています。
1: kd> !process 0xffffd306475f3080 0
PROCESS ffffd306475f3080
    SessionId: 1  Cid: 0e2c    Peb: de77d53000  ParentCid: 186c
    DirBase: acf00000  ObjectTable: ffff91043a9f0300  HandleCount: 421.
    Image: chrome.exe

1: kd> !process 0xffffd30647005080 0
PROCESS ffffd30647005080
    SessionId: 1  Cid: 1f08    Peb: 55f34a000  ParentCid: 186c
    DirBase: 115f00000  ObjectTable: ffff9104356f9700  HandleCount: 350.
    Image: chrome.exe

1: kd> !process 186c 0
Searching for Process with Cid == 186c
PROCESS ffffd30645650080
    SessionId: 1  Cid: 186c    Peb: 55ae4ec000  ParentCid: 09a0
    DirBase: 93200000  ObjectTable: ffff91043ae2f780  HandleCount: 1177.
    Image: chrome.exe
　Sandbox化プロセス以外の「0xffffd30645650080」をはじめとするプロセスはJobオブジェクトの制御下に入っていません。なぜ？という疑問が沸きますが、次の比較的新しいメモリダンプの解析結果を見てみます。
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 = 0xfffff804`59a00000 PsLoadedModuleList = 0xfffff804`59e480b0
Debug session time: Sun Nov  3 09:56:47.110 2019 (UTC + 9:00)
System Uptime: 0 days 1:42:54.949
　このダンプは、2019年11月3日に採取されています。先ほどと同じ解析コードを実行し、情報を収集します。
0xffffc48924b9a080	eJob->0xffffc48927174080	ProcLimit->0	TotalProcs->0025	ActiveProcs->6	InactiveProcs->0	chrome.exe
	+01: 0xffffc48924b9a080	eJob->0xffffc48927174080	ActiveThread->030	chrome.exe
	+02: 0xffffc489267ee080	eJob->0xffffc48927174080	ActiveThread->008	chrome.exe
	+03: 0xffffc48924bf5080	eJob->0xffffc48927174080	ActiveThread->003	chrome.exe
	+04: 0xffffc489264e1080	eJob->0xffffc48927174080	ActiveThread->000	chrome.exe
	+05: 0xffffc48920b72080	eJob->0xffffc48927174080	ActiveThread->000	chrome.exe
0xffffc489267ee080	eJob->0xffffc48927174080	ProcLimit->0	TotalProcs->0025	ActiveProcs->6	InactiveProcs->0	chrome.exe
	+01: 0xffffc48924b9a080	eJob->0xffffc48927174080	ActiveThread->030	chrome.exe
	+02: 0xffffc489267ee080	eJob->0xffffc48927174080	ActiveThread->008	chrome.exe
	+03: 0xffffc48924bf5080	eJob->0xffffc48927174080	ActiveThread->003	chrome.exe
	+04: 0xffffc489264e1080	eJob->0xffffc48927174080	ActiveThread->000	chrome.exe
	+05: 0xffffc48920b72080	eJob->0xffffc48927174080	ActiveThread->000	chrome.exe
0xffffc48924bf5080	eJob->0xffffc48927174080	ProcLimit->0	TotalProcs->0025	ActiveProcs->6	InactiveProcs->0	chrome.exe
	+01: 0xffffc48924b9a080	eJob->0xffffc48927174080	ActiveThread->030	chrome.exe
	+02: 0xffffc489267ee080	eJob->0xffffc48927174080	ActiveThread->008	chrome.exe
	+03: 0xffffc48924bf5080	eJob->0xffffc48927174080	ActiveThread->003	chrome.exe
	+04: 0xffffc489264e1080	eJob->0xffffc48927174080	ActiveThread->000	chrome.exe
	+05: 0xffffc48920b72080	eJob->0xffffc48927174080	ActiveThread->000	chrome.exe
0xffffc48925830080	eJob->0xffffc48926db2080	ProcLimit->1	TotalProcs->0001	ActiveProcs->1	InactiveProcs->0	chrome.exe
	+01: 0xffffc48925830080	eJob->0xffffc48926db2080	ActiveThread->012	chrome.exe
0xffffc48925cce080	eJob->0xffffc48926db0080	ProcLimit->0	TotalProcs->0001	ActiveProcs->1	InactiveProcs->0	chrome.exe
	+01: 0xffffc48925cce080	eJob->0xffffc48926db0080	ActiveThread->015	chrome.exe
0xffffc48926deb080	eJob->0xffffc489265ec080	ProcLimit->1	TotalProcs->0001	ActiveProcs->1	InactiveProcs->0	chrome.exe
	+01: 0xffffc48926deb080	eJob->0xffffc489265ec080	ActiveThread->012	chrome.exe
　この情報を見ると、Google社のChromeチームはJobオブジェクトの適応範囲を劇的に変更しています。つまり、Rendererプロセスだけではなく、Controllerプロセス「0xffffc48924b9a080」をはじめとする他のプロセスもJobオブジェクトの制御下に置いています。ちなみに、すべてのJobオブジェクトのFlagは次のように設定され、Sandbox化が進められていることが分かります。
+001: 0xffffc48924b9a080	EJob->0xffffc48927174080	Flags->01800000	LFlags->0x800	Flags2->0x0	TotalProc->25	ActiveProc->0006	chrome.exe
+002: 0xffffc489267ee080	EJob->0xffffc48927174080	Flags->01800000	LFlags->0x800	Flags2->0x0	TotalProc->25	ActiveProc->0006	chrome.exe
+003: 0xffffc48924bf5080	EJob->0xffffc48927174080	Flags->01800000	LFlags->0x800	Flags2->0x0	TotalProc->25	ActiveProc->0006	chrome.exe
+004: 0xffffc48925830080	EJob->0xffffc48926db2080	Flags->01800010	LFlags->0x2108	Flags2->0x0	TotalProc->1	ActiveProc->0001	chrome.exe
+005: 0xffffc48925cce080	EJob->0xffffc48926db0080	Flags->01800010	LFlags->0x2000	Flags2->0x0	TotalProc->1	ActiveProc->0001	chrome.exe
+006: 0xffffc48926deb080	EJob->0xffffc489265ec080	Flags->01800010	LFlags->0x2508	Flags2->0x0	TotalProc->1	ActiveProc->0001	chrome.exe
　この情報も本館の独自解析コードで取得しています。個々のフラグをビットレベルで解析すると、これら複数のChromeプロセスの様々な性質や設計変更内容が手に取るように分かります。時には、担当開発者たちの思考回路をはじめとする、きわめて興味深い情報さえ取得できます。

　以上、Google社のChromeチームのJobオブジェクトの応用過程を解析してみました。Chromeチームは人材が豊富でブラウザ分野で圧倒的な地位を示しているといわれていますが、Windows 8で大幅に仕様変更されたJobオブジェクトの実践的な応用にはそれなりの研究時間が必要であったことが推察されます。なお、上記情報をよく吟味してみると、いくつかの不可解なデータも散見されます。たとえば、実行中スレッドを1個も持たないChromeプロセスの姿などが検出されています。セキュリティー上は好ましいことではないでしょうが、本稿ではその方面の解析紹介は割愛します。

　なお、JobオブジェクトはWindows 10ではSiloやServer Siloと不可分の関係を持つようになりました。この方面の情報は本館の「この記事」で提供しています。

ビジネスメニュー

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