简易内核实现笔记(一) ——开启操作系统前的准备

BIOS

在计算机电源打开的一瞬间，x86架构的CPU处于实模式下，所谓的实模式就是8086CPU运行的模式，x86家族的CPU为了做到向下兼容，全部默认开机时运行在8086的模式下，在实模式中，所有的地址都是物理地址，寄存器大小都是16位，寻址采用20位地址线，由段地址左移4位+偏移地址实现。

在实模式背景下，第一行代码的位置是0xf000：0xfff0，也就是0xffff0，这一行代码的指令是jmp f000:e05b,这个跳转的地址就是BIOS的第一行代码地址，随后BIOS就会进行硬件自检，在没有问题后就会执行最后一行代码jmp 0x7c00跳转到主引导程序MBR处。

MBR

MBR占512字节，正好是一个硬盘扇区的大小，在这512字节的程序中，MBR的任务就是把加载器载入内存中执行：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126

;主引导程序 
;------------------------------------------------------------
%include "boot.inc"
SECTION MBR vstart=0x7c00         
   mov ax,cs      
   mov ds,ax
   mov es,ax
   mov ss,ax
   mov fs,ax
   mov sp,0x7c00
   mov ax,0xb800
   mov gs,ax

; 清屏
;利用0x06号功能，上卷全部行，则可清屏。
; -----------------------------------------------------------
;INT 0x10   功能号:0x06	   功能描述:上卷窗口
;------------------------------------------------------
;输入：
;AH 功能号= 0x06
;AL = 上卷的行数(如果为0,表示全部)
;BH = 上卷行属性
;(CL,CH) = 窗口左上角的(X,Y)位置
;(DL,DH) = 窗口右下角的(X,Y)位置
;无返回值：
   mov     ax, 0600h
   mov     bx, 0700h
   mov     cx, 0                   ; 左上角: (0, 0)
   mov     dx, 184fh		   ; 右下角: (80,25),
				   ; 因为VGA文本模式中，一行只能容纳80个字符,共25行。
				   ; 下标从0开始，所以0x18=24,0x4f=79
   int     10h                     ; int 10h

   ; 输出字符串:MBR
   mov byte [gs:0x00],'1'
   mov byte [gs:0x01],0xA4

   mov byte [gs:0x02],' '
   mov byte [gs:0x03],0xA4

   mov byte [gs:0x04],'M'
   mov byte [gs:0x05],0xA4	   ;A表示绿色背景闪烁，4表示前景色为红色

   mov byte [gs:0x06],'B'
   mov byte [gs:0x07],0xA4

   mov byte [gs:0x08],'R'
   mov byte [gs:0x09],0xA4
	 
   mov eax,LOADER_START_SECTOR	 ; 起始扇区lba地址
   mov bx,LOADER_BASE_ADDR       ; 写入的地址
   mov cx,4			 ; 待读入的扇区数
   call rd_disk_m_16		 ; 以下读取程序的起始部分（一个扇区）
  
   jmp LOADER_BASE_ADDR + 0x300
       
;-------------------------------------------------------------------------------
;功能:读取硬盘n个扇区
rd_disk_m_16:	   
;-------------------------------------------------------------------------------
				       ; eax=LBA扇区号
				       ; ebx=将数据写入的内存地址
				       ; ecx=读入的扇区数
      mov esi,eax	  ;备份eax
      mov di,cx		  ;备份cx
;读写硬盘:
;第1步：设置要读取的扇区数
      mov dx,0x1f2
      mov al,cl
      out dx,al            ;读取的扇区数

      mov eax,esi	   ;恢复ax

;第2步：将LBA地址存入0x1f3 ~ 0x1f6

      ;LBA地址7~0位写入端口0x1f3
      mov dx,0x1f3                       
      out dx,al                          

      ;LBA地址15~8位写入端口0x1f4
      mov cl,8
      shr eax,cl
      mov dx,0x1f4
      out dx,al

      ;LBA地址23~16位写入端口0x1f5
      shr eax,cl
      mov dx,0x1f5
      out dx,al

      shr eax,cl
      and al,0x0f	   ;lba第24~27位
      or al,0xe0	   ; 设置7～4位为1110,表示lba模式
      mov dx,0x1f6
      out dx,al

;第3步：向0x1f7端口写入读命令，0x20 
      mov dx,0x1f7
      mov al,0x20                        
      out dx,al

;第4步：检测硬盘状态
  .not_ready:
      ;同一端口，写时表示写入命令字，读时表示读入硬盘状态
      nop
      in al,dx
      and al,0x88	   ;第4位为1表示硬盘控制器已准备好数据传输，第7位为1表示硬盘忙
      cmp al,0x08
      jnz .not_ready	   ;若未准备好，继续等。

;第5步：从0x1f0端口读数据
      mov ax, di
      mov dx, 256
      mul dx
      mov cx, ax	   ; di为要读取的扇区数，一个扇区有512字节，每次读入一个字，
			   ; 共需di*512/2次，所以di*256
      mov dx, 0x1f0
  .go_on_read:
      in ax,dx
      mov [bx],ax
      add bx,2		  
      loop .go_on_read
      ret

   times 510-($-$$) db 0
   db 0x55,0xaa

可以看到MBR的代码分为两部分，第一个部分就是在窗口打印”1 MBR”这几个字符，这是通过向段起始0xb800处的内存写入字符实现的。在实模式下，这个地址就是显存的位置。第二部分就是写入loader，也就是函数rd_disk_m_16，在这个函数里，cx寄存器储存的是要读的磁盘扇区个数。相关的宏定义如下：

宏LOADER_START_SECTOR就是0x2，表示我们要向磁盘第三个扇区（第一个是0x0）读loader，LOADER_BASE_ADDR就是loader被写入的地址0x900。

在加载完loader之后，MBR的使命就结束了，最后一条命令jmpLOADER_BASE_ADDR+0x300就是跳转到loader的第一条命令去执行loader。

Loader

我们的loader就负责做四个事情：

• 加载全局描述符表
• 进入保护模式
• 创建页表，展开虚拟地址空间
• 加载操作系统内核

保护模式

所谓的保护模式就是可以寻址32位（4GB）的模式，而’保护’二字指的就是在这个模式下CPU为程序执行提供了一些内存的保护措施，这个措施就是通过全局描述符表来实现的。为了开启保护模式，我们要做3件事：

• 加载全局描述符表
• 打开A20 Gate
• 修改控制寄存器CR0第一位为1

全局描述符表

全局描述符表就是一个表，存储着段描述符，所谓的描述符就是关于内存段的一些信息，CPU会根据这些信息做出相应的措施，所谓的全局就是指这个表不是局部的。一个描述符占了64位8字节，每位的意义如下：

由于一些向下兼容的原因，一些东西是不连续的，但不妨碍我们理解：

• 段界限：一个段的最大大小是20位，如果索引超过段界限CPU会触发异常。
• G：段界限的粒度，如果G为0就代表粒度是1位，对应到段界限就是20位1MB。G为1就代表粒度为4KB，对应到段界限就是4GB，因此实际的段界限大小等=粒度大小*段界限-1
• 段基址：顾名思义，不用说了
• D/B：一个用来兼容80286保护模式的位，表示有效地址和操作数的位数。D为0表示16位，D为1表示32位（所以对我们不用80286的就没什么用）
• L：为1表示64位代码段，0表示32位
• AVL：available字段，这个available是对于用户来说的，不是硬件，所以是可以随便用的
• P：用于指示段是否存在于内存中，用到这个段时如果它不存在，就会触发CPU的异常，然后跳转到异常处理程序中把它加载到内存中。
• DPL：表示特权级，特权级一共4级，从高到低为0，1，2，3。
• S：为1表示系统段，0表示非系统段
• type：段的类型，这三位对于系统段和非系统段有不同的定义：

A20 Gate

实模式能够寻址的空间是1MB 20位，要进入保护模式的32位寻址，就要去除20位寻址的限制，这个限制被称为A20 Gate，打开A20 Gate的方法就是将端口0x92的第一个位置写为1：

1
2
3

in al,0x92
or al,0000_0010B
out 0x92,al

而进入保护模式的方法就是将控制寄存器CR0的第0位写为1：

1
2
3

mov eax, cr0
or eax, 0x00000001
mov cr0, eax

因此，进入保护模式的代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

;-----------------   准备进入保护模式   -------------------
;1 打开A20
;2 加载gdt
;3 将cr0的pe位置1

   ;-----------------  打开A20  ----------------
   in al,0x92
   or al,0000_0010B
   out 0x92,al

   ;-----------------  加载GDT  ----------------
   lgdt [gdt_ptr]

   ;-----------------  cr0第0位置1  ----------------
   mov eax, cr0
   or eax, 0x00000001
   mov cr0, eax

   jmp dword SELECTOR_CODE:p_mode_start	     ; 刷新流水线，避免分支预测的影响,这种cpu优化策略，最怕jmp跳转，
					     ; 这将导致之前做的预测失效，从而起到了刷新的作用。
.error_hlt:		      ;出错则挂起
   hlt

虚拟地址空间

在进入保护模式之后，我们所访问的32位地址仍然是物理地址，虚拟地址为我们提供了一层抽象，使得每个进程都可以在32位地址空间中运行，我们只需要通过页表将它们映射到物理地址即可，这样写程序就不用再自己去管地址从哪里开始了。

页表

页表是虚拟地址与物理地址的映射关系，由于将来每个操作系统下的进程，包括操作系统自己都是在32位虚拟地址空间中运行的，因此每个进程都需要有自己的页表，我们将物理地址分页，每个页占有4kB的大小，一个页表项就占32位4字节，检索4GB的虚拟内存空间总共需要1M个页表，在内存中占4MB，这个大小显然是无法接受的，因此我们再创建一个页表的页表，也就是页目录表，一个页目录项也是32位4字节，因此一个页目录项也可以索引4kB的空间，那么检索4GB的虚拟地址空间只需要4GB/4kB/4kB=1024个页目录，只需要4096个字节就可以了，这样的开销就可以接受。

对于1024个页目录，我们需要10位地址来进行索引，这10位地址就是虚拟地址中的高10位，我们将这10位地址4就是对应页表的偏移地址，再加上页目录表的起始地址就得到了对应页表所在的物理地址，一个页表中有1024个页，因此检索它也需要10位地址，这10位地址就是虚拟地址中的中间10位，我们用这中间10位地址4就得到了所在页的偏移地址，加上前面得到的页表物理地址就得到了对应页所在物理地址，这个页中存储的就是真实物理地址的偏移量，再加上最低12位虚拟地址就得到了对应的真实物理地址了。

因为每个页表项都是4字节，因此它们的值里面低12位全是0，因此为了避免浪费就要往里面加一些关于页表的安全信息：

其中：

• P：该页存在于物理地址中
• R/W：读写权限，0表示只读，1表示可读可写
• US：普通用户/超级用户位，为1表示在普通用户级，普通用户在特权级3
• PWT：通写位，1表示处于通写模式，表示改该页是高速缓存
• PCD：打开使用高速缓存
• A:访问位，如果CPU访问过该页，就会把它置为1，之后的操作系统我们会将它置为0，通过count置为1的次数就能判断它是否常常被使用，是就将这个页存入缓存中
• D：脏页位，CPU对一个页进行写操作时，就会把这个位置为1，仅对页表项有效
• G：global位，若为global，那么这个页表就会一直在高速缓存TLB中保存
• AVL：软件的可用为，CPU不会管，怎么用就是软件定义的了

对页表的初始化我们要有一个约定，也就是4GB的虚拟地址空间中，高1GB是只有操作系统内核才能访问的区域，因此在初始化页表时我们要将内核区的页表和普通页表分开，并且为了减小开销在未来将所有进程的内核页表通用，所以完整的loader代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380

   %include "boot.inc"
   section loader vstart=LOADER_BASE_ADDR
;构建gdt及其内部的描述符
   GDT_BASE:   dd    0x00000000 
	       dd    0x00000000

   CODE_DESC:  dd    0x0000FFFF 
	       dd    DESC_CODE_HIGH4

   DATA_STACK_DESC:  dd    0x0000FFFF
		     dd    DESC_DATA_HIGH4

   VIDEO_DESC: dd    0x80000007	       ; limit=(0xbffff-0xb8000)/4k=0x7
	       dd    DESC_VIDEO_HIGH4  ; 此时dpl为0

   GDT_SIZE   equ   $ - GDT_BASE
   GDT_LIMIT   equ   GDT_SIZE -	1 
   times 60 dq 0					 ; 此处预留60个描述符的空位(slot)
   SELECTOR_CODE equ (0x0001<<3) + TI_GDT + RPL0         ; 相当于(CODE_DESC - GDT_BASE)/8 + TI_GDT + RPL0
   SELECTOR_DATA equ (0x0002<<3) + TI_GDT + RPL0	 ; 同上
   SELECTOR_VIDEO equ (0x0003<<3) + TI_GDT + RPL0	 ; 同上 

   ; total_mem_bytes用于保存内存容量,以字节为单位,此位置比较好记。
   ; 当前偏移loader.bin文件头0x200字节,loader.bin的加载地址是0x900,
   ; 故total_mem_bytes内存中的地址是0xb00.将来在内核中咱们会引用此地址
   total_mem_bytes dd 0					 
   ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

   ;以下是定义gdt的指针，前2字节是gdt界限，后4字节是gdt起始地址
   gdt_ptr  dw  GDT_LIMIT 
	    dd  GDT_BASE

   ;人工对齐:total_mem_bytes4字节+gdt_ptr6字节+ards_buf244字节+ards_nr2,共256字节
   ards_buf times 244 db 0
   ards_nr dw 0		      ;用于记录ards结构体数量

   loader_start:
   
;-------  int 15h eax = 0000E820h ,edx = 534D4150h ('SMAP') 获取内存布局  -------

   xor ebx, ebx		      ;第一次调用时，ebx值要为0
   mov edx, 0x534d4150	      ;edx只赋值一次，循环体中不会改变
   mov di, ards_buf	      ;ards结构缓冲区
.e820_mem_get_loop:	      ;循环获取每个ARDS内存范围描述结构
   mov eax, 0x0000e820	      ;执行int 0x15后,eax值变为0x534d4150,所以每次执行int前都要更新为子功能号。
   mov ecx, 20		      ;ARDS地址范围描述符结构大小是20字节
   int 0x15
   jc .e820_failed_so_try_e801   ;若cf位为1则有错误发生，尝试0xe801子功能
   add di, cx		      ;使di增加20字节指向缓冲区中新的ARDS结构位置
   inc word [ards_nr]	      ;记录ARDS数量
   cmp ebx, 0		      ;若ebx为0且cf不为1,这说明ards全部返回，当前已是最后一个
   jnz .e820_mem_get_loop

;在所有ards结构中，找出(base_add_low + length_low)的最大值，即内存的容量。
   mov cx, [ards_nr]	      ;遍历每一个ARDS结构体,循环次数是ARDS的数量
   mov ebx, ards_buf 
   xor edx, edx		      ;edx为最大的内存容量,在此先清0
.find_max_mem_area:	      ;无须判断type是否为1,最大的内存块一定是可被使用
   mov eax, [ebx]	      ;base_add_low
   add eax, [ebx+8]	      ;length_low
   add ebx, 20		      ;指向缓冲区中下一个ARDS结构
   cmp edx, eax		      ;冒泡排序，找出最大,edx寄存器始终是最大的内存容量
   jge .next_ards
   mov edx, eax		      ;edx为总内存大小
.next_ards:
   loop .find_max_mem_area
   jmp .mem_get_ok

