首页
论坛
课程
招聘
[X64内核]对比总结32位和64位下,IDT,GDT,DS,CS,TSS,FS,GS的异同
2020-7-22 21:48 4203

[X64内核]对比总结32位和64位下,IDT,GDT,DS,CS,TSS,FS,GS的异同

2020-7-22 21:48
4203

环境及配置:

虚拟机:win10 X64 1903,VS2015+WDK10驱动开发环境

 

主机OS: Win10 1809

 

WIndbg:Windbg10.0.18362.1,VKD-Redux

 

虚拟机:VMware 15.5.5

 

win10 1903是微软于2019年新推出的操作系统版本,它涵盖了微软所有最新的安全保护机制,如SMEP,SMAP,KPTI,CFG,patch guard以及一系列和硬件漏洞有关的缓解机制等。他是19年度功能性更新的版本,1909版本年1903版本的稳定版,所以区别应该是不大。

 

我的虚拟机版本是VMware 15.5.5,15.5.5较15的早期版本稳定且快速。它修复了很多bug,比如早期版本无法从主机复制文件到虚拟机的bug。我没采用最新的15.5.6版本,整体感觉不如15.5.5好用(该版本创建虚拟机时优先采用nvme虚拟磁盘,但实测区别不大,甚至感觉慢于SCSI)。?

 

因为内核代码只要稍有错误就会产生致命的崩溃,所以无论是驱动开发还是内核安全研究,都不可避免的会蓝屏。所以为了少花时间在重复的崩溃+重启+连接调试器+修改内存数据上,我的建议是给虚拟机拍摄运行时快照,一旦崩溃直接恢复到上一个运行时状态,如果您的电脑配置一般,可以尝试将虚拟机内存减小,减少了文件读写的总量从而提高了恢复速度。快照还能间接绕过KALSR

 

图片alt

 

多啰嗦一句,请大家在调试漏洞/研究内核前一定要把网断掉,因为联网后Windows的自动更新会偷偷修改内存布局,可能导致实验出错。我之前在做9-9-9-9-12分页实验时,经常才解析到第一/二级页表就发现后面的页表内存全都失效了,我排查很久才发现是因为没有断网。。。。我的断网设置如下

 

图片alt

 

windbg是我配置VS2015+WDK10驱动开发环境时,WDK里自带的windbg,版本是Windbg10.0.18362.1,但我感觉不同windbg的版本区别不会很大,硬要说的话,特别老的版本无法执行类似 dq gdtr 指令,只能先r gdtr,然后dq addrgdt,很不方便。而且老的windbg可能将win10识别成win7,因为它出生那会还没win10呢。但即使这样其实影响也不大,原因是windbg并没有深度的侵入系统,他只是一个将内核信息做格式化后展示出来的printer而已。前段时间论坛很多兄弟都在发HEVD教程,大家翻一翻就知道怎么配了。

 

最后,很多同学都使用Virtual KD进行内核调试,VKD确实方便,但建议既要配置传统的管道调试环境又要配置VKD环境,原因是,VKD每次都只能在启动时用调试器连接操作系统,相当于每一次OS都以boot debug选项启动,这个给我们将来调试和研究patch guard 带来了很大的困难,因为如果在PG初始化之前就附加了调试器,那么PG是不会初始化的,导致PG被“绕过”,就无法研究他的原理了,想研究PG我觉得最好别用VKD-redux,用管道调试合适。

 

顺便一提,有的人说只要附加调试器就能绕过PG,我觉得这种说法不太准确,应该是在PG初始化前附加调试器可以自动绕过,就是那个windows图标刚出现,马上附加调试器是可以的,VKD-redux是可以在初始化前附加上去的。如果用管道调试,太考验人的手速的人品了,几乎做不到,

预备知识

阅读本文需要熟练掌握32位操作系统下段保护模式和页保护模式的知识,还需要有X64汇编基础。

对比总结32位和64位下,IDT,GDT,DS,CS,TSS,FS,GS的异同

