[转帖]Linux进程地址空间详解_VMware, Unix及操作系统讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  VMware, Unix及操作系统讨论区 »
总帖数
1
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 3634 | 回复: 0   主题: [转帖]Linux进程地址空间详解        下一篇 
lusxingbao
注册用户
等级:少校
经验:1487
发帖:100
精华:0
注册:2012-11-12
状态:离线
发送短消息息给lusxingbao 加好友    发送短消息息给lusxingbao 发消息
发表于: IP:您无权察看 2012-11-12 13:21:49 | [全部帖] [楼主帖] 楼主

这篇文章将更为详细得讨论Linux下进程的虚拟地址空间的布局。如下所述的内容都是基于32位系统的。

Linux传统内存布局

北京联动北方科技有限公司

进程的线性地址空间分为两部分:

1、从0×00000000到0xbfffffff的线性地址,无论进程运行在用户态还是内核态都可以寻址。

2、从0xc0000000到0xffffffff的线性地址,只有内核态的进程才能寻址。

进程的栈从地址0xc0000000向低地址发展,同时内存映射区域从0×40000000向高地址发展,因为栈所用内存相对较小(通常小于 100MB),因此约有2GB左右的映射空间;可执行文件的正文段从0×8048000开始,然后依次是数据段,BSS段,进程堆的起始点大于BSS段的结束点,并向高地址发展,因为0×40000000以上已用作内存映射用,因此堆的大小只有约1G,这有点太小了。

为了验证传统内存布局方式,使用以下测试程序,测试环境为Slackware 13.37 (Kernel 2.6.37)。

?View Code C


为了使内核切换到传统内存布局,执行命令#sysctl -w vm.legacy_va_layout=1(因为Linux 2.6.7及以后版本内核已经默认使用新的内存布局方式了)。
运行此程序,查看其输出及相应/proc/pid/maps内容:

?View Code TEXT
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 #root@slack:~#./a.out & [6] 9528 main=0x80483e4 print=0x8048300 first=0xbfd00b9c p0=0x804a008 p1=0x4018d008 p2=0x4028e008 p3=0x6028f008   #root@slack:~#cat /proc/9528/maps 08048000-08049000 r-xp 00000000 08:01 140878 /root/a.out 08049000-0804a000 rw-p 00000000 08:01 140878 /root/a.out 0804a000-0806b000 rw-p 00000000 00:00 0 [heap] 40000000-4001d000 r-xp 00000000 08:01 931801 /lib/ld-2.13.so 4001d000-4001e000 r--p 0001c000 08:01 931801 /lib/ld-2.13.so 4001e000-4001f000 rw-p 0001d000 08:01 931801 /lib/ld-2.13.so 4001f000-40022000 rw-p 00000000 00:00 0 40029000-40185000 r-xp 00000000 08:01 931779 /lib/libc-2.13.so 40185000-40186000 ---p 0015c000 08:01 931779 /lib/libc-2.13.so 40186000-40188000 r--p 0015c000 08:01 931779 /lib/libc-2.13.so 40188000-40189000 rw-p 0015e000 08:01 931779 /lib/libc-2.13.so 40189000-a0290000 rw-p 00000000 00:00 0 bf841000-bf862000 rw-p 00000000 00:00 0 [stack] ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]


首先分析程序的输出:
1、因为main()函数和printf()函数位于代码段中,而代码段是从0×08048000开始的,所以符合表中所述。
2、first是第一个临时变量,由于在first之前还有一些环境变量,它的值并非0xbfffffff,而是0xbfcd1264,这是正常的。
3、p0是在堆中分配的,其地址小于0×4000 0000,这也是正常的。
4、但p1和p2也是在堆中分配的,而其地址竟大于0×4000 0000,与表一描述不符。

原因在于:运行时堆的位置与内存管理算法相关,也就是与malloc的实现相关。关于内存管理算法的问题,我们在后继文章中有详细描述,这里只作简要说明。在glibc实现的内存管理算法中,malloc小块内存是在小于0×4000 0000的内存中分配的,通过brk/sbrk不断向上扩展,而分配大块内存,malloc直接通过系统调用mmap实现,分配得到的地址在文件映射区,所以其地址大于0×40000000。
所以,p0是在堆上分配的,而p1~p3则是通过mmap实现的,这表现在maps文件的倒数第三行(40189000-a0290000)。

然后分析maps文件内容:
08048000-08049000 代码段
08049000-0804a000 数据段
(注意本程序无BSS段)
0804a000-0806b000 堆
40000000-40189000 内存映射区,本程序映射了ld和libc动态链接库
40189000-a0290000 内存映射区,malloc用其为p1~p3分配内存
bf841000-bf862000 栈
ffffe000-fffff000 内核为我们映射的系统调用入口代码