;------  int 15h ax = E801h 获取内存大小,最大支持4G  ------
; 返回后, ax cx 值一样,以KB为单位,bx dx值一样,以64KB为单位
; 在ax和cx寄存器中为低16M,在bx和dx寄存器中为16MB到4G。
.e820_failed_so_try_e801:
   mov ax,0xe801
   int 0x15
   jc .e801_failed_so_try88   ;若当前e801方法失败,就尝试0x88方法

;1 先算出低15M的内存,ax和cx中是以KB为单位的内存数量,将其转换为以byte为单位
   mov cx,0x400	     ;cx和ax值一样,cx用做乘数
   mul cx 
   shl edx,16
   and eax,0x0000FFFF
   or edx,eax
   add edx, 0x100000 ;ax只是15MB,故要加1MB
   mov esi,edx	     ;先把低15MB的内存容量存入esi寄存器备份

;2 再将16MB以上的内存转换为byte为单位,寄存器bx和dx中是以64KB为单位的内存数量
   xor eax,eax
   mov ax,bx		
   mov ecx, 0x10000	;0x10000十进制为64KB
   mul ecx		;32位乘法,默认的被乘数是eax,积为64位,高32位存入edx,低32位存入eax.
   add esi,eax		;由于此方法只能测出4G以内的内存,故32位eax足够了,edx肯定为0,只加eax便可
   mov edx,esi		;edx为总内存大小
   jmp .mem_get_ok

;-----------------  int 15h ah = 0x88 获取内存大小,只能获取64M之内  ----------
.e801_failed_so_try88: 
   ;int 15后，ax存入的是以kb为单位的内存容量
   mov  ah, 0x88
   int  0x15
   jc .error_hlt
   and eax,0x0000FFFF
      
   ;16位乘法，被乘数是ax,积为32位.积的高16位在dx中，积的低16位在ax中
   mov cx, 0x400     ;0x400等于1024,将ax中的内存容量换为以byte为单位
   mul cx
   shl edx, 16	     ;把dx移到高16位
   or edx, eax	     ;把积的低16位组合到edx,为32位的积
   add edx,0x100000  ;0x88子功能只会返回1MB以上的内存,故实际内存大小要加上1MB

.mem_get_ok:
   mov [total_mem_bytes], edx	 ;将内存换为byte单位后存入total_mem_bytes处。


;-----------------   准备进入保护模式   -------------------
;1 打开A20
;2 加载gdt
;3 将cr0的pe位置1

   ;-----------------  打开A20  ----------------
   in al,0x92
   or al,0000_0010B
   out 0x92,al

   ;-----------------  加载GDT  ----------------
   lgdt [gdt_ptr]

   ;-----------------  cr0第0位置1  ----------------
   mov eax, cr0
   or eax, 0x00000001
   mov cr0, eax

   jmp dword SELECTOR_CODE:p_mode_start	     ; 刷新流水线，避免分支预测的影响,这种cpu优化策略，最怕jmp跳转，
					     ; 这将导致之前做的预测失效，从而起到了刷新的作用。
.error_hlt:		      ;出错则挂起
   hlt

[bits 32]
p_mode_start:
   mov ax, SELECTOR_DATA
   mov ds, ax
   mov es, ax
   mov ss, ax
   mov esp,LOADER_STACK_TOP
   mov ax, SELECTOR_VIDEO
   mov gs, ax

; -------------------------   加载kernel  ----------------------
   mov eax, KERNEL_START_SECTOR        ; kernel.bin所在的扇区号
   mov ebx, KERNEL_BIN_BASE_ADDR       ; 从磁盘读出后，写入到ebx指定的地址
   mov ecx, 200			       ; 读入的扇区数

   call rd_disk_m_32

   ; 创建页目录及页表并初始化页内存位图
   call setup_page

   ;要将描述符表地址及偏移量写入内存gdt_ptr,一会用新地址重新加载
   sgdt [gdt_ptr]	      ; 存储到原来gdt所有的位置

   ;将gdt描述符中视频段描述符中的段基址+0xc0000000
   mov ebx, [gdt_ptr + 2]  
   or dword [ebx + 0x18 + 4], 0xc0000000      ;视频段是第3个段描述符,每个描述符是8字节,故0x18。
					      ;段描述符的高4字节的最高位是段基址的31~24位

   ;将gdt的基址加上0xc0000000使其成为内核所在的高地址
   add dword [gdt_ptr + 2], 0xc0000000

   add esp, 0xc0000000        ; 将栈指针同样映射到内核地址

   ; 把页目录地址赋给cr3
   mov eax, PAGE_DIR_TABLE_POS
   mov cr3, eax

   ; 打开cr0的pg位(第31位)
   mov eax, cr0
   or eax, 0x80000000
   mov cr0, eax

   ;在开启分页后,用gdt新的地址重新加载
   lgdt [gdt_ptr]             ; 重新加载

;;;;;;;;;;;;;;;;;;;;;;;;;;;;  此时不刷新流水线也没问题  ;;;;;;;;;;;;;;;;;;;;;;;;
;由于一直处在32位下,原则上不需要强制刷新,经过实际测试没有以下这两句也没问题.
;但以防万一，还是加上啦，免得将来出来莫句奇妙的问题.
   jmp SELECTOR_CODE:enter_kernel	  ;强制刷新流水线,更新gdt
enter_kernel:    
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
   call kernel_init
   mov esp, 0xc009f000
   jmp KERNEL_ENTRY_POINT                 ; 用地址0x1500访问测试，结果ok


;-----------------   将kernel.bin中的segment拷贝到编译的地址   -----------
kernel_init:
   xor eax, eax
   xor ebx, ebx		;ebx记录程序头表地址
   xor ecx, ecx		;cx记录程序头表中的program header数量
   xor edx, edx		;dx 记录program header尺寸,即e_phentsize

   mov dx, [KERNEL_BIN_BASE_ADDR + 42]	  ; 偏移文件42字节处的属性是e_phentsize,表示program header大小
   mov ebx, [KERNEL_BIN_BASE_ADDR + 28]   ; 偏移文件开始部分28字节的地方是e_phoff,表示第1 个program header在文件中的偏移量
					  ; 其实该值是0x34,不过还是谨慎一点，这里来读取实际值
   add ebx, KERNEL_BIN_BASE_ADDR
   mov cx, [KERNEL_BIN_BASE_ADDR + 44]    ; 偏移文件开始部分44字节的地方是e_phnum,表示有几个program header
.each_segment:
   cmp byte [ebx + 0], PT_NULL		  ; 若p_type等于 PT_NULL,说明此program header未使用。
   je .PTNULL

   ;为函数memcpy压入参数,参数是从右往左依然压入.函数原型类似于 memcpy(dst,src,size)
   push dword [ebx + 16]		  ; program header中偏移16字节的地方是p_filesz,压入函数memcpy的第三个参数:size
   mov eax, [ebx + 4]			  ; 距程序头偏移量为4字节的位置是p_offset
   add eax, KERNEL_BIN_BASE_ADDR	  ; 加上kernel.bin被加载到的物理地址,eax为该段的物理地址
   push eax				  ; 压入函数memcpy的第二个参数:源地址
   push dword [ebx + 8]			  ; 压入函数memcpy的第一个参数:目的地址,偏移程序头8字节的位置是p_vaddr，这就是目的地址
   call mem_cpy				  ; 调用mem_cpy完成段复制
   add esp,12				  ; 清理栈中压入的三个参数
.PTNULL:
   add ebx, edx				  ; edx为program header大小,即e_phentsize,在此ebx指向下一个program header 
   loop .each_segment
   ret

;----------  逐字节拷贝 mem_cpy(dst,src,size) ------------
;输入:栈中三个参数(dst,src,size)
;输出:无
;---------------------------------------------------------
mem_cpy:		      
   cld
   push ebp
   mov ebp, esp
   push ecx		   ; rep指令用到了ecx，但ecx对于外层段的循环还有用，故先入栈备份
   mov edi, [ebp + 8]	   ; dst
   mov esi, [ebp + 12]	   ; src
   mov ecx, [ebp + 16]	   ; size
   rep movsb		   ; 逐字节拷贝

   ;恢复环境
   pop ecx		
   pop ebp
   ret


;-------------   创建页目录及页表   ---------------
setup_page:
;先把页目录占用的空间逐字节清0
   mov ecx, 4096
   mov esi, 0
.clear_page_dir:
   mov byte [PAGE_DIR_TABLE_POS + esi], 0
   inc esi
   loop .clear_page_dir

;开始创建页目录项(PDE)
.create_pde:				     ; 创建Page Directory Entry
   mov eax, PAGE_DIR_TABLE_POS
   add eax, 0x1000 			     ; 此时eax为第一个页表的位置及属性
   mov ebx, eax				     ; 此处为ebx赋值，是为.create_pte做准备，ebx为基址。

;   下面将页目录项0和0xc00都存为第一个页表的地址，
;   一个页表可表示4MB内存,这样0xc03fffff以下的地址和0x003fffff以下的地址都指向相同的页表，
;   这是为将地址映射为内核地址做准备
   or eax, PG_US_U | PG_RW_W | PG_P	     ; 页目录项的属性RW和P位为1,US为1,表示用户属性,所有特权级别都可以访问.
   mov [PAGE_DIR_TABLE_POS + 0x0], eax       ; 第1个目录项,在页目录表中的第1个目录项写入第一个页表的位置(0x101000)及属性(3)
   mov [PAGE_DIR_TABLE_POS + 0xc00], eax     ; 一个页表项占用4字节,0xc00表示第768个页表占用的目录项,0xc00以上的目录项用于内核空间,
					     ; 也就是页表的0xc0000000~0xffffffff共计1G属于内核,0x0~0xbfffffff共计3G属于用户进程.
   sub eax, 0x1000
   mov [PAGE_DIR_TABLE_POS + 4092], eax	     ; 使最后一个目录项指向页目录表自己的地址

;下面创建页表项(PTE)
   mov ecx, 256				     ; 1M低端内存 / 每页大小4k = 256
   mov esi, 0
   mov edx, PG_US_U | PG_RW_W | PG_P	     ; 属性为7,US=1,RW=1,P=1
.create_pte:				     ; 创建Page Table Entry
   mov [ebx+esi*4],edx			     ; 此时的ebx已经在上面通过eax赋值为0x101000,也就是第一个页表的地址 
   add edx,4096
   inc esi
   loop .create_pte

;创建内核其它页表的PDE
   mov eax, PAGE_DIR_TABLE_POS
   add eax, 0x2000 		     ; 此时eax为第二个页表的位置
   or eax, PG_US_U | PG_RW_W | PG_P  ; 页目录项的属性RW和P位为1,US为0
   mov ebx, PAGE_DIR_TABLE_POS
   mov ecx, 254			     ; 范围为第769~1022的所有目录项数量
   mov esi, 769
.create_kernel_pde:
   mov [ebx+esi*4], eax
   inc esi
   add eax, 0x1000
   loop .create_kernel_pde
   ret


;-------------------------------------------------------------------------------
			   ;功能:读取硬盘n个扇区
rd_disk_m_32:	   
;-------------------------------------------------------------------------------
							 ; eax=LBA扇区号
							 ; ebx=将数据写入的内存地址
							 ; ecx=读入的扇区数
      mov esi,eax	   ; 备份eax
      mov di,cx		   ; 备份扇区数到di
;读写硬盘:
;第1步：设置要读取的扇区数
      mov dx,0x1f2
      mov al,cl
      out dx,al            ;读取的扇区数

      mov eax,esi	   ;恢复ax

;第2步：将LBA地址存入0x1f3 ~ 0x1f6

      ;LBA地址7~0位写入端口0x1f3
      mov dx,0x1f3                       
      out dx,al                          

      ;LBA地址15~8位写入端口0x1f4
      mov cl,8
      shr eax,cl
      mov dx,0x1f4
      out dx,al

      ;LBA地址23~16位写入端口0x1f5
      shr eax,cl
      mov dx,0x1f5
      out dx,al

      shr eax,cl
      and al,0x0f	   ;lba第24~27位
      or al,0xe0	   ; 设置7～4位为1110,表示lba模式
      mov dx,0x1f6
      out dx,al

;第3步：向0x1f7端口写入读命令，0x20 
      mov dx,0x1f7
      mov al,0x20                        
      out dx,al

;;;;;;; 至此,硬盘控制器便从指定的lba地址(eax)处,读出连续的cx个扇区,下面检查硬盘状态,不忙就能把这cx个扇区的数据读出来

;第4步：检测硬盘状态
  .not_ready:		   ;测试0x1f7端口(status寄存器)的的BSY位
      ;同一端口,写时表示写入命令字,读时表示读入硬盘状态
      nop
      in al,dx
      and al,0x88	   ;第4位为1表示硬盘控制器已准备好数据传输,第7位为1表示硬盘忙
      cmp al,0x08
      jnz .not_ready	   ;若未准备好,继续等。

;第5步：从0x1f0端口读数据
      mov ax, di	   ;以下从硬盘端口读数据用insw指令更快捷,不过尽可能多的演示命令使用,
			   ;在此先用这种方法,在后面内容会用到insw和outsw等

      mov dx, 256	   ;di为要读取的扇区数,一个扇区有512字节,每次读入一个字,共需di*512/2次,所以di*256
      mul dx
      mov cx, ax	   
      mov dx, 0x1f0
  .go_on_read:
      in ax,dx		
      mov [ebx], ax
      add ebx, 2
			  ; 由于在实模式下偏移地址为16位,所以用bx只会访问到0~FFFFh的偏移。
			  ; loader的栈指针为0x900,bx为指向的数据输出缓冲区,且为16位，
			  ; 超过0xffff后,bx部分会从0开始,所以当要读取的扇区数过大,待写入的地址超过bx的范围时，
			  ; 从硬盘上读出的数据会把0x0000~0xffff的覆盖，
			  ; 造成栈被破坏,所以ret返回时,返回地址被破坏了,已经不是之前正确的地址,
			  ; 故程序出会错,不知道会跑到哪里去。
			  ; 所以改为ebx代替bx指向缓冲区,这样生成的机器码前面会有0x66和0x67来反转。
			  ; 0X66用于反转默认的操作数大小! 0X67用于反转默认的寻址方式.
			  ; cpu处于16位模式时,会理所当然的认为操作数和寻址都是16位,处于32位模式时,
			  ; 也会认为要执行的指令是32位.
			  ; 当我们在其中任意模式下用了另外模式的寻址方式或操作数大小(姑且认为16位模式用16位字节操作数，
			  ; 32位模式下用32字节的操作数)时,编译器会在指令前帮我们加上0x66或0x67，
			  ; 临时改变当前cpu模式到另外的模式下.
			  ; 假设当前运行在16位模式,遇到0X66时,操作数大小变为32位.
			  ; 假设当前运行在32位模式,遇到0X66时,操作数大小变为16位.
			  ; 假设当前运行在16位模式,遇到0X67时,寻址方式变为32位寻址
			  ; 假设当前运行在32位模式,遇到0X67时,寻址方式变为16位寻址.

      loop .go_on_read
      ret

注意，在内核页表中，我们仍置US位为U，是因为内核的加载程序是运行在用户特权下的。由于我们目前只需要1MB的物理内存，每个页能映射4kB，因此只需要创建256个普通页表项，普通页表目录也只需要一个，并且这1MB的内存中，虚拟地址就等于物理地址。另外，第一个内核页表目录也指向256个普通页表项，因为我们需要让内核在这1MB的物理内存下被加载运行，之后的那1GB内核虚拟内存的页表和页表目录创建时就把P位置为0，表示他们不存在于内存中。

在加载完页表之后，我们就可以把控制寄存器CR0的第31位置为1，表示让CPU开启虚拟寻址模式，然后重新将全局描述符表加载到内核区域，再将内核加载到内核区的内存中就可以运行操作系统内核了。