1.IA32e

首先这块其实自己也不太懂,可能理解也不太准,我就是分享给大家我是怎么理解的。IA-32e 是扩展IA32指令集,e代表extention。XP下CPU不是有好几种工作模式嘛,保护模式,实模式,虚拟8086模式,64位下新加了一种IA32e模式,IA32e又分成两种工作模式,第一种是内核是64位的,用户程序可以是64位或32位的。还有一种叫Legacy模式:是内核是32位,用户程序也是32位的运行模式。我既可以安装64位的操作系统也能安装32位的,就得益于此IA-32e。

 

到64位就不再兼容很早以前的模式比如虚拟8086这些过时的东西,但Legasy模式就能很好兼容之前的模式(不是说64位就用不到之前的模式了,比如64位操作系统启动时还是实模式,然后逐渐进入ia-32e模式,但系统稳定后就永远稳定在ia32e模式)。

2.如何查看是否处于IA-32e模式

C0000080,该常量既不是一个虚拟地址,也不是一个物理地址。他是MSR寄存器有关的一个宏,可能是一个偏移,用rdmsr C0000080 指令查看MSR寄存器在那个偏移的值。

 

查看得到msr[c0000080] = 00000000 00000d01 00000000 00000000 00000000 00000000 00000000 00000000 00001101 00000001

 

该字节数组下标索引是8的位置1就说明出于ia32e模式,注意,是下标索引是8的位置,是从0开始数的,也就是第9位被置一,表明是ia32e模式,另外考虑字节序,是从后往前数的。

3.32/64位下的CS和DS

DS,ES,SS在64位模式下已不再使用。

 

IA32e下,代码段CS,数据段DS仍和32位一样使用64位,即8字节的描述符,但仅仅是DS和CS段描述符一样,不意味着64位所有GDT表项和32位的都完全相同。用Windbg dq gdtr的结果如下

 

图片alt

 

如果出现连续4个8字节全是0表明GDT已经结束。可以看到,这里甚至没有用l参数指定长度GDT就全显示出来了,可见64位的GDT表确实比32位OS下的GDT表要短的多。64位下变短的原因我觉得主要有两方面,一是因为IA-32e用不到为了兼容虚拟8086模式、实模式而存在的GDT表项,所以微软把他删了。其实XP系统中也没怎么用到,系统进入保护模式后,这些项就完全没用了,就那么空在那,甚至还有从系统启动到结束就没用过的表项。不但占地方还给了黑客可趁之机,很多大神看上了这一大片有可读写可执行属性的内存,把Shellcode或者全局数据区布置在这了,这操作也是非常的骚气。二是由于到了64位微软对段保护机制严重弱化,甚至已经基本废掉了段保护机制,DS,ES,SS在64位模式下已不再使用。自然GDT表项就少了。目前64位主要依靠页保护机制,SMEP,SMAP,KPTI等保护机制的核心也是页保护而不是段保护。

 

图片alt

 

Windbg有个dg指令可以快速判断代码段/数据段描述符,用法是dg+相对于GDT表首地址的偏移,就以第三项00209b00 00000000的为例,它距离GDT表首16个字节,就是两个GDT表长度为10h,所以dg 10 后如下所示

 

图片alt

 

简单解释一下:Code表示是给CS段描述符用的,P1是0表示DPL是0,是给零环用的。基址base和界限limit都是0,是由于强制平坦导致的,所谓强制平坦就是基址为0,界限是0,这么做是为兼容性考虑。再对比白皮书中段选择子,发现L位被置一,说明是64位代码段。

 

再以第四项为例解析一下 dg 18

 

图片alt

 

显然是给零环用的代码段,但是L位已经不代表64/32位,只有代码段才生效。

 

同理可知,dg 20 是三环代码段,dg 28 是三环数据段。

4.32/64位下的TSS

GDT表第9项是TSS任务段,用dg 40查看如下

 

图片alt

 

