x64 Kernel memory Space structure

0x00 Preface

This article mainly discusses the structure of the kernel virtual address space under Windows 7 x64, and can take advantage of the wiindbg Debug extension command "! Cmkd.kvas "to show the overall layout of the kernel virtual address space under x64. Understanding the address layout of the kernel is a good idea in some cases, such as when researching the source and virtualization of new Blue pill.

0X01 Basic Structure

The X64 CPU has a 64-bit address, but it actually supports only 48-bit virtual address space for software use. The high 16 bits of the virtual address are always set to 0000 in user mode, and all are FFFF in kernel mode.

Therefore, the user mode address space range is 0X00000000~00000000--0X0000FFFF~FFFFFFFF, the kernel mode address space range is 0xffff0000~00000000--0xffffffff~ffffffff, So the size of the kernel virtual address space visible to the operating system is 256TB. The Windows operating system divides the entire kernel address space into several fixed-size virtual address spaces with a specific purpose. The following table is about the specific partitioning of Windows for virtual address space:

Start Address	End Address	Memory size	Use
FFFF0800 ' 00000000	fffff67f ' FFFFFFFF	238TB	Not used
FFFFF680 ' 00000000	Fffff6ff ' FFFFFFFF	512GB	Pte Memory Space
FFFFF700 ' 00000000	fffff77f ' FFFFFFFF	512GB	Hyper Memory Space
FFFFF780 ' 00000000	FFFFF780 ' 00000FFF	4KB	System Shared Space
FFFFF780 ' 00001000	Fffff7ff ' FFFFFFFF	512gb-4k	System Cache Working Set
FFFFF800 ' 00000000	fffff87f ' FFFFFFFF	512GB	Initialize map area
FFFFF880 ' 00000000	fffff89f ' FFFFFFFF	128GB	System PTE Zone
Fffff8a0 ' 00000000	FFFFF8BF ' FFFFFFFF	128GB	Paged pool area
FFFFF900 ' 00000000	fffff97f ' FFFFFFFF	512GB	Session Space
FFFFF980 ' 00000000	FFFFFa70 ' FFFFFFFF	1TB	Kernel Dynamic virtual space
FFFFFa80 ' 00000000	*nt! MmNonPagedPoolStart-1	6TB Max	PFN data
*nt! Mmnonpagedpoolstart	*nt! Mmnonpagedpoolend	512GB Max	No paged memory pool
FFFFFFFF ' FFc00000	FFFFFFFF ' FFFFFFFF	4MB	Hal and Loader mapping area

The Windows operating system uses a number of specific data structures, such as push Locks,ex Fast referenced pointers and interlocked slists, Operations on these data structures require the CPU to perform two atomic operations on the number of the same virtual address. Therefore, although the virtual address of the 64-bit processor is 64 bits, it must have a 128-bit long cmpxchg instruction. However, there is no such instruction in the earlier 64-bit processors, which can cause failures when using the above data structures. The 64-bit CPU has limited the virtual address valid bit to 48 bits, while the Windows operating system further restricts the virtual address effective bit to 44 bits, the virtual address space that can actually be used to store the above data structure is 2^44, that is, the 64-bit virtual address space of high 8TB space, That's 0xfffff80000000000-0xffffffffffffffff. For example, previous "unused space", "Pte Memory Space", "Hyper memory Space" and "system cache working set" all exceeded the 44-bit virtual address limit and could not store these specific data structures. These restrictions will also affect user space, the user space available virtual memory size limit to 8TB, that is, 0x00000000 ' 00000000-0x000007ff ' FFFFFFFF, kernel space available virtual virtual memory size is 8TB, that is 0xfffff000 ' 00000000-0xffffffff ' FFFFFFFF. One point to note is that the virtual memory that is not in the range of FFFF0800 ' 00000000-fffff7ff ' ffffffff is used by the Windows operating system and does not always allocate and save the specific data structures described above.

The 64-bit processor physical page size is 4kb,cpu using PTEs (page table entry) to complete the mapping from the virtual address to the physical address, so each PTE maps a 4K size physical page. The PTEs under the 64-bit processor account for 64 bits, which is 8 bytes in order to be compatible with the larger physical address and PFNS (page frame number, which is the pager). Therefore, the physical page of a single page table can hold 512 PTEs, and all PTEs can map virtual addresses of 2MB (512*4KB). Similarly, because PDEs (page directory Entries, pages catalog entry) points to the physical page of a page table, a single PDE can map a 2MB virtual address space.

