2010-02-26 11:43:19 +00:00
|
|
|
#pragma once
|
2000-01-17 21:02:50 +00:00
|
|
|
|
2013-05-07 00:14:36 +00:00
|
|
|
#include <cportlib/cportlib.h>
|
|
|
|
|
|
2006-05-10 17:47:44 +00:00
|
|
|
//
|
|
|
|
|
// Kernel Debugger Port Definition
|
|
|
|
|
//
|
2005-04-25 14:44:48 +00:00
|
|
|
struct _KD_DISPATCH_TABLE;
|
|
|
|
|
|
2006-05-10 17:47:44 +00:00
|
|
|
BOOLEAN
|
|
|
|
|
NTAPI
|
|
|
|
|
KdPortInitializeEx(
|
2013-05-07 00:14:36 +00:00
|
|
|
PCPPORT PortInformation,
|
|
|
|
|
ULONG ComPortNumber
|
2006-05-10 17:47:44 +00:00
|
|
|
);
|
|
|
|
|
|
|
|
|
|
BOOLEAN
|
|
|
|
|
NTAPI
|
|
|
|
|
KdPortGetByteEx(
|
2013-05-07 00:14:36 +00:00
|
|
|
PCPPORT PortInformation,
|
2013-04-13 21:28:10 +00:00
|
|
|
PUCHAR ByteReceived);
|
2006-05-10 17:47:44 +00:00
|
|
|
|
|
|
|
|
VOID
|
|
|
|
|
NTAPI
|
|
|
|
|
KdPortPutByteEx(
|
2013-05-07 00:14:36 +00:00
|
|
|
PCPPORT PortInformation,
|
2006-05-10 17:47:44 +00:00
|
|
|
UCHAR ByteToSend
|
|
|
|
|
);
|
|
|
|
|
|
2022-03-07 23:42:06 +00:00
|
|
|
#ifdef _NTOSKRNL_
|
2005-04-25 19:42:48 +00:00
|
|
|
|
2005-04-25 14:44:48 +00:00
|
|
|
/* KD ROUTINES ***************************************************************/
|
2002-02-09 18:41:24 +00:00
|
|
|
|
2002-01-23 23:39:26 +00:00
|
|
|
typedef enum _KD_CONTINUE_TYPE
|
|
|
|
|
{
|
2005-04-25 14:44:48 +00:00
|
|
|
kdContinue = 0,
|
|
|
|
|
kdDoNotHandleException,
|
|
|
|
|
kdHandleException
|
[NTOS:KD/KD64/KDBG] Share some code between our legacy KD/KDBG and KD64.
Our legacy KD module is slowly being phased out for the more recent KD64
Kernel Debugger that supports WinDbg, but at the same time we must retain
support for GCC debugging and the KDBG interface.
For the time being few #ifdef _WINKD_ have been introduced in KD64 so that
some of its code/data does not completely get shared yet with the legacy KD,
until the latter becomes phased out.
KD Modifications:
=================
- Remove the implementation of NtQueryDebugFilterState() /
NtSetDebugFilterState() that now comes entirely from KD64.
- Remove KD variables that are now shared with KD64.
- Share common code with KD64: KdpMoveMemory(), KdpZeroMemory(),
KdpCopyMemoryChunks(), KdpPrint(), KdpPrompt().
- KDBG: Remove the duplicated KdpCopyMemoryChunks() function.
- In KdpServiceDispatcher() and KdpEnterDebuggerException(), call the
KdpPrint() worker function that correctly probes and captures its arguments.
- Temporarily stub out KdEnterDebugger() and KdExitDebugger() that is used
by the shared code, until KD is removed and only the KD64 version of these
functions remain.
- Re-implement the KD/KDBG KdpPrompt() function using a custom KdpPromptString()
helper compatible with KD64, that is called by the KD64 implementation of
KdpPrompt(). This KdpPromptString() helper now issues the prompt on all
the KD loggers: e.g. if you use both at the same time COM-port and SCREEN
debugging, the prompt will appear on both. Before that the prompt was always
being displayed on COM port even if e.g. a SCREEN-only debug session was used...
- ppc_irq.c: Fix the prototype of KdpServiceDispatcher().
KD64 Fixes:
===========
- Initialize the MaximumLength member of the counted STRING variables
before using them elsewhere.
- Get rid of alloca() within SEH block in KdpPrint() (addendum to 7b95fcf9).
- Add the ROS-specific handy dump commands in KdSystemDebugControl().
2019-11-17 21:55:36 +00:00
|
|
|
} KD_CONTINUE_TYPE;
|
2002-01-23 23:39:26 +00:00
|
|
|
|
2005-04-25 14:44:48 +00:00
|
|
|
typedef
|
[NTOS:KD][KDBG] Rework the BootPhase >= 2 initialization of the KD/KDBG kernel debugger. (#4892)
CORE-17470
+ KdpDebugLogInit: Add resources cleanup in failure code paths.
Fix, in an NT-compatible manner, how (and when) the KD/KDBG BootPhase >=2
initialization steps are performed.
These are necessary for any functionality KDBG needs, that would depend
on the NT I/O Manager and the storage and filesystem stacks to be running.
This includes, creating the debug log file, and for KDBG, loading its
KDBinit initialization file.
As a result, file debug logging is fixed.
The old ReactOS-specific (NT-incompatible) callback we did in the middle
of IoInitSystem() is removed, in favor of a runtime mechanism that should
work on Windows as well.
The idea for this new mechanism is loosely inspired by the TDL4 rootkit,
see http://blog.w4kfu.com/public/tdl4_article/draft_tdl4article.html
but contrary to it, a specific hook is used instead, as well as the
technique of driver reinitialization:
https://web.archive.org/web/20211021050515/https://driverentry.com.br/en/blog/?p=261
Its rationale is as follows:
We want to be able to perform I/O-related initialization (starting a
logger thread for file log debugging, loading KDBinit file for KDBG,
etc.). A good place for this would be as early as possible, once the
I/O Manager has started the storage and the boot filesystem drivers.
Here is an overview of the initialization steps of the NT Kernel and
Executive:
----
KiSystemStartup(KeLoaderBlock)
if (Cpu == 0) KdInitSystem(0, KeLoaderBlock);
KiSwitchToBootStack() -> KiSystemStartupBootStack()
-> KiInitializeKernel() -> ExpInitializeExecutive(Cpu, KeLoaderBlock)
(NOTE: Any unexpected debugger break will call KdInitSystem(0, NULL); )
KdInitSystem(0, LoaderBlock) -> KdDebuggerInitialize0(LoaderBlock);
ExpInitializeExecutive(Cpu == 0): ExpInitializationPhase = 0;
HalInitSystem(0, KeLoaderBlock); <-- Sets HalInitPnpDriver callback.
...
PsInitSystem(LoaderBlock)
PsCreateSystemThread(Phase1Initialization)
Phase1Initialization(Discard): ExpInitializationPhase = 1;
HalInitSystem(1, KeLoaderBlock);
...
Early initialization of Ob, Ex, Ke.
KdInitSystem(1, KeLoaderBlock);
...
KdDebuggerInitialize1(LoaderBlock);
...
IoInitSystem(LoaderBlock);
...
----
As we can see, KdDebuggerInitialize1() is the last KD initialization
routine the kernel calls, and is called *before* the I/O Manager starts.
Thus, direct Nt/ZwCreateFile ... calls done there would fail. Also,
we want to do the I/O initialization as soon as possible. There does
not seem to be any exported way to be notified about the I/O manager
initialization steps... that is, unless we somehow become a driver and
insert ourselves in the flow!
Since we are not a regular driver, we need to invoke IoCreateDriver()
to create one. However, remember that we are currently running *before*
IoInitSystem(), the I/O subsystem is not initialized yet. Due to this,
calling IoCreateDriver(), much like any other IO functions, would lead
to a crash, because it calls
ObCreateObject(..., IoDriverObjectType, ...), and IoDriverObjectType
is non-initialized yet (it's NULL).
The chosen solution is to hook a "known" exported callback: namely, the
HalInitPnpDriver() callback (it initializes the "HAL Root Bus Driver").
It is set very early on by the HAL via the HalInitSystem(0, ...) call,
and is called early on by IoInitSystem() before any driver is loaded,
but after the I/O Manager has been minimally set up so that new drivers
can be created.
When the hook: KdpInitDriver() is called, we create our driver with
IoCreateDriver(), specifying its entrypoint KdpDriverEntry(), then
restore and call the original HalInitPnpDriver() callback.
Another possible unexplored alternative, could be to insert ourselves
in the KeLoaderBlock->LoadOrderListHead boot modules list, or in the
KeLoaderBlock->BootDriverListHead boot-driver list. (Note that while
we may be able to do this, because boot-drivers are resident in memory,
much like we are, we cannot insert ourselves in the system-driver list
however, since those drivers are expected to come from PE image files.)
Once the KdpDriverEntry() driver entrypoint is called, we register
KdpDriverReinit() for re-initialization with the I/O Manager, in order
to provide more initialization points. KdpDriverReinit() calls the KD
providers at BootPhase >= 2, and schedules further reinitializations
(at most 3 more) if any of the providers request so.
2023-01-09 18:35:18 +00:00
|
|
|
NTSTATUS
|
2023-01-09 11:31:03 +00:00
|
|
|
(NTAPI *PKDP_INIT_ROUTINE)(
|
|
|
|
|
_In_ struct _KD_DISPATCH_TABLE *DispatchTable,
|
|
|
|
|
_In_ ULONG BootPhase);
|
2004-06-23 00:49:22 +00:00
|
|
|
|
2005-04-25 14:44:48 +00:00
|
|
|
typedef
|
2004-06-23 00:49:22 +00:00
|
|
|
VOID
|
2008-11-29 20:47:48 +00:00
|
|
|
(NTAPI*PKDP_PRINT_ROUTINE)(
|
2019-11-17 15:44:22 +00:00
|
|
|
PCHAR String,
|
- More sharing between ntdll/ntoskrnl: shared Dbg code.
- Added NtCreateDebugObject, NtDebugContinue, NtQueryDebugFilterState, NtSetDebugFilterState, NtWaitForDebugEvent to system call list.
- Added some debug constants to headers
- Updated RtlpCheckForActiveDebugger in ntoskrnl to return whatever we're expecting as the "normal" case.
- Added RtlpSetInDbgPrint to rtl support library for special DbgPrint implementation difference in user-mode
- Removed all the deprecated debug APIs in ntdll.
- Implemented NtQueryDebugFilterState and NtSetDebugFilterState based on royce's implementation.
- Started modifications on KeDebugService, and implemented DebugService in rtl
- Implemented all the Dbg* APIs in RTL.
- Implemented DbgUiConnectToDbg, DbgUiContinue, DbgUiWaitStateChange, DbgUiRemoteBreakin, DbgUiIssueRemoteBreakin
- Changed KD Print callbacks to also receive the length of the string.
Right now, one call that should be shared still isn't (the final DebugPrint call) because calling KeDebugService from kernel-mode seems to cause a hang. Also, DebugService does not currently cause an exception like it should (instead it still calls the Kdp handler), because those changes would've made the patch even bigger and are still untested.
svn path=/trunk/; revision=18078
2005-09-26 04:59:48 +00:00
|
|
|
ULONG Length
|
|
|
|
|
);
|
2002-01-23 23:39:26 +00:00
|
|
|
|
2005-04-25 14:44:48 +00:00
|
|
|
/* INIT ROUTINES *************************************************************/
|
2004-08-26 16:04:50 +00:00
|
|
|
|
2022-07-10 13:01:01 +00:00
|
|
|
KIRQL
|
|
|
|
|
NTAPI
|
|
|
|
|
KdbpAcquireLock(
|
|
|
|
|
_In_ PKSPIN_LOCK SpinLock);
|
|
|
|
|
|
|
|
|
|
VOID
|
|
|
|
|
NTAPI
|
|
|
|
|
KdbpReleaseLock(
|
|
|
|
|
_In_ PKSPIN_LOCK SpinLock,
|
|
|
|
|
_In_ KIRQL OldIrql);
|
|
|
|
|
|
2019-11-17 15:44:22 +00:00
|
|
|
VOID
|
|
|
|
|
KdpScreenAcquire(VOID);
|
|
|
|
|
|
|
|
|
|
VOID
|
|
|
|
|
KdpScreenRelease(VOID);
|
|
|
|
|
|
[NTOS:KD][KDBG] Rework the BootPhase >= 2 initialization of the KD/KDBG kernel debugger. (#4892)
CORE-17470
+ KdpDebugLogInit: Add resources cleanup in failure code paths.
Fix, in an NT-compatible manner, how (and when) the KD/KDBG BootPhase >=2
initialization steps are performed.
These are necessary for any functionality KDBG needs, that would depend
on the NT I/O Manager and the storage and filesystem stacks to be running.
This includes, creating the debug log file, and for KDBG, loading its
KDBinit initialization file.
As a result, file debug logging is fixed.
The old ReactOS-specific (NT-incompatible) callback we did in the middle
of IoInitSystem() is removed, in favor of a runtime mechanism that should
work on Windows as well.
The idea for this new mechanism is loosely inspired by the TDL4 rootkit,
see http://blog.w4kfu.com/public/tdl4_article/draft_tdl4article.html
but contrary to it, a specific hook is used instead, as well as the
technique of driver reinitialization:
https://web.archive.org/web/20211021050515/https://driverentry.com.br/en/blog/?p=261
Its rationale is as follows:
We want to be able to perform I/O-related initialization (starting a
logger thread for file log debugging, loading KDBinit file for KDBG,
etc.). A good place for this would be as early as possible, once the
I/O Manager has started the storage and the boot filesystem drivers.
Here is an overview of the initialization steps of the NT Kernel and
Executive:
----
KiSystemStartup(KeLoaderBlock)
if (Cpu == 0) KdInitSystem(0, KeLoaderBlock);
KiSwitchToBootStack() -> KiSystemStartupBootStack()
-> KiInitializeKernel() -> ExpInitializeExecutive(Cpu, KeLoaderBlock)
(NOTE: Any unexpected debugger break will call KdInitSystem(0, NULL); )
KdInitSystem(0, LoaderBlock) -> KdDebuggerInitialize0(LoaderBlock);
ExpInitializeExecutive(Cpu == 0): ExpInitializationPhase = 0;
HalInitSystem(0, KeLoaderBlock); <-- Sets HalInitPnpDriver callback.
...
PsInitSystem(LoaderBlock)
PsCreateSystemThread(Phase1Initialization)
Phase1Initialization(Discard): ExpInitializationPhase = 1;
HalInitSystem(1, KeLoaderBlock);
...
Early initialization of Ob, Ex, Ke.
KdInitSystem(1, KeLoaderBlock);
...
KdDebuggerInitialize1(LoaderBlock);
...
IoInitSystem(LoaderBlock);
...
----
As we can see, KdDebuggerInitialize1() is the last KD initialization
routine the kernel calls, and is called *before* the I/O Manager starts.
Thus, direct Nt/ZwCreateFile ... calls done there would fail. Also,
we want to do the I/O initialization as soon as possible. There does
not seem to be any exported way to be notified about the I/O manager
initialization steps... that is, unless we somehow become a driver and
insert ourselves in the flow!
Since we are not a regular driver, we need to invoke IoCreateDriver()
to create one. However, remember that we are currently running *before*
IoInitSystem(), the I/O subsystem is not initialized yet. Due to this,
calling IoCreateDriver(), much like any other IO functions, would lead
to a crash, because it calls
ObCreateObject(..., IoDriverObjectType, ...), and IoDriverObjectType
is non-initialized yet (it's NULL).
The chosen solution is to hook a "known" exported callback: namely, the
HalInitPnpDriver() callback (it initializes the "HAL Root Bus Driver").
It is set very early on by the HAL via the HalInitSystem(0, ...) call,
and is called early on by IoInitSystem() before any driver is loaded,
but after the I/O Manager has been minimally set up so that new drivers
can be created.
When the hook: KdpInitDriver() is called, we create our driver with
IoCreateDriver(), specifying its entrypoint KdpDriverEntry(), then
restore and call the original HalInitPnpDriver() callback.
Another possible unexplored alternative, could be to insert ourselves
in the KeLoaderBlock->LoadOrderListHead boot modules list, or in the
KeLoaderBlock->BootDriverListHead boot-driver list. (Note that while
we may be able to do this, because boot-drivers are resident in memory,
much like we are, we cannot insert ourselves in the system-driver list
however, since those drivers are expected to come from PE image files.)
Once the KdpDriverEntry() driver entrypoint is called, we register
KdpDriverReinit() for re-initialization with the I/O Manager, in order
to provide more initialization points. KdpDriverReinit() calls the KD
providers at BootPhase >= 2, and schedules further reinitializations
(at most 3 more) if any of the providers request so.
2023-01-09 18:35:18 +00:00
|
|
|
NTSTATUS
|
2008-11-29 20:47:48 +00:00
|
|
|
NTAPI
|
2005-06-25 17:01:17 +00:00
|
|
|
KdpScreenInit(
|
2023-01-09 11:31:03 +00:00
|
|
|
_In_ struct _KD_DISPATCH_TABLE *DispatchTable,
|
|
|
|
|
_In_ ULONG BootPhase);
|
2005-06-25 17:01:17 +00:00
|
|
|
|
[NTOS:KD][KDBG] Rework the BootPhase >= 2 initialization of the KD/KDBG kernel debugger. (#4892)
CORE-17470
+ KdpDebugLogInit: Add resources cleanup in failure code paths.
Fix, in an NT-compatible manner, how (and when) the KD/KDBG BootPhase >=2
initialization steps are performed.
These are necessary for any functionality KDBG needs, that would depend
on the NT I/O Manager and the storage and filesystem stacks to be running.
This includes, creating the debug log file, and for KDBG, loading its
KDBinit initialization file.
As a result, file debug logging is fixed.
The old ReactOS-specific (NT-incompatible) callback we did in the middle
of IoInitSystem() is removed, in favor of a runtime mechanism that should
work on Windows as well.
The idea for this new mechanism is loosely inspired by the TDL4 rootkit,
see http://blog.w4kfu.com/public/tdl4_article/draft_tdl4article.html
but contrary to it, a specific hook is used instead, as well as the
technique of driver reinitialization:
https://web.archive.org/web/20211021050515/https://driverentry.com.br/en/blog/?p=261
Its rationale is as follows:
We want to be able to perform I/O-related initialization (starting a
logger thread for file log debugging, loading KDBinit file for KDBG,
etc.). A good place for this would be as early as possible, once the
I/O Manager has started the storage and the boot filesystem drivers.
Here is an overview of the initialization steps of the NT Kernel and
Executive:
----
KiSystemStartup(KeLoaderBlock)
if (Cpu == 0) KdInitSystem(0, KeLoaderBlock);
KiSwitchToBootStack() -> KiSystemStartupBootStack()
-> KiInitializeKernel() -> ExpInitializeExecutive(Cpu, KeLoaderBlock)
(NOTE: Any unexpected debugger break will call KdInitSystem(0, NULL); )
KdInitSystem(0, LoaderBlock) -> KdDebuggerInitialize0(LoaderBlock);
ExpInitializeExecutive(Cpu == 0): ExpInitializationPhase = 0;
HalInitSystem(0, KeLoaderBlock); <-- Sets HalInitPnpDriver callback.
...
PsInitSystem(LoaderBlock)
PsCreateSystemThread(Phase1Initialization)
Phase1Initialization(Discard): ExpInitializationPhase = 1;
HalInitSystem(1, KeLoaderBlock);
...
Early initialization of Ob, Ex, Ke.
KdInitSystem(1, KeLoaderBlock);
...
KdDebuggerInitialize1(LoaderBlock);
...
IoInitSystem(LoaderBlock);
...
----
As we can see, KdDebuggerInitialize1() is the last KD initialization
routine the kernel calls, and is called *before* the I/O Manager starts.
Thus, direct Nt/ZwCreateFile ... calls done there would fail. Also,
we want to do the I/O initialization as soon as possible. There does
not seem to be any exported way to be notified about the I/O manager
initialization steps... that is, unless we somehow become a driver and
insert ourselves in the flow!
Since we are not a regular driver, we need to invoke IoCreateDriver()
to create one. However, remember that we are currently running *before*
IoInitSystem(), the I/O subsystem is not initialized yet. Due to this,
calling IoCreateDriver(), much like any other IO functions, would lead
to a crash, because it calls
ObCreateObject(..., IoDriverObjectType, ...), and IoDriverObjectType
is non-initialized yet (it's NULL).
The chosen solution is to hook a "known" exported callback: namely, the
HalInitPnpDriver() callback (it initializes the "HAL Root Bus Driver").
It is set very early on by the HAL via the HalInitSystem(0, ...) call,
and is called early on by IoInitSystem() before any driver is loaded,
but after the I/O Manager has been minimally set up so that new drivers
can be created.
When the hook: KdpInitDriver() is called, we create our driver with
IoCreateDriver(), specifying its entrypoint KdpDriverEntry(), then
restore and call the original HalInitPnpDriver() callback.
Another possible unexplored alternative, could be to insert ourselves
in the KeLoaderBlock->LoadOrderListHead boot modules list, or in the
KeLoaderBlock->BootDriverListHead boot-driver list. (Note that while
we may be able to do this, because boot-drivers are resident in memory,
much like we are, we cannot insert ourselves in the system-driver list
however, since those drivers are expected to come from PE image files.)
Once the KdpDriverEntry() driver entrypoint is called, we register
KdpDriverReinit() for re-initialization with the I/O Manager, in order
to provide more initialization points. KdpDriverReinit() calls the KD
providers at BootPhase >= 2, and schedules further reinitializations
(at most 3 more) if any of the providers request so.
2023-01-09 18:35:18 +00:00
|
|
|
NTSTATUS
|
2008-11-29 20:47:48 +00:00
|
|
|
NTAPI
|
2005-06-25 17:01:17 +00:00
|
|
|
KdpSerialInit(
|
2023-01-09 11:31:03 +00:00
|
|
|
_In_ struct _KD_DISPATCH_TABLE *DispatchTable,
|
|
|
|
|
_In_ ULONG BootPhase);
|
2005-05-09 01:38:29 +00:00
|
|
|
|
[NTOS:KD][KDBG] Rework the BootPhase >= 2 initialization of the KD/KDBG kernel debugger. (#4892)
CORE-17470
+ KdpDebugLogInit: Add resources cleanup in failure code paths.
Fix, in an NT-compatible manner, how (and when) the KD/KDBG BootPhase >=2
initialization steps are performed.
These are necessary for any functionality KDBG needs, that would depend
on the NT I/O Manager and the storage and filesystem stacks to be running.
This includes, creating the debug log file, and for KDBG, loading its
KDBinit initialization file.
As a result, file debug logging is fixed.
The old ReactOS-specific (NT-incompatible) callback we did in the middle
of IoInitSystem() is removed, in favor of a runtime mechanism that should
work on Windows as well.
The idea for this new mechanism is loosely inspired by the TDL4 rootkit,
see http://blog.w4kfu.com/public/tdl4_article/draft_tdl4article.html
but contrary to it, a specific hook is used instead, as well as the
technique of driver reinitialization:
https://web.archive.org/web/20211021050515/https://driverentry.com.br/en/blog/?p=261
Its rationale is as follows:
We want to be able to perform I/O-related initialization (starting a
logger thread for file log debugging, loading KDBinit file for KDBG,
etc.). A good place for this would be as early as possible, once the
I/O Manager has started the storage and the boot filesystem drivers.
Here is an overview of the initialization steps of the NT Kernel and
Executive:
----
KiSystemStartup(KeLoaderBlock)
if (Cpu == 0) KdInitSystem(0, KeLoaderBlock);
KiSwitchToBootStack() -> KiSystemStartupBootStack()
-> KiInitializeKernel() -> ExpInitializeExecutive(Cpu, KeLoaderBlock)
(NOTE: Any unexpected debugger break will call KdInitSystem(0, NULL); )
KdInitSystem(0, LoaderBlock) -> KdDebuggerInitialize0(LoaderBlock);
ExpInitializeExecutive(Cpu == 0): ExpInitializationPhase = 0;
HalInitSystem(0, KeLoaderBlock); <-- Sets HalInitPnpDriver callback.
...
PsInitSystem(LoaderBlock)
PsCreateSystemThread(Phase1Initialization)
Phase1Initialization(Discard): ExpInitializationPhase = 1;
HalInitSystem(1, KeLoaderBlock);
...
Early initialization of Ob, Ex, Ke.
KdInitSystem(1, KeLoaderBlock);
...
KdDebuggerInitialize1(LoaderBlock);
...
IoInitSystem(LoaderBlock);
...
----
As we can see, KdDebuggerInitialize1() is the last KD initialization
routine the kernel calls, and is called *before* the I/O Manager starts.
Thus, direct Nt/ZwCreateFile ... calls done there would fail. Also,
we want to do the I/O initialization as soon as possible. There does
not seem to be any exported way to be notified about the I/O manager
initialization steps... that is, unless we somehow become a driver and
insert ourselves in the flow!
Since we are not a regular driver, we need to invoke IoCreateDriver()
to create one. However, remember that we are currently running *before*
IoInitSystem(), the I/O subsystem is not initialized yet. Due to this,
calling IoCreateDriver(), much like any other IO functions, would lead
to a crash, because it calls
ObCreateObject(..., IoDriverObjectType, ...), and IoDriverObjectType
is non-initialized yet (it's NULL).
The chosen solution is to hook a "known" exported callback: namely, the
HalInitPnpDriver() callback (it initializes the "HAL Root Bus Driver").
It is set very early on by the HAL via the HalInitSystem(0, ...) call,
and is called early on by IoInitSystem() before any driver is loaded,
but after the I/O Manager has been minimally set up so that new drivers
can be created.
When the hook: KdpInitDriver() is called, we create our driver with
IoCreateDriver(), specifying its entrypoint KdpDriverEntry(), then
restore and call the original HalInitPnpDriver() callback.
Another possible unexplored alternative, could be to insert ourselves
in the KeLoaderBlock->LoadOrderListHead boot modules list, or in the
KeLoaderBlock->BootDriverListHead boot-driver list. (Note that while
we may be able to do this, because boot-drivers are resident in memory,
much like we are, we cannot insert ourselves in the system-driver list
however, since those drivers are expected to come from PE image files.)
Once the KdpDriverEntry() driver entrypoint is called, we register
KdpDriverReinit() for re-initialization with the I/O Manager, in order
to provide more initialization points. KdpDriverReinit() calls the KD
providers at BootPhase >= 2, and schedules further reinitializations
(at most 3 more) if any of the providers request so.
2023-01-09 18:35:18 +00:00
|
|
|
NTSTATUS
|
2008-11-29 20:47:48 +00:00
|
|
|
NTAPI
|
2019-11-17 15:44:22 +00:00
|
|
|
KdpDebugLogInit(
|
2023-01-09 11:31:03 +00:00
|
|
|
_In_ struct _KD_DISPATCH_TABLE *DispatchTable,
|
|
|
|
|
_In_ ULONG BootPhase);
|
2005-05-09 01:38:29 +00:00
|
|
|
|
2022-11-18 16:44:29 +00:00
|
|
|
#ifdef KDBG
|
2023-03-10 17:12:32 +00:00
|
|
|
#define KdpKdbgInit KdbInitialize
|
2022-11-18 16:44:29 +00:00
|
|
|
#endif
|
2007-06-28 17:49:02 +00:00
|
|
|
|
|
|
|
|
|
2005-04-25 14:44:48 +00:00
|
|
|
/* KD GLOBALS ***************************************************************/
|
|
|
|
|
|
[NTOS:KD/KD64/KDBG] Share some code between our legacy KD/KDBG and KD64.
Our legacy KD module is slowly being phased out for the more recent KD64
Kernel Debugger that supports WinDbg, but at the same time we must retain
support for GCC debugging and the KDBG interface.
For the time being few #ifdef _WINKD_ have been introduced in KD64 so that
some of its code/data does not completely get shared yet with the legacy KD,
until the latter becomes phased out.
KD Modifications:
=================
- Remove the implementation of NtQueryDebugFilterState() /
NtSetDebugFilterState() that now comes entirely from KD64.
- Remove KD variables that are now shared with KD64.
- Share common code with KD64: KdpMoveMemory(), KdpZeroMemory(),
KdpCopyMemoryChunks(), KdpPrint(), KdpPrompt().
- KDBG: Remove the duplicated KdpCopyMemoryChunks() function.
- In KdpServiceDispatcher() and KdpEnterDebuggerException(), call the
KdpPrint() worker function that correctly probes and captures its arguments.
- Temporarily stub out KdEnterDebugger() and KdExitDebugger() that is used
by the shared code, until KD is removed and only the KD64 version of these
functions remain.
- Re-implement the KD/KDBG KdpPrompt() function using a custom KdpPromptString()
helper compatible with KD64, that is called by the KD64 implementation of
KdpPrompt(). This KdpPromptString() helper now issues the prompt on all
the KD loggers: e.g. if you use both at the same time COM-port and SCREEN
debugging, the prompt will appear on both. Before that the prompt was always
being displayed on COM port even if e.g. a SCREEN-only debug session was used...
- ppc_irq.c: Fix the prototype of KdpServiceDispatcher().
KD64 Fixes:
===========
- Initialize the MaximumLength member of the counted STRING variables
before using them elsewhere.
- Get rid of alloca() within SEH block in KdpPrint() (addendum to 7b95fcf9).
- Add the ROS-specific handy dump commands in KdSystemDebugControl().
2019-11-17 21:55:36 +00:00
|
|
|
/* Serial debug connection */
|
2005-04-25 14:44:48 +00:00
|
|
|
#define DEFAULT_DEBUG_PORT 2 /* COM2 */
|
|
|
|
|
#define DEFAULT_DEBUG_COM1_IRQ 4 /* COM1 IRQ */
|
|
|
|
|
#define DEFAULT_DEBUG_COM2_IRQ 3 /* COM2 IRQ */
|
|
|
|
|
#define DEFAULT_DEBUG_BAUD_RATE 115200 /* 115200 Baud */
|
|
|
|
|
|
|
|
|
|
/* KD Native Modes */
|
[NTOS:KD/KD64/KDBG] Share some code between our legacy KD/KDBG and KD64.
Our legacy KD module is slowly being phased out for the more recent KD64
Kernel Debugger that supports WinDbg, but at the same time we must retain
support for GCC debugging and the KDBG interface.
For the time being few #ifdef _WINKD_ have been introduced in KD64 so that
some of its code/data does not completely get shared yet with the legacy KD,
until the latter becomes phased out.
KD Modifications:
=================
- Remove the implementation of NtQueryDebugFilterState() /
NtSetDebugFilterState() that now comes entirely from KD64.
- Remove KD variables that are now shared with KD64.
- Share common code with KD64: KdpMoveMemory(), KdpZeroMemory(),
KdpCopyMemoryChunks(), KdpPrint(), KdpPrompt().
- KDBG: Remove the duplicated KdpCopyMemoryChunks() function.
- In KdpServiceDispatcher() and KdpEnterDebuggerException(), call the
KdpPrint() worker function that correctly probes and captures its arguments.
- Temporarily stub out KdEnterDebugger() and KdExitDebugger() that is used
by the shared code, until KD is removed and only the KD64 version of these
functions remain.
- Re-implement the KD/KDBG KdpPrompt() function using a custom KdpPromptString()
helper compatible with KD64, that is called by the KD64 implementation of
KdpPrompt(). This KdpPromptString() helper now issues the prompt on all
the KD loggers: e.g. if you use both at the same time COM-port and SCREEN
debugging, the prompt will appear on both. Before that the prompt was always
being displayed on COM port even if e.g. a SCREEN-only debug session was used...
- ppc_irq.c: Fix the prototype of KdpServiceDispatcher().
KD64 Fixes:
===========
- Initialize the MaximumLength member of the counted STRING variables
before using them elsewhere.
- Get rid of alloca() within SEH block in KdpPrint() (addendum to 7b95fcf9).
- Add the ROS-specific handy dump commands in KdSystemDebugControl().
2019-11-17 21:55:36 +00:00
|
|
|
#define KdScreen 0
|
|
|
|
|
#define KdSerial 1
|
|
|
|
|
#define KdFile 2
|
2020-03-28 09:45:31 +00:00
|
|
|
#define KdKdbg 3
|
|
|
|
|
#define KdMax 4
|
2005-04-25 14:44:48 +00:00
|
|
|
|
|
|
|
|
/* KD Private Debug Modes */
|
|
|
|
|
typedef struct _KDP_DEBUG_MODE
|
|
|
|
|
{
|
2005-06-25 17:01:17 +00:00
|
|
|
union
|
|
|
|
|
{
|
|
|
|
|
struct
|
|
|
|
|
{
|
2005-04-25 14:44:48 +00:00
|
|
|
/* Native Modes */
|
|
|
|
|
UCHAR Screen :1;
|
|
|
|
|
UCHAR Serial :1;
|
|
|
|
|
UCHAR File :1;
|
|
|
|
|
};
|
2005-05-09 01:38:29 +00:00
|
|
|
|
2005-04-25 14:44:48 +00:00
|
|
|
/* Generic Value */
|
|
|
|
|
ULONG Value;
|
|
|
|
|
};
|
[NTOS:KD/KD64/KDBG] Share some code between our legacy KD/KDBG and KD64.
Our legacy KD module is slowly being phased out for the more recent KD64
Kernel Debugger that supports WinDbg, but at the same time we must retain
support for GCC debugging and the KDBG interface.
For the time being few #ifdef _WINKD_ have been introduced in KD64 so that
some of its code/data does not completely get shared yet with the legacy KD,
until the latter becomes phased out.
KD Modifications:
=================
- Remove the implementation of NtQueryDebugFilterState() /
NtSetDebugFilterState() that now comes entirely from KD64.
- Remove KD variables that are now shared with KD64.
- Share common code with KD64: KdpMoveMemory(), KdpZeroMemory(),
KdpCopyMemoryChunks(), KdpPrint(), KdpPrompt().
- KDBG: Remove the duplicated KdpCopyMemoryChunks() function.
- In KdpServiceDispatcher() and KdpEnterDebuggerException(), call the
KdpPrint() worker function that correctly probes and captures its arguments.
- Temporarily stub out KdEnterDebugger() and KdExitDebugger() that is used
by the shared code, until KD is removed and only the KD64 version of these
functions remain.
- Re-implement the KD/KDBG KdpPrompt() function using a custom KdpPromptString()
helper compatible with KD64, that is called by the KD64 implementation of
KdpPrompt(). This KdpPromptString() helper now issues the prompt on all
the KD loggers: e.g. if you use both at the same time COM-port and SCREEN
debugging, the prompt will appear on both. Before that the prompt was always
being displayed on COM port even if e.g. a SCREEN-only debug session was used...
- ppc_irq.c: Fix the prototype of KdpServiceDispatcher().
KD64 Fixes:
===========
- Initialize the MaximumLength member of the counted STRING variables
before using them elsewhere.
- Get rid of alloca() within SEH block in KdpPrint() (addendum to 7b95fcf9).
- Add the ROS-specific handy dump commands in KdSystemDebugControl().
2019-11-17 21:55:36 +00:00
|
|
|
} KDP_DEBUG_MODE;
|
2005-04-25 14:44:48 +00:00
|
|
|
|
|
|
|
|
/* KD Internal Debug Services */
|
|
|
|
|
typedef enum _KDP_DEBUG_SERVICE
|
|
|
|
|
{
|
2005-06-25 17:01:17 +00:00
|
|
|
DumpNonPagedPool = 0x1e, /* a */
|
|
|
|
|
ManualBugCheck = 0x30, /* b */
|
|
|
|
|
DumpNonPagedPoolStats = 0x2e, /* c */
|
|
|
|
|
DumpNewNonPagedPool = 0x20, /* d */
|
|
|
|
|
DumpNewNonPagedPoolStats = 0x12, /* e */
|
|
|
|
|
DumpAllThreads = 0x21, /* f */
|
|
|
|
|
DumpUserThreads = 0x22, /* g */
|
|
|
|
|
KdSpare1 = 0x23, /* h */
|
|
|
|
|
KdSpare2 = 0x17, /* i */
|
|
|
|
|
KdSpare3 = 0x24, /* j */
|
2009-06-27 09:54:56 +00:00
|
|
|
EnterDebugger = 0x25, /* k */
|
|
|
|
|
ThatsWhatSheSaid = 69 /* FIGURE IT OUT */
|
[NTOS:KD/KD64/KDBG] Share some code between our legacy KD/KDBG and KD64.
Our legacy KD module is slowly being phased out for the more recent KD64
Kernel Debugger that supports WinDbg, but at the same time we must retain
support for GCC debugging and the KDBG interface.
For the time being few #ifdef _WINKD_ have been introduced in KD64 so that
some of its code/data does not completely get shared yet with the legacy KD,
until the latter becomes phased out.
KD Modifications:
=================
- Remove the implementation of NtQueryDebugFilterState() /
NtSetDebugFilterState() that now comes entirely from KD64.
- Remove KD variables that are now shared with KD64.
- Share common code with KD64: KdpMoveMemory(), KdpZeroMemory(),
KdpCopyMemoryChunks(), KdpPrint(), KdpPrompt().
- KDBG: Remove the duplicated KdpCopyMemoryChunks() function.
- In KdpServiceDispatcher() and KdpEnterDebuggerException(), call the
KdpPrint() worker function that correctly probes and captures its arguments.
- Temporarily stub out KdEnterDebugger() and KdExitDebugger() that is used
by the shared code, until KD is removed and only the KD64 version of these
functions remain.
- Re-implement the KD/KDBG KdpPrompt() function using a custom KdpPromptString()
helper compatible with KD64, that is called by the KD64 implementation of
KdpPrompt(). This KdpPromptString() helper now issues the prompt on all
the KD loggers: e.g. if you use both at the same time COM-port and SCREEN
debugging, the prompt will appear on both. Before that the prompt was always
being displayed on COM port even if e.g. a SCREEN-only debug session was used...
- ppc_irq.c: Fix the prototype of KdpServiceDispatcher().
KD64 Fixes:
===========
- Initialize the MaximumLength member of the counted STRING variables
before using them elsewhere.
- Get rid of alloca() within SEH block in KdpPrint() (addendum to 7b95fcf9).
- Add the ROS-specific handy dump commands in KdSystemDebugControl().
2019-11-17 21:55:36 +00:00
|
|
|
} KDP_DEBUG_SERVICE;
|
2005-04-25 14:44:48 +00:00
|
|
|
|
|
|
|
|
/* Dispatch Table for Wrapper Functions */
|
|
|
|
|
typedef struct _KD_DISPATCH_TABLE
|
|
|
|
|
{
|
|
|
|
|
LIST_ENTRY KdProvidersList;
|
|
|
|
|
PKDP_INIT_ROUTINE KdpInitRoutine;
|
|
|
|
|
PKDP_PRINT_ROUTINE KdpPrintRoutine;
|
[NTOS:KD][KDBG] Rework the BootPhase >= 2 initialization of the KD/KDBG kernel debugger. (#4892)
CORE-17470
+ KdpDebugLogInit: Add resources cleanup in failure code paths.
Fix, in an NT-compatible manner, how (and when) the KD/KDBG BootPhase >=2
initialization steps are performed.
These are necessary for any functionality KDBG needs, that would depend
on the NT I/O Manager and the storage and filesystem stacks to be running.
This includes, creating the debug log file, and for KDBG, loading its
KDBinit initialization file.
As a result, file debug logging is fixed.
The old ReactOS-specific (NT-incompatible) callback we did in the middle
of IoInitSystem() is removed, in favor of a runtime mechanism that should
work on Windows as well.
The idea for this new mechanism is loosely inspired by the TDL4 rootkit,
see http://blog.w4kfu.com/public/tdl4_article/draft_tdl4article.html
but contrary to it, a specific hook is used instead, as well as the
technique of driver reinitialization:
https://web.archive.org/web/20211021050515/https://driverentry.com.br/en/blog/?p=261
Its rationale is as follows:
We want to be able to perform I/O-related initialization (starting a
logger thread for file log debugging, loading KDBinit file for KDBG,
etc.). A good place for this would be as early as possible, once the
I/O Manager has started the storage and the boot filesystem drivers.
Here is an overview of the initialization steps of the NT Kernel and
Executive:
----
KiSystemStartup(KeLoaderBlock)
if (Cpu == 0) KdInitSystem(0, KeLoaderBlock);
KiSwitchToBootStack() -> KiSystemStartupBootStack()
-> KiInitializeKernel() -> ExpInitializeExecutive(Cpu, KeLoaderBlock)
(NOTE: Any unexpected debugger break will call KdInitSystem(0, NULL); )
KdInitSystem(0, LoaderBlock) -> KdDebuggerInitialize0(LoaderBlock);
ExpInitializeExecutive(Cpu == 0): ExpInitializationPhase = 0;
HalInitSystem(0, KeLoaderBlock); <-- Sets HalInitPnpDriver callback.
...
PsInitSystem(LoaderBlock)
PsCreateSystemThread(Phase1Initialization)
Phase1Initialization(Discard): ExpInitializationPhase = 1;
HalInitSystem(1, KeLoaderBlock);
...
Early initialization of Ob, Ex, Ke.
KdInitSystem(1, KeLoaderBlock);
...
KdDebuggerInitialize1(LoaderBlock);
...
IoInitSystem(LoaderBlock);
...
----
As we can see, KdDebuggerInitialize1() is the last KD initialization
routine the kernel calls, and is called *before* the I/O Manager starts.
Thus, direct Nt/ZwCreateFile ... calls done there would fail. Also,
we want to do the I/O initialization as soon as possible. There does
not seem to be any exported way to be notified about the I/O manager
initialization steps... that is, unless we somehow become a driver and
insert ourselves in the flow!
Since we are not a regular driver, we need to invoke IoCreateDriver()
to create one. However, remember that we are currently running *before*
IoInitSystem(), the I/O subsystem is not initialized yet. Due to this,
calling IoCreateDriver(), much like any other IO functions, would lead
to a crash, because it calls
ObCreateObject(..., IoDriverObjectType, ...), and IoDriverObjectType
is non-initialized yet (it's NULL).
The chosen solution is to hook a "known" exported callback: namely, the
HalInitPnpDriver() callback (it initializes the "HAL Root Bus Driver").
It is set very early on by the HAL via the HalInitSystem(0, ...) call,
and is called early on by IoInitSystem() before any driver is loaded,
but after the I/O Manager has been minimally set up so that new drivers
can be created.
When the hook: KdpInitDriver() is called, we create our driver with
IoCreateDriver(), specifying its entrypoint KdpDriverEntry(), then
restore and call the original HalInitPnpDriver() callback.
Another possible unexplored alternative, could be to insert ourselves
in the KeLoaderBlock->LoadOrderListHead boot modules list, or in the
KeLoaderBlock->BootDriverListHead boot-driver list. (Note that while
we may be able to do this, because boot-drivers are resident in memory,
much like we are, we cannot insert ourselves in the system-driver list
however, since those drivers are expected to come from PE image files.)
Once the KdpDriverEntry() driver entrypoint is called, we register
KdpDriverReinit() for re-initialization with the I/O Manager, in order
to provide more initialization points. KdpDriverReinit() calls the KD
providers at BootPhase >= 2, and schedules further reinitializations
(at most 3 more) if any of the providers request so.
2023-01-09 18:35:18 +00:00
|
|
|
NTSTATUS InitStatus;
|
[NTOS:KD/KD64/KDBG] Share some code between our legacy KD/KDBG and KD64.
Our legacy KD module is slowly being phased out for the more recent KD64
Kernel Debugger that supports WinDbg, but at the same time we must retain
support for GCC debugging and the KDBG interface.
For the time being few #ifdef _WINKD_ have been introduced in KD64 so that
some of its code/data does not completely get shared yet with the legacy KD,
until the latter becomes phased out.
KD Modifications:
=================
- Remove the implementation of NtQueryDebugFilterState() /
NtSetDebugFilterState() that now comes entirely from KD64.
- Remove KD variables that are now shared with KD64.
- Share common code with KD64: KdpMoveMemory(), KdpZeroMemory(),
KdpCopyMemoryChunks(), KdpPrint(), KdpPrompt().
- KDBG: Remove the duplicated KdpCopyMemoryChunks() function.
- In KdpServiceDispatcher() and KdpEnterDebuggerException(), call the
KdpPrint() worker function that correctly probes and captures its arguments.
- Temporarily stub out KdEnterDebugger() and KdExitDebugger() that is used
by the shared code, until KD is removed and only the KD64 version of these
functions remain.
- Re-implement the KD/KDBG KdpPrompt() function using a custom KdpPromptString()
helper compatible with KD64, that is called by the KD64 implementation of
KdpPrompt(). This KdpPromptString() helper now issues the prompt on all
the KD loggers: e.g. if you use both at the same time COM-port and SCREEN
debugging, the prompt will appear on both. Before that the prompt was always
being displayed on COM port even if e.g. a SCREEN-only debug session was used...
- ppc_irq.c: Fix the prototype of KdpServiceDispatcher().
KD64 Fixes:
===========
- Initialize the MaximumLength member of the counted STRING variables
before using them elsewhere.
- Get rid of alloca() within SEH block in KdpPrint() (addendum to 7b95fcf9).
- Add the ROS-specific handy dump commands in KdSystemDebugControl().
2019-11-17 21:55:36 +00:00
|
|
|
} KD_DISPATCH_TABLE, *PKD_DISPATCH_TABLE;
|
2005-04-25 14:44:48 +00:00
|
|
|
|
|
|
|
|
/* The current Debugging Mode */
|
|
|
|
|
extern KDP_DEBUG_MODE KdpDebugMode;
|
|
|
|
|
|
|
|
|
|
/* Port Information for the Serial Native Mode */
|
2013-05-07 00:14:36 +00:00
|
|
|
extern ULONG SerialPortNumber;
|
|
|
|
|
extern CPPORT SerialPortInfo;
|
2005-04-25 14:44:48 +00:00
|
|
|
|
|
|
|
|
/* Init Functions for Native Providers */
|
|
|
|
|
extern PKDP_INIT_ROUTINE InitRoutines[KdMax];
|
|
|
|
|
|
|
|
|
|
/* Dispatch Tables for Native Providers */
|
|
|
|
|
extern KD_DISPATCH_TABLE DispatchTable[KdMax];
|
|
|
|
|
|
|
|
|
|
/* The KD Native Provider List */
|
|
|
|
|
extern LIST_ENTRY KdProviders;
|
2002-07-18 00:25:31 +00:00
|
|
|
|
2022-11-18 16:44:29 +00:00
|
|
|
#endif // _NTOSKRNL_
|
2011-02-19 21:50:11 +00:00
|
|
|
|
2015-08-28 14:01:58 +00:00
|
|
|
#if DBG && defined(_M_IX86) && !defined(_WINKD_) // See ke/i386/traphdlr.c
|
2011-02-19 21:50:11 +00:00
|
|
|
#define ID_Win32PreServiceHook 'WSH0'
|
|
|
|
|
#define ID_Win32PostServiceHook 'WSH1'
|
|
|
|
|
typedef void (NTAPI *PKDBG_PRESERVICEHOOK)(ULONG, PULONG_PTR);
|
|
|
|
|
typedef ULONG_PTR (NTAPI *PKDBG_POSTSERVICEHOOK)(ULONG, ULONG_PTR);
|
|
|
|
|
extern PKDBG_PRESERVICEHOOK KeWin32PreServiceHook;
|
|
|
|
|
extern PKDBG_POSTSERVICEHOOK KeWin32PostServiceHook;
|
|
|
|
|
#endif
|