Force page-in pageable kernel modules code

[0vercl0k]

As an example, most of nt's section are pageable (also true for any other drivers) which means the memory manager can page out those sections of code. This leads to part of nt / or other drivers not being part of a full crash-dump for example:

kd> u 0xfffff8045e811ee8
nt!RtlMinimalBarrier:
fffff804`5e811ee8 ??              ???
                       ^ Memory access error in 'u 0xfffff8045e811ee8'

kd> ? 0xfffff8045e811ee8 - nt
Evaluate expression: 3579624 = 00000000`00369ee8

kd> !dh nt
[...]

SECTION HEADER #4
INITKDBG name
   18F3B virtual size
  351000 virtual address
   19000 size of raw data
  34F400 file pointer to raw data
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
68000020 flags
         Code
         Not Paged
         (no align specified)
         Execute Read

Idea would be to add a driver to the project that could do that job.

[0vercl0k]

After making a bunch of tests in fbl_kern, I initially thought accessing those pages from kernel-mode with a driver would page in the content of the section; it seems to work but for the INITKDBG section of ntos.. and I'm not too sure why. When the driver tries to access it, it bugchecks the system.

kd> !analyze -v
Connected to Windows 10 18362 x64 target at (Sat Feb 13 17:46:27.983 2021 (UTC - 8:00)), ptr64 TRUE
Loading Kernel Symbols
...............................................................
................................................................
...............................................
Loading User Symbols
...............
Loading unloaded module list
.......
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.  This cannot be protected by try-except.
Typically the address is just plain bad or it is pointing at freed memory.
Arguments:
Arg1: fffff8056eff4000, memory referenced.
Arg2: 0000000000000000, value 0 = read operation, 1 = write operation.
Arg3: fffffc861a4fec01, If non-zero, the instruction address which referenced the bad memory
	address.
Arg4: 0000000000000000, (reserved)

Debugging Details:
------------------

