intel spectre microcode引起的启动变慢及解决方案

有段时间没有光顾博客了，年后工作内容饱满，各种各样的事情，忙得不亦乐乎。

今天有点时间，就写一下其中一个bug的解决吧，也算记录一下一个程序员日常工作的点滴。另外也让人们看看intel的漏洞给我们程序员带来多大的麻烦。

这篇文章我想尽量写的非技术化，我想让围墙外的人们也了解一下程序员的工作。也许儿子长大了做的是和计算机无关的工作，他看到这篇文章也许会说：‘哦，爸爸每天就是做这些啊，真没劲’。

都知道intel的补丁会拖累系统的性能，离奇的是最近报的一个bug中显示OVM3.4打上microcode补丁后启动时间延长了两分半，这是客户不能接受的！

而且这个问题只在公司的几台大的服务器上可以重现，本人的两台小dell pc就一边去吧，而这也给解决问题增加了难度。

这个bug早在年前就被客户提出来了，由于调试环境的缺乏一直悬在那里。最近借来一台机器赶紧开整。

对于启动问题，kdump派不上用场，唯一可以依赖的就是启动时打印的那段log，可以看到有一段间隔有大概200s的时间。

(XEN) [2018-03-16 04:33:19] Dom0 has maximum 20 VCPUs
(XEN) [2018-03-16 04:33:19] ELF: phdr 0 at 0xffffffff81000000 -> 0xffffffff81ac8                                           000
(XEN) [2018-03-16 04:33:19] ELF: phdr 1 at 0xffffffff81ac8000 -> 0xffffffff81c53                                           000
(XEN) [2018-03-16 04:33:19] ELF: phdr 2 at 0xffffffff81c53000 -> 0xffffffff81c6c                                           318
(XEN) [2018-03-16 04:33:19] ELF: phdr 3 at 0xffffffff81c6d000 -> 0xffffffff81e4e                                           000
(XEN) [2018-03-16 04:36:42] [VT-D]iommu.c:1555: d0:unknown(0): 0000:7f:0e.2

 

通过测试发现这段间隔在用旧的XEN跑也得花费50s左右的时间。分析比对代码发现是construct_dom0这个庞然大物。因为dom0有11GB之多，构造这么大的guest花50s也不算多，所以这不是construct_dom0本身的问题。

那是什么原因呢，继续看代码，调试，看代码。。。。此处略去十万字。

阳光总在风雨后，工作这么多年来我发现一个现象，在一个bug调试很久都没有结果的时候总是会有一个转机出现。 这次这个转机来的还算快，就是加上参数“bti=ibrs=0”以后启动速度正常了。但是这把ibrs的功能都禁掉了，客户的系统还会暴露在Spectre2的攻击威胁之下。

还得继续看代码，但是只需要看Spectre相关的代码了，主要是x86汇编中中断，异常和nmi部分的入口和出口代码。还真让我发现了一个代码的bug，我们用的一个比较指令永远会跳转，IBRS不会关掉，而这在若干人若干次的review中居然没有发现包括我，然后居然被提交了，而且在海量测试中竟没有触发panic。

我仿佛看到了一丝曙光，期待着就此修复这个问题，修改后的测试结果给我泼了一盆冷水，问题照旧！

进一步的分析发现启动阶段还是得关掉IBRS，让启动代码跑在全速的环境下。过程不表，加上新的修改后客户表示happy了。

到此故事还没有完，

patch发到社区，维护者提了若干意见，还在继续沟通中。

那边紧急来电，2.6.18内核Spectre补丁有点问题，请速去救援。。。