Linux最新内存布局

鉴于以上传统内存布局的限制,Linux 2.6.7及以后版本已经默认使用另一种新的内存布局方式,如下图所示:

北京联动北方科技有限公司

从上图可以看到,mmap 映射区域至顶向下扩展, mmap 映射区域和堆相对扩展,直至耗尽虚拟地址空间中的剩余区域,弥补了经典内存布局方式的不足。

为了使用此新的内存布局,执行命令#sysctl -w vm.legacy_va_layout=0,然后重新编译运行程序并查看其输出及maps文件内容:

?View Code TEXT
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 #root@slack:~#./a.out & [6] 9529 main=0x80483e4 print=0x8048300 first=0xbff18e6c p0=0x804a008 p1=0xb7554008 p2=0x97553008 p3=0x57552008   #root@slack:~#cat /proc/9529/maps 08048000-08049000 r-xp 00000000 08:01 140882 /root/a.out 08049000-0804a000 rw-p 00000000 08:01 140882 /root/a.out 0804a000-0806b000 rw-p 00000000 00:00 0 [heap] 575c8000-b76cc000 rw-p 00000000 00:00 0 b76cc000-b7828000 r-xp 00000000 08:01 931779 /lib/libc-2.13.so b7828000-b7829000 ---p 0015c000 08:01 931779 /lib/libc-2.13.so b7829000-b782b000 r--p 0015c000 08:01 931779 /lib/libc-2.13.so b782b000-b782c000 rw-p 0015e000 08:01 931779 /lib/libc-2.13.so b782c000-b782f000 rw-p 00000000 00:00 0 b7837000-b7839000 rw-p 00000000 00:00 0 b7839000-b7856000 r-xp 00000000 08:01 931801 /lib/ld-2.13.so b7856000-b7857000 r--p 0001c000 08:01 931801 /lib/ld-2.13.so b7857000-b7858000 rw-p 0001d000 08:01 931801 /lib/ld-2.13.so bff4e000-bff6f000 rw-p 00000000 00:00 0 [stack] ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]


对比上一次maps文件内容,发现现在的内存映射区域已经从b7857000开始了,并且向下发展。p1~p3现在位于575c8000-b76cc000区域内。

新的内存布局图还显示栈底和Kernel Space之间、栈顶和映射区域之间、堆和BSS段之间都有一个随机的offset,每次运行程序时的值都不一样,这样会使得使用缓冲区溢出进行攻击更加困难。如果需要,当然也可以让程序的栈和映射区域从一个固定位置开始,只需要设置全局变量randomize_va_space值为0即可(默认值为 1)。
不明白offset的作用?让我们再执行一次程序,然后观察其输出和maps文件:

?View Code TEXT


和之前一次执行的输出相比较,发现程序输出中first变量的地址已经变了,而且maps文件中栈和内存映射区域的地址也变了。

那么,禁用offset会怎么样呢?执行命令#sysctl -w kernel.randomize_va_space=0,运行程序两次,再观察其输出:
第一次的输出:

?View Code TEXT


第二次的输出:

?View Code TEXT


正如所预料的,这两次运行的输出一模一样,其实再多执行几次也是一样的。

多线程内存空间布局

以上所述的都是只有主线程情况下的内存布局,那多线程情况下的布局是怎样的呢?
这里也使用一个程序来测试:

?View Code CPP


编译此程序gcc thread.c -lpthread,运行后其输出如下:

?View Code TEXT
1 2 3 4 5 6 7 8 9 10 11 first=0xbfbaf648 (0xb671db70): first=0xb671d384 (0xb671db70): p0=0x804a248 p1=0xb4e1d008 (0xb6f1db70): first=0xb6f1d384 (0xb6f1db70): p0=0x804a650 p1=0xb49fd008 (0xb771db70): first=0xb771d384 (0xb771db70): p0=0xb4d00468 p1=0xb4bff008 (0xb5f1db70): first=0xb5f1d384 (0xb5f1db70): p0=0xb4d00900 p1=0xb4afe008 (0xb571db70): first=0xb571d384 (0xb571db70): p0=0x804aa58 p1=0xb48fc008


主线程与第一个线程的栈之间的距离:0xbfbaf648 – 0xb771d384 = 132M
第一个线程与第二个线程的栈之间的距离:0xb771d384 – 0xb6f1d384= 8M
其它几个线程的栈之间距离均为8M。
也就是说,主线程的栈空间最大为132M,而普通线程的栈空间仅为8M,超这个范围就会造成栈溢出(后果很严重)。




赞(0)    操作        顶端 
总帖数
1
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论