载入内核程序

在载入内核之前，首先我们要了解ELF文件格式，ELF的E和L就是executable and linkable的缩写，一个ELF文件在链接或者执行视图中可以分段(segment)或者分节(section)：

elf的header是一个数据结构，用来记录这个ELF文件的信息：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

/* 32位elf头 */
struct Elf32_Ehdr
{
    unsigned char e_ident[16];
    Elf32_Half e_type;
    Elf32_Half e_machine;
    Elf32_Word e_version;
    Elf32_Addr e_entry;
    Elf32_Off e_phoff;
    Elf32_Off e_shoff;
    Elf32_Word e_flags;
    Elf32_Half e_ehsize;
    Elf32_Half e_phentsize;
    Elf32_Half e_phnum;
    Elf32_Half e_shentsize;
    Elf32_Half e_shnum;
    Elf32_Half e_shstrndx;
};

其中，e_indent[16]功能如下：

e_type占2字节，表示elf目标文件类型，一共有下面几种：

其余的字段意义如下：

在加载程序中，我们需要做的就是将内核按照编译好的虚拟地址将各个段复制到对应的位置，然后jump到内核的运行入口（链接时可用指定）去开启内核，然后loader的生命历程就结束了。

附录

虚拟机bochs的安装与配置

这里使用2.6.2版本，下载地址： https://sourceforge.net/projects/bochs/files/bochs/2.6.2/

下载源代码文件之后解压进入目录，然后配置：

1
2
3
4
5
6
7
8

./configure \
--prefix=/*你的安装目录*/ \
--enable-debugger \
--enable-disasm \
--enable-iodebug \
--enable-x86-debugger \
--with-x \
--with-x11

然后make,如果报错说

1
2

Makefile:179: recipe for target 'bochs' failed
make: *** [bochs] Error 1

就再makefile里找到LIBS =，尾部加上-lpthread,注意这里不要再configure，否则makefile会被覆盖，再make，make install就可以了

进入bochs的目录，然后配置文件bochsrc.disk：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# Configuration file for Bochs
# 设置Bochs在运行过程中能够使用的内存: 32 MB
megs: 32

# 设置真实机器的BIOS和VGA BIOS
# 修改成你们对应的地址

romimage: file=*bochs的目录*/share/bochs/BIOS-bochs-latest
vgaromimage: file=*bochs的目录*/bochs-2.6.2/share/bochs/VGABIOS-lgpl-latest

# 设置Bochs所使用的磁盘
# 设置启动盘符
boot: disk

# 设置日志文件的输出
log: bochs.out

# 开启或关闭某些功能，修改成你们对应的地址
mouse: enabled=0
keyboard:keymap=*bochs的目录*/share/bochs/keymaps/x11-pc-us.map

# 硬盘设置
ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14

# 增加gdb支持，这里添加会报错，暂时不需要
# gdbstub: enabled=1, port=1234, text_base=0, data_base=0, bss_base=0

然后运行bin/bximage，创建一个60M的虚拟硬盘，遇到选项全部回车，然后问size的时候填个60，然后把让你复制的这一行：ata0-master: type=disk, path="hd60M.img", mode=flat, cylinders=121, heads=16, spt=63复制到配置文件中，记得path改成绝对路径，bochs不认识相对路径

之后运行bochs就完事了

glibc malloc 源码分析

linux给了我们两种类型的系统调用来申请动态内存，分别是brk()和mmap()，malloc()仅仅是在这二者之上做了一些其他的事情而已，这里从源代码来剖析一下glibc malloc都做了什么。源代码是glibc v2.32版本。

chunk

‘chunk’指的就是malloc分配内存的最小单元，我们来看下它的数据结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

/*
  This struct declaration is misleading (but accurate and necessary).
  It declares a "view" into memory allowing access to necessary
  fields at known offsets from a given base. See explanation below.
*/

struct malloc_chunk {

  INTERNAL_SIZE_T      mchunk_prev_size;  /* Size of previous chunk (if free).  */
  INTERNAL_SIZE_T      mchunk_size;       /* Size in bytes, including overhead. */

  struct malloc_chunk* fd;         /* double links -- used only if free. */
  struct malloc_chunk* bk;

  /* Only used for large blocks: pointer to next larger size.  */
  struct malloc_chunk* fd_nextsize; /* double links -- used only if free. */
  struct malloc_chunk* bk_nextsize;
};

首先INTERNAL_SIZE_T其实就是无符号整数size_t：x86-64 linux下，32位操作系统为4字节32位，64位操作系统为64位8字节，用下面的这个宏定义：

1
2
3

#ifndef INTERNAL_SIZE_T
# define INTERNAL_SIZE_T size_t
#endif

这里面的4根指针注释上都强调了只有在free了后才使用，因此使用中的chunk是长这样的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

    chunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	    |             Size of previous chunk, if unallocated (P clear)  |
	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	    |             Size of chunk, in bytes                     |A|M|P|
      mem-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	    |             User data starts here...                          .
	    .                                                               .
	    .             (malloc_usable_size() bytes)                      .
	    .                                                               |
nextchunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	    |             (size of chunk, but used for application data)    |
	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	    |             Size of next chunk, in bytes                |A|0|1|
	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

这里注意，mchunk_size最后面的3个bit是用来表示这个chunk的一些信息的，意义如下:

• A表示NON_MAIN_ARENA，记录当前 chunk 是否不属于主线程，1 表示不属于，0 表示属于。
• M表示IS_MAPPED，记录当前chunk是否由mmap分配的，1表示是，0表示不是。
• P表示PREV_INUSE，记录物理上相邻的前一个chunk是否正在使用，1表示正在使用，0表示没有。

接下来就是一些chunk的宏函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

#ifndef MALLOC_ALIGNMENT
#define MALLOC_ALIGNMENT       (2 * SIZE_SZ)
#endif

/* conversion from malloc headers to user pointers, and back */

#define chunk2mem(p)   ((void*)((char*)(p) + 2*SIZE_SZ))
#define mem2chunk(mem) ((mchunkptr)((char*)(mem) - 2*SIZE_SZ))

//#define offsetof(s,m) ((size_t)&(((s*)0)->m))
/* The smallest possible chunk */
#define MIN_CHUNK_SIZE        (offsetof(struct malloc_chunk, fd_nextsize))

/* The smallest size we can malloc is an aligned minimal chunk */

#define MINSIZE  \
  (unsigned long)(((MIN_CHUNK_SIZE+MALLOC_ALIGN_MASK) & ~MALLOC_ALIGN_MASK))

其中：

• chunk2mem(p)：偏移2*SIZE_SZ到用户真正使用的数据区

• MIN_CHUNK_SIZE:chunk的最小size。在CTF wiki的引用里面MIN_CHUNK_SIZE的定义是：

  1	#define MIN_CHUNK_SIZE (offsetof(struct malloc_chunk, fd_nextsize))

  这里offsetof()函数返回的是一个size_t，大小为结构成员相对于结构开头的偏移量，在64位操作系统下，MIN_CHUNK_SIZE是32，32位操作系统下是16。

• MINSIZE：申请最小的堆内存大小，展开后和MIN_CHUNK_SIZE一样。（虽然是个无关紧要的细节，但我没看懂为什么要定义相同的MIN_CHUNK_SIZE和MINSIZE）

检查对齐的宏：

1
2
3
4
5
6
7
8

/* Check if m has acceptable alignment */

#define aligned_OK(m)  (((unsigned long)(m) & MALLOC_ALIGN_MASK) == 0)

//SIZE_SZ = sizeof(size_t)
#define misaligned_chunk(p) \
  ((uintptr_t)(MALLOC_ALIGNMENT == 2 * SIZE_SZ ? (p) : chunk2mem (p)) \
   & MALLOC_ALIGN_MASK)

这里可以看出，申请内存大小必须是2*SIZE_SZ的整数倍，否则也会给你对齐到整数倍。

然后是把malloc请求的size转换为对应chunk的size宏和对request size做检查的宏：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

/* pad request bytes into a usable size -- internal version */

#define request2size(req)                                         \
  (((req) + SIZE_SZ + MALLOC_ALIGN_MASK < MINSIZE)  ?             \
   MINSIZE :                                                      \
   ((req) + SIZE_SZ + MALLOC_ALIGN_MASK) & ~MALLOC_ALIGN_MASK)

/* Check if REQ overflows when padded and aligned and if the resulting value
   is less than PTRDIFF_T.  Returns TRUE and the requested size or MINSIZE in
   case the value is less than MINSIZE on SZ or false if any of the previous
   check fail.  */
static inline bool
checked_request2size (size_t req, size_t *sz) __nonnull (1)
{
  if (__glibc_unlikely (req > PTRDIFF_MAX))
    return false;
  *sz = request2size (req);
  return true;
}

接下来是对chunk做一些操作的宏，从命名和定义就可以看出具体用途：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

/* size field is or'ed with PREV_INUSE when previous adjacent chunk in use */
#define PREV_INUSE 0x1
/* extract inuse bit of previous chunk */
#define prev_inuse(p)       ((p)->mchunk_size & PREV_INUSE)
/* size field is or'ed with IS_MMAPPED if the chunk was obtained with mmap() */
#define IS_MMAPPED 0x2
/* check for mmap()'ed chunk */
#define chunk_is_mmapped(p) ((p)->mchunk_size & IS_MMAPPED)
/* size field is or'ed with NON_MAIN_ARENA if the chunk was obtained
   from a non-main arena.  This is only set immediately before handing
   the chunk to the user, if necessary.  */
#define NON_MAIN_ARENA 0x4
/* Check for chunk from main arena.  */
#define chunk_main_arena(p) (((p)->mchunk_size & NON_MAIN_ARENA) == 0)
/* Mark a chunk as not being on the main arena.  */
#define set_non_main_arena(p) ((p)->mchunk_size |= NON_MAIN_ARENA)
/*
   Bits to mask off when extracting size

   Note: IS_MMAPPED is intentionally not masked off from size field in
   macros for which mmapped chunks should never be seen. This should
   cause helpful core dumps to occur if it is tried by accident by
   people extending or adapting this malloc.
 */
#define SIZE_BITS (PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
/* Get size, ignoring use bits */
#define chunksize(p) (chunksize_nomask (p) & ~(SIZE_BITS))
/* Like chunksize, but do not mask SIZE_BITS.  */
#define chunksize_nomask(p)         ((p)->mchunk_size)
/* Ptr to next physical malloc_chunk. */
#define next_chunk(p) ((mchunkptr) (((char *) (p)) + chunksize (p)))
/* Size of the chunk below P.  Only valid if !prev_inuse (P).  */
#define prev_size(p) ((p)->mchunk_prev_size)
/* Set the size of the chunk below P.  Only valid if !prev_inuse (P).  */
#define set_prev_size(p, sz) ((p)->mchunk_prev_size = (sz))
/* Ptr to previous physical malloc_chunk.  Only valid if !prev_inuse (P).  */
#define prev_chunk(p) ((mchunkptr) (((char *) (p)) - prev_size (p)))
/* Treat space at ptr + offset as a chunk */
#define chunk_at_offset(p, s)  ((mchunkptr) (((char *) (p)) + (s)))
/* extract p's inuse bit */
#define inuse(p)							      \
  ((((mchunkptr) (((char *) (p)) + chunksize (p)))->mchunk_size) & PREV_INUSE)
/* set/clear chunk as being inuse without otherwise disturbing */
#define set_inuse(p)							      \
  ((mchunkptr) (((char *) (p)) + chunksize (p)))->mchunk_size |= PREV_INUSE
#define clear_inuse(p)							      \
  ((mchunkptr) (((char *) (p)) + chunksize (p)))->mchunk_size &= ~(PREV_INUSE)
/* check/set/clear inuse bits in known places */
#define inuse_bit_at_offset(p, s)					      \
  (((mchunkptr) (((char *) (p)) + (s)))->mchunk_size & PREV_INUSE)
#define set_inuse_bit_at_offset(p, s)					      \
  (((mchunkptr) (((char *) (p)) + (s)))->mchunk_size |= PREV_INUSE)
#define clear_inuse_bit_at_offset(p, s)					      \
  (((mchunkptr) (((char *) (p)) + (s)))->mchunk_size &= ~(PREV_INUSE))
/* Set size at head, without disturbing its use bit */
#define set_head_size(p, s)  ((p)->mchunk_size = (((p)->mchunk_size & SIZE_BITS) | (s)))
/* Set size/use field */
#define set_head(p, s)       ((p)->mchunk_size = (s))
/* Set size at footer (only when chunk is not in use) */
#define set_foot(p, s)       (((mchunkptr) ((char *) (p) + (s)))->mchunk_prev_size = (s))

Bin

前面也说了，chunk是用户通过malloc申请内存的最小单元，glibc malloc不会在一个chunk free了以后马上将内存还给操作系统，而是创建了一些数据结构来接管他们，以节省再次申请时的时间，由于时间空间局部性的存在，这种设计一般来说是能起作用的（当然对于生命周期很长的程序这样的设计可能导致一大堆内存释放不掉）。在内部为了管理这些free chunk，glibc使用了一种叫bins的结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

#define NBINS 128
typedef struct malloc_chunk *mbinptr;

/* addressing -- note that bin_at(0) does not exist */
#define bin_at(m, i) \
  (mbinptr) (((char *) &((m)->bins[((i) - 1) * 2]))			      \
             - offsetof (struct malloc_chunk, fd))

/* analog of ++bin */
#define next_bin(b)  ((mbinptr) ((char *) (b) + (sizeof (mchunkptr) << 1)))

/* Reminders about list directionality within bins */
#define first(b)     ((b)->fd)
#define last(b)      ((b)->bk)
/* Normal bins packed as described above */
mchunkptr bins[NBINS * 2 - 2];

这里就能看出来，bins是一个chunk指针组成的数组，而前面chunk的数据结构定义中也有指向前一个free chunk和后一个free chunk的指针(如果这个chunk也是free的话)，也就是说，bins实际上就是一个管理free chunk的链表数组。在bins中，如果两个free chunk是物理相邻的，两个chunk就会合并以减少内存碎片，相似地，如果在bins里找不到malloc要的size大小的chunk，那么就会从大chunk中分割出一个符合size要求的chunk来，这个步骤后面的代码会看到。

bins又细分为fastbin，smallbin，largebin和unsortedbin，free chunk会根据一些规则被分到这4个组里。

Fast Bin

首先，小size的chunk在free后如果物理相邻就会被合并，但很多程序常常会申请和释放小内存块，要是每次malloc或者free小块都会进行合并和分割就会导致程序变慢，为了照顾着一些很常用的小块内存，fast bins就出现了：

1
2
3
4
5
6
7
8
9
10
11
12
13

typedef struct malloc_chunk *mfastbinptr;
//indexing
#define fastbin(ar_ptr, idx) ((ar_ptr)->fastbinsY[idx])

/* offset 2 to use otherwise unindexable first 2 bins */
#define fastbin_index(sz) \
  ((((unsigned int) (sz)) >> (SIZE_SZ == 8 ? 4 : 3)) - 2)
/* The maximum fastbin request size we support */
#define MAX_FAST_SIZE     (80 * SIZE_SZ / 4)

#define NFASTBINS  (fastbin_index (request2size (MAX_FAST_SIZE)) + 1)
/* Fastbins */
mfastbinptr fastbinsY[NFASTBINS];

NFASTBINS展开以后是10，而根据fastbin_index的定义(这个定义中的-2显然受到了MIN_CHUNK_SIZE的约束)，0和1的index不存在，因此fastbin最多cache 8个chunk，根据这个宏可以推出每个index对应的chunk size大小：

