血泪控诉:曝光数月的AMD微代码bug毁掉了我的周末

AMD公司发布的 Ryzen 3000处理器中,存在一项与随机数生成器相关的严重微代码bug。也正是因为这个早已曝光数月却没有得到有效解决的“错误”,本篇文章的主人公 Jim Salter 度过了一个非常糟糕的周末。你能想象,一整天都在跟踪错误的问题,寻找 bug 原因的场景吗?

Ryzen 3000的RDRAND函数(本应成为一款高质量的伪随机数生成器)每次都会返回0xFFFFFFFF,修复过程也是相当煎熬。

上周末,Jim 怀着激动的心情坐在家中的工作间里,在他打算部署自己的第一台 Ryzen 3000工作站时,却遗憾的发现,AMD的一项微代码bug(最初公布于今年7月,但直到现在仍广泛存在于各类系统当中)打破了这美好的幻想。

虽然 Jim 经过努力,让这套 Ryzen 3700X 系统恢复了正常,而且速度也相当惊人,但他不得不承认的是:AMD 的微代码 bug仍然存在,而且现在缺少简单易行的修复方法。

事实上,在 Ryzen 3700X 发布后不久,AMD Ryzen 3000的使用者就已经发现了这款崭新的CPU存在问题:Windows用户无法顺利启动Dstiny 2(原因是存在电源管理bug,不过困扰 Jim 的倒不是这个问题),Linux用户甚至发现自己经常无法正常启动系统。

福布斯杂志作者 Jason Evangelho 在今年7月的文章中报告了初步现象与总结意见,AMD公司的代表则通过电子邮件发出了回复声明:

AMD公司已经确认了引发问题的根本原因,并对BIOS程序进行了修复,旨在解决Ryzen 3000处理器无法运行某些Linux发行版以及Destiny 2的功能问题。我们已经将更新后的BIOS发放给各主板合作伙伴,希望消费者能够在未来几天之内使用到新的BIOS。

AMD的回应乍听起来似乎不错,AMD自己的态度也很乐观,但现实情况却并非如此。因为一旦CPU的微代码中存在bug,就只能由主板供应商发布新的系统BIOS才能实现修复。换句话说,用户并不能简单通过AMD提供的下载链接自行安装修复。

而且AMD方面虽然在今年7月就做出了回复,但截至到目前为止,AMD方面也仅仅只是发送了通知邮件而已。它并没有在其他渠道做出任何的相关提醒,不仅没有新闻稿,而且这封邮件看起来诚意略显不足,仿佛在说这只是一个能够在一两周之内轻松解决的小问题。

现在,已经过去三个月的今天,踩了坑的 Jim 表示:AMD的微代码bug问题非常严重。

从 RDRAND 开始

存在 bug 的代码会对 RDRAND 指令做出错误的响应,而这个 bug 之所以非常严重,则需要从 RDRAND 说起。

事实上,从英特尔的Broadwell以及AMD Zen架构开始,现代x86_64 CPU必须内置高质量的板载随机数生成器(RNG),负责利用热“噪声”快速向具有内核级访问权限的用户提供高熵伪随机数。而RDRAND,正是触发随机数生成的指令。

AMD的整个设计体系本应该非常安全,然而真实的情况却存在一些偏差。

首先是一条CPUID函数调用,用于检查RDRAND的可用性;此外,RDRAND调用的返回值中还包含一条“进位”,该位会在CPU RNG无法生成足够的随机数时通知作为调用方的应用程序。遗憾的是,在安装修复补丁之前,Ryzen 3000会对CPUID 01H调用回应“yes”,并将进位设置为“1”,表明其已经成功创建了有机高质量随机数……同时每一次的“随机”数都被赋值为了0xFFFFFFFF。

只有在足够广泛的数据集当中,连续20个0xFFFFFFFF才可能被视为有效的“随机”分组。但在大多数情况下,我们使用的数据集都没那么广泛。

大家不要尝试使用/dev/hwrng来检查自己的设备是否受到AMD微代码bug的影响,这是因为/dev/hwrng可能会从其他来源获取数据。在Jim的案例中,它倒确实是从RDRAND处获取数据,这让Jim很快就发现了问题。

RDRAND bug的主要影响

今年6月,Ryzen 3000中的RDRAND bug首次被发现时,Linux用户开始大量发布报告,表示自己基于Ryzen 3000的操作系统无法正常启动。而引导失败正是由systemd使用RDRAND引发的;不过遗憾的是,这已经不是systemd第一次与AMD CPU上存在问题的随机数生成器发生冲突了。