0x02 Core Virtual Space composition

The following describes the specific components of the kernel address space and their role.

Unused (Unused System Space)

by nt! Mmsystemrangestart started, this section is not used under Windows 7 X64

Pte Spaces (Pte space)

This section contains a Level 4 page table of virtual address mappings for user space and kernel space under x64. The mapping scope for different page table pages under X64 is as follows:

PTE Pages FFFFF680 ' 00000000

PDE Pages FFFFF6FB ' 40000000

PPE Pages FFFFF6FB ' 7da00000

PXE Pages FFFFF6FB ' 7dbed000

Hyper Space (hyperspace)

The working set of the mapping process. Addresses contained in the EPROCESS.Vm.VmWorkingSetList of each process

0xfffff700 ' 01080000 will map to this space. This space includes the MMWSL (Memory Manager working set list) structure and the array structure of the Mmwsle (Memory Manager Working set list Entry), including each physical page of the process working set.

It is important to note that although the function mimappageinhyperspaceworker () supports mapping the physical page to the virtual address of the hyper space, it actually maps the physical page to the PTE space instead of the real hyper space.

Share Systems page (shared system pages)

The 4 K-size pages are shared by user space and kernel space, and are primarily used to convey information quickly before the user layer and kernel layer, and the data structure that is shared is nt!_kuser_shared_data.

System cache Working set (systems cache working set)

The working set (working set) that contains the virtual address of the system cache, and the Working Set list entry (Working set lists Entries).

Kernel variable nt! Mmsystemcachews a data structure (that is, nt!_mmsupport) that points to the system cache working set. You can use the WinDbg command to display the working Set linked list entry for the system cache

"!wsle 1 @@ (((Nt!_mmsupport *) @@ (nt! mmsystemcachews))->vmworkingsetlist) ". These items are used to trim the physical pages of the virtual memory (trim) system cache.

Initialize load map area (Initial Loader Mappings)

Both the Ntoskrnl,hal and the kernel debug DLLs (KDCOM,KD1394,KDUSB) are loaded into this area. In addition, this space contains the thread stacks of the idle thread, the stack of DPC, the KPCR and the data structure of the idle thread.

Paged pool area (Paged)

The end address of the paged pool is saved in the variable nt! The Mmpagedpoolend. The size of the paged pool is saved in the variable nt! Mmsizeofpagedpoolinbytes. When Mivapagepool () is called, the MIOBTAINSYSTEMVA () function allocates memory from this area, and the memory allocation method of the paged pool is determined by the variable nt! The Mipagedpoolvabitmap is determined by the bitwise (BIT).

PFN databases (PFN database)

For each physical page of the system there is a corresponding entry in PFN (nt! mmhighestpossiblephysicalpage+1). You can enter commands in WinDbg '? Poi (nt! Mmnonpagedpoolstart)-POI (nt! mmpfndatabase) ' To get the size of the ' PFN Database '. You can also use the command