注意，在fast bins中的free chunk是LIFO的，使用单向链表实现，fast bins能fast也是基于时间空间局部性。在malloc申请一个chunk时，首先就会在fast bins中查找有没有适合的size，如果没用才会进行后面的操作：

1
2
3

/* Set if the fastbin chunks contain recently inserted free blocks.  */
/* Note this is a bool but not all targets support atomics on booleans.  */
int have_fastchunks;

BTW，fast bins中的chunk会被标记为使用中，即链表中chunk的PREV_INUSE都会被设置为1，为了防止被合并。

Small bin

顾名思义，small bins就是包含着小size chunk的bins：

1
2
3
4
5
6
7
8
9
10
11
12

#define NBINS             128
#define NSMALLBINS         64
#define SMALLBIN_WIDTH    MALLOC_ALIGNMENT
#define SMALLBIN_CORRECTION (MALLOC_ALIGNMENT > 2 * SIZE_SZ)
#define MIN_LARGE_SIZE    ((NSMALLBINS - SMALLBIN_CORRECTION) * SMALLBIN_WIDTH)

#define in_smallbin_range(sz)  \
  ((unsigned long) (sz) < (unsigned long) MIN_LARGE_SIZE)

#define smallbin_index(sz) \
  ((SMALLBIN_WIDTH == 16 ? (((unsigned) (sz)) >> 4) : (((unsigned) (sz)) >> 3))\
   + SMALLBIN_CORRECTION)

从源码中可以看出，一个chunk是small还是large，是由宏MIN_LARGE_SIZE决定的，这个size在64位操作系统上是1024，在32位系统上是512，小于它的被定义为small chunk，大于等于的是large chunk。

而根据smallbin_index(sz)的indexing规则，32位系统下(SMALLBIN_WIDTH != 16)为sz/8，64位下为sz/16，在已知sz必须和2 * SIZE_SZ(64位操作系统为16，32位操作系统为8)对齐的情况下，那么我们就能反推出small chunk总共的index数量为1024/16=64，正好和NSMALLBINS对上了！

然后我们就可以得到不同small bin的index下，每个size的chunk的一一对应关系,注意MIN_CHUNK_SIZE规定了最小的size，因此index是1和0的情况是不存在的,所以实际情况上，small bins有62个index！

fast bin是和small bin的范围有重合的，实际上，fast bins就是small bins的cache。

Large Bin

搞懂了small bins，large bins就很简单了，前面说过，比MIN_LARGE_SIZE大的chunk都称为large bins，它们是如何indexing的就看源代码怎么定义的了：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

#define largebin_index_32(sz)                                                \
  (((((unsigned long) (sz)) >> 6) <= 38) ?  56 + (((unsigned long) (sz)) >> 6) :\
   ((((unsigned long) (sz)) >> 9) <= 20) ?  91 + (((unsigned long) (sz)) >> 9) :\
   ((((unsigned long) (sz)) >> 12) <= 10) ? 110 + (((unsigned long) (sz)) >> 12) :\
   ((((unsigned long) (sz)) >> 15) <= 4) ? 119 + (((unsigned long) (sz)) >> 15) :\
   ((((unsigned long) (sz)) >> 18) <= 2) ? 124 + (((unsigned long) (sz)) >> 18) :\
   126)

#define largebin_index_32_big(sz)                                            \
  (((((unsigned long) (sz)) >> 6) <= 45) ?  49 + (((unsigned long) (sz)) >> 6) :\
   ((((unsigned long) (sz)) >> 9) <= 20) ?  91 + (((unsigned long) (sz)) >> 9) :\
   ((((unsigned long) (sz)) >> 12) <= 10) ? 110 + (((unsigned long) (sz)) >> 12) :\
   ((((unsigned long) (sz)) >> 15) <= 4) ? 119 + (((unsigned long) (sz)) >> 15) :\
   ((((unsigned long) (sz)) >> 18) <= 2) ? 124 + (((unsigned long) (sz)) >> 18) :\
   126)

// XXX It remains to be seen whether it is good to keep the widths of
// XXX the buckets the same or whether it should be scaled by a factor
// XXX of two as well.
#define largebin_index_64(sz)                                                \
  (((((unsigned long) (sz)) >> 6) <= 48) ?  48 + (((unsigned long) (sz)) >> 6) :\
   ((((unsigned long) (sz)) >> 9) <= 20) ?  91 + (((unsigned long) (sz)) >> 9) :\
   ((((unsigned long) (sz)) >> 12) <= 10) ? 110 + (((unsigned long) (sz)) >> 12) :\
   ((((unsigned long) (sz)) >> 15) <= 4) ? 119 + (((unsigned long) (sz)) >> 15) :\
   ((((unsigned long) (sz)) >> 18) <= 2) ? 124 + (((unsigned long) (sz)) >> 18) :\
   126)

#define largebin_index(sz) \
  (SIZE_SZ == 8 ? largebin_index_64 (sz)                                     \
   : MALLOC_ALIGNMENT == 16 ? largebin_index_32_big (sz)                     \
   : largebin_index_32 (sz))

#define bin_index(sz) \
  ((in_smallbin_range (sz)) ? smallbin_index (sz) : largebin_index (sz))

看一下这个嵌套三元表达式的宏就知道，large bins一共分为了6组，每组的index个数可以从移位算符得出，算一算就可以知道它们一一对应到表里，glibc内存管理ptmalloc源码分析里有完整的数据，这里给出CTF wiki的比较简短的总结：

Unsorted Bin

源码定义如下：

1
2

/* The otherwise unindexable 1-bin is used to hold unsorted chunks. */
#define unsorted_chunks(M)          (bin_at (M, 1))

可见unsorted bin定义在了bins的第一个index下，因此unsorted bin只是一个链表。

Top Chunk

glibc对top chunk定义和描述如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

/*
   Top

    The top-most available chunk (i.e., the one bordering the end of
    available memory) is treated specially. It is never included in
    any bin, is used only if no other chunk is available, and is
    released back to the system if it is very large (see
    M_TRIM_THRESHOLD).  Because top initially
    points to its own bin with initial zero size, thus forcing
    extension on the first malloc request, we avoid having any special
    code in malloc to check whether it even exists yet. But we still
    need to do so when getting memory from system, so we make
    initial_top treat the bin as a legal but unusable chunk during the
    interval between initialization and the first call to
    sysmalloc. (This is somewhat delicate, since it relies on
    the 2 preceding words to be zero during this interval as well.)
 */

/* Conveniently, the unsorted bin can be used as dummy top on first call */
#define initial_top(M)              (unsorted_chunks (M))

根据注释描述，所谓的top chunk就是位于可用堆内存地址最高位的chunk，它不属于任何bin，只有当没有chunk可用时它才会向系统去申请扩展heap的可用区域。为防止被合并，top chunk的prev_inuse始终为1。初始情况时，unsorted chunks用作top chunk。

现在总结一下，宏NBINS告诉我们bins一共有108个入口，small bins有62个，large bins一共有63个，加起来125个bin，根据bin的indexing宏bin_at的定义，bin[0]和bin[127]是不存在的，因此bin[1]就是top chunk，也是unsorted bin，加起来总共126个。

BTW，bins的定义是：

1

mchunkptr bins[NBINS * 2 - 2];

也就是实际size有NBINS * 2 - 2一共254个mchunkptr，而chunk实例的是6个mchunkptr的大小，这怎么存的下呢？但我们注意到，bins中的chunk是头节点，那么chunk中的mchunk_prev_size和mchunk_size是没有意义的！而fd_nextsize和bk_nextsize只有large chunk才会用到，那么出于节省内存的想法，我们只需要2个mchunkptr，总共需要的就是126*2=254个mchunkptr的大小，正好对上了！

总之，glibc的malloc使用的内存管理方法就是链表数组的内存池，和gnu C++远古版本std allocator是相同的思想，因此在后面版本的gnu C++里面默认allocator都是封装malloc，如果看了侯捷的STL源码剖析，别被书里推崇无比的内存池allocator误导了。

其他核心结构

malloc_state

定义如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

struct malloc_state
{
  /* Serialize access.  */
  __libc_lock_define (, mutex);

  /* Flags (formerly in max_fast).  */
  int flags;

  /* Set if the fastbin chunks contain recently inserted free blocks.  */
  /* Note this is a bool but not all targets support atomics on booleans.  */
  int have_fastchunks;

  /* Fastbins */
  mfastbinptr fastbinsY[NFASTBINS];

  /* Base of the topmost chunk -- not otherwise kept in a bin */
  mchunkptr top;

  /* The remainder from the most recent split of a small request */
  mchunkptr last_remainder;

  /* Normal bins packed as described above */
  mchunkptr bins[NBINS * 2 - 2];

  /* Bitmap of bins */
  unsigned int binmap[BINMAPSIZE];

  /* Linked list */
  struct malloc_state *next;

  /* Linked list for free arenas.  Access to this field is serialized
     by free_list_lock in arena.c.  */
  struct malloc_state *next_free;

  /* Number of threads attached to this arena.  0 if the arena is on
     the free list.  Access to this field is serialized by
     free_list_lock in arena.c.  */
  INTERNAL_SIZE_T attached_threads;

  /* Memory allocated from the system in this arena.  */
  INTERNAL_SIZE_T system_mem;
  INTERNAL_SIZE_T max_system_mem;
};

这里就可以看到，前面所说的bins是malloc_state的一部分，因此一个malloc_state的实例就是一个分配区域，下面一一说明这些变量：

flags是一些标志位，它的用途从后面的宏定义就可以看出来：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

/*
   NONCONTIGUOUS_BIT indicates that MORECORE does not return contiguous
   regions.  Otherwise, contiguity is exploited in merging together,
   when possible, results from consecutive MORECORE calls.

   The initial value comes from MORECORE_CONTIGUOUS, but is
   changed dynamically if mmap is ever used as an sbrk substitute.
 */

#define NONCONTIGUOUS_BIT     (2U)

#define contiguous(M)          (((M)->flags & NONCONTIGUOUS_BIT) == 0)
#define noncontiguous(M)       (((M)->flags & NONCONTIGUOUS_BIT) != 0)
#define set_noncontiguous(M)   ((M)->flags |= NONCONTIGUOUS_BIT)
#define set_contiguous(M)      ((M)->flags &= ~NONCONTIGUOUS_BIT)

这里就是用flags的第2位来判断MORECORE是否返回了连续的虚拟地址空间，0为是，1为否。实际上MORECORE就是系统调用sbrk()，只是经过了重重包装：

1
2
3
4
5
6
7
8
9
10
11
12

#define MORECORE         (*__morecore) 
void * __default_morecore (ptrdiff_t);
void *(*__morecore)(ptrdiff_t) = __default_morecore;
void *
__default_morecore (ptrdiff_t increment)
{
  void *result = (void *) __sbrk (increment);
  if (result == (void *) -1)
    return NULL;

  return result;
}

have_fastchunk用来表示这个分配区域是否有fast chunk。以前版本的glibc malloc是用flags的第1位来判断是否有fast chunk的，定义宏的方法和contiguous是一样的，但我看的这个版本是在malloc_state定义了一个have_fastchunk来判断，感觉新的版本有点浪费内存资源了。

fastbinsY，前面已经说过了，存储fast chunk链表指针的数组。

top，指向bins top chunk的指针。

last_remainder，指向chunk的指针， 分配区上次分配 small chunk 时，从一个 chunk 中分 裂出一个 small chunk 返回给用户， 分裂后的剩余部分形成一个 chunk，last_remainder 就是 指向的这个 chunk 。

bins：前面说过了，存储chunk的链表指针数组，分为unsorted bin，fast bin，small bin， large bin，bin[0]不存在，bin[1]是unsorted bin。

binmap：一个int数组，关于它的用途，可以看下面部分的代码：

1
2
3
4
5
6
7
8
9
10
11

/* Conservatively use 32 bits per map word, even if on 64bit system */
#define BINMAPSHIFT      5
#define BITSPERMAP       (1U << BINMAPSHIFT)
#define BINMAPSIZE       (NBINS / BITSPERMAP)

#define idx2block(i)     ((i) >> BINMAPSHIFT)
#define idx2bit(i)       ((1U << ((i) & ((1U << BINMAPSHIFT) - 1))))

#define mark_bin(m, i)    ((m)->binmap[idx2block (i)] |= idx2bit (i))
#define unmark_bin(m, i)  ((m)->binmap[idx2block (i)] &= ~(idx2bit (i)))
#define get_binmap(m, i)  ((m)->binmap[idx2block (i)] & idx2bit (i))

这里可以看出BINMAPSIZE的值是128/32=4，我们知道int是32位，那么binmap实际上就是一个128位的buffer，这些宏就是在定义每一位对应每一个bins的映射关系，ptmalloc就使用这些位来标记对应bin中是否有free chunk。

next：一根指向下一个分配区的指针。

next_free：一根指向下一个free分配区的指针。

system_mem：记录当前分配去已经分配的内存大小。

max_system_mem：记录当前分配去最大能分配的内存大小。

malloc_par

定义如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

struct malloc_par
{
  /* Tunable parameters */
  unsigned long trim_threshold;
  INTERNAL_SIZE_T top_pad;
  INTERNAL_SIZE_T mmap_threshold;
  INTERNAL_SIZE_T arena_test;
  INTERNAL_SIZE_T arena_max;

  /* Memory map support */
  int n_mmaps;
  int n_mmaps_max;
  int max_n_mmaps;
  /* the mmap_threshold is dynamic, until the user sets
     it manually, at which point we need to disable any
     dynamic behavior. */
  int no_dyn_threshold;

  /* Statistics */
  INTERNAL_SIZE_T mmapped_mem;
  INTERNAL_SIZE_T max_mmapped_mem;

  /* First address handed out by MORECORE/sbrk.  */
  char *sbrk_base;

#if USE_TCACHE
  /* Maximum number of buckets to use.  */
  size_t tcache_bins;
  size_t tcache_max_bytes;
  /* Maximum number of chunks in each bucket.  */
  size_t tcache_count;
  /* Maximum number of chunks to remove from the unsorted list, which
     aren't used to prefill the cache.  */
  size_t tcache_unsorted_limit;
#endif
};

各个变量的意义如下（摘自ptmalloc源码剖析）：

trim_threshold字段表示收缩阈值，默认为 128KB，当每个分配区的 top chunk 大小大于 这个阈值时，在一定的条件下，调用 free 时会收缩内存，减小 top chunk 的大小。由于 mmap 分配阈值的动态调整，在 free 时可能将收缩阈值修改为 mmap 分配阈值的 2 倍，在 64 位系 统上， mmap 分配阈值最大值为 32MB，所以收缩阈值的最大值为 64MB，在 32 位系统上， mmap 分配阈值最大值为 512KB，所以收缩阈值的最大值为 1MB。 收缩阈值可以通过函数 mallopt()进行设置。

top_pad 字段表示在分配内存时是否添加额外的 pad，默认该字段为 0。 mmap_threshold 字段表示 mmap 分配阈值，默认值为 128KB，在 32 位系统上最大值为 512KB， 64 位系统上的最大值为 32MB，由于默认开启 mmap 分配阈值动态调整，该字段的 值会动态修改，但不会超过最大值。

arena_test 和arena_max 用于 PER_THREAD 优化，在 32 位系统上 arena_test默认值为 2， 64 位系统上的默认值为 8， 当每个进程的分配区数量小于等于 arena_test 时，不会重用已有 的分配区。为了限制分配区的总数，用 arena_max 来保存分配区的最大数量，当系统中的分 配区数量达到 arena_max，就不会再创建新的分配区，只会重用已有的分配区。 这两个字段 都可以使用 mallopt()函数设置。