早期一批CPU中存在的一项bug,会导致某些AMD系统在从挂起状态恢复至正常工作状态后停止生成正确的“随机”数。而此次发生的新bug,则会导致Ryzen 3000用户全程得不到任何合适的随机数。这两个问题,都导致了systemd在Linux操作系统中被长期锁定。因此今年5月,systemd提交了一项修复程序,如果systemd从RNG得到的返回值为0xFFFFFFFF,则该修复程序会转而使用备用RNG源。(但这种修复方式本身也有问题,因为从技术上讲0xFFFFFFFF是个完全有效的随机数——因此,只要经过足够长的时间,systemd终究会在收到这个哪怕本应正确的随机数时,将其误判为错误状况,而后再直接切换至RNG。)

Systemd的补丁虽然做的很一般,但确实能够让操作系统顺利启动。只是它并不能真正从根本上解决问题,毕竟这种治标不治本的方式压根没有触及到随机数生成器那个层面。

Jim 在自己的系统上,用了一整个周末的时间,跟踪一个个错误问题。这个过程让 Jim非常抓狂。

Jim 首先怀疑问题来自系统上安装的全新RX 590显卡,然后就一次次更新操作系统发行版以及内核版本。但这些更新根本没用。

崭新的系统不断报出一个个讨厌的BUG:软锁定——22项错误彻底卡住了PU#n,并迅速令系统整体陷入瘫痪。/var/log/syslog中的调用信息也没什么指导意义,不过至少让Jim找到了第一条线索。

最终,在经历了一系列尝试、气急败坏的咒骂、无数杯咖啡和几口小酒之后,Jim 终于把CPU的频繁锁定与调用跟踪记录联系了起来。因为 Jim 发现,在每一次跟踪中,都会出现“WireGuard”的身影。

Jim 称:事实证明,WireGuard依靠RDRAND(如果可用)生成新的会话ID。会话ID必须唯一,WireGuard还要求其不是简单的连续整数,因此它会从RDRAND中获取伪随机值,将其与现有会话ID清单进行比较以确保不存在冲突,而后将该ID分配给新会话。

请注意这里的最后一句“确保不存在冲突“,它的意义在于,如果现有会话同新会话拥有相同的ID,则WireGuard会向RDRAND请求另一个“随机”数,并再次检查其唯一性,依此类推。由于系统上的RDRAND(以及任何未经更新的Ryzen 3000系统)始终返回0xFFFFFFFF,因此这个过程就会无限循环。内核代码发生无限循环当然不是什么好事,紧随其后的必然是系统崩溃与硬件重启。

但,问题并不是出在WireGuard身上!WireGuard正确地检查了RDRAND是否可用、是否给出一个值,以及该值是否正确设置了进位。它的责任,就是确保不仅获得了一个值,而且确定该值确实是适当的随机值。然而即使这样,爱岗敬业的WireGuard还是让用户的系统陷入了瘫痪。

现代系统需要高质量的伪随机数来完成众多任务,其中“随机”的含义当然不可能是“始终返回0xFFFFFFFF”。还有另一种直观的候选方法,也就是地址空间布局随机化(ASLR)。Windows与Linux都只采用RDRAND作为随机机制中的一部分,旨在确保永远不会以相同的顺序加载同一段代码,从而减轻相关软件栈遭到破坏的风险。

修复问题,至少是发现问题

正如AMD公司代表在今年7月接受采访时所言,真正的修复手段是对主板进行BIOS更新,同时确保BIOS当中包含针对CPU本体的微代码补丁。然而当 Jim 这样做时,却发现并没有那么简单。

Jim 使用dmidecode程序检查了自己的BIOS,发现日期是2019年8月12日,所以当看到华硕主板下载页面上更新到9月的BIOS时,Jim 非常惊喜。为了尽快结束这糟糕的一天,Jim 选择了立刻下载BIOS更新,并将其保存到U盘当中,重新启动系统,然后进入设置程序,一气呵成。

不过遗憾的是,在成功更新并再次重新启动之后,Jim 突然意识到自己犯了个错误——没错,华硕虽然列出了BIOS的更新日期,但其提供的实际版本与 Jim 之前使用的一样,都是3.2.0。所以Jim 的CPU仍然坚持认为0xFFFFFFFF是随机度最高、质量最好的生成数。

遭遇这一系列事情的 Jim ,火气一下就上来了:systemd虽然悄悄解决了这个bug,但大多数应用程序只是直接忽略,我怎么知道问题到底有没有得到修复?如果两年之后,事实证明ASLR根本无法提供真正的随机数,那我因此遇到的破坏性攻击又由谁来负责?

不过,好在几番冥思苦想后,Jim 突然发现自己完全可以使用Linux上的hexdump工具对内核设备/dev/hwrng进行检查,以证明确实存在这一问题。