‘? (Poi (nt! Mmnonpagedpoolstart)-POI (nt! Mmpfndatabase)/@@ (sizeof (NT!_MMPFN)) to get the total number of items in the PFN. And the starting address for this area is saved in nt!. The mmpfndatabase.

Non-paged memory pool (non-paged pool)

The area of the non-paged memory pool is directly behind the PFN database. The starting address of the non-paged memory pool is saved in nt! The Mmnonpagedpoolstart. When Mivanonpagedpool () is called, MIOBTAINSYSTEMVA () allocates memory in this area. How memory is allocated is determined by the variable nt! The minonpagepoolvabitmap is determined by position.

Hardware abstraction layer and load map area (HAL and Loader Mappings)

Kernel global variable nt! The Milowhalva contains the starting address of this area, the 0xffffffffffc00000. The end address matches the end address of the X64 kernel virtual address space at 0xFFFFFFFFFFFFFFFF. This area is used only when the system starts, that is, in the Mminitsystem () function, the memory in this area can no longer be used after the initialization of the boot is complete.

The function miaddhaliomappings () is called at the end of the system initialization function Mminitsystem () to scan the virtual address space to determine if there is an I/O mapping to this space, and if so, the function Miinsertiospacemap () will be called. Added to the I/O queue maintained by the system. For each I/O mapping area, Miinsertiospacemap () creates a tracker item with the pool label "Io Space Mapping Trackers" and joins it to the head nt! In a doubly linked list of Mmioheader, where each item represents a virtual memory block that has mapped the physical address, some fields in the tracker item also contain information about the physical memory and virtual address mappings.

 
struct _IO_SPACE_MAPPING_TRACKER {
    LIST_ENTRY Link;
    PHYSICAL_ADDRESS  Pfn;
    ULONGLONG  Pages;
    PVOID Va;
    . . . 
}

Session Space

With regard to the data structure of the session, both the session pool and the conversation image are loaded into this area.

Session images include drive images such as Win32k.sys (Windows Manager), CDD.dll (Canonical display Driver), TSDDD.dll (Frame Buffer display Driver), Dxg.sys (DirectX Graphics Driver) and so on.

For any process, the mm_session_space that its eprocess->session points to is the session structure to which it belongs, and the session pool is scoped by Mm_session_space->pagespoolstart and Mm_ Session_space->pagespoolend specified.

System PTEs (Sys PTEs)

This area includes the mapped view,mdl,adapter memory, the driver's image, and the kernel stack. When Mivasystemptes () is used, the function miobtainsystemva () is called to allocate memory in this area.

Kernel dynamic virtual space (Kernel VA space)

This area consists of the system cache view, a specific paged memory pool, and a specific nonpaged memory pool. Nt! Misystemavailableva saves the number of 2MB zones available for dynamic kernel virtual space.

When the argument to call Miobtainsystemva () is mivasystemcache,mivaspecialpoolpaged or mivaspecialpoolnonpaged, memory will be allocated from this area.

0x03 allocation of kernel virtual memory

The memory Manager uses the function miobtainsystemva () to dynamically allocate different 2MB of memory from different kernel virtual address spaces. When the MIOBTAINSYSTEMVA () function is called, the caller needs to specify the total number of PDE items allocated and the allocation type of system virtual memory (Nt!_mi_system_va_type), whereas for this function the type that is valid is Mivapagedpool. Mivanonpagedpool,mivasystemptes,mivasystemcache,mivaspecialpoolpaged,mivaspecialpoolnonpaged.

MIOBTAINSYSTEMVA () can meet the allocation requests for different kernel virtual spaces. For example, Mivapagedpool requires the allocation of a paged pool area (Paged Pool region), Mivanonpagedpool requires that no paged pool area be allocated (non-paged The Mivasystemptes allocates the system Pte region, while the other types of allocation requests are the direct allocation of system dynamic virtual memory (the dynamic system VA zone). The release of the memory is done by the function mireturnsystemva ().

An example of a dynamic memory allocation is Miexpandsystemcache () calling Miobtainsystemva () to get the view of the system cache. Miexpandsystemcache () call MIOBTAINSYSTEMVA (Mivasystemcache) to request storage for cache Manager VACB (Virtual Address Control Block) Virtual Memory for data structures

0X04 System Pte Management (Syspte Management)

Memory allocated by MIOBTAINSYSTEMVA () from the Syspte zone is allocated by mireserveptes () in accordance with the allocation requirements (nt! Mikernelstackpteinfo and nt! Misystempteinfo) is further divided into two categories, which are designed to prevent the fragmentation of virtual memory. Because kernel stack memory, especially for system and service process threads, has a long lifetime, other types of allocations, such as the MDL life cycle, are relatively short.

Two types of Structures nt! Mikernelstackpteinfo and nt! Misystempteinfo all belong to Nt!_mi_system_pte_type, and these structures are produced by the function miinitializesystemptes (), Each of them contains information that can affect the 128GB space of the Syspte area. While the function mireserveptes () requires one of these constructs as a parameter to request memory outside the Syspte region, the requested memory is freed by Mireleaseptes ().

When the virtual memory address is nt! Mikernelstackpteinfo and nt! When Misystempteinfo is overwritten, it has exhausted the area of memory extended by calling Miexpandptes () (actually called MIOBTAINSYSTEMVA (mivasystemptes)).

The functions mmallocatemappingaddress () and Mmcreatekernelstack () are all applications nt! Mikernelstackpteinfo types of memory, while functions MIVAILDATELAMGEPFN () and Micreateimagefilemap (), MIRELOCATEIMAGEPFN (), Mirelocateimageagain () Application nt! Misystempteinfo type of memory.

x64 Kernel memory Space structure