n_mmaps 字段表示当前进程使用 mmap()函数分配的内存块的个数。 n_mmaps_max 字段表示进程使用 mmap()函数分配的内存块的最大数量，默认值为 65536，可以使用 mallopt()函数修改。 max_n_mmaps字段表示当前进程使用 mmap()函数分配的内存块的数量的最大值，有关 系 n_mmaps <= max_n_mmaps 成立。 这个字段是由于 mstats()函数输出统计需要这个字段。 no_dyn_threshold 字段表示是否开启 mmap 分配阈值动态调整机制，默认值为 0，也就 是默认开启mmap 分配阈值动态调整机制。 pagesize 字段表示系统的页大小，默认为 4KB。 mmapped_mem 和 max_mmapped_mem 都用于统计mmap 分配的内存大小，一般情况 下两个字段的值相等， max_mmapped_mem用于mstats()函数。 max_total_mem 字段在单线程情况下用于统计进程分配的内存总数。 sbrk_base字段表示堆的起始地址。

References：

[1]. https://ctf-wiki.github.io/ctf-wiki/pwn/linux/glibc-heap/heap_structure-zh

[2].glibc内存管理ptmalloc源码分析

7.2 第六章 关于C语言方面的问题(C Language Issues)

“终有一天你将会明白”

—— Neel Mehta ，X-Force互联网安全系统高级研究员

7.2.1 概论

当你正在检查软件并覆盖潜在的安全漏洞时，理解编程语言底层如何实现数据类型以及运算的细节，以及这些细节会如何影响到执行流(execution flow)非常重要。审计员在汇编层面上检查应用程序二进制能够明确地看出数据是怎样存储以及更改的，以及对数据块操作的确切含义。然而，当你在源代码的层面上对应用程序进行审计时，一些细节就显得抽象并且不那么显然了。这种抽象能够导致一些软件中存在微妙的漏洞，这些漏洞在很长时间内不会被注意并修正。一个彻底的审计者应该熟悉源代码使用的语言的底层实现，并且熟悉这些实现细节会如何在边缘情况或者特殊情况下导致安全方面的问题。

本章将会对C语言细微的细节进行探讨，这些细节能够对应用程序的安全以及鲁棒性产生不利的影响。特别地，本章将会讨论原始数据类型(primitive types)的存储，算术溢出以及下溢的情况，类型转换问题，符号位扩展以及截断。你也会看到一些C语言有趣的细微差别， 包括来自某些操作符和其他通常不被重视的行为导致的意外结果。虽然本章的重点是C语言，但很多原则也可以应用到其他语言上。

7.2.2 C语言背景

本章会明确地讨论C语言的特性并且使用从C语言标准中定义的各种术语。你不必去查阅相关标准文献来配合食用，不过本章会明确地使用最新发布的C99标准草案(ISO/IEC 9899:1999)，关于C99标准，可以在下面链接找到： www.open-std.org/jtc1/sc22/wg14/www/standards.

标准草案附带的C Rationale文档也很有用， 有兴趣的读者可以看看Peter Van der Linden的优秀图书Expert C Programming， Kernighan与Ritchie写的The C Programming Language。如果你对购买ISO标准的最终版本或旧的ANSI标准感兴趣的话，两者都在ANSI组织的网站出售 (www.ansi.org).

虽然这一章包含了一个最近的标准，但是内容针对的是目前C的主流使用，特别是ANSI C89/ISO 90标准。因为我们要讨论底层的安全细节，所以会添加关于跨版本C变更相关的任何情况的注释。

在讨论标准时，偶尔会用到术语“未定义的行为”(undefined behavior)和“实现定义的行为”(implementation-defined behavior)。未定义行为是错误行为:编译器不需要处理的条件，因此会产生未指定的结果。实现定义的行为是由底层实现决定的行为。应该以一种一致的、合乎逻辑的方式来处理它，处理它的方法应该文档化。

7.2.3 数据存储概述

在深入研究C的细节之前，应该回顾一下C类型的基础知识，特别是它们的存储大小、值范围和表示。本节从一般的角度解释类型，探索诸如二进制编码、二进制补码算法和字节顺序约定等细节，并以一些常见和未来实现的实用观察作为结束。

C标准将对象定义为执行环境中的数据存储区域;它的内容可以表示值。每个对象都有一个相关联的类型:一种解释存储在该对象中的值并赋予其意义的方法。在C标准中定义了许多类型，但本章主要关注以下内容 ：

• 字符类型。有三种字符类型，分别是char, signed char, unsigned char。所有三种类型都在存储中占用1个字节，不管char类型是否是带有符号的。大多数系统当前都默认char是带富豪的，尽管编译器的标志(flags)通常能够更改这个行为
• 整数类型。有4中标准的带符号整数类型，包括short int, int ,long int, long long int。每个标准带符号整数类型都对应了不带符号的整数类型，并且对应的存储大小都相同。(注：long long int是在C99标准时才出现的新类型)
• 浮点型。有三种实数浮点型和三种复数浮点型。实数浮点型是float, double, long double，三种复数型是float_Complex, double_Complex, long double_Complex。(注：复数类型是C99标准时才出现的新类型。)
• 位字段(bit fields)。位字段是对象中的特定位数。 位字段可以是带符号的和无符号的，取决于它们的声明。 如果没有给出符号类型说明符，则位字段的符号依赖于实现。

注

位字段可能对于一些程序员来说并不熟悉，因为它们通常不会出现在网络代码(network code)或低层级代码之外。 下面是一个关于位字段的例子：

1
2
3
4
5
6
7
8
9

struct controller
{
    unsigned int id:4;
    unsigned int tflag:1;
    unsigned int rflag:1;
    unsigned int ack:2;
    unsigned int seqnum:8;
    unsigned int code:16;
};

controller结构中有很多数。id表示一个4位的无符号整数，tflag，rflag表示1位，ack是两位，seqnum是8位，code是16位。 这种结构的成员很可能被布局成内存中一个32位区域内的连续位。

从抽象的角度来看，每个整数类型(包括字符类型)都表示了一个占不同大小空间的整数，编译器可以将它们映射到合适的由底层架构决定(underlying architecture-dependent)的数据类型。每个字符会占用1字节的存储(尽管1字节可能不一定等于8位).sizeof(char)会一直是1，你也可以一直使用无符号字符的指针，sizeof和memcpy()来检查和操作其他类型的实际内容。 其他整数类型具有一定范围的值，它们必须能够表示这些值，并且它们之间必须保持一定的关系（例如long不能比short小）， 但除此之外，它们的实现很大程度上取决于它们的架构和编译器。

带符号整数类型能够表示正数和负数，但无符号类型只能表示正数。每个带符号整数类型都有一个对应的无符号整数类型，并且占用相同的存储空间。无符号整数类型有两种不同的位：数位(value bits)包含对象值实际的2进制表示，填充位(padding bits) 是可选的，且标准未指定。带符号整数除了数位和填充位还有额外的一个位：符号位。 如果符号位在有符号整数类型中是清晰的，则其对值的表示与该值在相应的无符号整数类型中的表示相同。 换句话说，不管它是存储在整型还是无符号整型中，正42的底层位模式都应该是相同的。

整数类型有精度和宽度。精度是整型使用的值位数。宽度是类型用于表示其值的位数，包括值和符号位，但不包括填充位。对于无符号整数类型，精度和宽度是相同的。对于有符号整数类型，宽度比精度大1。

程序员能够用多种方式调用不同的类型。对于整数类型，例如short int，程序员通常可以省略int关键字，因此关键字signed short int, signed short, short int和short表示同一数据类型。一般地，如果signed和unsigned关键字被省略了，那么数据类型就会被假定为带符号类型。但是，这种假设对于char类型不成立，因为它是否为带符号取决于具体实现。(通常，char类型是带符号的，如果你想100%确定一个带符号的字符类型，你可以在声明时直接使用signd char。)

C语言还通过typedef 支持丰富的类型别名系统。 因此，程序员通常在指定已知大小和表示形式的变量时做一些约定。例如在UNIX和网络编程中，int8_t, uint8_t, int32_t, u_int32_t就很受程序员欢迎。它们分别表示8位带符号整数，8位无符号整数，32位带符号整数，32位无符号整数。 Windows程序员倾向于使用BYTE、CHAR和DWORD等类型，它们分别对应为8位无符号整数、8位带符号整数和32位无符号整数 。

二进制编码

（这里作者想要cover到所有架构的东西，以至于很多地方为了叙述严谨而导致很啰嗦，建议这一部分参考主要讲述Intel架构的CSAPP —by译者）

无符号整数值通过纯粹的二进制形式进行编码，也就是二进制的计数系统。每个位是0或者1，表示这一位所对应的2的指数所贡献的值。将一个表示为二进制的正数转换为十进制，只需要将第n位对应的数乘以2n−1再全部加起来就可以了，例如下面的例子：

\[00011011=24+23+21+20=27\]

\[00001111=23+22+21+20=15\]

\[00101010=25+23+21=42\]

相近地，将一个十进制表示的正数转换为二进制，只需要不断将它除以2直到结果为0，然后取结果的余数从最高位开始作为对应的数就可以了，例如下面的例子： $$ 55=32+16+4+2+1\

=25+24+22+21+20\

=00110111\

37=32+4+1\

=25+22+20\

=00100101 $$

有符号整数使用符号位以及数位和填充位。C标准给出了三种可能的算术方案，因此也给出了符号位的三种可能解释：

• 符号和幅度(sign and magnitude)数的符号在符号位中存储，1代表负数0代表正数。数的幅度保存在数位中。这种方案对于人类来说简单易读易理解，但对于计算机来说很难处理，因为它们不得不明确地对于算术操作去比较幅度和符号。
• 二进制反码(ones complement)同样，符号位中1代表负数0代表正数。正数值能够直接从数位中读取。然而，负数值不行，首先要将整个数都取反。在二进制反码中，取反的意思就是将所有位的0和1反转。为了找出一个负数的值，你必须先将它们的位都转回来。这个系统对于计算机来说更好一些，但仍然还有一些在加法上问题，以及就像符号和幅度表达的方法一样，对于两个这样的值会造成歧义：正0和负0。
• 二进制补码(twos complement)符号位中1作为负数0作为正数。可以从正数值中直接从数位中读取大小，但无法从负数中的数位中直接读取。首先也需要将所有数位反转。在二进制补码中，反转操作意味着所有数位0和1反转，然后再加上1。这种方法对于机器来说能够非常好地工作，并且移出了会存在两个0的歧义。

（关于反码和补码为什么能在机器上很好地工作，本质上是一些数学性质上的优势，和本书给出的定义相反，从线性空间的角度去考量二进制补码和反码会显得非常直观与显然，关于这部分细节可以参考CSAPP的第二章相关部分——by译者）

正数通常在内部被表示为二进制补码，特别是在现代计算机中。就像前面提到的，二进制补码将正数编码为标准的二进制编码形式。正数值的范围取决于数位的位数。一个使用二进制补码的8位带符号整数有7个数位和1个符号位，7个数位能够表示从0到127。二进制补码将所有的负数值按照前面所述的方式编码，范围从-128到-1。也就是说，8位带符号整数能够表示-128到127的整数。

对于算术来说， 符号位放置在数据类型的最重要位中。 一般地，一个宽度为x的带符号补码能够表示的数范围为−2x−1到2x−1−1。下面的表显示了不同典型宽度补码能表示的数的范围。

就先前面所述的，补码将所有数位反转并加1，下面的表给出了-15的补码表示：

1

0000 1111 15的标准二进制表示1111 0000 反转所有的位0000 0001 加11111 0001 -15的二进制补码1101 0110 一个不知道具体值的负数的二进制补码0010 1001 反转所有位0000 0001 加10010 1010 42的二进制形式，因此最初的值是-42

位的次序

在现代架构中，有两种将数位字节排序的约定：大端(big endian)和小端(little endian)。这些约定会使用于大于1个字节的数据类型，例如short和int型。在大端架构中，字节在内存中从最大位的字节开始到最小位的字节结束。小端在内存中的排布方式相反。例如，你有一个4位的整数，它的值位1234。在二进制中，它的值是11000000111001。这个值位于内存地址500的位置。在大端机器中，它会在内存中如此放置：

1
2
3
4

地址 500: 00000000
地址 501: 00000000
地址 502: 00110000
地址 503: 00111001

在小端机器中，它会这样放置：

1
2
3
4

地址 500: 00111001
地址 501: 00110000
地址 502: 00000000
地址 503: 00000000

因特尔机器是小端方式的，但是RISC机器，例如SPARC是大端方式的。一些机器能够同时应对两种约定。

常见的实现

从实践的角度讲，对于现代的，32位补码机器， 关于C的基本类型及其表示，你能说些什么 ？一般地，整数型不会带有填充位，所以你不需要考虑它。任何数都是用补码来表示的。一个字节会有8位的长度。字节的排序也有不同，在Intel机器上是小端方式，在RISC上是大端方式。

char类型默认为带符号类型并且占用1个字节。short类型占用2字节，int类型占用4字节。long型占4字节，long long型占8字节。在知道了整数是使用补码编码的，以及它们底层中占用的空间大小，得到它们能表示的最大和最小值就很简单了，下面的表总结了一些常见的整数类型数据在32位机器上所占空间大小与范围。

当不久的将来64位机器更加普及时会怎样？ 下面的列表描述了一些目前正在使用或已经被提议的类型系统：

• ILP32 int，long，指针为32位，和所有32位机器的标准一样
• ILP32LL int， long，指针为32位，新的类型long long为64位。long long是C99标准中新增的，标准中规定它要有不小于64位大小，但它不悔更高任何语言的基础特性。
• LP64 int， long，指针都为64位。int型更改为了64位， 这对该语言具有相当重要的意义。
• ILP64 long和指针为64位，也就是指针和long类型从32位变成了64位
• LLP64 指针和新的数据类型long long为64位。int和long型仍为32位。

下面的表简单总结了这些类型对应系统的大小：

如你所见，常见的数据类型的大小中，ILP32模型是32位平台上大多数编译器所遵循的。 LP64模型是为64位平台生成代码的编译器的真实标准。正如你在本章后面学到的，int类型是C语言的基本单元;许多东西都在幕后从它转换而来。由于int数据类型在表达式计算中非常依赖，LP64模型是64位系统的理想选择，因为它不会改变int数据类型;因此，它在很大程度上保留了预期的C类型转换行为。

7.2.4 算术边界条件

你已经了解了C的基本整数类型的最小和最大可能值是由它们在内存中的底层表示决定的。上面的表给出了32位补码体系结构的典型范围。 所以，现在你可以探索当你尝试跨越这些边界时会发生什么。对变量进行简单的算术运算，如加法、减法或乘法，可能会导致无法在该变量中保存值。看一下这个例子

1

unsigned int a;a=0xe0000020;a += 0x20000020；

你知道a可以没有任何问题地赋值为0xE0000020；无符号32位整数地最大值为4,294,967,295或者0xFFFFFFFF。然而，当0x20000020和0xE0000000相加后，理论上的结果值0x100000040无法被变量a容纳。当一个算术运算的结果值大于最大可能的表示数值时，我们就称他为数字溢出条件。

下面是一个有点不一样的例子：

1
2
3

unsigned int a;
a=0;
a-=1;

这个程序将a减去1，a的初始值为0，因此运算结果理论上为-1，但它不能被a容纳因为它小于了a的最小可能值0.这个结果被称为数字下溢条件。

注

数值溢出条件在安全编程文献中也称为数值溢出(numeric overflows)、算术溢出(arithmetic overflows)、整数溢出(integer overflows)或整数环绕(integer wrapping) 。数值下溢条件可称为数值下溢(numeric underflows)、算术下溢(arithmetic underflows)、整数下溢(integer underflows)或整数环绕。具体来说，可以使用术语“环绕一个值(wrapping around a value)”或“在0以下环绕(wrapping below zero)”。