40偏移的确是TSS任务段的起始没错,但这里解析出的TSS段,它的段基址和偏移都是不对的。如果用用dq查看这个基址,会发现这里根本没有内存。这是因为,64位下的TSS段已经不再是32位下的8字节了,而是扩展到了16字节,但dg指令默认取8字节,所以解析出来一定是错的。

 

我们手工解析这个16字节的TSS:fffff80545a5dff0 : 45008ba5 c0000067 00000000 fffff805,段基址应该是:fffff805+45+a5+c000 = fffff80545a5c000。这是TSS真正的起始地址。这里需要大家自己把相应位置的数据找出来,记住顺序。

 

虽然英特尔设计TSS的初衷是给OS厂商做任务切换的(一定要注意!任务切换不等于线程切换!),但32位时代无论是微软还是Linux都没有采用英特尔的设计,因为跟MSR不一样,TSS不是一个寄存器而是块内存区域,真要用这个来切换,会导致频繁的内存读写,内存读写十分耗时会降低系统的速度。有多耗时呢?只要做过5级页表映射实验的同学应该都深有体会,所以微软和Linux都用MSR寄存器来切,英特尔也意识到了这点,所以64位时代英特尔干脆把TSS段的任务切换作用彻底废了,再也不保存之前那些通用寄存器了。

 

32位TSS长这样

 

图片alt

 

64位的TSS变成这样

 

2104

 

64位的TSS主要用于存放内核切换时用到的栈指针,上图中IST是一些特殊的栈指针,和中断有关。RSP0,1,2,3就是零环,1环,2环,三环的默认栈指针。我们已经知道TSS的基址是fffff80545a5c000,但TSS开头的四个字节是Reserved,所以要想正确解析出RSP还得再加上4变成fffff80545a5c004

 

图片alt

 

可以看到,RSP0是fffff805 45a5f200,还记得三环进零环时切换成内核栈的过程嘛,这个内核栈指针就是RSP0了,每次切换到零环默认用这个栈指针。RSP1,RSP2都是0,操作系统没用到1环和2环。RSP3没有的,因为每次三环进零环RSP3是随机的。我们可以查看一下RSP0内核栈,发现全是0

 

图片alt

5.32/64位下的IDT表

大部分情况下,零环代码就用RSP0这个内核栈了。但是少部分情况,有一些特殊的中断比如不可屏蔽中断和双重错误会使用特殊的栈。TSS里那一堆IST其实也是RSP指针,这里保存着特殊的栈指针。光这么说肯定听不懂,我们具体看看64位下的IDT表,
图片alt

 

64位下的IDT表项已经全部从之前的64位变成128位。总结一下,64位下CS和DS仍然是8字节没变,而TSS和IDT变成了128位也就是16字节。由于最新的windows基本废弃了段保护机制,数据段和代码段的基址和偏移已经没有意义了,没必要把8字节的段描述符扩展到16字节,数据/代码段寄存器可以被强制平坦。但TSS和IDT的基址和界限还是有实际意义的,他们不能被强制平坦的,必须扩展到128位基址和偏移才有地方放,才能寻址到全部的地址空间,不然只有8字节肯定放不下那么大的偏移和界限,所以IDT项要16个字节

 

以0号中断为例手工解析一下。

fffff805 45a5b000 : 43168e00-00107100 00000000-fffff805

 

不能用之前解析TSS的方法解析它。按照之前的方法他的基址应该等于00000000 fffff805+43+00+ 0010=fffff80543000010,但IDT的结构和TSS不同,应该是00000000 fffff805+4316+7100=fffff80543167100,我们可以对照一下下图64位的中断门描述符的结构,发现offset的确应该是63..32+31..16+15..0

 

图片alt

 

可以对比一下32位的中断门描述符结构:

 

图片alt

 

(注释:1.64位取消了任务门 2.64位合并了中断门和陷阱门描述符 3.32/64位中断门的差别只有IST和偏移地址)

 

我们再用!idt来验证一下0号中断处理函数的地址是不是刚刚解析出来的那个值

 

图片alt

 

