CORE-16448, PR #2003. Supersedes PR #1997.
This commit supersedes commit 6c5c7809 (r54503).
The original code was checking for the NMI or Double-Fault TSS by
comparing the current stack-traced EIP address with their corresponding
trap handler address ranges. That method was actually buggy because
nothing was ensuring that the trap handlers were in the "expected" order
in the kernel binary (and in memory).
Instead, we now can handle completely generic nested TSSes, instead of
just the NMI or the Double-Fault ones.
The way we proceed is by performing the full stack backtrace of the
current TSS, then once finished we check whether this TSS is nested
(has a parent). If so we change the (cached) current TSS to the latter,
restarting the backtrace at the parent TSS' latest EIP.
Examples of stack backtraces:
=============================
- General Protection fault:
<snip>
*** Fatal System Error: 0x0000007f
(0x0000000D,0x00000000,0x00000000,0x00000000)
Entered debugger on embedded INT3 at 0x0008:0x80953528.
kdb:> bt
Eip:
<ntoskrnl.exe:153529 (sdk/lib/rtl/i386/debug_asm.S:57 (RtlpBreakWithStatusInstruction))>
Frames:
<ntoskrnl.exe:899b0 (ntoskrnl/ke/bug.c:1136 (KeBugCheckWithTf))>
<ntoskrnl.exe:134826 (ntoskrnl/ke/i386/exp.c:1161 (KeRaiseUserException))>
<ntoskrnl.exe:19ae67 (ntoskrnl/ke/i386/traphdlr.c:1282 (KiTrap0DHandler))>
<ntoskrnl.exe:19a840 (:0 (KiTrap0D))>
<ntoskrnl.exe:1925e6 (ntoskrnl/include/internal/i386/intrin_i.h:45 (KiInitMachineDependent))>
<ntoskrnl.exe:187688 (ntoskrnl/ke/krnlinit.c:305 (KeInitSystem))>
<ntoskrnl.exe:17fb2f (ntoskrnl/ex/init.c:1621 (Phase1InitializationDiscard))>
<ntoskrnl.exe:3247f (ntoskrnl/ex/init.c:2019 (Phase1Initialization))>
<ntoskrnl.exe:11c079 (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup))>
<ntoskrnl.exe:135c8a (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup))>
<ntoskrnl.exe:11c040 (ntoskrnl/ps/thread.c:141 (PspSystemThreadStartup))>
<5d8950ec>
Couldn't access memory at 0x83E58959!
</snip>
- Double-fault (manually triggered by removing the GP handler):
Note how the backtrace explicitly specifies the crossed TSS boundaries,
and the trace in the parent TSS is indeed consistent with the previous
example. Note also that log2lines (used here to completely resolve the
trace) failed to see KiTrap08Handler(), which has been instead mistaken
for KiTrap09().
<snip>
*** Fatal System Error: 0x0000007f
(0x00000008,0x8009C000,0x00000000,0x00000000)
Entered debugger on embedded INT3 at 0x0008:0x80953528.
kdb:> bt
[Active TSS 0x0050 @ 0x80A10CA0]
Eip:
<ntoskrnl.exe:153529 (sdk/lib/rtl/i386/debug_asm.S:57 (RtlpBreakWithStatusInstruction))>
Frames:
<ntoskrnl.exe:899b0 (ntoskrnl/ke/bug.c:1136 (KeBugCheckWithTf))>
<ntoskrnl.exe:19a1d8 (ntoskrnl/ke/i386/traphdlr.c:917 (KiTrap09))> // <-- Here, log2lines fails to see it's actually KiTrap08Handler.
<ntoskrnl.exe:19a145 (:0 (KiTrap08))>
[Parent TSS 0x0028 @ 0x8009C000]
<ntoskrnl.exe:1925e6 (ntoskrnl/include/internal/i386/intrin_i.h:45 (KiInitMachineDependent))>
<ntoskrnl.exe:187688 (ntoskrnl/ke/krnlinit.c:305 (KeInitSystem))>
<ntoskrnl.exe:17fb2f (ntoskrnl/ex/init.c:1621 (Phase1InitializationDiscard))>
<ntoskrnl.exe:3247f (ntoskrnl/ex/init.c:2019 (Phase1Initialization))>
<ntoskrnl.exe:11c079 (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup))>
<ntoskrnl.exe:135c8a (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup))>
<ntoskrnl.exe:11c040 (ntoskrnl/ps/thread.c:141 (PspSystemThreadStartup))>
<5d8950ec>
Couldn't access memory at 0x83E58959!
</snip>
- Import KdpCopyMemoryChunks() from kd64/kdapi.c, and re-implement
KdbpSafeReadMemory() and KdbpSafeWriteMemory() around it.
Note that these functions read virtual memory and are equivalent of
the kd64 KdpReadVirtualMemory() and KdpWriteVirtualMemory()
respectively.
- Get rid of the KdpEnableSafeMem() call in KdInitSystem().
- Adjust kd gdbstub.c wrapper in accordance.
We allow specifying manually the TSS selector number or its descriptor address,
and dump more information from the associated KTSS structure.
Also add the KdbpRetrieveTss() helper to retrieve the PKTSS from its
corresponding selector number. It will also be useful for future improvements.
- Always include kd64.h
- Change KdpPrompt() prototype to be compatible between KDBG and _WINDK_
- Rename KdComponentTable to KdpComponentTable to prevent a conflict
- Add some functions stubs and global variables
This allows avoiding one of the previous implementation limits:
leaked IRP not queued to a thread are now totally visible since
we look directly in the memory pool.
For now, it allows searching for pool allocations in
both paged and non paged pool.
It is based on Andreas Schuster work to identify POOL_HEADER
structures.
This is far from perfect, and totally doesn't match the
WinDBG way of doing it. Instead of browsing pool to find
matching 'IRP' tags, we just browse all the processes
to find the queued IRP. This requires the IRPs to be queued,
obviously, and will make us miss the leaked IRPs, for instance.
Proper way to do it would be to implement !poolfind and then
rely on its implementation to find our IRPs.
Perhaps later ;-)
..\ntoskrnl\kdbg\i386\i386-dis.c(3131,23): warning: adding 'char' to a string does not append to the string [-Wstring-plus-int]
oappend ("%cs:" + intel_syntax);
~~~~~~~^~~~~~~~~~~~~~
..\ntoskrnl\kdbg\i386\i386-dis.c(3131,23): note: use array indexing to silence this warning
oappend ("%cs:" + intel_syntax);
^
& [ ]
Fixes clang warning:
..\ntoskrnl\kdbg\kdb.c(175,25): warning: variable 'TrapCr4' is uninitialized when used here [-Wuninitialized]
KdbTrapFrame->Cr4 = TrapCr4;
^~~~~~~
..\ntoskrnl\kdbg\kdb.c(140,45): note: initialize the variable 'TrapCr4' to silence this warning
ULONG TrapCr0, TrapCr2, TrapCr3, TrapCr4;
^
= 0