(为什么叫wrapping，因为无论是underflow还是overflow都是从一个边界（上界或者下界）跳到另一个边界，就像一个闭环一样，至于为什么是闭环，主要是CPU的ALU在进行补码加法运算时会将溢出位舍去，详见CSAPP第二章的整数运算小节 —by译者)

尽管这些条件在实际代码中似乎并不常见或无关紧要，但它们实际上经常发生，而且从安全角度来看，它们的影响可能非常严重。算术运算的错误结果会破坏应用程序的完整性，并经常导致其安全性的损害。在代码块早期出现的数字溢出或下溢可能导致一系列微妙的级联错误(series of cascading faults);不仅单个算术操作的结果受到污染，而且后续使用该污染结果的每个操作都会引入一个攻击者可能会产生意外影响的点。

注

尽管数值环绕在大多数编程语言中很常见，但它在C/ C++程序中是一个特殊的问题，因为C要求程序员执行低级任务，而这些低级任务由更抽象的高级语言自动处理。这些任务，如动态内存分配和缓冲区长度跟踪，通常需要运行一些容易受到攻击的计算。攻击者通常通过操纵长度计算来利用算术边界条件，以便分配足够的内存。如果发生这种情况，程序以后就会冒在已分配空间的边界之外操作内存的风险，这通常会导致可利用的情况。另一种常见的攻击技术是绕过保护敏感操作(如内存副本)的长度检查。本章提供了几个例子，说明如何下溢和溢出条件导致可利用的漏洞。通常，审计人员在检查代码时应该注意算术边界条件，并确保考虑到这些细微的、层叠的缺陷可能带来的影响。

警告

我们在示例中尝试使用int和unsigned int类型，以避免代码受到C默认类型提升的影响。这个主题在本章后面“类型转换”中会提到，但现在，请注意，当你在C语言的算术表达式中使用char或short时，它会在算术执行之前被转换成int。

无符号整数边界

在C规范中，无符号整数被定义为服从模运算规则(参见“模运算”侧栏)。对于一个使用X位存储空间的无符号整数，该整数的算术运算以2X为模进行。例如，对8位无符号整数的运算以28或256为模进行。再看看这个简单的表达式 :

1
2
3

unsigned int a;
a=0xE0000020;
a+=0x20000020;

加法运算的模为232,或者4,294,967,296 (0x100000000)。加法的结果为0x40，也就是(0xE0000020 + 0x20000020)取0x100000000的模。

另一种概念化它的方法是将数字溢出结果的额外位视为截断。如果以二进制方式进行计算0xE0000020 + 0x20000020，将得到以下结果：

1
2
3

  1110 0000 0000 0000 0000 0000 0010 0000
+ 0010 0000 0000 0000 0000 0000 0010 0000
= 1 0000 0000 0000 0000 0000 0000 0100 0000

真实得到的a的结果是0x40，二进制形式为 0000 0000 0000 0000 0000 0000 0100 0000。

(其实Intel的CPU就是这么做的，ALU在做加法运算发生溢出时，溢出的进位会被舍掉，传到overflow flag里，详见CSAPP第二章—by译者)

模运算

模运算是计算机科学中广泛使用的一种运算系统。“X取Y的模”表示“X除以Y的余数”例如，100对11取余是1因为100除以11，结果是9余数是1。C中的模数运算符被写成%。因此在C中，表达式(100% % 11)的值为1，表达式(100 / 11)的值为9。

模运算对于确保数字被限制在一定范围内很有用，你经常在哈希表中看到它用于这个目的。解释一下，当X取Y的模，X和Y都是正数，结果的最大值是Y-1最小值是0。如果您有一个包含100个buckets的哈希表，并且你需要将一个哈希映射到其中一个bucket，那么你可以这样做：

1
2
3
4

struct bucket *buckets[100];
...
bucket = buckets[hash % 100];

对于模运算是如何工作的，可以见下面的简单循环：

1
2
3

for (i=0; i<20; i++)
	printf("%d ", i % 6);
printf("\n");

表达式(i% 6)本质上限定了i在0到5之间的范围。当程序运行时，它输出如下内容:

1

0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 0 1

可以看到，当i从0上升到19时，i%6也上升了，但是每次它达到最大值5时，它就会返回到0。当你通过这个值向前移动时，你将环绕最大值5。如果向后移动这些值，则将从0”向下”环绕到最大值为5。

—- 以下内容接标题“模运算”之前—-

你可以看到它和加法的结果是一样的，但是没有最高位。这与机器层面的情况相差无几。例如，Intel架构有一个carry flag(CF)，它包含最高位。C语言没有允许访问这个标志的机制，但是根据底层架构，可以通过汇编代码来检查它。

下面是由于乘法而发生的数字溢出条件的示例 ：

1
2
3

unsigned int a;
a=0xe0000020;
a*= 0x42;

同样，以0x100000000为模进行算术运算。乘法的结果是0xC0000840，它是(0xE0000020 * 0x42)取0x100000000的模。下面是二进制表示：

1
2
3

          1110 0000 0000 0000 0000 0000 0010 0000
*         0000 0000 0000 0000 0000 0000 0100 0010
= 11 1001 1100 0000 0000 0000 0000 1000 0100 0000

实际上得到的结果是0xC0000840，它的二进制表示形式是1100 0000 0000 0000 0000。再一次，你可以看到不适合结果的较高位是如何被有效地截断的。在机器级别，通常可以检测整数乘法的溢出，并恢复乘法的高位。例如，在Intel上，imul指令在进行乘法运算时使用的目标对象大小是源操作数的两倍，如果乘法运算的结果需要大于源操作数的宽度，则imul指令将设置OF(overflow flag)和CF (carry flag)标志。一些代码甚至使用内联汇编来检查数值溢出(在本章后面的边栏“Intel上的乘法溢出”中讨论).

你已经看到了一些例子，它们说明了加法和乘法是如何导致算术溢出的。另一个可能导致溢出的操作符是左移，在本讨论中，它可以被认为是与2的乘法。它的行为与乘法非常相似，因此这里没有提供示例。

现在你可以来看一些与无符号整数算术溢出相关的安全问题了。下面的代码是最近在客户机代码中发现的可利用条件的经过清理、编辑的版本：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

u_char *make_table(unsigned int width, unsigned int height,
				u_char *init_row)
{
	unsigned int n;
	int i;
	u_char *buf;
	n = width * height;
	buf = (char *)malloc(n);
	if (!buf)
		return (NULL);
	for (i=0; i< height; i++)
		memcpy(&buf[i*width], init_row, width);
	return buf;
}

makr_table()函数的目的是获取宽度(width)，高度(height)，以及初始行(init_row)在内存中创建一个表格，每行初始化为和init_row相同的值。即假定用户能用width和height控制表格的维度。如果他们使用了一个非常大的维度，例如width设置为1,000,000，宽度设置为3,000，那么malloc()函数就会尝试申请3,000,000,000字节的内存空间。内存分配可能会失败，然后所调用的函数检测到错误以后会优雅地去处理它。然而，用户可以用它在width和height的相乘中造成算术溢出，只要将维度设置的足够大。潜在来说这种溢出已经可以被利用了，因为内存分配在width和height相乘后完成，而表格的初始化是在后面的for循环中进行的。因此如果我将width设置为0x40，height设置为0x1000001，乘法的结果就会是0x400000400，这个值对0x100000000的模是0x00000400，用十进制表示就是1024.所以1024个字节会被分配，但for循环会将init_row严格地进行1600万次复制。一个聪明的攻击者就能够通过进程运行时环境的底层细节来利用这种溢出获得整个应用程序的控制权。

现在再来看一个和上面例子相近的真实漏洞案例，这个例子发现于在OpenSSH 服务器。下面的代码来自OpenSSH 3.1问答认证(challenge-response authentication)代码：auth2-chall.c中的input_userauth_info_response()函数：

1
2
3
4
5
6
7
8
9

	u_int nresp;
...
	nresp = packet_get_int();
	if (nresp > 0) {
		response = xmalloc(nresp * sizeof(char*));
		for (i = 0; i < nresp; i++)
			response[i] = packet_get_string(NULL);
	}
	packet_check_eom()

无符号整数nresp是用户能够控制的，它的目的是告诉服务器有多少响应。它被用来分配response[]数组然后将这个网络数据填充进去。在response[]数组通过xmalloc()的调用分配后，resp会乘以sizeof(char*)，也就是4个字节。如果用户将nresp设置得足够大，算术溢出就会发生，然后乘法的结果就可能会变成一个较小的数。例如，如果nresp的值是0x40000020，乘法的结果就会是128(0x80),因此，0x80个字节就会被分配，但for循环会尝试将0x40000020个字符从packet取出然后送到response[]里！这就是一个可以远程利用的危险漏洞。

现在将注意力集中到算数下溢上。对于无符号整数，做减法时可能会导致一个值从最小可表示值0环绕。由于取模的过程，最终下溢的结果会是一个非常大的正数。下面是一个简短的例子：

1
2

unsigned int a;
a=0x10;a-=0x30;

我们来看一下二进制下的计算:

1
2
3

  0000 0000 0000 0000 0000 0000 0001 0000
- 0000 0000 0000 0000 0000 0000 0011 0000
= 1111 1111 1111 1111 1111 1111 1110 0000

最终a的结果会是0xffffffe0，在二进制补码的表示下是一个负数-0x20。但在模运算的前提下，如果你将数值移动超过了最大可能的值，那你就会在0处环绕。类似的情况也会在你低于最小值时发生：你将会环绕到最大的数值上。由于a是一个unsigned int型，因此它的值在减法后就会是0xffffffe0而不是-0x20。限免的代码是一个关于无符号整数算数下溢的例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

struct header {
	unsigned int length;
	unsigned int message_type;
};
char *read_packet(int sockfd)
{
	int n;
	unsigned int length;
	struct header hdr;
	static char buffer[1024];
	if(full_read(sockfd, (void *)&hdr, sizeof(hdr))<=0){
		error("full_read: %m");
		return NULL;
	}
	length = ntohl(hdr.length); //这里length是加粗
	if(length > (1024 + sizeof (struct header) - 1)){
        error("not enough room in buffer\n");
		return NULL;
	}
	if(full_read(sockfd, buffer,
			length sizeof(struct header))<=0) //这里length加粗
	{
		error("read: %m");
		return NULL;
	}
	buffer[sizeof(buffer)-1] = '\0';
	return strdup(buffer);
}

这份代码从网络中读入packet的header然后取出它的32位长度写入length变量中。length变量表示packet所占的总字节数，因此程序会先检查packet数据部分是否长于1024个字节以防止溢出。然后它尝试通过将(length sizeof(struct header))个字节读入缓冲区，从网络中读取packet的其余部分。这是有意义的，因为代码希望读取packet的数据部分，即总长度减去头的长度。

有漏洞的地方在于如果用户将长度设置为小于sizeof(struct header)的值，那么减去(length sizeof(struct header))就会造成整数下溢，最后将一个很大的size参数掺入full_read()。这个错误可能造成缓冲区溢出，因为在那个时候，read()可能会一直将数据复制到缓冲区知道连接关闭时，这样就可能允许攻击者获得进程的控制权。

Intel中的乘法溢出

一般地，处理器会在发生整数溢出时探测到它然后提供处理机制；然而，它们几乎没有用在错误检查上并且一般这种机制C语言也没有访问权限。例如，Intel处理器会在乘法发生溢出时将overflow flag(OF)的值保存在EFLAGS寄存器中，但C成语言如果不使用内部汇编代码的话就无法检查这个flag。有时这样做是出于安全原因，例如在Windows操作系统中处理MSRPC请求的NDR解组例程。下面的代码来自rpcrt4.dll，会在从RPC请求中各种数据类型的解组中调用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

sub_77D6B6D4 proc near
var_of = dword ptr -4
arg_count = dword ptr 8
arg_length = dword ptr 0Ch
push ebp
mov ebp, esp
push ecx
and [ebp+var_of], 0
		; set overflow flag to 0
push esi
mov esi, [ebp+arg_length]
imul esi, [ebp+arg_count]
		; multiply length * count
jno short check_of // 这一行是加粗，第一次检查
mov [ebp+var_of], 1
		; if of set, set out flag
check_of:
cmp [ebp+var_of], 0
jnz short raise_ex
		; must not overflow
cmp esi, 7FFFFFFFh //第二次检查
jbe short return
		; must be a positive int
raise_ex:
push 6C6h
		; exception
call RpcRaiseException
return:
mov eax, esi
		; return result
pop esi
leave
retn 8

你能看到这个函数会将所提供的元素数量和每个元素的大小相乘，这个过程中做了两次检查。第一次是它使用jno检查overflow flag来保证乘法没有导致溢出。然后它确保了结果值的大小小于或者等于带符号整数能表示的最大值，也就是0x7FFFFFFF，二者只要有其中之一检查失败，函数就会抛出异常。

带符号整数边界

带符号整数略有不同。根据C语言特性，带符号整数的算术溢出或下溢的结果是实现定义的，可能包含机器陷阱或故障(machine trap or fault)。然而在大多数常见架构中，有符号算术溢出的结果定义良好且可预测，不会导致任何类型的异常。这些边界行为是补码算法在硬件上实现的自然结果，在主流机器上应该是一致的。

如果你还记得的话，可以用二进制补码表示的最大带符号整数的正值是，除有效位为0外，所有位都被设为1。这是因为最大的位表示该数字的符号，而该位中的值为1表示该数字为负数。当对有符号整数的操作导致算术溢出或下溢时，结果值“包围符号边界”并通常导致符号更改。例如，在32位整数中，值0x7FFFFFFF是一个大的正数。向其添加1将产生结果0x80000000，这是一个很大的负数。看看另一个简单的例子：

1
2
3

int a;
a=0x7FFFFFF0;
a+=0x100

加法的结果是-0x7fffff10, 或者 -2,147,483,408。来看一下它的二进制加法过程：

1
2
3

  0111 1111 1111 1111 1111 1111 1111 0000
+ 0000 0000 0000 0000 0000 0001 0000 0000
= 1000 0000 0000 0000 0000 0000 1111 0000

a的结果值是0x800000f0，它是正确的结果，但由于整数是用二进制补码来表示的，实际的值就会被表示为-0x7fffff10。在这个情况下，一个很大的正数加上一个很小的正数得到了一个很大的负数。

使用带符号加法，你可以通过使正数绕到0x80000000周围变成负数来溢出符号边界。你还可以通过使一个负数绕到0x80000000以下并变成正数来降低符号边界。负数的减法和加法是一样的，所以你可以把它们分析成本质上是相同的运算。乘法和移位过程中也可能出现溢出，对其结果进行分类就不那么容易了。从本质上说，这些位元可能会下落;如果结果的符号位中有1位，结果就是负的。否则,它不是。乍一看，涉及乘法的算术溢出似乎有点棘手，但攻击者通常可以让它们返回有用的目标值。

注

在本章中，read()函数用于演示与整数相关的各种形式的缺陷。为了清晰起见，这有点过于简化了，因为许多现代系统在系统调用级别验证read()的长度参数。这些系统(包括BSDs和更新的Linux 2.6内核)检查这个参数是否小于或等于相应大小的有符号整数的最大值，从而最小化内存损坏的风险。

很多在计算中未预料到的符号改变可以导致代码中微妙的可利用漏洞。这些变化可能曹正程序错误地计算所要求的空间，导致出现和上面无符号整数越过边界相似的情况。这种性质的错误通常发生在对直接从外部源(如网络数据或文件)获取的整数执行算术运算的应用程序中。下面的代码就是一个简单的例子，它展示了应用程序越过符号边界可能造成的影响：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

