KeLowerIrql/KeRaiseIrqlToDpcLevel/KfRaiseIrql are defined as FORCEINLINE in ntoskrnl/ke/amd64/irql.c
Use KxLowerIrql/KxRaiseIrqlToDpcLevel/KxRaiseIrql instead, which call their respective Ke*/Kf* counterparts.
During the boot process, it makes possible to initalize the driver's
devices right after the driver is loaded. Moreover, this way one can be
sure that all critical devices are initialized before the
IopMarkBootPartition call (because we explicitly call the driver's
AddDevice routine now, after each driver is loaded)
CORE-7826
- Use DeviceNode->State field and its values, instead of
DeviceNode->Flags for tracking current node state
- Change DNF_* flags to the ones compatible with Windows XP+
- Simplify state changes for device nodes and encapsulate all the logic
inside the PiDevNodeStateMachine routine. This makes the ground for
future improvements in the device removal sequence and
resource management
- Now values inside DeviceNode->State and ->Flags are compatible with
the windbg !devnode macro and can be tracked using it
- BUGFIX: fixed cases where IRP_MN_START_DEVICE or
IRP_MN_QUERY_DEVICE_RELATIONS may be sent to a device after a
IRP_MN_REMOVE_DEVICE
CORE-7826
Add another PnPBootDriversInitialized variable to indicate a point where
both disk subsystem and SystemRoot symlink are initialized, and use it
in a PiCallDriverAddDevice call.
- Move the driver's name obtaining logic into the IopGetDriverNames
function
- Create a new PiCallDriverAddDevice instead of PipCallDriverAddDevice
and move it to pnpmgr/devaction.c file. Move around all its internal
helpers too
- Support a proper Windows-compatible driver loading order for a PDO
(lower filters, main service, upper filters, etc.)
- Set a correct Problem for the DeviceNode, in case of an error during
driver loading
- Check the Start Type for all drivers before loading
- Do not try to load drivers during the early boot stage when there is
no disk subsystem initialized
- Do not hold the IopDriverLoadResource while trying to reference a
driver object (but still acquire it when we actually need to load a
driver)
- Change IopLoadDriver and IopInitializeDriverModule to use registry
handle instead of a service name string and/or full registry path
- Do not try to reference a driver object inside IopLoadDriver. It's
supposed to be done before the function call
- Split IopLoadUnloadDriver into IopLoadDriver and calling DriverUnload
- Schedule the worker for (un)loading driver in a separate routine
(IopDoLoadUnloadDriver) this allows IopLoadDriver to be called
separately (if we are sure that we're in the system process)
- Remove IopCreateDriver and put its code into IoCreateDriver and
IopInitializeDriverModule. It's hard to extract a meaningful common
part from it
- Refactor IopInitializeDriverModule. Extend and put the DriverName
generation logic into it. Now this function frees the ModuleObject in
case of failure and returns STATUS_FAILED_DRIVER_ENTRY in case of
DriverInit failure (will be used later)
If the CPU does support CPUID instruction but does not have the Brand String,
the legacy name detection should be performed either in CIM_Processor (WMI),
in the Processor device driver, or in the application itself.
The deleted Intel CPU name detection code can go to the WMI at some point.
In fact Windows XP and 2003 kernels do not have any strings of that kind.
This effectively reverts the hack committed 6 years ago in 7a985425 (r63798)
that was intended to workaround CORE-7952.
CORE-17413
- Fix behaviour when adding or removing entries in the middle of an existing run
- Do not touch output parameters when failing, caller might rely on this.
- Convert PARTITION_TABLE_OFFSET to the number of bytes instead of
(number of bytes) / 2. This avoids many confusing casts
- Use a cache aligned buffer for MBR
- BUGFIX: do not call IoGetRelatedTargetDevice while guarded mutex is acquired
(the function issues an APC, but they are disabled inside a critical section)
- BUGFIX: only the beginning of a structure for GUID_PNP_CUSTOM_NOTIFICATION was copied and queued.
Just pass it as-is to a subscriber, without copying
- Don't convert event GUID to string, store and compare GUID struct itself
- Split IopNotifyPlugPlayNotification into 3 functions for each type of notification
(less stack usage and for future changes)
- Move initialization code for notifications into a separate routine
- Use separate lists and locks for every type of notification
- Put "TargetDeviceChange" notifications into their place inside DEVICE_NODE
CmResourceTypeDevicePrivate resources are created the the bus driver, for its own later use,
when children devices will receive the IRP_MN_START_DEVICE.
Do not translate them, as they have no meaning outside bus driver.
- Change INIT_FUNCTION and INIT_SECTION to CODE_SEG("INIT") and DATA_SEG("INIT") respectively
- Remove INIT_FUNCTION from function prototypes
- Remove alloc_text pragma calls as they are not needed anymore
This is required since the NX protection proagates from the highest level, enforcing NX on the entire range, independent of whether lower level P*Es have the bit set or not. It might be useful to add a platform specific constant to allow making page tables NX on architectures that have a different behavior.
* Move MiBuildPfnDatabaseFromPageTables into MiBuildPfnDatabase
* Make sure to call MmInitializeProcessAddressSpace() from the x64 version of MiInitMachineDependent()
* Handle result of MmInitializeProcessAddressSpace in MiInitMachineDependent (Should do the same for x86)
* Remove obsolete x64 debug print
- Deliver pending APCs on trap exit
- Pass the trapframe of KiApcInterrupt to KiDeliverApcs, not NULL.
- Fix parameter passing from KiSwapContext to KiSwapContextInternal and KiSwapContextResume, so that the ApcBypass parameter is not uninitialized
- Fix return value of KiSwapContextResume to correctly indicate whether we want to have APCs directly delivered or not (when there are non, or when delivery is suppressed)
The previous version (like the x86 one) used a combination of C and asm code, called from C code to switch the stack. This is problematic, since there is no guarantee what assumptions C code makes about the stack (i.e. it can place any kind of stack pointers into registers or on the stack itself.) The new algorithm returns back to the systemcall entry point in asm, which then calls KiConvertToGuiThread, which is also asm and calls KeSwitchKernelStack ...
To be 100% correct and not rely on assumptions, stack switching can only be done when all previous code - starting with the syscall entry point - is pure asm code, since we can't rely on the C compiler to not use stack addresses in a way that is not transparent. Therefore the new code uses the same mechanism as for normal system calls, returning the address of the asm function KiConvertToGuiThread, which is then called like an Nt* function would be called normally. KiConvertToGuiThread then allocated a new stack, switches to it (which is now fine, since all the code is asm), frees the old stack, calls PsConvertToGuiThread (which now will not try to allocate another stack, since we already have one) and then jumps into the middle of KiSystemCallEntry64, where the system call is handled again.
Also simplify KiSystemCallEntry64 a bit by copying the first parameters into the trap frame, avoiding to allocate additional stack space for the call to KiSystemCallHandler, which now overlaps with the space that is allocated for the Nt* function.
Finally fix the locations where r10 and r11 are stored, which is TrapFrame->Rcx and TrapFrame->EFlags, based on the situation in user mode.
CORE-14037
- Fix buggy retrieval of the current calling Irp->Tail.Overlay.Thread.
- The 4th argument (KernelRoutine) to the KeInitializeApc() is **NOT**
optional; however its 5th argument (RundownRoutine) is.
So use the mandatory routine for freeing the allocated APC instead.
We don't use the rundown routine yet.
- Check whether the ExAllocatePoolWithTag() call failed or not before
queueing the allocated APC.
The current implementation of device tree enumeration does not distinguish
between possible identifier strings. This change is not a hack,
NT 5.2 still creates a new device node for this hardware ID.
The entire function should be rewritten to match Windows implementation.
