Dev

Windows Via C/C++ note 2

好像和第一篇隔了很久，主要是因为我懒，而且一开始我纠结要按顺序看书还是按照我自己的兴趣来，最后兴趣占了上风所以就鸽了一阵子。。。今天强迫自己整理一下这些笔记的时候才想起来这个大坑。


Windows Via C/C++ note 2(内存管理)

Windows 和 Linux 很多地方都相似，比如说虚拟地址的使用，内存的分页分段等等。但是相较而言，Windows 某些内存管理会相比较来说更加上层（？或者反过来，更加底层？）

体系结构

分区

Windows 上的地址空间的划分大约是这样的:

1
2
3
4
5
6
7
8
9
+-------------------+-------------------------+---------------------------------------+
|       分区        |       32 bit            |                  64 bit               |
+-------------------+-------------------------+---------------------------------------+
|    空指针赋值      |  0x00000000-0x0000ffff  | 0x0000000000000000-0x000000000000ffff |
+-------------------+-------------------------+---------------------------------------+
|     用户模式       |  0x00010000-0x7ffeffff  | 0x0000000000010000-0x000007fffffeffff |
+-------------------+-------------------------+---------------------------------------+
|     内核模式       |  0x7fff0000-0x7fffffff  | 0x0000080000000000-0xffffffffffffffff |
+-------------------+-------------------------+---------------------------------------+

虽然用户模式下的内存是进程可以控制的，但是进程A是不能够访问到进程B中用户模式下任意一个地址的内容。Windows 中的所有.exe|.dll都会载入到用户态中。

可以获得更大的用户空间

如上表，内核模式几乎占据了一半的地址空间，但是其实上用户可以通过boot configuration data(BCD)指令来设置当前用户的地址空间

1
BCD /set IncreaseUserVA 3072        ; 当前用户的地址空间上升到3GB

不过如果这样处理之后，Windows 内核的性能就会下降，导致进程数量的创建受限，运行速度下降等等

64->32的兼容：地址的最高位

因为用户模式的最高位在32bit下是0(0x7xxxxxxx)，所以有一些应用的程序会将当前指针的最高位用作标志位。当其应用访问指针的时候会检查这个标志位。所以如果64bit 的程序简单的使用了更多地址的话，就会导致这个标志位被覆盖，从而导致应用的崩溃。为了保护这一点，Windows 在链接阶段的时候提供了标志位/LARGEADDRESSA WARE，如果使用这个标志位，程序才会使用更高位的地址，否则程序的地址将会限制在0x000000007ffeffff以下。这个运行环境就被称为address sandbox(地址空间沙箱)

内存分配

Windows 下的内存存在的形式主要有这几种

  • 闲置 Free
  • 私有 Private
  • 映像 Image
  • 已映射 Mapped

在Windows 下的内存分配得到一个可以使用的内存主要分为两步:

  • 预定 Reserve
  • 调度 Commit

Reserve 得到的 Memory 暂时未提交给应用，因此是不能使用的。但同时其相当于占据了一部分的地址空间，这部分的地址空间在之后的程序运行中也不能被其他的用途占用（除非被释放了）

预定地址 Reserve

系统创建一个进程的时候，就会赋予其一个完整的地址空间。我们需要调用函数VirutalAlloc来预定(Reserve)其中的区域(region)

分配地址空间的时候，系统会确保当前的起始地址正好是分配粒度(allocation granularity)的整数倍(也就是所谓的对齐)。目前来收，大部分的平台默认的分配粒度都是64KB(0x10000)，也就是说，系统会把分配的内存地址对其到这个地址上
但是对于操作系统来说不存在这个限制，也就是说操作系统为我们申请的内存空间不会被对齐。操作系统也需要申请内存空间，包括PEB，TEB还有内建的堆等等

预定的空间大小也是需要对齐的，预定空间大小通常是和页面大小(4KB)对齐的。如果我们申请的空间大小为10KB，那么x32/64的电脑会强制帮我们申请一个12KB大小的堆