STACK_TEXT:  
fffffc86`1a4fe188 fffff805`6ef49642     : fffff805`6eff4000 00000000`00000003 fffffc86`1a4fe2f0 fffff805`6edc5be0 : nt!DbgBreakPointWithStatus
fffffc86`1a4fe190 fffff805`6ef48d32     : 00000000`00000003 fffffc86`1a4fe2f0 fffff805`6ee73f60 00000000`00000050 : nt!KiBugCheckDebugBreak+0x12
fffffc86`1a4fe1f0 fffff805`6ee5fa07     : fffffafd`7ebf5f80 fffff805`6ef73110 00000000`00000000 fffff805`6f106900 : nt!KeBugCheck2+0x952
fffffc86`1a4fe8f0 fffff805`6ee83161     : 00000000`00000050 fffff805`6eff4000 00000000`00000000 fffffc86`1a4fec01 : nt!KeBugCheckEx+0x107
fffffc86`1a4fe930 fffff805`6ed1daef     : ffffbf0a`744002c0 00000000`00000000 00000000`00000000 fffff805`6eff4000 : nt!MiSystemFault+0x1d3171
fffffc86`1a4fea30 fffff805`6eda8904     : fffffafd`7ebf5000 fffff805`6f106900 00000000`00000000 fffff805`6eff4000 : nt!MmAccessFault+0x34f
fffffc86`1a4febd0 fffff805`6ed3b6ac     : 00000000`00000001 fffffafc`02b77fa0 fffffc86`1a4fed40 fffffafd`7ebf57f8 : nt!MiFaultInProbeAddress+0xbc
fffffc86`1a4fec80 fffff805`6ed3abbe     : fffffc86`1a4fedf0 00000000`00000000 fffffc86`1a4fedf0 fffff805`6eff4000 : nt!MiLockPageLeafPageTable+0x15c
fffffc86`1a4fecf0 fffff805`6ed3aa49     : ffffbf0a`00000000 00000000`00000000 00000000`00000000 fffff805`6f60708b : nt!MiProbeAndLockPages+0x15e
fffffc86`1a4fee40 fffff805`6f624749     : ffffbf0a`74416f00 00000000`00000000 00000000`00000000 fffff80e`bfdf5428 : nt!MmProbeAndLockPages+0x29
fffffc86`1a4fee70 fffff80e`bfdf5453     : ffffbf0a`6dc25940 ffff9288`c7c02f90 00000000`00351000 00000000`00000740 : nt!VerifierMmProbeAndLockPages+0xb9
fffffc86`1a4feeb0 fffff80e`bfdf56e5     : fffff805`6eca3000 fffffc86`00000000 00000000`00000000 fffff805`6eca3000 : lockmem_drv!LckForcePagingIn+0x183 [C:\lockmem\src\lockmem-drv\lockmem-drv.c @ 302] 
fffffc86`1a4fef30 fffff80e`bfdf59d4     : ffffffff`80002f6c ffff9288`c7c02f80 00000000`00000000 ffff9288`c7c03000 : lockmem_drv!LckHandleEntry+0x255 [C:\lockmem\src\lockmem-drv\lockmem-drv.c @ 399] 
fffffc86`1a4ff030 fffff80e`bfdf51fd     : ffffffff`80002f6c fffff80e`bfdf5490 00000000`00000000 00020000`00000000 : lockmem_drv!LckWalkDirectoryEntries+0x284 [C:\lockmem\src\lockmem-drv\lockmem-drv.c @ 192] 
fffffc86`1a4ff0e0 fffff80e`bfdf50de     : 00000000`00000000 fffff805`6f296305 00000000`00000000 ffffd690`e519e95d : lockmem_drv!LckDoWork+0xed [C:\lockmem\src\lockmem-drv\lockmem-drv.c @ 467] 
fffffc86`1a4ff170 fffff805`6ecd4cc9     : ffffbf0a`73bc1060 ffffbf0a`6dc25940 00000000`00000000 00000000`00000001 : lockmem_drv!LckDispatchDeviceControl+0x5e [C:\lockmem\src\lockmem-drv\lockmem-drv.c @ 550] 
fffffc86`1a4ff1c0 fffff805`6f28e6c5     : fffffc86`1a4ff540 ffffbf0a`6dc25940 00000000`00000001 ffffbf0a`73c8c5b0 : nt!IofCallDriver+0x59
fffffc86`1a4ff200 fffff805`6f28e01a     : ffffbf0a`00000000 00000000`00000000 00000000`00000000 fffffc86`1a4ff540 : nt!IopSynchronousServiceTail+0x1a5
fffffc86`1a4ff2a0 fffff805`6f28da36     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x5ca
fffffc86`1a4ff3e0 fffff805`6ee71115     : 00000000`00000000 00000000`00000000 00000000`00000000 00007fff`24e62220 : nt!NtDeviceIoControlFile+0x56
fffffc86`1a4ff450 00007fff`252fc144     : 00007fff`222257b7 00000000`00000000 00003a9a`c698a670 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x25
00000098`c417f698 00007fff`222257b7     : 00000000`00000000 00003a9a`c698a670 00000000`00000000 00007fff`25289bc7 : ntdll!NtDeviceIoControlFile+0x14
00000098`c417f6a0 00007fff`23b763e0     : 00000000`00000000 cccccccc`00000000 00000000`00000000 00000000`00000000 : KERNELBASE!DeviceIoControl+0x67
00000098`c417f710 00007ff6`b969b82d     : 00000000`00000000 00000000`00000000 00000098`c417f7a0 00000000`00000000 : KERNEL32!DeviceIoControlImplementation+0x80
00000098`c417f760 00000000`00000000     : 00000000`00000000 00000098`c417f7a0 00000000`00000000 00000000`00000000 : lockmem!main+0x4cd [C:\lockmem\src\lockmem\lockmem.cc @ 242] 

FAULTING_SOURCE_CODE:  
   298: 
   299:         try
   300:         {
   301:             MmProbeAndLockPages(Mdl, KernelMode, IoReadAccess);
>  302:         }
   303:         except(EXCEPTION_EXECUTE_HANDLER)
   304:         {
   305:             //
   306:             // If MmProbeAndLockPages, it means the pages are locked already, so skip over those.
   307:             //


kd> .frame 0n11;dv /t /v
0b fffffc86`1a4feeb0 fffff80e`bfdf56e5     lockmem_drv!LckForcePagingIn+0x183 [C:\lockmem\src\lockmem-drv\lockmem-drv.c @ 302] 
fffffc86`1a4feef0 struct _IMAGE_SECTION_HEADER * Section = 0xfffff805`6eca3288
kd> db 0xfffff8056eca3288
fffff805`6eca3288  49 4e 49 54 4b 44 42 47-3b 8f 01 00 00 10 35 00  INITKDBG;.....5.

I've noticed that this section is sometimes included in some of my crash-dump, but sometimes it isn't. So there's definitely some mystery here that I need to figure out..

Also, I noticed in the previous message that the section is supposedly not to be paged according to the bit in the section header of the PE (Not Paged) which is even more strange.

[0vercl0k]

So I confirmed that this is the only section with this behavior on my system, so special-casing seems to work. Now I still need to figure out if wrapping sections in MDLs achieves what I really want... the documentation seems to imply that it doesn't but not quite sure.