char *read_data(int sockfd)
{
	char *buf;
	int length = network_get_int(sockfd);
	if(!(buf = (char *)malloc(MAXCHARS)))
		die("malloc: %m");
	if(length < 0 || length + 1 >= MAXCHARS){
		free(buf);
		die("bad length: %d", value);
	}
	if(read(sockfd, buf, length) <= 0){
		free(buf);
        die("read: %m");
	}
	buf[value] = '\0';
	return buf;
}

这个例子从网络中读入一个整数然后首先理智地做了一些检查。首先，检查了长度来保证它是否大于等于0，也就是是否为正数。然后检查长度来保证它是否小于MAXCHAS。然而，在代码的第二部分检查中，length变量被加了1.这就给攻击向量开了一扇门：0x7FFFFFFF会通过第一道检查（因为它大于0）然后进入第二道检查后，0x7FFFFFFF + 1是0x80000000，也就是一个负数，read()然后就可能在使用了一个有效的没有限制长度的参数下调用，从而导致潜在的缓冲区溢出情况。

在对待带符号整数时，这样的错误会很容易犯，而且发现它同样具有挑战性。允许用户直接指定整数的协议特别容易出现这种类型的漏洞。为了在实践中检验这一点，我们来看看一个执行不安全计算的真实应用程序。以下漏洞是OpenSSL 0.9.6代码基中与处理抽象语法符号(Abstract Syntax Notation ASN.1)编码数据相关的漏洞。(ASN.1是一种用于描述在计算机之间发送的任意信息的语言，这些信息使用它的基本编码规则BER进行编码。)这种编码是这种性质的漏洞的完美候选，因为该协议显式地处理由不受信任的客户机提供的32位整数。下面代码取自crypto/asn1/a_d2i_fp.c的 ASN1_d2i_fp()函数，该函数负责从IO (BIO)缓冲流中读取ASN.1对象。为简洁起见，对该代码进行了编辑。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

c.inf=ASN1_get_object(&(c.p),&(c.slen),&(c.tag),&(c.xclass),
				len-off);