如果程序之后不使用预定地址的时候，应通过VritualFree将当前的地址空间释放

调拨物理存储器 Commit

光是预定空间还是不能使用的，我们还需要向操作系统提交我们的预定地址，让操作系统为地址分配物理存储器。这个过程被称为调度(Committing)。物理存储器始终都是以页面为单位来进行调拨的。调拨的时候使用的函数也是VirtualAlloc。
当我们调拨的时候，其实我们不需要为整个预定地址空间都进行调拨，可以指定为整个区域中的第二个和第四个页面进行调度。

同样，当我们不再使用物理存储器的时候，我们应该撤销调拨(decommitting)，同样也是通过VirtualFree来释放。

物理存储器？
物理存储器包括物理内存，硬盘这类存储介质。但是具体要用哪个取决于整个映射执行的过程。

物理存储器与页交换文件

刚刚讲了很多，不知道大家有没有这样的问题:

都说每个进程的地址空间都有32bit那么大（对于32位而言），也就是4GB都占满了。但是计算机中有好多个进程在运行，怎么放得下呢？
我玩的游戏都有 30GB ，但是如果整个游戏都放到内存里的话其他的程序又怎么运行呢？

过去内存条本身有多大，计算机可用的内存就有多大。但是现在的计算机会采取虚拟内存的技术，将磁盘中的一部分物理内存分配出来作为内存文件，这类文件就称为 页交换文件(paging file)。也就是说，当程序在访问一个地址的时候，这个地址所映射的可能不是一个内存的地址，而是一个磁盘上的数据，这个时候就会和《计算机组成原理课程》中提到的一样，会发生 缺页。当发生缺页之后，程序会尝试从内存中寻找一块空闲内存页（找不到的时候，会用一个算法选取一个），然后和页交换文件中的页进行交换。

之前提到的申请地址空间并且调拨物理存储器的时候，其实本质上 也就是从硬盘中的页交换文件分配 得到。只有在发生了缺页中断之后，才会将当前的地址空间放入内存。
当一个线程访问所属进程的地址空间的地址的时候，可能会有两种情况

  • 当前数据存放在内存中
  • 当前数据未存放于内存

那么整体的工作流程大致如下

如果频繁的发生内存和页交换文件之间进行页面复制，机器就会花费大量时间在内存处理上，这个过程称为 硬盘颠簸(thrash)。如果颠簸过于严重，就会导致当前系统运行过慢。

不在页交换文件的物理存储器

我们知道每一个exe或者dll都会被加载到内存中执行，那么是不是所有的exe/dll都会在加载后放入页交换文件中呢？

系统在加载exe文件的时候，实际上并不会将其放入到页交换文件。系统会计算出要加载的exe/dll的大小，然后在进程中预定一个区域用于存放文件的代码和数据，之后会直接将 该区域与文件本身所在的物理存储器相关联 ，相当于说文件本身(file image 文件映像)就被映射到了内存中。
这种把一个位于硬盘上的文件映像(也就是一个.exe或者.dll)用作地址空间区域对应的物理存储器时，这个文件映像就是 内存映射文件(memory mapped file)。
一般来说，dll/exe被载入时，系统就会预定地址区域(region)，并且把当前的文件映像映射到这个区域中。
但是其实系统提供了另一种形式，支持将数据文件映射到地址空间上，之后会介绍（类似于linux 中的map函数)

操作：修改页交换文件

系统其实默认是会在每一个磁盘下都组织页交换文件的，但是其实我们可以手动更改其大小。

内存区域与映射

之前介绍过内存的类型，这里对其进行进一步的解释:

闲置
即是说当前区域中的虚拟地址没有任何后备存储器。改地址空间尚未预定（未Reserve）。

私有
区域中的虚拟地址以系统的页交换文件作为后备存储器

