学习BIOS近三个月了,遇到了不少难缠的问题,特别是最近这个,和操作系统、硬件都有很大关系。但是解bug的过程中学到了不少东西,特别是像windbg,IDA这些工具,以前一直没有机会用,现在都用上了。
问题是这样的,测试那边测试主板时发现使用某些CPU时,在BIOS下开启了过热关机的选项,发现在WinXP下,CPU温度超过了设定的关机温度时,操作系统不能正常关机,而在Win2k下则可以正常关机。导师(当然就是带我入门的前辈啦)让我解这个问题。本来以为问题很简单的,现实查看SuperIO的datasheet,因为系统和CPU的温度都由SuperIO控制器里的Hardware Mornitor或者environment Manager来控制,当然SuperIO芯片集成了很多功能,特别是有些人可能很感兴趣的键盘控制器。但是看了几遍,没有发现这里有什么问题,又用RU.exe比较了正常系统和异常系统下的SuperIO寄存器值,也没发现什么不对劲的地方。试来试去也试不出个所以然来。
想起一个多月前学的ACPI规范,好像里面也有讲有温度监测。于是翻出来看,果然里面说有,大意就是当有Hardware Mornitor会监测CPU温度,当超过某个设定值时,就会向CPU申请SCI(System Control Interrupt)中断(与之对应的是SMI中断,SMI中断会促使CPU进入SMM模式,据说在这个模式下执行的代码拥有比操作系统更高的权限,比ring0还高,不是不是真的,请高手指教),操作系统接到这个中断请求之后,会去执行DSDT里面的_TMP对象来获取CPU温度Tt,再拿这个温度与_CRT对象返回的值Tc(Critical Temperature)相比较, 如果Tt>Tc,操作系统马上就会关机。
这下子总算有点明白了,我第一感觉就是读错了(其实没有仔细考虑),于是又继续苦读ACPI Spec(干这行就是有成山的Spec看不完,这一本就有800多页)。找到了个方法,就是把温度数值抛到 IOport 0x80,然后再用Debug卡去读抛出来的数值。把Dump出来的DSDT修改一下,然后再用Asl.exe导入到注册表里(在这里又要嗦一下,据说有一种rootkit,叫做ACPI rootkit,不知道是不是用ASL语言实现的,但是我用试着在DSDT里写一些代码访问了一下一些敏感部位的内存,发现操作系统禁止了。不知道是为什么)。完了之后重启电脑,操作系统就会去读取注册表里面的DSDT,而不会去读取BIOS里的DSDT了。完了之后发现一个很怪异的情况,就是在操作系统初始化的时候(就是在跑滚动调的时候,不知是不是这么理解),有数据是不断的抛出来的(虽然是一样的数据,Debug卡上的LED会闪烁),等到看到桌面以后,系统停止抛出数据了,用SE.exe手工设置寄存器的值,让CPU温度高于预设的关机温度(当然是假的了),这时候按照datasheet说的,superio控制器会产生SCI中断,操作系统就会去执行_TMP对象,然后就会抛出温度数据(我写的代码就在里面)。这不得不让人抓狂。还是不死心,觉得肯定是某个地方读数据读错了。到网上搜了一下关于ACPI的资料,发现Windbg提供了AMLI工具,专门用来调试ACPI代码的。于是奋斗了一天下午,终于把Windbg双机调试模式弄好了(期间碰到的最大问题是Windbg老是提示没有找到symbol,我明明千辛万苦的下载了最新的symbol,设置好了路径,就是说没有找到。后来设置成然他到symbol服务器上自己去找,它终于很开心的工作起来了)
Ctrl+Break马上让windbg把系统断下来,!amli find _TMP找到_TMP对象的路径\_TZ.THRM._TMP,然后!amli bp \_TZ.THRM._TMP下个断点,然后!amli debugger启动ACPI.sys里内置的调试器。然后g,没有断下来,系统欢快的运行了起来。重启,在系统初始化的时候Ctrl+Break,然后如法炮制下了个断点,等了一会儿,终于断下来了,然后单步了几下,终于发现所有函数都执行得很正常。终于死心了。
没有办法,暂时没有了思路,还是看Spec,ACPI Spec又埋头继续看,终于又有了发现,原来SCI中断是由很多器件共享的(也就是很多器件都会触发SCI中断),器件如果需要触发这个中断,就需要连一根线到南桥的GPEx_STS寄存器的某一位上,GPEx_TST寄存器一共有两组共128位,表示系统接受128中不同的SCI中断。外设需要申请SCI中断的时候,就去置位GPEx_STS寄存器中相应的位,然而,这个中断能不能够传到CPU,还要由GPEx_EN寄存器来决定,GPEx_EN寄存器中相应的位值1,中断信号才能传到CPU。于是猜想是不是GPEx_EN被清零了呢,用SE.exe一看,果然被清零了。这时候更加让人觉得迷惑了,为什么系统初始化的过程中,ACPI中的事件处理程序代码能够被处理呢(这说明GPEx_EN绝对是没有被清零的)。于是在操作系统还没有开始显示滚动条的时候,断下来。Ib 42c(GPEx_EN寄存器组分配在IO空间),果然发现GPEx_EN寄存器组不是零。输入g回车,系统又继续向前行,进入桌面之后,再次读GPEx_EN寄存器,发现已经被清零了(当然这时候外设发出什么SCI中断,系统都是不闻不问了)。换了几个CPU,发现系统正常运行时,GPEx_EN寄存器不是全为零的,而且始终如此。
没有办法,现在就是特别想看看源码,看看系统在开机的过程中究竟做了些什么。找了NT4的源码,发现NT4没有实现ACPI,又看了WIN2K的源码(其实只是部分),发现泄露出来那部分里面没有ACPI子系统。WRK就更加没有了。听说ReactOS完全仿照windows,于是去下载了ReactOS的源码,发现ACPI部分的代码怎么就那么向linux内核的源码呢?(以前曾经看过N本linux内核分析,不过都是水过鸭背,一点不留,不过代码的形状却是记得的)
不如看看linux下面是怎么实现的。看linux内核源码,网上推荐说用sourceInsight,下下来用了一下,发现真的相当不错。看了linux里面的SCI中断处理例程acpi_ev_sci_xrupt_handler发现里面的处理流程非常简单,就是看看传进来的事件是fixed event还是general perpose event,如果是前者,就直接执行处程序,如果是后者,就直接把任务查到任务队列里,由内核工作线程去执行,内核线程再执行任务结构里的回调函数。要出问题,也就出在回调函数里,不过回调函数头绪很多,不想一一查看了,况且两个操作系统的实现也可能不一样。
又回到windows下,再看看windows internal 4th,在windbg下,断下系统,!idt查看系统的中断处理函数,赫然发现ACPI!ACPIInterruptServiceRoutine,这是我要找的吗?Bp ACPI!ACPIInterruptServiceRoutine下了个断点,g然后就断下来了。函数还挺长0x328个字节(在本菜鸟看来)。不厌其烦的在正常的和异常的系统上各跟了几遍,看不出个所以然来,只是发现这个例程执行完之后,io口0x42c就被清零了。函数里面跳转很多,依赖的莫名其妙的结构也很多。但是路貌似只有这一条了,只有把它仔细的理清了,才能知道问题究竟在不在这里。终于下定决心把它仔细读完,并且翻译成C代码,其中的数据结构也练猜带蒙的蒙出来了,最后的结论是,问题不在这里。这个例程例行公事的做一下PM Timer的累计,然后看看有没有GPE事件,如果有的话就将GPEx_EN清零(意思是,处理中断期间,不再接受中断),然后将任务KeInsertQueueDpc查到任务队列里,再由ACPI!ACPIInterruptDispatchEventDpc例程进行分派。于是 u ACPI!ACPIInterruptDispatchEventDpc L150 看一看,又是数不清的调转和未知的数据结构。看来得试一试IDA了,IDA之前没有用过多少,最多就是看看它画出来的流程图。网上查了一下,发现有人在讨论他的F5功能,然后发现是一个插件,可以将二进制逆成C代码,很高兴,于是装上插件,找ACPI!ACPIInterruptDispatchEventDpc这个函数还真难找,于是想了一个笨办法,在windbg里面得到函数的长度,然后再去IDA里面找,果然快很多。找到以后,F5一下,果然爽的很。虽然出来的代码还是很难懂,但是比汇编已经好很多了,配合windbg里面提供的符号,很快弄清楚了这个函数的流程。注意到寄存器是不是被清零,和ACPI!GpeIsLevel这个数组有很大关系。
于是重启系统,还是在没有出现滚动条之前将系统断下来,然后ba w 4 ACPI!GpeIsLevel下一个硬件断点,看看究竟是什么东西修改了ACPI!GpeIsLevel这个数组。一下子断到了ACPI!ACPICallBackLoad。kb一下看看栈回溯,里面的函数都是巨长无比。还是先g一下看看吧。一共断了9次,每次断下来,都看一看ACPI!GpeIsLevel,发现了一些有意思的事情。
ACPI!GpeIsLevel每断两次,被清零和重建各一次,最后到第9次的时候,被清零了。第10次没有来,ACPI!GpeIsLevel没有被恢复。在正常的系统上,下同样的断点,只断下来两次,ACPI!GpeIsLevel被清零和重建各一次。Kb看一下栈回溯,终于发现有意思的事情,在异常的系统上,最后三次断下来的时候,栈回溯里面有些函数包含在名叫intelppm的模块里,系统正常运行的时候,就不会出现这些函数。Google一下intelppm,发现都是一些蓝屏死机的内容,问题很可能就是这个模块引起的。命令行下Sc config intelppm start= disabled,将这个服务关掉,一切都正常了。
那么intelppm究竟是什么呢,它是微软为intel的CPU写的CPU电源管理模块。CPU进入IDLE状态时,为了节省CPU功耗,CPU会进入C1或者C2、C3状态,其中C1进入状态就是用一条HLT指令实现的。
问题到了这里,依然没有彻底弄明白究竟是谁的错,秘密应该就藏在intelppm.Sys里面,可惜我太菜了,没有能力再深入追究下去了,希望高手们能支点招。但是这次确实是大大的练了一次手,Windbg和IDA玩了一把,操作系统的一些工作方式也有所了解了。
- 标 题:新手练解bug
- 作 者:qdk
- 时 间:2008-11-22 00:15:51
- 链 接:http://bbs.pediy.com/showthread.php?t=77198