MmLoadSystemImage has a PUNICODE_STRING NamePrefix parameter which is
currently unused in ReactOS. When the kernel loads the crash dump
storage stack drivers, the drivers will be loaded with MmLoadSystemImage
with a "dump_" or "hiber_" (for hibernation, which uses crash dump
stack too) prefix. This change adds in the prefix support, and is
supposed to push crash dump support forward.
CORE-376
- 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 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
* 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.
* 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.
