Purge data section object before creating an image mapping
Zero-out the tail of the page after reading from file
Properly map page as read-only when paging-in a COW memory map.
Previously, when creating a file section, Mm requested Cc to cache the file, then Cc would request pages from Mm, then Mm would request them back to serve its file-mapping role
Now, Mm does it all by itself. If file cahcing is requested by the FS driver, then Cc creates a file mapping and uses that to serve its purpose.
This is a rewrite of Cc
- 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
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.
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.
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.
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().)
This allows setting the memory protection of the kernel's resource
section as will. MmMakeKernelResourceSectionWritable() is re-implemented
around this helper.
- 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
"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.
* 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
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.
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.
The size is in bytes, not in pages! On x86 we got away with it, since PEB and TEB require only a single page and the 1 passed to MiInsertVadEx() was aligned up to PAGE_SIZE. On x64 this doesn't work, since the size is 2 pages.
Doing this is not only wrong because it acquires the same spinlock twice,
it also completely breaks the TLB flushing logic in MiMapPageInHyperSpace.
If the PTE with Offset 1 is still valid when a wrap-around to 0 happens,
the TLB flush on wrap-around will not clear the entry for this previous page.
After another loop around all hyperspace pages, page 1 is re-used but its
TLB entry has not been flushed, which may result into incorrect translation.
This means that MmSystemCacheStart, MmSystemCacheEnd, MmSizeOfSystemCacheInPages
have now a valid value.
System cache is not used atm the moment though. MmMapViewInSystemCache() is to
be implemented, and Cc is to be made aware of this.
CORE-14259
- Change MM_SYSTEM_SPACE_START to 0xFFFFF88000000000
- Move MI_DEBUG_MAPPING to the end of the system PTE range
- Add MI_SYSTEM_CACHE_START and MI_SYSTEM_CACHE_END, which is in the range that Vista uses as dynamic VA space for cache and other allocations
- Wrap x86 specific code that makes now invalid assumptions about the address space layout in #ifdef _M_IX86
Experiment and MSDN tend to show that a dirty BCB is queued for lazy write.
This will do the job here!
Also, renamed CcRosMarkDirtyFile() which is more accurate, and added a new
function CcRosMarkDirtyVacb() which just takes a VACB as arg (expected locked)
and marks it dirty (using previous implementation). Make CcRosMarkDirtyFile()
use it.
CORE-14235
This removes the "modified page writer" thread in Mm that was regularly blindly
attempting to flush dirty pages to the disk.
Instead, this commit introduces a lazy writer that will monitor dirty pages count
and will flush them to disk when this count is above a threshold. The threshold is
computed on Cc init.
Compared to what was done previously, this lazy writer will only write down files
that are not marked as temporary.
The mechanisms involved in this lazy writer worker are well described in Windows
Internals 4th editions (constants are coming from it ;-)).
Also fixed a bad (and old!) bug in CcRosFlushDirtyPages() where target count could
be overflow and the function would spin forever while holding the VACBs lock. This is
mandatory as now lazy writer will call it with "random" values.
This also allows implementing CcWaitForCurrentLazyWriterActivity() :-).
Also renamed DirtyPageCount to its MS equivalent.
CORE-14235
Note: before we had a BOOLEAN parameter called StoreInstruction, but in reality it was not specifying whether the fault was from a store store instruction, but whether it was an access violation rather than a page-not-present fault. On x86 without PAE there are only 2 kinds of access violations: (1) Access of a kernel mode page from user mode, which is handled early and (2) access of a read-only (or COW) page with a writing instruction. Therefore we could get away with this, even though it relied on the wrong assumption that a fault, which was not a page-not-present-fault, was automatically a write access. This commit only changes one thing: we pass the full fault-code to MmAccessFault and handle the rest from there in exactly the same way as before. More changes are coming to make things clear.
[REACTOS] Misc 64 bit fixes
* [NTOS:MM] Allow MEM_DOS_LIM in NtMapViewOfSection on x64 as well
* [NTOS:MM] Implement x64 version of MmIsDisabledPage
* [HAL] Remove obsolete code
* [NTOS:KE] Fix amd64 version of KeContextToTrapFrame and KeTrapFrameToContext
* [XDK] Fix CONTEXT_XSTATE definition
* [PCNET] Convert physical address types from pointers to PHYSICAL_ADDRESS
Its purpose is to dump the non paged consumption, tag by tag,
to allow tracking potential faulting driver in case ReactOS starts lacking memory.
This will look like what !poolused outputs, even though it doesn't deal with paged pool.
Thanks to Thomas for his kind review and improvement suggestions.
CORE-14048
