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.
We are doing IoCallDriver here, so the valid stack location should be
CurrentLocation <= Irp->StackCount (just a check for a completly incorrect value)
&& CurrentLocation > 1 (ensure that we have a place for another call)
CORE-17189
Co-authored-by: Thomas Faber <thomas.faber@reactos.org>
RtlGetNtProductType comes into two variants: one in user-mode that is exported for use from NTDLL layer and the kernel-mode that is used exclusively by the NT kernel. The kernel-mode variant of the function is not exported.
- Some "PartitionInfo->PartitionNumber = 0;" are ROS-specific hacks for
xHalIoAssignDriveLetters(), that should be fixed... Mark them as such.
- Un-hardcode some "magic" values (partition IDs, max number of
partition table entries, etc.).
- Use NULL instead of '0' for null-pointers.
- Fix some typos in comments.
Introduce the PiPerformSyncDeviceAction routine for queuing
synchronous device actions
Change all kernel code to use PiPerformSyncDeviceAction and
PiQueueDeviceAction for device enumeration
CORE-10456
Use single IOCTL (IOCTL_DISK_GET_DRIVE_GEOMETRY_EX) for retrieving
disk basic geometry information along with disk size.
Previous implementation used to issue two requests for that.
And rearrange them in more logical order.
This effectively splits the file, leaving public "Io" functions in
pnpmgr.c along with some things not related do device object management.
Functions which manipulate the device tree are left in devaction.c.
In future all these functions will only be accessed from
DeviceActionWorker.
While being public API, IoRequestDeviceEject and IoInvalidateDeviceState
have been moved to devaction.c as well. In next commits they will be
converted to DeviceActionWorker routines and their callers will be put
in pnpmgr.c
If SEH is used in a C trap handler, the exception frame will be
registered before the call to KiEnterTrap, which means we save
the wrong trap handler. We'll therefore also restore this wrong
frame for the excepting code, resulting in a stale SEH chain.
We avoid this problem by saving the handler in the assembly
trap entry code instead of from C. While SEH in a C trap handler
should now theoretically be safe, we still forbid it through
asserts in the C KiEnterTrap variants to make any potential
future problems more obvious. Should this functionality be
needed at some point and deemed safe, these asserts can then be
removed.
- Sync some INIT_FUNCTION with how they are used and what is already
specified in the headers.
Addendum to commit 85e5b5be (r49445).
- KdbpGetCommandLineSettings(): Remove INIT_FUNCTION.
Fix MSVC 2015 x86 custom build:
"...\ntoskrnl\kdbg\kdb.c(1699): error C2983: 'KdbpGetCommandLineSettings': all declarations must have an identical __declspec(code_seg(...))"
And may also fix obscure bugs when entering into the KDBG debugger.