映像
区域中的虚拟地址在最初的时候以映像文件(.exe/.dll)作为后备存储器。但是如果发生了写入（例如数据段被写入）则发生页交换，之后会用页交换文件作为后备存储器。

已映射
区域中的虚拟地址在最初的时候以内存映射文件(数据文件)作为后备存储器。但是如果发生了写入（例如数据段被写入）则发生页交换，之后会用页交换文件作为后备存储器。

PE文件在进行映射的时候，每个 段(section 都必须另起一页，而且起始地址必须要是系统页面大小的整数倍。
页大小目前默认是4KB
区分一下: 段的起始地址必须是系统页大小整数倍(4KB)，而整体区域必须是粒度的整数倍(最小64KB)
一个 **块(block)**就是一个连续的页面，同一个块里面是连续的页面，这些页面的具有相同的保护属性，而且会以 相同类型的物理存储器作为后备存储器。

虚拟内存

Windows 下有三种使用内存的方式

  • 虚拟内存：适用于大型对象或者大型数组管理
  • 内存映射文件：适用于大型数据流文件，已经在不同进程之间共享数据
  • 堆：用于管理小型对象

查询虚拟内存的API

对于许多基本信息(页面大小，分配粒度等)我们不应该自己硬编码在程序中，而是应该使用系统API去得到进程初始化时设置的变量:

1
VOID GetSystemInfo(LPSYSTEM_INFP psi);

注意这个API在32bit程序运行在64bit下的(Windows 32bit On Windows 64bit,WOW64模拟层)情况时，此时用这个查询得到的值和同一个系统中，64bit运行得到的值有所不同。

查看虚拟内存状态的话，可以使用下列API:

1
2
3
4
5
BOOL GetProcessMemoryInfo(
    HANDLE hProcess,
    PPROCESS_MEMORY_COUNTERS ppmc,
    DWORD cdSize
)

利用这个API能够查看到当前运行的进程中可能用到的最大内存，也称为 工作集。为了提高程序性能，我们可以考虑减小工作集。

使用虚拟内存的API

对于预定(Reserve)|调度(Commit)虚拟内存的时候，我们统一使用下列API

1
2
3
4
5
6
PVOID VirtualAlloc(
    PVOID pvAddress,
    SIZE_T dwSizw,
    DWORD fdwAllocationType,
    DWORD fdwProtect
)

对于参数fdwAllocationType,在预定内存的时候需要传入MEM_RESERVE，而调度内存的时候传入MEM_COMMIT。并且预定区域和调度物理存储器的时候的保护属性一般是相同的。不过在预定阶段，分配的大小始终是64KB对其的，而调度的时候则是按照4KB对齐。如果不想分开来写，可以写成如下形式同时完成预定的和调度

1
VirtualAlloc(NULL, 0x1000 * 4, MEM_RESERVE|MEM_COMMIT, PAGE_READWRITE); //注意第二个参数

相应的，为了撤销调拨的物理存储器和释放对应区域，可以通过调用下列API

1
2
3
4
5
BOOL VirtualFree(
    LPVOID pvAddress,
    SIZE_T dwSize,
    DWORD fdwFreeType
)

这个函数第一个参数必须接受一个区域的基地址（也就是之前在VirtualAlloc的返回值)在fdwFreeType为MEM_RELEASE的时候会将传入的地址中的所有地址撤销调度并且释放改区域。而传入MEM_DECOMMIT的时候，可以指定撤销的调度地址的大小。（注意不能取消指定范围內的区域）

一个页面的保护属性修改，我们可以使用这个API

1
2
3
4
5
6
BOOL VirtualProtect(
    PVOID pvAddress,
    SIZE_T dwSize,
    DWORD flNewProtect,
    PDWORD fplOldProtect
)

可以修改指向内存的基地址开始的，指定大小的区域的（当然这两个值最后都会页对齐）进行修改。

线程栈与虚拟内存