...
{
	/* suck in c.slen bytes of data */
	want=(int)c.slen;
	if (want > (len-off))
	{
		want-=(len-off);
    	if (!BUF_MEM_grow(b,len+want))
		{
			ASN1err(ASN1_F_ASN1_D2I_BIO,
				ERR_R_MALLOC_FAILURE);
			goto err;
		}
		i=want;
        // 这里所有want都加粗了

这份代码在一个获取ASN.1对象的循环中被调用。ASN1_get_object()函数读取下一个ASN.1对象指定长度的对象头部。这个长度被放置在c.slen里，是一个带符号整数，然后被传入want中ASN.1对象函数确保了这个值非负，因此c,slen的最大值可以是0x7FFFFFFF。在这种情况下，len就是内存中早已读入的数据数量，off是该数据到被解析对象的偏移量。因此，len-off就是被读入内存但还未被解析的数据量。如果代码发现对象大小大于可用的未解析数据大小，则决定分配更多空间并读入对象的其余部分。

BUF_MEM_grow()函数用来在内存缓冲区b中分配所要求的内存空间。它第二个变量是大小参数。这里的问题就是，len+want表达式用于第二个参数就可能导致溢出。比如假设len是200字节，off是50字节，攻击者经对象大小设置为0x7FFFFFFF，这将会传给want。 0x7FFFFFFF比在内存中的150个字节数据要大得多，因此会进入分配内存的代码。want会被减去150个已经读入的数据大小，然后得到值0x7FFFFF69，然后BUF_MEM_grow()的调用会请求len+want个字节的数据，或者说x7FFFFF69 + 200，也就是0x80000031，这个数是一个非常大的负数。

在内部，BUF_MEM_grow()函数进行比较，检查长度参数与之前分配的空间大小。因为负数小于它已经分配的内存量，所以它假定一切正常。因此，重新分配将被绕过，任意数量的数据可能被复制到分配的堆数据中，这会带来严重的后果。

7.2.5 类型转换

C语言在处理不同数据类型的交互上非常灵活。例如，通过一些强制类型转换，可以轻松地将无符号字符与有符号长整数相乘，将其添加到字符指针中，然后将结果传递给需要指向结构的指针的函数。程序员已经习惯了这种灵活性，因此他们倾向于混合数据类型，而不太关心幕后发生的事情。为了处理这种灵活性，当编译器需要将一种类型的对象转换为另一种类型时，它将执行所谓的类型转换。类型转换有两种形式:显式类型转换，程序员通过强制转换显式指示编译器从一种类型转换为另一种类型;隐式类型转换，编译器对变量进行“隐藏”转换，以使程序按预期运行。

注

你可能会看到在编程语言文献中称为“类型强制转换”(type coercions)的类型转换;这两个术语是同义的。

当你第一次了解一个典型的C程序中在幕后发生了多少隐式转换时，通常会感到惊讶。这些自动类型转换统称为默认类型转换，这会在当程序员执行看似简单的任务(如进行函数调用或比较两个数字)时，几乎不可思议地发生。

类型转换产生的漏洞通常很有趣，因为它们很微妙，很难在源代码中定位，而且它们常常导致这样的情况:关键远程漏洞的补丁就像将char更改为unsigned char一样简单。控制这些转换的规则看起来很微妙，你很容易认为你已经牢牢掌握了它们，而忽略了在分析或编写代码时造成巨大差异的一个重要的细微差别。

我们先部不要直接跳到已知的漏洞类别中，首先看看C编译器是如何在较低的级别上执行类型转换的，然后详细研究C的规则，以了解发生转换的所有情况。本节相当长，因为在有信心分析C的类型转换的基础之前，你必须涵了解很多内容。然而，这方面的语言是非常微妙的，它绝对值得花时间来获得一个坚实的基本规则的理解;你可以利用这种理解来发现大多数程序员甚至在概念级别上都没有意识到的漏洞。

概述

当面对协调两种不同类型的普遍问题时，C尽量避免让程序员感到意外。编译器遵循一组规则，这些规则试图封装关于如何管理混合不同类型的“常识”，通常，这些程序结果是正确的，且简单地执行程序员想要的操作。也就是说，应用这些规则通常会导致令人惊讶的、意想不到的行为。此外，如你所料，这些意外行为往往会带来可怕的安全后果。

在下一节中，我们将从探讨转换规则开始，即C在类型之间转换时使用的一般规则。它们指示机器如何在位级从一种类型转换为另一种类型。在您你很好地掌握了C如何在机器级别上在不同类型之间转换之后，你将研究编译器如何选择在C表达式上下文中应用哪种类型转换，这涉及到三个重要的概念:简单转换(simple conversions)、整数提升(integer promotions)和通常的算术转换(arithmetic conversions)。

注

虽然浮点数和指针等非整型类型有一定的覆盖范围，但本文主要讨论的是C如何操作整数，因为这些转换被广泛误解，并且对安全性分析至关重要。

转换规则

下面的规则描述了C如何从一种类型转换为另一种类型，但它们不描述何时执行转换或为什么执行转换。

注

下面的内容是特定于二进制补码实现的，代表了C规范中规则的精炼和实用版本。

整数类型：保值

在整数类型的转换中，一个重要的术语就是保值转换(value-preserving conversion)。

简单来说，如果新的类型能够表示所有旧类型可能的值，那么这种转换就成为保值的。在这种情况下，转换的结果不会导致值发生任何变化或者丢失。例如，如果一个unsigned char转换为int，这个转换就是保值的，因为整型能够表示无符号字符型的任意值。你可以在后面的表中对它进行验证。假设你考虑的是使用二进制补码的机器，那么一个8位的unsigned char能够表示0-255的任意值。一个32位的int型能够表示 -2147483648和 2147483647之间的任意值。因此没有一个unsigned char能表示的数字是int不能表示的。

相应地，在变值转换(value-changing conversion)中，旧地类型可能包含了新类型无法表示的值。例如，如果你将int转换为unsigned int，你就创造了这样一个棘手的情况。unsigned int在32位机器上的范围是0-4294967295,int的范围是-2147483648-2147483647.unsigned int无法表示任何int能表示的负数。

根据C标准，一些变值转换的结果有实现定义。这仅适用于具有带符号目标类型的值更改转换;对无符号类型的变值转换进行了定义，并且在所有实现中保持一致。(如果你还记得边界条件的讨论，这是因为无符号算术被定义为模运算系统。)二进制补码机遵循相同的基本行为，因此你可以相当有把握地解释它们如何执行对带符号目标类型的值更改转换。

整数类型：扩展

当你将一个较窄类型转换为另一个更宽的类型时，机器会按位将旧的变量复制到新的变量，然后将其他的高位设为0或者1.如果源类型是无符号的，机器就会使用零扩展(zero extension)，也就是在宽类型中将剩余高位设为0.如果源类型是带符号的，机器就会使用符号位扩展(sign extension)，也就是将宽类型剩余未使用位设为源类型中符号位的值。

警告

扩展过程会出现一些没有预料的实现：如果一个较窄的带符号类型，例如signed char，转换为一个更宽的无符号类型，例如unsigned int，那么符号位扩展仍然会发生。

图6-1展示了一个值为5的unsigned char类型保值转换为signed int型的过程

字符被放置到整数中，值被保留。在位模式级别，这只涉及零扩展:清除高位并将最低有效字节(least significant byte，LSB)移动到新对象的最低有效字节。

现在考虑一下signed char转换为int。int能表示所有signed char能表示的值，因此这个转换仍然是保值的，图6-2展示了在位级别的转换过程。

这个情况稍微会有些不同，因为值是相同的，但转变过程更复杂了一点。-5在signed char中位级别的表示为1111 1011。在int中，-5的位级表达为1111 1111 1111 1111 1111 1111 1111 1011.为了实现这个转换，编译器会生成汇编代码来执行符号位扩展。在图6-2中你能看到符号位在signed char中为1，因此为了保值，符号位就会被复制到其他int型中剩下的24位里。

前面的例子是保值转换。现在考虑一下变质扩展转换。如果你想要将一个值为-5的signed char转换为unsigned int。由于源类型是带符号的，因此符号位扩展就会执行，见图6-3：

正如前面所提到的，这个结果可能会震惊到开发者。你可以在本章后面“符号位扩展”小节中看到与之相关的安全影响。这种转换是变值的，因为一个unsigned int无法表示一个小于0的值。

整数类型：收缩

当将一个宽类型转换为窄类型时，机器只会使用一种机器：截断(truncation)。宽类型中与窄类型不匹配的位会被全部舍去。图6-4和图6-5展示了两个收缩转换。注意，所有的收缩转换都是变值转换，因为转换过程中精度丢失了。

图6-5:

整数类型：带符号与无符号

最后我们要考虑这样的整数转换：如果转换在相同宽度的带符号和无符号数之间发生，那么在位级别上什么都不会发生。这样的转换是变值的。例如，如果你有一个signed int型的-1，在二进制的表示为：1111 1111 1111 1111 1111 1111 1111 1111。

如果将具有相同位级别的这个数看作unsigned int，那么它的值就是4,294,967,295。这个过程在图6-6中有总结。 从unsigned int到int的转换在技术上可能是实现定义的，但其工作方式相同:保留位模式，值在新类型的上下文中进行解释

图6-7：

整数类型转换总结：

对于整数类型转换，这里有一些实用的规则：

• 从窄的带符号类型转换为宽的无符号类型，编译器会生成汇编指令执行符号位扩展，对象的值可能会改变。
• 从窄的带符号类型转换为宽的带符号类型，编译器会生成汇编指令执行符号位扩展，对象的值不变
• 从窄的无符号类型转换为宽的类型，编译器会生成汇编指令执行零扩展，对象的值不变
• 从宽类型转换为窄号类型，编译器会生成汇编指令执行截断，对象的值可能改变
• 相同宽度无符号类型和带符号类型之间的转换，编译器实际上不会做任何事，在位模式下是相同的，但对象的值可能会改变

下面的表总结了不同整数类型在C语言的二进制补码实现下转换时进行的操作。在接下来的章节中，这个表可以当作类型转换发生时一个有用的参考文献。表中左边是源类型，顶部代表目标类型。

浮点型和复数型

尽管由浮点数算术导致的漏洞并没有广泛地被挖出来，但造成漏洞这一件事是确实可能的。在财务软件中肯定会出现与浮点类型转换或表示问题相关的微妙错误。本章对浮点类型的讨论相当简短。有关更多信息，请参阅C标准文档和前面提到的C编程参考资料。

对于真正的浮点类型和整数类型之间的转换，C标准的规则为实现定义的行为留下了很大的空间。在从实类型到整数类型的转换中，将丢弃数字的小数部分。如果整数类型不能表示浮点数的整数部分，则结果是未定义的。类似地，从整数类型到实类型的转换也会尽可能地转移值。如果实类型不能表示该整数的值，但可以接近，则编译器将按照实现定义的方式将该整数四舍五入到下一个最大值或最小值。如果整数超出实类型的范围，则结果是未定义的。

不同精度的浮点类型之间的转换使用类似的逻辑处理。精度提升(promotion)不会引起值的变化。在导致值更改的精度下降(demotion)期间，编译器可以自由地使用实现定义的方式对数字进行四舍五入(如果可能的话)。如果由于目标类型的范围而无法四舍五入，则结果是未定义的。

其他类型

除了整数和浮点数之外，C语言中还有无数其他类型，包括指针、布尔型、结构体、联合体、函数、数组、枚举类型等等。在大多数情况下，从安全的角度来看，这些类型之间的转换并不十分关键，因此本章不会详细介绍它们。

指针运算会在本章中的“指针运算”小节中进行详细介绍。指针类型转换很大程度上取决于底层机器的架构，很多的类型转换都是实现定义的。实质上，程序员能够将指针和整型来回转换，将指针从一种类型转换为其他类型。其结果是实现定义的， 程序员需要认识到对齐限制和其他底层细节。

简单转换

现在你对C语言将一个整数类型转换为其他类型已经了解了，现在你可以来看一下这些类型转换发生时的情况了。简单转换(simple conversions)是一种C语言表达式，它直接使用前面提到的转换规则。

强制类型转换(casts)

强制类型转换(typecasts)是C语言让程序员进行显式类型转换的机制，就像下面的例子一样:

1

(unsigned char) bob

不管bob是什么，这个表达式都会将它转换为unsigned char类型。表达式的结果类型是unsigned char。

赋值

简单类型的转换也会在赋值运算符中发生。编译器一定会将右部的类型转换为左部的类型，就像下面例子所显示的：

1
2
3

short int fred;
int bob = -10;
fred = bob;

对于这两个赋值运算，编译器一定会将右部的类型转换为左部的类型。转换规则告诉你，从int类型的bob转换为short int型的fred会导致截断。

函数调用：原型(prototype)

C语言有两种风格的函数声明：旧的K&R风格，也就是参数类型在函数声明中没有具体说明。在ANSI风格中， 函数原型的使用仍然是可选的，但它很常见，在ANSI风格下，你会见到一些像这样的东西：

1
2
3
4
5
6
7
8

int dostuff(int jim, unsigned char bob);
void func(void)
{
    char a=42;
    unsigned short b=43;
    long long int c;
    c=dostuff(a, b);
}

函数dostuff()的声明中含有告诉编译器参数个数的原型。 经验法则是，如果函数有原型，则使用前面记录的规则以简单的方式转换类型。 如果函数没有原型， 就会出现所谓的默认参数提升(default argument promotions)(在整数提升中会提到)。

前面的例子中一个字符型（a）被转换为了int型(jim)，一个unsigned short型(b)被转换为了unsigned char(bob)，一个int型(do_stuff()的返回值)被转换成了long long int(c)。

函数调用：返回

return 将其操作数转换为封闭函数定义中指定的类型。例如，在下面的例子中，int类型a通过return被转换为了char类型：

1
2
3
4
5

char func(void)
{
    int a=42;
    return a;
}

整数提升(integer promotions)

整数提升详细说明了C语言如何将一个窄的整数类型，例如char或者short转换为int型（或者不常见的情况，转换为unsignd int)。由于下面的两种原因会使用这种向上的转换(up-conversion)，或者提升：

• 很多C语言的运算符要求操作对象为int或者unsigned int类型。对于这些运算符，C会使用整数提升规则将窄类型操作对象转换为int或者unsigned int。
• 整数提升是C语言中处理算术表达式中很重要的规则，它也被称为常规算术转换规则 (usual arithmetic conversions)。对于涉及整数的算术表达式，整数提升通常应用于操作数两边。

注

你可能会在其他文献中交替见到“整数提升(integer promotion)”和“整型提升(integral promotion)”，它们是相同的术语。

从C语言便准中能得到一个有用的概念：每个整数型数据都有一个叫整数转换等级(integer conversion rank)的东西。这些等级将整数类型数据做了一个等级的排序，通过它们的宽度从低到高。每种类型的带符号和无符号种类级别是相同的。 下面的列表按从高到低的等级转换对整数类型进行排序。对于其他整数类型，C标准也会设置等级，但是这个列表应该足以满足本文的讨论：

• long long int, unsigned long long int
• long int, unsigned long int
• unsigned int, int
• unsigned short,short
• char, unsigned char, signed char
• _Bool

基本来说， 在C中可以使用int或unsigned int的任何地方，也可以使用具有较低整数转换等级的任何整型。这意味着你可以使用更小的类型，比如char和short int，来代替C表达式中的int。你也可以使用类型为_Bool、int、signed int或unsigned int的位字段。位字段不被赋予整数转换等级，但它们被视为比它们相应的基类型更窄的类型。 这是有意义的，因为int的位字段通常比int小，最宽的情况下和int的宽度相同。

如果将整数提升应用于变量，会发生什么?首先，如果变量不是整数类型或位字段，提升过程不会执行任何操作。第二，如果变量是整数类型，但是它的整数转换级别大于或等于int类型，提升过程也不做任何事情。因此，int、unsigned int、long int、指针和浮点数不会因整数提升而改变。

因此，整数提升负责获取更窄的整型类型或位字段，并将其提升为整型或无符号整型。否则，将执行一个到unsigned int的保值转换。

在实际应用中，这意味着几乎所有东西都能被转换为int，因为int可以保存所有较小类型的最小值和最大值。唯一可能提升为无符号整型的类型是具有32位的无符号整型位字段，或者某些特定于实现的扩展整型类型。

关于过去版本的注解

C89标准对C类型转换规则进行了重要的修改。在C语言的K&R时代，整数提升是保符号(unsigned-preserving)的，而不是保值的。因此，在当前的C规则中，如果较窄的无符号整数类型(如unsigned char)被提升为较宽的有符号整数(如int)，则值转换规定新类型为有符号整数。在旧规则中，提升将保留无符号性，因此结果类型将是unsigned int，这改变了许多有符号/无符号比较的行为，这些比较涉及到比int窄的类型提升。

整数提升的总结

基本上的规则如下：如果一个整数类型比int要窄，那么证书体系基本上都会将它们转换为int。下面的表总结了几个常见类型的整数提升结果：

整数提升应用

现在你理解整数提升了，下面的小节会探讨它们会在C语言哪些地方被使用。

一元算符 +

一元算符 +会对其操作数执行整数提升。例如，如果变量bob的类型是char，那么(+bob)的结果类型为int，尽管(bob)表达式的结果类型为char。

一元算符 -

一元算符-会对其操作数先执行整数提升再取负数。 无论提升后的操作数是否有符号，都会执行二进制补码的取负，这涉及到位的反转，然后加一。 (一个数取负，只要把数的补码表示再取一次补码就可以了 —by译者)

Leblancian悖论

David Leblanc是一位专业的研究员和审计者，也是世界上C/C++的顶级专家之一。 他记录了在与同事Atin Bansal一起开发SafeInt类时发现的两个补码运算的一个迷人的细微差别(http://msdn.microsoft.com/library/en-us/dncode/html/secure01142004.asp)。将两个补码数相减，会执行各位取反然后加1。假设一个32位的带符号数据类型，那么0x80000000取反是什么？

你将所有位取反后，得到了0x7fffffff，然后加上1，你得到了0x80000000。因此这个数的取负就是它本身！

当开发人员使用负整数表示一组特殊的数字或尝试取整数的绝对值时，这种特性就会发挥作用。下面的代码让一个负索引指定一个辅助哈希表。除非攻击者能够指定索引为0x80000000，否则这种方法可以正常工作。对数字进行取负不会导致值发生变化，并且0x80000000 % 1000是-648，这会导致数组之前的内存被修改。

1
2
3
4
5
6
7
8
9
10
11

int bank1[1000], bank2[1000];
...
void hashbank(int index, int value)
{
	int *bank = bank1;
	if (index<0) {
		bank = bank2;
		index = -index;
	}
	bank[index % 1000] = value;
}

译者注：

补码在数学性质上是单满映射，也就是在能够表示的范围之内，一个数的和它的二进制补码是一一对应的，那么为什么会出现上述的悖论(一个数的补码负数是本身)呢？本质上就是0x80000000是int型能表示的最小值，而int型能表示的最大值是最小值的绝对值减一，也就是说int是无法表示-0x80000000的，它理论值是-INT_MIN-1，即INT_MAX+1，但在int里这个数就越界了，然后就从INT_MAXoverflow回了INT_MIN。

一元算符 ~

一元算符~会在进行整数提升之后将操作数取反码。 对于补码实现，这有效地对有符号和无符号操作数执行相同的操作:将位反转。

移位算符

移位算符>>和<< 改变变量的位模式。整数提升会应用到这两个算符中，结果类型等于算符左边操作数提升后的类型，就像下面例子一样：

1
2
3
4

char a = 1;
char c = 16;
int bob;
bob = a << c;

a会被转成整数，c也会被转成整数。提升后的左边操作数是int型，因此表达式的结果类型是int。a的整数表达就是原来的值往左移16位。

switch语句

整数提升也会用在switch语句中。switch语句的表达式一般会像这样：

1
2
3
4
5
6
7

switch (controlling expression)
{
    case (constant integer expression): body;
    	break;
    default: body;
    	break;
}

整数提升以以下方式使用:首先，它们应用于控制表达式，以便表达式具有提升类型。然后，将所有整型常量转换为控制表达式提升的类型。

函数调用

使用K&R语义的旧C语言程序在其函数声明中没有指定参数的数据类型。当在没有原型的情况下调用函数时，编译器必须执行称为默认参数提升(default argument promotions)的操作。基本上，整数提升应用于每个函数参数，任何浮点类型的参数都转换为double类型的参数。考虑以下示例：

1
2
3
4
5
6
7
8
9
10

int jim(bob)
char bob;
{
	printf("bob=%d\n", bob);
}
int main(int argc, char **argv)
{
	char a=5;
	jim(a);
}

在这个例子中，a的拷贝值被传入了jim()函数。char类型首先会被整数提升整数类型，然后这个整数会被传入jim()函数。 编译器为jim()函数发出的代码需要一个整型参数，它执行将该整型直接转换回bob变量的char格式。

常规算术转换

在许多情况下，C应该接受两个可能具有不同类型的操作数，并执行一些涉及这两个操作数的算术运算。C标准给出了一种通用算法，用于将两种类型协调为兼容类型。 这个方法称为常规算术转换(usual arithmetic conversions)。

规则1：浮点优先

浮点数要优先于整数类型，也就是如果一个变量在算术表达式中是浮点数类型，那么其他类型就会被转换为浮点型。如果一个浮点型比其他的类型精度低，那么这个浮点型会被提升为精度更高的类型。

规则2：应用整数提升

如果两个操作数都不是浮点型，那么回到整数类型的规则。首先，整数提升会应用到两边的操作数。这是拼图中极其重要的一块！如果你回顾前面的章节，这个规则表示任何小于int的整数类型都会被转换为int，与int有相同宽度或者更宽的会被放到一边。下面是一个简单的例子：

1
2
3

unsigned char jim = 255;
unsigned char bob = 255;
if ((jim + bob) > 300) do_something();

在这个表达式中，运算符+会对操作数使用常规算术转换，结果类型会是一个int型，并且记录加法的值(510)。因此，do_something会被调用，尽管这个表达式看起来会导致溢出。 总而言之:只要算术涉及小于整数的类型，就会在幕后将窄类型提升为整数。这里有另一个简单的例子：

1
2

unsigned short a=1;
if ((a-5) < 0) do_something();

从直观上看如果你有一个值为1的unsigned short，减去5以后会在0处下溢到一个很大的值。然而，如果你测试这段代码，你将会看到do_something()被调用了因为减法算符两边的操作数在比较前都被提升到了int型。因此a被从unsigned short转换成了int，然后一个int类型的的数减去了5，结果是-4。这对int是合法值，因此比较表达式的结果为真。请注意如果你做下面的操作，那么do_something()将不会被调用：

1
2
3

unsigned short a=1;
a=a-5;
if (a < 0) do_something();

整数提升发生在(a-5)这里，但结果的整数值-4会被赋值到unsigned short的a里面。正如你所知道的，一个int型被转换为unsigned short会导致截断，最后导致a的值为一个非常大的正数。因此，比较表达式将不返回真。

规则3：整数提升后为相同类型

如果两个操作数在整数提升后是相同类型，那么久不必进行后面的类型转换，因为算术运算会被直接带到机器级别。这可能会在两边操作数都被提升到int型时发生，或者它们本身就是相同的没有被整数提升影响到的类型。

规则4：相同符号，不同类型

如果两个操作数在整数提升后是不同的类型，但是它们是否有符号位是相同的，那么窄的类型会被转换为宽的类型。换句话说，如果两边操作数都是signed或者两边都是unsigned，那么在整数转换层级上较低的类型会被转换成转换层级上较高的类型。

注意这个规则对于short或者符号类型没有用，因为它们早就通过整数提升变成了int。这个规则对于更大大小数的算术运算更管用，例如long long int或者long int。下面是一个例子：

1
2
3
4

int jim =5;
long int bob = 6;
long long int fred;
fred = (jim + bob);

整数提升不会改变任何类型，因为它们都是在宽度上大于或者等于int型的。因此这个规则会在加法开始前让jim被转换为long int，加法结果的类型是long int，然后再被转换为long long int赋值给fred。

在下一节中，你将会考虑操作数为不同类型，并且一个是signed另一个是unsigned。这种情况在安全层面上会有很多有趣的东西。

规则5：带符号类型比带无符号类型更宽

对于这个规则(signed遇见unsigned —by译者)，第一种情形就是unsigned操作数在转换等级上大于signed操作数，或者它们的等级是相同的的情况下，你将一个signed操作数转换为unsigned操作数。这个行为可能会震惊到你，然后导致像下面的情况：

1
2
3

int jim = -5;
if (jim < sizeof (int))
	do_something();

比较算符<会导致常规类型转换应用到两边的操作数。因此整数提升会应用到jim和sizeof(int)里，但这并不会影响到它们。然后继续进行常规算术转换，它试图照除哪个类型应该被当作比较的通用类型。在这种情况下，jim是带符号整数，sizeof(int)是size_t，也就是无符号整数类型。由于size_t在类型转换等级上更高，因此无符号类型在这里就有了优先级，因此，jim会被转换为无符号整数类型，然后比较表达式结果为假，do_something()不会被调用。在32位系统里，真实的比较是下面这样：

1
2

if (4294967291 < 4)
	do_something();

规则6：带符号类型比无符号类型更窄，能保值

如果带符号类型比无符号类型的转换等级更高，并且能够在从无符号类型到带符号类型执行保值转换，那么就会将任何东西转换为带符号整数。就如下面的例子：

1
2
3

long long int a=10;
unsigned int b= 5;
(a+b);

带符号变量为long long int，能够表示任何unsigned int的值，因此编译器会将两边操作数转换为带符号类型：long long int.

规则7：带符号类型比无符号类型更窄，不能保值

还有一项规则：如果带符号类型比无符号类型的转换等级更高，但是不是所有的无符号整数能表示的数带符号类型都能表示，那么就会发生有点奇怪的事。 获取带符号整数的类型，将其转换为对应的无符号整数类型，然后将两个操作数转换为该类型并使用。 下面是一个例子：

1
2
3

unsigned int a = 10;
long int b=20;
(a+b);

这个例子要假设在这个机器上，int类型和long int类型长度相同。假发算符会导致常规算术转换被应用。首先进行整数提升，但不会改变任何类型。带符号类型long int转换层级比无符号类型unsigned int更高。但带符号类型无法表示无符号类型的所有值。因此会启动最后这条规则。首先找到带符号操作数类型(long int)，对应相应的无符号类型，unsigned long int，然后将两边操作数都转换为unsigned long int。因此表达式结果类型为unsigned long int，值为30.

算术转换总结

下面是对有用的算术转换做总结。后面的表格也是同样的总结。

• 如果任意一方是浮点数，双方操作数都会被转换为两边中精度最高的浮点数。这个你掌握了。
• 对两边都进行整数提升。如果这两个操作数现在是相同类型的。这个你掌握了
• 如果两个操作数在是否带符号，这种情况一样的会将低转换等级的一方转换为高转换等级的一方。这个你掌握了。
• 如果无符号操作数等级大于等于带符号操作数，就将带符号操作数转换为无符号数。这个你掌握了。
• 如果如果带符号操作数等级大于无符号操作数，并且能够进行保值转换，将无符号数转换为带符号数类型。这个你掌握了。
• 如果如果带符号操作数等级大于无符号操作数，并且不能够进行保值转换，那就将两边都转换为带符号类型对应的无符号类型。

常规算术转换应用

现在你理解了常规算术转换，那就可以来看看这些转换被用在了哪里：

加法

加法可以在两个算术类型，以及算术类型和指针类型之间发生。指针运算会在小节“指针运算”中介绍。但现在，我们只需要考虑变量为算术类型，编译器会对两边使用常规算术转换。

减法

减法可以在两个算术类型，以及算术类型和指针类型之间发生。在两个算术类型进行减法的情况时，编译器会对两边使用常规算术转换。

乘法算符

算符* /的操作数两边都必须时算术类型，并且%的变量必须时整数类型。常规算术转换会被用到两边的操作数中。

关系和等价算符

当两个算术操作数被比较时，常规算术转换会被用到两边的操作数中。结果类似会是int，值为1或者0，取决于测试的结果。

二进制位级算符

二进制位级算符& ^ ！要求整数型操作数。常规算术转换会被使用。

问号标记算符(question mark operator)

从类型转换的视角看，条件运算符是C语言最有趣的算符之一。下面有一个例子可以看出它的应用有多广泛：

1
2
3
4
5

int a=1;
unsigned int b=2;
int choice=-1;
...
result = choice ? a : b ;

在这个例子中，第一个操作数choice如果为真，那么表达式的结果就是第二个操作数，也就是a，否则就是第三个操作数b。

编译器必须在编译时知道条件表达式的结果类型，这在这种情况下可能比较棘手。C语言所做的是确定对第二个和第三个参数运行常规算术转换后的结果是哪种类型，并使该类型成为表达式的结果类型。因此，在前面的示例中，无论choice的值是什么，表达式的结果都是unsigned int。

类型转换总结

下面的表格总结了一些常见类型转换的细节：