发现0号中断指定的处理函数基址的确是fffff80543167100

 

64位的中断门描述符里有个IST项,他叫IST索引号,这就和我们之前的特殊栈指针联系起来了,如果不指定索引号默认填写0,使用的就是RSP0,但是如果你不喜欢默认的栈,想使用系统分配的特殊的栈,就需要指定了IST,就把那个特殊IST的编号写到这里。

 

下图是之前查看过的TSS。以第0个IDT项43168e00-00107100 00000000-fffff805为例: 里面8e00里的00 就是IST,如果这个位置的数字是0,就用默认的RSP0,栈指针就是下图中fffff80545a5f200。如果这个数是1,内核栈就用IST1,IST1就是下图中的fffff80545a5f3d0,

 

图片alt

 

是2内核栈就用IST2,对应fffff80545a5f5d0。因为大部分IDT项用不到特殊的栈指针,所以大部分IDT表项这里都是0,对应fffff80545a5f200

 

从下图可以看到,01,02,08中断的中断处理函数的栈比较特殊,windbg给我们特殊标了出来,对应idtr项的IST分别是04,03和01,没标出来的IST都是0,即都是用的默认的内核栈。

 

01号是硬件断点的中断,02号中断是系统突然掉电的中断,而8号中断是处理双重错误,就是处理一个异常时又出现异常的处理函数,系统会蓝屏,这些函数都挺特殊,都不用默认的内核栈指针了。

 

图片alt

6.32/64位下的FS和GS

32位系统FS三环时指向TEB,零环时用KPCR,而64位系统三环时用GS指向TEB,零环时GS指向KPCR(之前32位windows下根本没用过GS),也就是说,在64位下不再用FS指向KPCR和TEB,64位下用GS取代了FS,FS则继续留给32位程序继续用

 

和32位的一样,64位IDT表里仍然大量使用中断门描述符,但任务门已经没了,而且调用门和陷阱门windows仍然没有用,虽然windows不使用不代表不能人为构造,但是它这么做的原因是什么呢,这就不得不提到一个中断门独有的优势。

 

中断门有个天然属性,就是执行中断处理函数时,默认是屏蔽掉可屏蔽中断的,比如时钟中断。即相当于在中断处理函数最开始的位置插入了一行汇编指令cli,该指令修改RFLAG寄存器的IF标志位,设置当前函数为不可中断。

 

图片alt

 

如果没有设置中断不可屏蔽行不行,答案是不行的,我们知道一旦进入零环后,32位系统的FS寄存器/64位系统下的GS寄存器,必须要设置指向内核结构体KPCR之后,才能将中断打开,这样线程才能正常调度。

 

以KiBreakpointTrapShadow为例,它是int3的中断处理函数,如果是三环执行到int3,就进入执行该函数(零环执行int3则是直接进入KiBreakpointTrap),设想有如下情景:假如在刚进KiBreakpointTrapShadow没有关闭中断,如果执行到第一行 test [rsp+arg_0], 1 时突然时钟中断来了,并且导致线程切换,切换时一定用到KPCR结构体,但是此时swapgs还没执行到,从IDA可以看出,swapgs指令还在第三行,GS并没有来得及指向正确的KPCR,如果此时切换线程,结果必然是线程切换失败,系统直接崩溃蓝屏。

 

如果微软大量使用陷阱门或调用门,进入中断处理例程后这俩默认是开中断的,虽然GS很快能被修正,但理论上还是能被外部中断打断,所以不太稳定。然而中断门会自动屏蔽rflag标志位的IF中断标志位,这是他的优点,所以操作系统只使用中断门而不使用陷阱门和调用门。

 

既然FS/GS还是需要指向KPCR的,就从侧面说明FS和GS不能被强制平坦,因为如果他俩也被强制平坦,KPCR的基址就没地方保存了。

 

事实也正是如此,但问题是,既然FS和GS没被强制平坦,又没有像TSS一样扩展到128位,那该怎么指向正确的地址空间呢,微软的解决方案是,他给出了三个寄存器,