Windows中对于栈的操作也是按照虚拟内存的管理方式来管理的。每一条线程，都会由系统创建一个线程栈，这个线程栈就是一个由系统预定并且调度的空间。一般来说，系统会预定一块 1M 大的区域，然后在其中调度两页来使用。这些参数其实都是可以定制的:

  • 在CreateThread/_begintreadex 函数中，可以指定一开始要调拨给线程的栈地址空间大小。
  • PE文件头中会记录需要预定的地址空间的大小

可以看到，在第二个调度的页面中，是一个 防护页面(guard page)。
当线程的栈越来越深，试图访问防护页面的内存的时候，系统就会得到通知。此时系统会执行如下逻辑：

  • 给下一个相邻的页面调度物理存储器
  • 消除防护页面的 GUARD_PAGE 的标志
  • 给刚刚分配的页面指定这个标志。

这个技术能够保证 只有线程需要的时候才给栈调度足够的存储器，从而减小存储器的使用。

注意，当调用不断加深的时候，整个栈会如图所示:

如图，如果此时栈还要加深的话，那么此时栈底的这个页面也不会被标志为防护页面。如果程序继续运行到这，系统为栈底调度页面的时候，就会抛出一个错误EXCEPTION_STACK_OVERFLOW。系统将使用结构化异常处理(structure exception handling,SEH)来处理这个问题。当弹出这个错误后，不单单时这个线程，整个进程都将被收回控制权。

为什么不对最后一个页面调度页面，而是用其作为边界检测呢？
若相邻的区域中，下一个地址也已经被调度了，那么就会 发生内存被破坏而无法察觉的情况:

另外一种难以察觉的溢出就是 栈下溢，例如:

1
2
3
4
5
int TestForStackOverflow(){
    BYTE aBytes[1000];

    aBytes[100000] = 0;
}

如果对应的位置上是另一条线程的已调拨区域，就可能会引发访问违规却无法察觉。比如这个操作:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
DWORD WINAPI ThreadFunc(PVOID pvParam){
    BYTE aBytes[0x10];

    MEMORY_BASIC_INFORMATION mbi;

    // The Stack All Size

    SIZE_T s = (SIZE_T)mbi.AllocationBase + 1024 * 1024;

    // Point to stack reserve memory end
    PBYTE pAddress = (PBYTE)s;
    BYTE* pBytes = (BYTE*)VirtualAlloc(pAddress, 0x10000, MEM_COMMIT|MEM_RESERVE, PAGE_READWRITE);

    // Write the 1 from this stack to next memory
    aBytes[0x10000] = 1; 
}

由于栈后方正好有一个空间，就导致程序能够溢出并且不发生错误。

C/C++运行时栈的检查

PS：这里的栈检查不是指放置canary的那种检查
对于一个调度默认大小的栈(一页4KB)来说，这样的代码会带来很大的问题

1
2
3
4
5
void Function(){
    int nValues[4000];

    nValues[0] = 1;
}

如上，我们第一次访问的地址就低于了 防护页面的地址，而之前的逻辑中我们可以知道，我们是首先访问了防护页面，才会为我们调度新的页面地址。如果严格按照上述逻辑的话，此时应该会发生访问越界。为了防止这个错误，编译器会插入一些代码来调用C运行库的栈检查函数。因为栈编译期间，就能够知道一个栈需要的大小。如果需要的栈空间大于目标系统的页面大小，编译器就会自动插入代码来调用栈检查函数。这个栈检查函数大致逻辑如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
void StackCheck(int nBytesNeededFromStack){

    ...
    while (nBytesNeededFromStack >= PAGESIZE){
        pbStackPtr -= PAGESIZE;

        // access one bytes at guard page to force 
        // new page to be committed
        pbStackPtr[0] = 0;

        nBytesNeededFromStack -= PAGESIZE;
    }
    ...
}

后记

说起来这篇好像内容缺了堆相关的，记起来之后会补上（咕咕咕？？）