* 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.
This version (after .rsrc) works different than the
proper version I used for 0.4.12 (after .reloc).
Inserting after .rsrc is actually not correct, but Thomas believes it can
be used as a temporary trick to avoid random memory corruption upon
relocations of the kernel, caused by ROSBE-154.
I follow his advice, although when judging from practical tests only:
as long as we limit this script to NTOSKRNL like I do for releases
there have no negative consequences been observed in real life yet
even with the proper version of 0.4.12.
Up to now those problems have only been observed when used for drivers
MODULE TYPE sdk/cmake/gcc.cmake as well, like
it was tried for a moment in master 0.4.13-dev-609-g
c4d8e2a6e9
Using for drivers immediately did lead to BSODs like CORE-16183 and therefore was
mitigated in master by total disabling of the scripts for both,
kernel and drivers in
0.4.13-dev-621-g
36e9a6f8dd
To allow installing DVDWritenow without BSOD,
we need the script at least for ntoskrnl!
I committed this patch (after .rsrc) already into 0.4.13RC and 0.4.14RC.
- Add boot video color constants
- Refactor palette initialization
- Move some common stuff in right place
- Get rid of some magic constants and hardcoded values
- Get rid of TopDelta variable (calculated at compile time)
- Update SAL annotations
Addendum to 5f2ca473. CORE-16216 CORE-16219
According to PC-9801 Bible p. 50, divisor for PIT will become unsupported in some cases after having removed the fractional part. Replace 19200 value with 9600 which is supported by both 10 MHz and 8 MHz machines.
Remove RTC switch from configure.cmd, now MSVC runtime checks are
supposed to be enabled/disabled via CMake define (-DRUNTIME_CHECKS=1)
Prepare for adding more dynamic analysis options
If a thread calls MiInsertPageInFreeList after the zero page thread has
woken up from its wait but before it acquired the PFN lock,
MmZeroingPageEvent might get set again even though there is no additional
work to be done.
By setting MmZeroingPageThreadActive together with the event, the variable
correctly indicates for future callers that the zero thread will process
newly added free pages.
This partially reverts r72990.
This means we now correctly handle the DO_POWER_PAGABLE flag.
In particular, Windows's usbhub.sys calls KeDelayExecutionThread from a
power IRP dispatch routine. We now handle this correctly.
Useful functions for debugging IO and PNP managers:
PipDumpDeviceNodes() - displays information about a node(s) in the device tree;
PipDumpResourceRequirementsList() - displays information about a Io List;
PipDumpCmResourceList() - displays information about a Cm List
The tree list of devices (DEVICE_NODE structures) is perhaps the main one in the PnP manager. They also store information about the hardware resources required and assigned to devices.
These functions can help with debugging. For example, you can call PipDumpDeviceNodes() before and after device enumeration and compare the resulting information.
For PipDumpDeviceNodes() it is possible to optionally output:
- allocated resources and boot configuration resources
- resources required
- translated resources
It is possible to displays both a single node and the entire tree.
Optionally, you can display child nodes.
The information output format for resource lists is maximally compressed, since often the only debugging port is a monitor.
The DebugLevel parameter allows dumping in two modes:
0 - unconditional;
1 - if NDEBUG is not defined in "debug.c".
The SYSTEM_PD_SIZE constant should not be used to determine the page boundary for page tables. It is better to use the portable MiIsPteOnPdeBoundary() macro for this.
which implements the required functionality.
ntdll and ntoskrnl now have a wrapper for this, with SEH.
This protects the function against malformed / bad images,
whilst still being able to use the code in freeldr et al.
Idea from Thomas.
CORE-14857
- Improve the device action worker to support more than just a single action
- Move the action queue code from IoInvalidateDeviceRelations to a new function IopQueueDeviceAction.
Probe the data before allocating a copy buffer. Otherwise NtSetValueKey returns an unexpected status code in case of too large data size.
This fixes the NtSetValueKey ntdll api tests.
The initializer for WmipGuidObjectType does not set UseDefaultObject,
and it's possible for user mode to obtain a handle to a GUID object
with SYNCHRONIZE access. Therefore that handle can be passed to
NtWaitForSingleObject, which means it must start with a DISPATCHER_HEADER.
The trap frame is in a random location on the stack, and setting Esp0 there
wastes significant amounts of space and may lead to unexpected stack overflows.
Also use a more descriptive expression for the V86 members of the KTRAP_FRAME.
Revert "[NTOS] On DBG builds, fill pool allocations with 0xCD and freed pool with 0xDD"
This reverts commit 24f240be8a.
Revert "[NTOS] Add compile time option to trace callers of pool allocations"
This reverts commit 8b20755040.
Revert "WIP"
This reverts commit 8cfd5c601f.
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().
- KD64: Update the list of supported Debug Filter Masks (KdComponentTable)
with the more up-to-date one from KDBG, that includes some components
that have been added in Vista+, but some of which we also use in ReactOS.
- NtQueryDebugFilterState(), NtSetDebugFilterState() and KdpPrint():
Add the Vista+ behaviour or falling back to the DEFAULT component ID
settings for unknown Components (compiled in only wheen NTDDI_VERSION >= NTDDI_VISTA).
+ Remove redundant comments and update these functions with SAL2 annotations.
- KDBG: Add extra documentation for the debug filter components list.
- CONFIG: Load all the supported Debug Filter Masks settings from the
registry.
- Introduce KdpScreenAcquire() / KdpScreenRelease() helpers that allow
to correctly acquire or release the screen when using INBV for
"Screen-Mode" debugging.
- Introduce KdpAcquireLock() / KdpReleaseLock() helpers so as to reduce
the copy-pasted code required when acquiring spin-locks in the KD debug
logger functions.
- Close the opened KdpLogFileHandle file in the KdpInitDebugLog() logger
in case we failed to create the logger writer thread.
Also use explicit kernel-mode handle when opening the log file.
- static-ify some local variables, remove few hardcoded values, and
minor formatting.
- Correctly define the INIT_FUNCTION's.
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>
This fixes a regression introduced in 5ab1cfc which
was causing Unix (BtrFS, ExtX, and so on) volumes not
to be assigned a drive letter assigned anymore. And
thus, they were no longer mounted and presented to the
users.
CORE-16499
- 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.
As documented in https://docs.microsoft.com/fr-fr/windows-hardware/drivers/ddi/wdm/nf-wdm-exallocatepoolwithtag
pool tag "characters" must be a value in the range 0x20 (space) to 0x7E (tilde),
which happen indeed to be the range of printable (non-extended) ASCII characters.
(The display problem was originally caught while attempting to display
the pool tag 0x3a306847 corresponding to 'Gh0:', a win32ss GDIOBJ pool tag
encoded with macro GDIOBJ_POOL_TAG().)
The major change with this rewrite is the support for the mount
manager. Fstub will now assume that most of the devices are PnP
and that they are already registered to the mount manager.
It will thus ask the mount manager to assign the drive letter.
Fstub will keep assigning drive letters non mission critical devices
such as CDs, floppies and other removable devices.
See MountMgr:QueryPoints API test that will now return mount points :-).
* [NTOS:INBV] Move typedefs to the only single file where they are used.
* [NTOS:INBV] Refactor code & resources
Remove garbage
* [NTOS:INBV] Reduce fade time and remove wait for animation.
They don't need to have a zeroed-out palette now that we can
automatically reset it from within the code.
Co-authored-by: Yaroslav Kibysh <yanet.prod@gmail.com>
This allows setting the memory protection of the kernel's resource
section as will. MmMakeKernelResourceSectionWritable() is re-implemented
around this helper.
This also makes it necessary to fix a bug in the previous code:
ZwEnumerateKey will not account for space for a null terminator, so to
ensure we have space, we must allocate the additional WCHAR, but not
include it in the buffer size passed to the function.
For MSVC, marking the section as discardable will do this automatically.
For GCC, we use a linker script that places it after the .reloc section
(which should be the last "real" section, check ld --verbose output for the
default linker script).
This fixes what seems to be a regression from r55835 (!).
This allows getting rid of the ?? hack in the kernel but this doesn't
allow enabling LUID device maps as ReactOS can no longer open a
session with them enabled. So, we must remain with device maps at
root
CORE-16114
- MiLocateKernelSections(): Fix the calculation of MiKernelResourceEndPte,
MmPoolCodeEnd and MmPteCodeEnd.
- MmMakeKernelResourceSectionWritable(): Fix PTE looping upper limit;
use MI_MAKE_HARDWARE_PTE_KERNEL to build the updated read-write PTE.
- Introduce the MmMakeKernelResourceSectionWritable() helper for
making the kernel resource memory section writable, and use it
in KeGetBugMessageText(). Indeed, this latter function patches
in place the bugcheck resource message to trim any trailing
newlines before displaying the message on screen.
See also https://github.com/osresearch/uxen/blob/83bad53/dm/introspection-win7.c#L286
that mentions it too.
This fixes bugcheck text display (e.g. the MANUALLY_INITIATED_CRASH one)
when using (at least) MSVC-built ReactOS, avoiding a Page-Fault
exception during the bugcheck.
- Cover KeGetBugMessageText() in SEH since we are accessing kernel
resources that could also be corrupted in bugcheck scenarii, and we
don't want to further bugcheck.
- Fix newline trimming loop.
- KiDoBugCheckCallbacks():
* Wrap the bugcheck CallbackRoutine call in SEH.
* Add a FIXME concerning the need of further memory validation of CurrentRecord.
- Add a FIXME concerning the need to run the bugcheck-reason callbacks
with the KbCallbackReserved1 reason, in KeBugCheckWithTf().
Mentioned in http://blog.ptsecurity.com/2012/06/customizing-blue-screen-of-death.html
- Un-hardcode the RPL_MASK value.
- s/KiUnexpectedInterrupt&Number/KiUnexpectedInterrupt&Vector/
- Use C-style comments in traphdlr.c as everywhere else in the file.
- Update the URLs for the MSDN "FPO" macro documentation.
- Windows requires 16 bytes of response data.
- Add the PLUGPLAY_CONTROL_USER_RESPONSE_DATA type.
- Usetup and Umpnpmgr must fail if NtPlugPlayControl(PlugPlayControlUserResponse) does not return STATUS_SUCCESS.
So that they handle LUID mappings and process device maps.
Get rid of the ObpParseSymbolicLinkToIoDeviceObject helper and introduce a
new helper ObpProcessDosDeviceSymbolicLink that will do the same things
but also handle name creation/deletion as well as device map handling.
All this is based on previous code (hence the same comments :-)).
What's left to do now is to add support for device maps in ObpLookupObjectName
It is now able to set the newly created device map to any
process and will default to current process if none is provided.
It also sets system device map if no process is specified.
It also deferences existing device map in the process if needed.
Finaly, it will make the directory object permanant.
- 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 could happen if BCB was marked dirty previously.
Marking VACB dirty on unpin could lead to a double write of
the VACB, even if clean.
Indeed, now that setting BCB dirty leads to marking VACB
dirty, the VACB can be flushed in between by the lazy-writer.
The BCB state is not reset on VACB flush, contrary to the VACB state.
Thus, on unpin even if the VACB was already flushed, we were
setting back the dirty state, leading the VACB to be flushed again.
This could bring a small performance downgrade. Though it remains
limited since this is mostly used for FS metadata.
Possibly it could lead to metadata corruption, but this is likely
less possible.
CORE-15954
- Add and initialize a global power capabilities variable.
- Return the global power capabilities via NtPowerInformation.SystemPowerCapabilities.
- Report the presence of power button, sleep button and lid.
It better captures the intent now in FsRtlIsNameInExpressionPrivate and
fixes a slight overallotion by 4 bytes in FsRtlIsDbcsInExpression.
While at it, use the ANSI_DOS_DOT macro in the Dbcs version.
CORE-15902
This allows querying volume information without issuing an IRP to the owner device.
The kernel is supposed to already have all the required information to return
to the caller.
Side effect: this allows querying volume information for devices not implementing
IRP_MJ_QUERY_VOLUME_INFORMATION such as null.sys
This fixes opening null device in Python.
Fix based on debugging by Maxim Smirnov in PR #1442
CORE-14551
"Release" builds should not BSoD on 'Freeing pool - invalid tag specified' case,
this is compatible with Windows behaviour.
Nothing changes otherwise concerning the "Debug" builds, where pool-tag mismatch
triggers a BSoD as expected.
CORE-15446
- Correctly probe the FileName user pointer before capturing its contents.
- A paging file name with zero length is invalid too.
- Remember (TODO!) in the code that the lower bounds of the Safe*Size values
need to be checked too!
* The previous version was overcomplicated and broken and therefore disabled.
* The new version also enforces NX protection on x64.
* Now that protecting works, also protect the boot loaded images.
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.
* [WIN32K] Fix handle calculation in DbgGdiHTIntegrityCheck
* [NOTEPAD] Fix MSVC warnings
* [PSDK] Simplify *PROC definitions in windef.h
* [VIDEOPRT] Don't try to use NtVdmControl on x64
* [FREELDR] Fix some macros
* [CRT] Make qsort 64 bit compatible
* [NTOS] Use #ifndef _WIN64 instead of #ifdef _M_IX86 around C_ASSERTs
* [FAST486] Fix 64 bit warnings and change DWORD to ULONG, so it can be used in kernel mode
* [APPHELP_APITEST] Fix 64 bit issue
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 ;-)
This may look strange, since this buffer is originally allocated using
the TAG_IO_NAME tag. However, it happens that file-system drivers are
allowed to re-allocate this buffer: this is what the MS' open-sourced
CDFS driver does, see e.g. CdCommonCreate() and CdNormalizeFileNames()
in cdfs/create.c .
This fixes a pool tag mismatch 'mNoI' != 'nFdC' BSOD when resources
are freed when closing a file that has been opened with a relative name
on a CDFS-mounted volume.
* Add an NDK header to define INIT_FUNCTION/INIT_SECTION globally
* Use _declspec(allocate(x)) and _declspec(code_seg(x)) on MSVC versions that support it
* Use INIT_FUNCTION on functions only and INIT_SECTION on data only (required by MSVC)
* Place INIT_FUNCTION before the return type (required by MSVC)
* Make sure declarations and implementations share the same modifiers (required by MSVC)
* Add a global linker option to suppress warnings about defined but unused INIT section
* Merge INIT section into .text in freeldr
For now, this is just a split between scan and flush that
were both done during lazy scan previously.
Lazy scan shouldn't perform any write operation, but only
queue a write behind operation.
Our implementation is far from the original, as it seems
our lazy scan should queue a write behind operation per
shared cache map. Right now, we only perform global
operation.
This will avoid corruption when a file size is little grown and read afterwards.
Up to now, FSD where reading 0es instead of expected data, causing corruption.
This fixes MS FastFAT not being able to mount a FAT volume in ReactOS, corrupting
the FAT.
This also fixes the CcSetFileSizes kmtest tests.
This is based on a patch by Thomas Faber.
CORE-11819
This incorrect behavior was leading to a call at too high IRQL for paged code.
This was triggered by MS FastFAT.
ReleaseFromLazyWrite call was already correctly called to that regard.
CORE-11819
Also, probe the service name when unloading a driver if called from
user-mode. This will avoid that userland applications can trigger an
invalid read in the kernel (and thus, a BSOD).
CORE-15468
- Require the user to have TCB privilege for using this function.
- Probe and capture the user-provided string (and avoid usermode-triggered BSODS ;-)
- Allocate the OEM-converted string in *NonPagedPool* because we are
going to transmit the buffer to BOOTVID.
This avoids performing a double-free (even though that's hidden by the
fact we use lookaside allocations for VACB), and it avoids freeing
a memory address at an uninitialized address.
We don't care about references here, the VACB was just allocated, never
linked and we're its only user.
CORE-15413
- Simplify the volume-deletion code in RawCheckForDismount().
- Fixes the OpenCount check in RawClose(): the VCB mutex must be
released when the volume has not been dismounted, either because
OpenCount != 0 or because RawCheckForDismount() returned FALSE.
- Explicitly use VCB_STATE_LOCKED instead of hardcoding its value.
- In IRP_MN_VERIFY_VOLUME handling, lock the volume before playing
with it, and again let the volume be dismounted only if OpenCount == 0
(and the IoDeleteDevice() call is done by RawCheckForDismount()).
Now, we make sure that we update ref count and BCB list membership
with the BCB lock held, in a row.
This will avoid race conditions where the BCB was removed from the
list, then referenced again, leading to inconsistencies in memory
and crashes later on.
This could notably be triggered while building ReactOS on ReactOS
(one would call this a regression).
CORE-15235
- Rework CmpSetSystemValues() and remove its 1st-stage text-mode setup hack, since a real registry hive will be used for 1st-stage either.
- Lock, then unlock the registry in NtInitializeRegistry when initializing the hives & flusher.
- Call CmpInitializeHiveList() (i.e., initialize the other hives like \Software, \User, \.Default) only when we are not in setup-mode.
svn path=/branches/setup_improvements/; revision=74747
This reverts a7c26408 (r53255) and ff75ae1b (r53694), and a hack from 6075ae9a (r46690).
svn path=/branches/setup_improvements/; revision=74745
svn path=/branches/setup_improvements/; revision=74746
- Improve the capture of OBJECT_ATTRIBUTES parameters that are passed
(by pointer) to the Cm* helper functions, and the capture of
UNICODE_STRINGs.
- Correctly differentiate user-mode vs. kernel-mode root directory handles
(in OBJECT_ATTRIBUTES): note that most of the Cm* APIs expect their
parameters to be kernel-mode (pointers, handles...).
CORE-13448
- Validate the information class parameter in NtQueryValueKey().
- Call the post-callback in NtSetValueKey() only if the callback
has been registered and the CmSetValueKey() call is executed.
We won't reuse a BCB created for mapping, we will now have
our own dedicated BCB.
This allows having a bit more cleaner implementation of CcPinMappedData()
We now handle race conditions when creating BCB to avoid
having duplicated BCB per shared maps.
Also, we already specify whether the memory will be pinned
when creating the BCB, to avoid potential duplications or
BCB misuse.
If so, return such BCB instead of creating a new one. This will
allow (at some point) to be more consistent in case of concurrent
mapping.
This fixes a few CcMapData tests.
Given current ReactOS implementation, a VACB can be pinned
several times, with different BCB. In next commits, a single
BCB will be able to be pinned several times. That would
lead to severe inconsistencies in counting and thus corruption.
This quick check based on bits and operation is for 2^ based
sector sizes (most of the cases) and will perform faster than
the modulo operation which is still used in fallback in case
the sector size wouldn't be a power of 2.
IopCloseFile can be called by IopDeleteFile. In that situation, it
doesn't set any process as first parameter. Furthermore, we are in a
situation where it's not required to lock the file object (see the
assert before the call).
- SeIsTokenChild(): Correctly check whether a caller-provided token
is a child from the current process' primary token by looking at
its ParentTokenId member.
- Add a SeIsTokenSibling() helper to determine whether a caller-provided
token and the current process' primary token are siblings, by comparing
their ParentTokenId's and AuthenticationId's.
NOTE: Children tokens are created through CreateRestrictedToken();
sibling tokens are created through DuplicateToken() (amongst others).
See slide 49 of https://www.slideshare.net/Shakacon/social-engineering-the-windows-kernel-by-james-forshaw
or https://googleprojectzero.blogspot.com/2016/01/raising-dead.html
for some details.
This could be triggered when attempting to read/write to really big
files. It was causing an attempt to read 0 bytes in Cc, leading to
asserts failure in the kernel (and corrupted file).
CORE-15067
Currently, our CcMapData() behavior (same goes for CcPinRead()) is broken
and is the total opposite of what Windows kernel does. By default, the later
will let you map a view in memory without even attempting to bring its
data in memory. On first access, there will be a fault and memory will
be read from the hardware and brought to memory. If you want to force read
on mapping/pinning, you have to set the MAP_NO_READ (or PIN_NO_READ) flag
where kernel will fault on your behalf (hence the need for MAP_WAIT/PIN_WAIT).
On ReactOS, by default, on mapping (and thus pinning), we will force a view
read so that data is in memory. The way our cache memory is managed at the
moment seems not to allow to fault on invalid access and if we don't force
read, the memory content will just be zeroed.
So trying to match Windows behavior, by default, now CcMapData() will enforce
the MAP_NO_READ flag and warn once about this behavior change.
It's based on the code that was in CcPinRead() implementation. This
made no sense to have CcPinMappedData() doing nothing while implementing
everything in CcPinRead(). Indeed, drivers (starting with MS drivers)
can map data first and pin it afterwards with CcPinMappedData(). It was
leading to incorrect behavior with our previous noop implementation.
Short: The code was suffering from an off-by-one bug (inconsistency between inclusive end exclusive end address), which could lead to freeing one page above the initialization code. This led to freeing part of the kernel import section on x64. Now it is consistently using the aligned/exclusive end address.
Long:
* Initialization sections are freed both for the boot loaded images as well as for drivers that are loaded later. Obviously the second mechanism needs to be able to run at any time, so it is not initialization code itself. For some reason someone decided though, it would be a smart idea to implement the code twice, once for the boot loaded images, once for drivers and concluding that the former was initialization code itself and had to be freed.
* Since freeing the code that frees the initialization sections, while it is doing that is not possible, it uses a "smart trick", initially skipping that range, returning its start and end to the caller and have the caller free it afterwards.
* The code was using the end address in an inconsistent way, partly aligning it to the start of the following section, sometimes pointing to the last byte that should be freed. The function that freed each chunk was assuming the latter (i.e. that the end was included in the range) and thus freed the page that contained the end address. The end address for the range that was returned to the caller was aligned to the start of the next section, and the caller used it to free the range including the following page. On x64 this was the start of the import section of ntoskrnl. How that worked on x86 I don't even want to know.
The PROCESS_DEVICEMAP_INFORMATION union has 2 fields, one is a handle, the other one is a structure of 36 bytes (independent of architecture). The handle forces 64 bit alignment on 64 bit builds, making the structure 4 bytes bigger than on 32 bit builds. The site is checked in NtQueryInformationProcess (case ProcessDeviceMap). The expected size on x64 is the size of the Query structure without alignment. autocheck correctly passes the site of the Query union member, while smss passes the full size of PROCESS_DEVICEMAP_INFORMATION. Packing the structure is not an option, since it is defined in public headers without packing. Using the original headers sizeof(PROCESS_DEVICEMAP_INFORMATION) is 0x28, sizeof(PROCESS_DEVICEMAP_INFORMATION::Query) is 0x24.
- Rename ObDirectoryType to ObpDirectoryObjectType and remove it from NDK (this is not exported!)
- Rename ObSymbolicLinkType to ObpSymbolicLinkObjectType
- Remove duplicated ObpTypeObjectType from ob.h
Kernel stacks that re freed, can be placed on an SLIST for quick reuse. The old code was using a member of the PFN of the last stack page as the SLIST_ENTRY. This relies on the following (non-portable) assumptions:
- A stack always has a PTE associated with it.
- This PTE has a PFN associated with it.
- The PFN has an empty field that can be re-used as an SLIST_ENTRY.
- The PFN has another field that points back to the PTE, which then can be used to get the stack base.
Specifically: On x64 the PFN field is not 16 bytes aligned, so it cannot be used as an SLIST_ENTRY. (In a "usermode kernel" the other assumptions are also invalid).
The new code does what Windows does (and which seems absolutely obvious to do): Place the SLIST_ENTRY directly on the stack.
It's hardly understandable and doesn't really makes sense.
Furthermore, it breaks compatibility with 3rd party FSD that
don't implement such FSCTL.
Obviously, Windows doesn't do this.
For user mode, when probing output buffer, if it's null, length
will also be set to 0.
This avoids user mode applications being able to trigger various
asserts in ReactOS (and thus BSOD when no debugger is plugged ;-)).
NDK: Define PLUGPLAY_CONTROL_PROPERTY_DATA.Properties and PLUGPLAY_CONTROL_DEVICE_RELATIONS_DATA.Relations values.
NTOSKRNL: Map PLUGPLAY_CONTROL_PROPERTY_DATA.Properties values to IoGetDeviceProperty properties and add (dummy) code for unsupported cases.
UMPNPMGR: Use PLUGPLAY_CONTROL_PROPERTY_DATA.Properties values in PNP_GetDeviceRegProp.