IA32_FS_BASE C0000100,IA32_GS_BASE C0000101,IA32_KERNEL_GS_BASE C0000102

 

并没把基址保存在FS/GS里而是MSR寄存器里,用这三个寄存器配合rdmsr指令就能读到MSR里FS和GS寄存器的值,换言之FS/GS的偏移被保存到MSR里了。

 

下图中,用rdmsr C0000100来读取内核FS,但在零环里读到不到内核的FS,读出来全是0,只能在用户进程下才能读到。rdmsr C0000101零环下能读到内核GS,也就是KPCR的首地址。我们可以将rdmsr C0000101的返回值解析成kpcr结构体。

 

图片alt

 

总结一下,64位下FS/GS寄存器不保存KPCR的基址和偏移,他们被保存在MSR里,当一个零环线程调度到三环线程时,系统会把MSR寄存器复制到FS寄存器,然后在三环中再用rdmsr C0000100就能读到0环FS寄存器的值。

 

而32位下KPCR的地址是该段选择子对应段描述符的偏移地址,32位下段描述符在GDT表里,但是64位下FS/GS虽然没有被强制平坦但和GDT表没任何关系了。这里纠正一个可能的误区,我们之前一直说段寄存器是8字节的,指的并不是段寄存器总长度,而是段描述符的长度。段寄存器在32/64位下应该都是96位 (这里我自己理解的也不一定对,欢迎吐槽,欢迎指正,热烈欢迎)

 

另外之前XP系统三环进零环是通过push 30 然后 pop fs 来设置FS的,64位下设置FS是通过swapgs,该指令本质上是把MSR中IA32_GS_BASE里的值和MSR里IA32_KERNEL_GS_BASE的值交换了一下。


挖华为终端产品漏洞赢巨额奖金! 注明看雪会员还有额外奖励!!

最后于 2020-8-3 09:28 被amzilun编辑 ,原因:
收藏
点赞4
打赏
分享
最新回复 (9)
雪    币: 963
活跃值: 活跃值 (2870)
能力值: (RANK:260 )
在线值:
发帖
回帖
粉丝
0x2l 活跃值 3 2020-7-23 09:24
2
1
我以前没断网后复现漏洞也是总出问题,后来才发现是windows自动打了补丁
雪    币: 256
活跃值: 活跃值 (161)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
ZwCopyAll 活跃值 2020-7-23 11:18
3
1
64位下 idt变成了128位 idt的寻址方式和以前还一样吗 多余出来的那些位是做什么的
雪    币: 4564
活跃值: 活跃值 (2353)
能力值: ( LV13,RANK:450 )
在线值:
发帖
回帖
粉丝
amzilun 活跃值 4 2020-7-23 11:42
4
0
ZwCopyAll 64位下 idt变成了128位 idt的寻址方式和以前还一样吗 多余出来的那些位是做什么的

对比一下32/64位的中断门,主要的差异就是IST和新增的偏移地址,文章里有说到哦~

最后于 2020-7-23 17:53 被amzilun编辑 ,原因:
雪    币: 201
活跃值: 活跃值 (219)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
cxbcxb 活跃值 2020-7-23 21:49
5
0
收藏了
雪    币: 5190
活跃值: 活跃值 (6301)
能力值: (RANK:65 )
在线值:
发帖
回帖
粉丝
Editor 活跃值 2020-7-28 13:36
7
0
感谢分享!
雪    币: 53
活跃值: 活跃值 (25)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
sshhll 活跃值 2020-7-30 00:31
8
0
感谢分享,mark
雪    币: 325
活跃值: 活跃值 (239)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
牧野鹰扬 活跃值 2020-8-18 22:35
9
0
谢谢分享
雪    币: 125
能力值: ( LV1,RANK:0 )
在线值:
发帖
回帖
粉丝
舒默哦 活跃值 2020-10-22 12:38
10
0
膜拜学习
游客
登录 | 注册 方可回帖
返回