Windows Kernel：物件管理、排程與驅動模型

Kernel 不是「一個大程式」

Windows 採用 hybrid kernel 設計。ntoskrnl.exe 內同時包含低階 Kernel 與多個 Executive manager；HAL 隔離部分硬體差異，kernel-mode drivers 則透過 I/O model 參與裝置、檔案系統、網路與其他子系統。

Object Manager：核心資源的共同模型

Process、Thread、File、Section、Event、Mutant、Semaphore、Token 與 Driver 等資源都以 object model 管理。這套模型統一了：

• 命名與 Object Manager namespace。
• Handle table 與 access rights。
• Reference counting 與 lifetime。
• Object type-specific operations。
• Security descriptor 與 access check。

HANDLE（process-local value）
  → HANDLE_TABLE_ENTRY
    → OBJECT_HEADER
      → typed body（EPROCESS、ETHREAD、FILE_OBJECT…）

Handle count 與 pointer count

Object lifetime 不只看 user-mode handle。Handle count 表示開啟的 handle 數量；pointer/reference count 還包含 kernel components 暫時或長期持有的 references。關閉最後一個 handle 後，object 可能仍因 kernel reference 存活；反過來，driver 若漏掉 dereference，便可能形成 resource leak。

Driver 取得 object pointer 時，應透過文件化 routine 執行 type 與 access validation，並對成功取得的 reference 成對釋放。不要把 user handle 強制轉型成 kernel pointer，也不要把 process A 的 handle 直接套到 process B。

Namespace 與路徑

Win32 的 C:\...、\\.\DeviceName 與 kernel namespace 中的 \Device\...、\BaseNamedObjects\... 屬於不同抽象層。Symbolic link 與 per-session namespace 會進一步影響解析結果。遇到「同名但開不到」的問題時，要確認：

1. 呼叫者所在 session。
2. Object type 與完整 native path。
3. Symbolic link 最終指向。
4. Token、integrity level 與 desired access。

常用 WinDbg 命令

Scheduler：真正被排程的是 Thread

Windows 使用 priority-driven、preemptive scheduler。每個 processor 維護與 runnable threads 有關的狀態；thread 的動態 priority、affinity、ideal processor、quantum 與 wait history 都會影響實際執行。

常見 thread state

Priority 高不代表永遠執行。Thread 可能在等待 I/O、鎖、event 或 page fault；高 priority 也可能造成 starvation。分析「程式卡住」時，通常先看所有 thread stacks 與 wait chain，而不是只看 CPU 百分比。

Dispatcher objects 與等待

Event、Mutex/Mutant、Semaphore、Timer、Process 與 Thread 都能參與 dispatcher wait。Synchronization event 喚醒一個 waiter 後自動 reset；notification event 則維持 signaled，直到明確 reset。等待錯誤常見於：

• Lock ordering 不一致造成 deadlock。
• 在持有 spin lock 時執行可能阻塞的操作。
• 忘記處理 timeout、cancel 或 teardown。
• User event 與 kernel reference 的 lifetime 不一致。

IRQL：限制現在能做什麼

IRQL 是 interrupt request priority，不是 thread priority，也不是一般意義的權限等級。提高 IRQL 會屏蔽部分較低優先級事件，因此高 IRQL 程式碼必須短、可預測，而且不能觸發需要等待的工作。

ISR、DPC 與 Work Item

可把延遲工作分成三層：

ISR（DIRQL）
  → 確認中斷、保存最小狀態
    → DPC（DISPATCH_LEVEL）
      → 完成不會阻塞的 deferred work
        → Work item / system thread（PASSIVE_LEVEL）
          → 需要 wait、pageable code 或複雜 I/O 的工作

若 DPC 執行過久，會增加 system-wide latency；若 ISR 過久，影響更嚴重。WPA 的 DPC/ISR analysis 適合定位 audio glitch、input lag 與 driver latency。

I/O Manager 與 IRP

I/O Manager 提供一致模型，讓 caller 不需要了解實體裝置與 driver stack 細節。IRP（I/O Request Packet）保存整個 I/O request 的狀態，而每一層 driver 透過自己的 I/O stack location 讀取參數並決定：處理、轉送、pending 或完成。

一個 IRP 的生命週期

User / kernel caller
  → I/O Manager 建立 IRP
    → top device object dispatch routine
      → filter / function / bus driver 逐層向下
        → device 或 lower stack 完成
      ← completion routines 由下往上執行
  ← caller 收到 status 與 information

關鍵規則包括：

• 每層使用自己的 current／next stack location。
• 回傳 STATUS_PENDING 代表稍後完成，不代表失敗。
• Completion routine 可能在與原 caller 不同的 thread context 執行。
• Cancel、timeout、PnP remove 與 surprise removal 必須納入設計。
• Double completion、漏 completion、錯誤 pending propagation 都可能造成 crash 或 hang。

Device stack：PDO、FDO、Filter