但WireGuard项目的Jason Donenfeld却警告称,/dev/hwrng在某些系统上可能从其他来源处获取随机数,换句话说,当看到一大堆FF时肯定能够证明它有问题,但当看到一大堆有效的伪随机数时也不能说明它没有问题。为此,Jason Donenfeld 还慷慨地分享了多种测试程序,能够帮助用户安全地直接访问RDRAND。

如果大家使用的是Linux,可以下载rdrand-test.zip,正常解压,然后在文件夹中直接运行。通过./amd-rdrandbug命令,用户可以查看自己的系统是否存在这一特定bug。./test-rdrand能够输出20条RDRAND取值,如果大家在测试中发现自己总是得到相同的值集,那么无论其看起来是否随机,都表明你已经成为这项bug的受害者!

如果大家使用的是Windows,那还得额外做点工作。首先下载Ubuntu桌面安装程序,然后创建一个Ubuntu启动U盘。接下来,你可以启动Ubuntu启动盘的实时环境(点击「Try Ubuntu」),然后下载并运行以下测试:

you@ubuntu-live:~$ wget https://cdn.arstechnica.net/wp-content/uploads/2019/10/rdrand-test.zip
you@ubuntu-live:~$ unzip rdrand-test.zip 
you@ubuntu-live:~$ cd rdrand-test
you@ubuntu-live:~$ ./amd-rdrand.bug

只有在足够广泛的数据集当中,连续20个0xFFFFFFFF才可能被视为有效的“随机”分组。但在大多数情况下,用户使用的数据集都没那么广泛。

Jim 的总结

经历了这样一个糟糕的周末,Jim 最后总结了自己的收获:

随机数生成器bug是个相当严重的问题,但更加令人不安的是,在过去三个月的时间里,AMD公司并没有就此问题进行积极的努力与强调。虽然总体而言,Ryzen 3000确实是一款出色的CPU平台,新系统也给我留下了深刻的印象……但是,整整一个周末令人头痛的故障排查经历,让我对这套系统的整体安全性产生了严重的怀疑,我甚至不知道这个bug什么时候才能得到修复。

日前,我与AMD公司的代表取得了联系。对方回答了我关于硬件的问题,但没有给出具体解决方案。等有了最新消息,我会及时向大家汇报更新消息。

事件后续

事后,在 Jim 联系AMD就此事进行询问时,AMD的一位代表询问了Jim 的主板型号(Asrock Rack X470D4U),而后又联系了Asrock。Asrock团队提供了已经完成微代码修复的定制BIOS版本,但 Jim 认为这种只适用于个人的BIOS版本没有任何意义。

与此同时,有读者在 Jim 的文章评论区给出了一些别的解决方法及缓解措施,尽管好像并没有什么用。

一种是在引导时将nordrand以参数形式传递给GRUB。这种方法并不能解决问题,因为该方法实际上就是告知内核不要使用RDRAND指令,这往往无法影响该指令自身的实际可用性。指令仍然存在于系统当中,而一切通过CPUID检查RDRAND可用性的代码也仍然会受到影响。类似的random.trust_cpu Linux引导选项也是如此。这些缓解性措施都没能真正禁用RDRAND,因此不能算是问题的理想解决方案。

另一种是安装amd64-microcode软件包。Jim 尝试后表示,结果还是不行。因为在默认情况下,amd64-microcode与intel-microcode软件包被直接安装在Ubuntu 19.10,以及所使用的系统当中,但这并不能解决RDRAND的故障。为此,Jim 再次联系了AMD,要求对方代表检查该软件包的状态并确定是否有必要对其做出更新。

以下是Jim的验证:

目前最新Ubuntu 10.10系统上的amd-64微代码补丁,其仍然无法解决RDRAND的问题。

在设置nordrand或者random-trust_cpu=0之后,rdrand在/proc/cpuinfo下仍显示为可用,因此这两种引导选项均无法真正解决这个问题。

One more thing

截止到本文发布,Jim的文章并没有进一步更新,我们也无从得知他是否已经等到了AMD所承诺的那个“具有真正意义的通用BIOS版本”。

其实,对于某些“极客” 来说,处理器的微代码早已不是什么神秘的东西,它可以被看成是一种处理器固件,从主板的BIOS中进行加载。而主板制造商则可以通过在新的BIOS版本中集成新的处理器微代码,支持新的处理器或是对一些所谓的bug进行修复。

但是真实情况我们也看到了,BIOS的更新并不容易,bug的修复难度也不低。不信,你看看隔壁的英特尔,它也同样正在忙着修补自家的漏洞呢。

原文链接: https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd-microcode-bug-destroyed-my-weekend/#lg=1&slide=1

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/BRebwaBfJ9eP28X9wQQc

扫码关注云+社区

领取腾讯云代金券

玩转腾讯云 有奖征文活动