我调过的难调的Bug

　　冷启动攻击
　　为获取环形缓冲区的数据，我进行了一次冷启动攻击。我为正在使用的主板搞到了一份概要拷贝，然后发现CPU的复位线上连了一块不受欢迎的板子。我把它短路了，重置CPU而不妨碍DRAM的完整性。然后，我把Boot挂载在引导程序上。
　　在引导程序里，我dump到了问题中环形缓冲区的内容。谢天谢地，这个缓存总是在一个固定的物理地址上被定位到，所以找到它不是问题了。
　　通过分析错误时间戳周边的环形缓冲区，我们发现了两个老的cache line。这两个cache line里有有效数据，但是在这两个cache line里的时间戳却是环形缓冲区里之前的时间。
　　导致CPU0上未定义指令的cache line与环形缓冲区里那两个老cache line之一相当契合，但是这并不说明其他可能的地方也是这样。我发现一个决定性的证据。假设，另一个消失的cache line是导致CPU1上未处理内核错误的元凶。
　　错置的cache line
　　cache line应该被写入0x0ebd2bc0（环形缓冲区里的cache line），但是事实上却写入了0x0018abc0（冲突的内核码）。这些地址在我们CPU上属于相同的缓存，它们的位[14:5]的值是相同的。不知为何它们有别名。
　　bit   28   24   20   16   12    8    4    0
　　|    |    |    |    |    |    |    |
　　0x0ebd2bc0 in binary is 0000 1110 1011 1101 0010 1011 1100 0000
　　0x0018abc0 in binary is 0000 0000 0001 1000 1010 1011 1100 0000
　　一个地址的低5位是cache line(32字节cache line)里的索引。后10位，即位[14:5]，表示缓存集。剩下的17位，即位[31:15]，用来表示缓存里当前存的是哪个cache line.
　　我向我们的CPU供应商提交了一个bug报告，之后他们制定了一个解决方案，并在下一版本CPU里修复了这个bug。
　　我期望听到更多牛掰的此类故事，也期望我自己可以再攒点这样的。