• PDO（Physical Device Object）代表 bus enumerator 發現的裝置。
• FDO（Functional Device Object）由主要功能 driver 建立。
• Filter DO 在 stack 上加入監控或額外功能。

不要用「一個裝置等於一個 driver」理解 Windows I/O。同一 request 往往穿過多個 device objects 與 drivers。

File-system Minifilter

Filter Manager（FltMgr.sys）提供檔案系統 filter 共用機制。Minifilter 只註冊需要處理的 operations；FltMgr 依 altitude 與 instance 順序呼叫 pre-operation callbacks，I/O 完成後再以反向順序呼叫 post-operation callbacks。

CreateFile
  → I/O Manager / FltMgr
    → high-altitude filter PreCreate
      → lower filters PreCreate
        → file system
      ← lower filters PostCreate
    ← high-altitude filter PostCreate

Microsoft 建議新的 file-system filter 優先使用 minifilter model，而不是 legacy filter。即使有 FltMgr，driver 仍要正確處理 callback IRQL、reentrancy、name query、context lifetime 與 teardown。

Kernel Memory：Pool、MDL 與 Ownership

Paged 與 Nonpaged

• Paged pool 可被換出；只能在允許 page fault 的 context 使用。
• Nonpaged pool 保證 resident，適合高 IRQL 或硬體相關路徑。
• NonPagedPoolNx 預設不可執行，能降低資料被當成 code 執行的風險。

Driver allocation 必須有明確 ownership：誰配置、誰釋放、失敗路徑是否釋放、IRP cancel 時是否仍被 callback 引用。Pool tag 是查漏的重要線索。

MDL 不等於 buffer

MDL（Memory Descriptor List）描述一組 physical pages 與 mapping 狀態，本身不是資料 buffer。處理 direct I/O 時，需要分清楚：原 user virtual address、locked pages、system-space mapping 與 mapping lifetime。對 user pointer 的任何信任都可能帶來 TOCTOU、invalid address 或權限問題。

Synchronization 與常見失敗模式

Driver 的困難通常不在 happy path，而是 concurrent I/O、cancel、PnP remove、power transition 與 unload 同時發生時仍能維持 lifetime 正確。

PatchGuard、VBS 與 Kernel Integrity

PatchGuard（Kernel Patch Protection）會保護特定核心結構與程式碼不被未授權修改；VBS/HVCI 則利用 virtualization-based isolation 強化 code integrity 與部分敏感狀態。它們不是單一「禁止 hook」開關，也不能取代 driver 安全設計。

研究 kernel instrumentation 時應使用文件化機制，例如 ETW、object callbacks、process/thread/image notify routines、minifilter、WFP 或 WDK 提供的 frameworks。修改 SSDT、IDT、核心 code 或 undocumented lists 不只版本脆弱，也可能觸發 bugcheck 並破壞系統完整性。

Kernel Debugging：從現象到 root cause

建議環境

• Hyper-V、VMware 或其他可還原 snapshot 的測試 VM。
• 與 target build 相符的 WDK、WinDbg 與 Microsoft symbol server。
• Kernel debugging transport 或完整／核心 memory dump。
• Driver Verifier 只對目標測試 driver 開啟，避免把整台機器變成噪音來源。

Crash dump triage

vertarget              ; OS、build、architecture
!analyze -v            ; 初始分類，不把結果當最終答案
.bugcheck               ; bugcheck code 與 parameters
k / kv                  ; current stack 與參數
!thread                 ; current thread、IRQL、wait
!process 0 0            ; process context
lmvm <driver>           ; driver version、timestamp、symbols
!irp <address>          ; 涉及 I/O 時檢查 IRP stack
!locks                  ; deadlock 或 resource contention

常見 bugcheck 思考方式

!analyze -v 是索引，不是判決。最上方出現某 driver 可能只是受害者；要沿 call stack、object lifetime、pool state 與事件時序證明 root cause。

驗證與可觀測性工具鏈

常見誤區

• IRQL 等於 thread priority：兩者用途不同。
• Nonpaged memory 永遠安全：pointer 仍可能失效，函式仍可能違反 IRQL contract。
• IRP 回傳就結束：pending 與 completion 可能在稍後、不同 context 發生。
• Handle 就是 object pointer：handle 是 process-local table entry。
• Driver unload 只要刪除 device object：還需停止 callback、timer、DPC、work item 與 active I/O。
• Dump 顯示的 blamed module 就是 root cause：memory corruption 常延遲到別處才爆炸。

延伸閱讀

• Microsoft Learn：Kernel-Mode Driver Architecture
• Microsoft Learn：End-User I/O Requests and File Objects
• Microsoft Learn：Filter Manager Concepts
• Microsoft Learn：Processing I/O Operations
• Windows Internals, 7th Edition, Part 2：I/O、storage、file systems、startup 與 management mechanisms

下一篇會從防禦者角度分析 malware execution chain：如何建立 timeline、如何辨識 memory anomaly，以及如何把單一 IOC 提升為可驗證的行為證據。